構造化データとは？種類、メリット、テストツール他、幅広く解説！

構造化データとは、（たとえばコンテンツのなかに「動画」があるなど）Webページの内容を検索エンジンにより分かりやすく伝えるためのデータ形式（専門のソースコード）のことです。HTML上で直接マークアップする方法はもちろん、イベントや商品、レストランなど一部のタイプに関しては手っ取り早く「データ ハイライター」を用いてタグ付けすることもできます。

SEO対策の一つの手段であり、アクセス数アップが期待できる要素として、決して無視できない大事な要素です。

そうしたなか、構造化データの役割について、実はよく分かっていない方も少なからずいらっしゃると思います。

そこで本記事では、構造化データについて、基本的な情報や仕組みを解説します。種類に加え、メリット、具体的な記述方法、問題なく反映されているか確認するテストツールにも言及します。

そうこう、おさえておきたいポイントにまんべんなくアプローチする内容です。

ぜひ参考にしてください。

構造化データとは？周縁知識とあわせて紹介

構造化データとは、繰り返しお伝えしますが、端的に述べると、検索エンジンがWebページの内容を理解しやすくなるデータ形式のことです。場合によってはその情報をユーザーがアクセスしやすいよう検索結果に表示してもらえることもあります。

本章では構造化データをより深く知るうえで、大事な周縁知識や背景とあわせて特徴を説明。いずれも基本です。確実におさえておきましょう。

検索エンジンについて

構造化データが検索エンジンの理解を促進するのに欠かせない要素であることはお分かりになったかと思います。

そもそも検索エンジンとは何でしょう？

一言で、普段私たちが使っているGoogleやYahoo！などの検索サービスです。

インターネットで疑問に感じたことを調べるため、検索窓にキーワードを入力すると関連したサイトが一覧で表示されます。これは検索エンジンのプログラムによるものです。当然、そこでの掲載順位が高いと、ユーザーの目に留まりやすくなり、アクセス数が増える傾向にあります。そのため、ホームページの運営者は特定のキーワードで上位表示を目指すべく、さまざまな施策に取り組むのが一般的です。俗にSEO対策と呼ばれます。

構造化データは、先述したとおり、基本は検索エンジンに向けたものです。ホームページを構成する各要素が何を指しているのか適切に伝えることで、結果的に、SEOにおいても効果を発揮します。

セマンティックWebについて

従来の検索エンジンは、ホームページに記載されているテキストをただの文字列として認識しているだけでした。つまり、文字の意味や文脈をしっかり理解できてはいなかったのです。無論、その後は今に至り進化を遂げることになります。そして、その発展のプロセスのなかで重要だったのがセマンティックWebです。これは「適切にWeb上のデータを把握できるようにしていこう」という実にシンプルな考え方に基づきます。

たとえば、コーポレートサイトでは、会社情報を記載するにあたって会社名や住所、電話番号など、基本項目それぞれが指すもの、意味をきっちり認識できるようになります。では、なぜ検索エンジンはそれらの情報を判断できるようになったのか。ここで構造化データの働きが浮かび上がるのです。

構造化データの詳細な定義と特徴

構造化データは、より細かく定義づけるならば、ずばりセマンティックWebを実現するためにHTMLの情報をより正確に理解できるようにしたものです。同じく先述したとおり、従来のテキスト情報に意味を持たせて、検索エンジンで有益な検索結果を提供できるようにする役割も持っています。

たとえば、「名前：新宿太郎」「生年月日：1980年1月1日」というテキストがあったとします。いうまでもなく、私たちはこの文字や言葉から情報（名前と生年月日）を受け取ることが可能です。しかし、過去の検索エンジンではただの文字列にすぎないものでした。そこには情報など存在しないといわんばかりに……。

しかし、構造化データの登場によって、検索エンジンと意味を共有することが可能になりました。その機能は着実に拡張し、現在では、伝えられる情報の精度は格段に上がっています。

構造化データの種類

構造化データの種類は要素ごとにさまざまです。

具体的には「ボキャブラリー」「シンタックス」「構造化タグ」の3点からそれぞれ主なタイプが存在します。

混同しやすいのがリッチリザルトの種類です。

本章では、あくまで構造化データの代表的な種類について紹介します。

ボキャブラリーとシンタックス

構造化データの種類を理解するうえで「ボキャブラリー」と「シンタックス」の言葉は覚えておきましょう。前者は、構造化データを設定する際の、情報を定義する規格です。名前なら「name」で住所なら「address」などが該当します。

他方、後者はマークアップの“仕様”です。主なタイプとして「Microdata」と「RDFa Lite」と「JSON-LD」が挙げられます。

構造化タグ

構造化タグについてまず知っておきたいのが「section」です。

これは、見出しと本文、その他の情報で構成されています。文章のまとまりを示すタグです。

「article」は記事であることを示すのに使います。

あわせて著者情報を伝えるには「author」プロパティのマークアップが必要です。

続けて「aside」はサイドバーで利用します。補足情報を示すときに使うのが一般的です。

「nav」はパンくずリストやグローバルナビゲーションなどで用います。

「header」はナビゲーションの補助やヘッダーを表すものです。

「footer」はフッターであることを示します。加えて、コンテンツの作成者や著作権に関する記述を含めるのも常用手段です。

以上、こうしたタグの活用が、検索エンジン側の認識・理解を助けてくれます。

「author」プロパティをマークアップする際のベストプラクティス

Google は、記事構造化データに関して技術ドキュメントに情報を追加しています。内容は、そのコンテンツの著者を伝えるために必要な「author」プロパティのマークアップにおけるベストプラクティスです。

以下、列挙します。

• すべての著者をマークアップに含める
• 複数の著者を明記する
• 追加のフィールドを使用する
• 「author.name」プロパティには著者の名前だけを記述する
• 適切なタイプを使用する

構造化データの主なメリット

構造化データの役割自体がすでにメリットに当たりますが、あらためて以下、挙げていきます。ぜひ、ホームページの運用に生かしてみてください。

検索エンジンに対するコンテンツの理解促進

再三述べている通り、構造化データは特定のテキストや画像の意味・文脈に対する検索エンジンの理解を助けます。制作したホームページの情報を正しく判断してもらえれば、ユーザーにも意図した内容を届けられます。

リッチリザルトでクリック促進

通常の検索結果（スニペット）では、ホームページのタイトルとその説明文だけが表示されます。しかし、構造化データを用いると「パンくずリスト」「レビュー」「FAQ」などサイトの内容を補完するように詳細の一部をさらに表示してくれるのです。先述したリッチリザルトの種類がまさしくこれに該当します。視認性が高く、通常に比べてクリックされる期待が持てるはずです。

ナレッジグラフにサイト情報が表示されやすい

ナレッジグラフとは、特定のワードで検索した際、検索ブラウザの右側に掲載されるパネル機能です。情報が大きく表示されるため、ユーザーとの接点が一気に近づきます。構造化データを駆使することで、検索エンジンから有益だと判断されれば、この枠に入る可能性は高まるでしょう。結果、クリック率の向上にもつながりやすくなります。

構造化データをHTMLに直接マークアップする方法

構造化データをHTMLに直接マークアップする場合、大きく分けると3つの方法、仕様があります。それらはずばり、先述したシンタックスです。

というわけで本章では、schema.orgによって定められ、Googleがサポートしているシンタックス、すなわち「Microdata」「RDFa Lite」「JSON-LD」について、具体的な記述例とあわせてご紹介します。

Microdataの場合

headタグ要素以外でも、metaやlink要素を使って記述できる点や、精度の高いHTML5 の構文に違反しないことがメリットとして挙げられるMicrodataですが、主には「itemscope」「itemtype」「itemprop」がプロパティとして使われています。

Microdataの記述例です。

<div itemscope>
  <p>私の名前は<span itemprop="name">新宿花子</span>です。</p>
</div>

1行目、divの開始タグ内にitemscope属性がついています。そして、終了タグである</div>

のあいだにはitempropでのプロパティが記述されています。

Microdataのメタデータの本体は、ルールとしてプロパティ名である「name」、値の「新宿花子」がペアです。

このマークアップによって、新宿花子という文字列がnameであることを検索エンジンに伝えられます。

なお、itemtype は次のように使われます。

<section itemscope itemtype="http://schema.org/Person" >

この場合、人物の情報を定義づける役割が果たされます。

RDFa Liteの場合

Microdataとマークアップ方法の近いシンタックスです。
W3Cによって規格化された形式で、「HTML5」や「XHTML」など幅広い言語で使用できます。
HTMLのソースコードで該当する箇所の近くに、構造化データを記述する点もMicrodata同様です。更新こそ面倒ですが、変更漏れは回避しやすいと考えます。

RDFa Liteの記述例です。

<div vocab="http://schema.org/" typeof="Corporation" >
<span property="name">サングローブ株式会社</span>
<span property="address" typeof="PostalAddress">
<span property="postalCode">160-0023</span>
<span property="addressRegion">東京都</span>
<span property="addressLocality">新宿区</span>
<span property="streetAddress">西新宿6-24-1 西新宿三井ビルディング4F</span>
</div>

各属性について、vocabは規格の定義（上記の場合、schema.org）、タイプ名はtypeofを用います（上記の場合、指定は会社を示すCorporation、郵便番号と顧客バーコードデータを示すPostalAddress）。そして、propertyには該当する内容が入ります。

JSON-LDの場合

JSON-LDはheadタグ要素内が一般的とはいえ、HTML内のどこでも記述可能です。データを1箇所にまとめられることができ、記述量も少なく、シンプルで分かりやすい点が特徴に挙げられます。

JSON-LDの記述例

<script type="application/ld+json">
{
    "@context" : "http://schema.org/",
    "@type":"Thing",
    "name":"商品名",
    "description":"商品の説明",
    "image":"画像のURL"
}
</script>

@contextで規格の定義（上記の場合、schema.org）、@typeでタイプが指定（上記の場合、schema.org）されます。
コンテンツの変更の際には、JSON-LDの調整も必須です。忘れないように注意しましょう。

構造化データに関するルールやマナー

本章では、構造化データに関するおさえておくべきルールやマナーについて述べます。

商品の構造化データは単一ページのみ

商品に対する構造化データについて、マークアップは単一ページのみ可能です。この点は、Googleのガイドラインでも指摘されています。そのため、商品一覧のページではなく、詳細ページで構造化データを記述するようにしてください。
なお、画像については、リッチリザルトを考慮するならば、プロパティに「image」を含めることが必要です。

レシピの構造化データにカロリーは決して必須ではない

以前、料理のレシピなどでカロリーを表示すると、ランキングに影響をもたらすとの噂がありました。しかし、実際のところカロリーは必須プロパティではなく、ランキングにも左右しません。あくまで検索エンジンにとって、要素が多ければその分、構造化データがコンテンツの理解に役立つという話です。これは、ユーザーにとっても当てはまります。カロリーを気にされる方は、一定数いらっしゃるはずです。そう考えれば（有益な情報を提供するなら）、表示させることに越したことはないでしょう。

複数のアイテムをマークアップする時の注意点

「レシピの画像」と「レシピの動画」を、別々にマークアップしたとします。そうすると、Google はそれぞれを独立した構造化データと認識するかもしれません。
そこで、防止策が必要です。おすすめは、「@id」のプロパティでの関連付け。1つのページで複数のアイテムをマークアップする場合、「@id」を使用し、指定する名前を統一することで、対象の画像、動画を紐づけ関連性のあるものと判断してくれます。

構造化データに関する疑問とGoogle社員の回答

構造化データについての疑問・質問の声が多いなか、以前、Google社員がまとめて回答していたことがありました。本章では、いくつかその趣旨を抜粋します。

ページ間の参照をGoogleは認識するの？

同一ページであれば、マークアップを関連付けることはよくあります。しかし、別々のページではそれほど多くありません。必要性があまり無いからです。それでも別々のページで関連付けを行いたいなら「@id」で統一をすればGoogleは認識してくれます。

ただし、テストツールでは反映されないため気をつけてください。

同じ内容に言及しているエンティティを同一視させるには？

エンティティとはWebサイトの実体性を伝える多くの要素のこと指します。具体的には運営者、電話番号、企業名などです。これらをマークアップする際は、同じ様式にしてください。なぜなら、Google は一貫性を好むからです。

リッチリザルトの表示以外でも役に立つ？

構造化データは、リッチリザルトだけで利用するわけではありません。そのページの内容を検索エンジンが理解できるようにすることが基本です。そのため、関連性があるなら、積極的に構造化データを用いることをおすすめします。結果的に、関連性の高い検索クエリからのトラフィックが増えるかもしれません。

リッチリザルトは2ページ目以降も出てくるの？

通常であれば、リッチリザルトは1ページ目だけに表示されるのが基本です。しかし、Googleの方でテストが行われている場合、2ページ目以降も出てくることがあるかもしれません。

構造化データにエラーがないか確認できるテストツール

本章では構造化データのテストツールについて言及します。

その変遷と随時更新される情報をあわせてご確認ください。

「構造化データ テストツール」と「リッチリザルト テスト」

構造化データを記述するにあたって、検索エンジンが認識しているかどうかは、テストツールで確認できます。

代表格は、やはり「構造化データ テストツール」でしょう。エラーが一目でわかるなど手軽で使いやすい点が人気を博しています（現在は後述する「スキーマ マークアップ検証ツール」に取って代わっています）。

方や、リッチリザルトの構造化データでお馴染みのツールは「リッチリザルト テスト」です。実際の Googlebot のレンダリングと同じ処理であったり、レンダリング後の HTML コードの確認であったり、プレビュー表示や加えて、モバイル・PC 両方のユーザーを識別したうえでの検証を可能にするなど機能の充実面が光ります。

「構造化データ テストツール」の存続が決定！

2020年10月（本記事の公開）時、「構造化データ テストツール」の提供は終了することが発表されていました。しかし、うって変わって12月、今後も存続することが決定します。

仮に件のツールが無くなったとして、構造化データの検証が全くできなくなるわけではありませんでした。そう、リッチリザルトとしてサポートするものに限っては確認可能。ただ、それであれば「リッチリザルト テスト」で事足ります。

schema.orgの仕様に準拠しているかどうかを純粋に検証できる「構造化データ テストツール」の有用性は、皮肉なことに終了のアナウンスによって再認識されることとなりました。終わってほしくないという声が多く寄せられていたのも納得です。

そうした背景もあってか、Googleはschema.orgが管理するツールとして「構造化データ テストツール」を残す決断をします。ドメインも移行。まさしく英断です。
リッチリザルトの検証は行わず、あくまでschema.orgの仕様に対しての検査ツールになりますが、（schema.orgに）新たなタイプが加われば、当然それらもチェックできます。実際、Webストーリーのようなビジュアルコンテンツを表現する「AmpStory」など新タイプやプロパティにも対応可能です。

「Schema Markup Validator」のβ版が公開！

当初予定されていた通り、schema.orgの所有物として「構造化データ テストツール」の後継（β版）が公開されました。
そう、「Schema Markup Validator」です。※なお、“Structured Data Testing Tool”が「構造化データ テストツール」と呼ばれるように、国内で定着する名称は変わってくると考えます。

使い方は従来のツールと同様で、URL もしくはコード入力で検証できます。
ユーザーインターフェースも同じであるため、操作に困ることはなさそうです。
違いを述べるならば、チェック機能でしょうか。
プロパティの値の形式は問われません。検証対象は、あくまで文法的に正しいか否かです（たとえば記事の公開日を表す 「datePublished」のプロパティで日時形式ではない文字列を記述してもエラーや警告は出ません）。
ただし、正式版としてローンチされるまでに改変される可能性はあります。

いずれにせよ、「構造化データ テストツール」存続決定から代替ツールの公開まで順調に進行していることは、ポジティブに捉えることのできるニュースといえるでしょう。

「リッチリザルト テスト」と「スキーマ マークアップ検証ツール」

前項で紹介した通り、構造化データのテストツールは、schema.orgの運用管理下で2021年5月に「Schema Markup Validator（以下スキーマ マークアップ検証ツールで統一）」が後継として公開されましたが、 現在、構造化データのテストツールとして位置づけられているのは、「リッチリザルト テスト」と「スキーマ マークアップ検証ツール」の2種1組のセットです（構造化データテストツールにアクセスすると、この2つのツールを紹介するページにリダイレクトされます）。

文字通りリッチリザルトのためのテストツールが「リッチリザルト テスト」ですが、検証対応外の要素に関しては、「スキーマ マークアップ検証ツール」を使うことになります。こうした使い分け、あるいは併用が望ましいというわけです。

おさらいも兼ねてですが、「リッチリザルト テスト」だけでも使える機能は少なくありません。たとえば、スマートフォン用とパソコン用のGooglebotを切り替えられます。また、レンダリング後のHTMLコードやスクリーンショットの取得が可能です。加えて、前回のクロール情報なども表示されます。

一方で「スキーマ マークアップ検証ツール」は、schema.org が定義しているすべての構造化データを検証できます。と、プロパティの値の正当性をチェックしない点も変わりません。引き続き念頭に置くようにしましょう。

Googleのエンジニアが語った構造化データの未来

構造化データ関連の機能開発を担当しているソフトウェアエンジニアの Ryan Levering（ライアン・レブリング）氏が、自身がゲストで招かれたポッドキャストで配信されている「Search Off The Record」のエピソード 35で長期的に考える構造化データの展望を、次のように語っていました。

内部グラフの解釈に構造化データが本当に重要な役割を果たすだろう。機械学習がさらに関わってくると思う。ページのすべての情報を構造化データで必ず伝えるというよりも、構造化データで特定したルートを通してもっと多くのデータを調整していきたい。

Search Off the Record: Structured data: What’s it all about?

さらには、人間を介さず、CMS やプラグインが必要な構造化データを自動的に実装するのが理想だとも考えているようです。

なお、中期的には「構造化データを使ったより多くの機能の提供」「視覚的な機能にとらわれないページの理解」「多くの機能で構造化データを普遍的に使う」といった考えも明らかにしています。

そう遠くない将来、Googleは新たな仕組みを提供してくれるのでしょうか。

構造化データがどのように進化していくか、今後も要チェックです。

ホームページ制作の際は、構造化データをうまく活用しよう！

構造化データはホームページ運営者とユーザーの双方にとって便利な機能です。

拙稿にて何度も繰り返してきましたが、構造化データを利用すれば、検索エンジンに対してページの情報を意図したとおりに伝えることができます。また、リッチリザルトが表示されることで、ユーザーをスムーズに自社のホームページへと誘導しやすくなります。結果、クリック率向上に寄与する期待は十分に持てるでしょう。

注意点もありますが、使わない手は無いはずです。

ホームページ制作の際は、ぜひうまく活用してみてください。