構造化データとは？SEO初心者が知っておきたい役割と使いどころ
SEOの設定を調べていると、「構造化データを入れた方がよい」という説明を見かけます。
ただ、コードの例だけを見せられても、何のために使うのか、どのページへ入れるのかは分かりにくいものです。
構造化データとは、そのページが何のページで、どんな情報を載せているかを、決められた形式で検索エンジンへ伝える補助情報です。
正しく設定しておくと、検索エンジンはページの内容を読み取りやすくなります。
ただし、構造化データは、検索順位が上がることや、検索結果に特別な形で表示されることを保証する仕組みではありません。
画面に表示していない価格や評価を、構造化データにだけ書き足してはいけません。
この記事では、構造化データの役割、使うページの選び方、検索結果の表示についての注意点、設定と更新の確認手順を、はじめての方向けに説明します。
Googleの対応範囲やテスト方法は、2026年10月27日に確認した公式情報をもとにしています。
目次
1. 構造化データは内容を機械へ伝える補助情報
構造化データは、ページに載っている情報を決まった形式で書き出したものです。
そうしておくと、どれが何を表す情報なのかをコンピューターが区別できます。
たとえば商品ページなら、どれが商品名で、どれが価格や在庫かを示せます。
ブログ記事なら、タイトル、書いた人、公開日、更新日、使っている画像を示せます。
Googleも構造化データに関する公式資料で、ページの情報を提供し、内容を分類するために標準化されたデータ形式だと説明しています。
構造化データは、多くの場合、ページのHTML(Webページを組み立てているコード)の中へ書き加えます。
Google検索は、JSON-LD、microdata、RDFaという三つの書き方に対応しています。
このうちJSON-LDは、本文とは別に、専用の記述をページ内へまとめて置く書き方です。
Googleは、サイトの設定で選べるならJSON-LDを使うことをすすめています。
とはいえ、はじめての方がコードを一から書く必要はありません。
CMS(記事や商品をブラウザ上で管理する仕組み)のテーマや拡張機能が、構造化データを自動で出力していることもあります。
そのため、新しく書き足す前に、自分のサイトが今どんな構造化データを出しているかを確かめます。
確認のしかたは、あとの「4. 実装と確認の基本手順」にあります。
構造化データは人が読む本文の代わりではなく、本文に書いてある情報の意味をコンピューターへ補足するものです。
画面に必要な説明を書かないまま構造化データだけを増やしても、読者の役に立つページにはなりません。
順番としては、本文、商品情報、会社情報を正確に書くのが先です。
構造化データに書けるのは、そこに書いた内容と一致するものだけです。
2. どんなページで使われるか
構造化データには種類があります。
種類や項目の名前には主にSchema.orgという共通の定義が使われますが、そこで定義されたものすべてがGoogleのリッチリザルトに対応しているわけではありません。
ページの内容に合う種類だけを選んで使います。
よく使われる種類は、次のとおりです。
ページや情報 | 主な種類 | 伝えられる情報の例 |
|---|---|---|
個別の商品ページ |
| 商品名、価格、在庫、評価など |
ブログ・ニュース記事 |
| タイトル、作成者、公開日、更新日、画像など |
トップページ・会社情報 |
| 組織名、URL、ロゴ、連絡先など |
パンくず(ページの階層) |
| サイト内で今見ているページへ至る経路 |
Googleの検索機能ごとに、対象ページ、必須項目の有無、推奨項目、画像や内容の条件が違います。
設定に入る前に、Google検索がサポートする構造化データの一覧を開きます。
この一覧は、自分のページに当てはまる機能から、その機能の個別ガイドへたどれる作りです。
たとえば記事の構造化データは、ブログやニュースなどの記事ページへ使います。
Googleは記事の構造化データの公式資料で、作成者、日付、見出し、画像など、読み取る情報を案内しています。
このArticleには必須項目はなく、記事に当てはまる推奨項目を正確に記述する考え方です。
組織の情報は、サイトのすべてのページへ同じ内容を重ねて入れる必要はありません。
Googleも組織の構造化データの公式資料で、トップページや会社情報ページなど、組織を説明している一つのページへ置けばよいと案内しています。
そのうえで、自分の組織にいちばん近い種類を選び、実際に当てはまる情報だけを書くようすすめています。
ページの内容と関係のない種類を選んではいけません。
たとえば、ふつうの記事をレシピとして扱うなど、内容と違う種類を使うのは避けます。
なお、Schema.orgのProductの定義はサービスも含みますが、Googleでどの表示の対象になるかは、目的の検索機能の個別ガイドで確かめます。
検索結果の見た目を狙って意味の違う種類を使うと、読者にも検索エンジンにも誤解を与えてしまいます。
商品ページで使う場合は、構造化データだけでなく、商品ページのSEOチェックで本文の商品名・説明・画像も合わせて見直せます。
3. 検索結果の特別表示は保証されない
リッチリザルトとは、画像、価格、評価などの追加情報が付いた検索結果の表示です。
通常の青いリンクと説明文だけの表示に比べて、目に入る情報が増えます。
ただし、構造化データを正しく設定しても、リッチリザルトが表示されるとは限りません。
Googleも構造化データに関する一般ガイドラインで、リッチリザルトテストに沿って正しく記述しても、検索結果に表示されない場合があると説明しています。
表示されない理由には、次のようなものがあります。
- ページの主な内容と構造化データが一致していない
- 画面に表示していない情報を構造化データに書いている
- 必ず書く項目や、その種類ごとのガイドラインを満たしていない
- Googleがそのページへアクセスできない
- 検索する人や状況によっては、別の表示のほうが適切だとGoogleが判断する
- テストツールでは分からない品質上の問題がページに残っている
一つでも当てはまると、書き方が正しくてもリッチリザルトの対象にならないことがあります。
構造化データは検索順位やリッチリザルトを保証する施策ではありません。「入れれば必ず目立つ表示になる」という説明は、そのまま受け取らないようにします。
設定が正しいかどうかを知るうえで、テストでエラーが出ないかの確認は大切です。
ただし、テストで検出できる問題には限りがあります。
本文の内容がよいか、読者が検索した目的に合っているか、サイトが信頼できるかまでは分かりません。
構造化データを入れる前に、ページの本文、タイトル、画像、価格、在庫、会社情報が正確かどうかを確かめます。
設定したあとも通常の検索結果しか表示されない場合を想定し、タイトルと本文だけで内容が伝わる状態にしておきます。
4. 実装と確認の基本手順
構造化データは、使う種類を決めてから設定します。
確認する場面は、公開の前と後の二つです。
変更前の設定やコードを保存し、不具合が出たときに元へ戻せる状態にしてから進めます。
基本の流れは次のとおりです。
- 対象ページを決める
商品ページ、記事ページ、会社情報など、どのページに何が載っているかを確認する - 公式の説明を読む
あてはまるGoogle検索セントラルの個別ガイドで、対象ページ、書く項目、画像、品質の条件を確認する - 今の状態を調べる
CMSやテーマ、拡張機能が何を出力しているか、生成元を確認する - 本文と一致させて設定する
画面に表示している名称、価格、在庫、日付と同じ情報を書く - 公開前にテストする
リッチリザルトテストの「コード」に公開予定の記述を入れ、重大なエラーが出ないか確認する - まず数ページで公開する
いきなり全ページへ広げず、代表的なページで表示と内容を確認する - 公開後に確認する
公開URLを再テストし、Search Console(Googleが提供する検索状況の確認ツール)のURL検査や、対応する種類のレポートでも読み取られた内容とエラーを確認する
URLを使ったテストは、Googleのツールがログインなしで取得できるページとリソースが対象です。
非公開の確認用サイトをテストのためだけに公開する必要はなく、公開予定のコードで先に確認します。
コードのテストだけでは、公開後のページへのアクセスや実際に出力される内容までは確かめられません。
また、リッチリザルトテストはGoogleの対応する検索表示を確認するもので、Schema.orgの全種類を調べる道具ではありません。
Googleのテストツールの案内では、一般的なSchema.orgの検証と、Google向けの検証を分けています。
CMSが自動で生成してくれる場合も、設定を有効にしただけで終わりにはしません。
テーマと拡張機能が同じ商品について異なる価格を出したり、空の項目や古い情報が残ったりすることがあります。
複数のデータがあるだけで誤りとは限らないので、必要な種類まで消さず、矛盾がある場合に生成元を整理します。
最初は代表的な一ページだけで、本文との一致、重大なエラー、Googleがアクセスできるかを確認し、それから対象を広げると安全です。
表示や出力に不具合が出た場合は変更した設定やコードを元に戻し、原因やエラーの意味が分からなければ制作者に相談します。
そのとき、テスト結果、対象のURL、使っているCMSや拡張機能の名前を添えると、確認がスムーズに進みます。
コードだけを送るのではなく、どのページの何を表すデータなのかも一緒に伝えます。
Search Consoleの基本的な見方は、「Google Search Consoleの始め方」にまとめてあります。
5. 更新時のずれに注意する
構造化データは、ページを更新したあとも本文と一致している必要があります。
最初の設定が正しくても、運用しているうちに本文だけが変わり、構造化データが古いまま残ることがあります。
特にずれやすいのは、次の情報です。
- 商品やサービスの名称
- 価格、通貨、税込・税別の扱い
- 在庫の有無、販売状態、予約を受け付けているか
- 公開日、更新日、イベントの日時
- 記事の作成者と画像
- 会社名、住所、電話番号、ロゴ
- パンくずの表示と、実際のカテゴリ構成
Googleは構造化データの一般ガイドラインで、構造化データを最新の情報にしておくよう求めています。
画面に表示していない内容や、ページと関係のない内容は書かないように、とも示しています。
本文の価格や在庫と構造化データを同じ元情報から更新できると、ずれを減らしやすくなります。ただし、自動生成でも更新後の出力確認は必要です。
手入力で管理している箇所があるなら、更新時のチェックリストへ「構造化データの確認」を一行加えます。
CMSの商品情報から自動生成している場合も、元の商品データが正しいかを確かめます。
公開画面と同じタイミングで構造化データも更新されるかも、あわせて見ておきます。
カテゴリを変更したときは、画面に出るパンくず、本文の内部リンク、BreadcrumbListに古い分類名やリンク先が残っていないかを見比べます。
同じページへ至る経路が複数ある場合は、複数のパンくずリストを記述できるため、すべてを一つの経路へそろえる必要はありません。
サイトの構造は、構造化データだけで伝えるものではありません。
読者が画面を見て、今どこにいるのか、次にどこへ進めるのかが分かることが大切です。
ページの構造と内部リンクの考え方は、「SEOに強いサイト構造とは？」でも説明しています。
まとめ
構造化データの役割と注意点を振り返ります。
- 構造化データは、本文に書いた情報の意味を検索エンジンへ補足するもの
- 商品、記事、組織、パンくずなど、ページの内容に合う種類だけを使う
- 正しく設定しても、検索順位やリッチリザルトの表示は保証されない
- 公式の説明、本文との一致、リッチリザルトテスト、公開後のURL検査を順に確認する
- 価格、在庫、日付、会社情報を更新したら、構造化データとのずれも確認する
まず一つやるなら、ログインなしで公開している代表的なページのURLをリッチリザルトテストへ入力します。
Googleのリッチリザルトに対応するデータが検出されるかと、報告された問題を確認できます。
何も検出されなくても、構造化データが一切ないとは限らないため、対象の種類と出力内容を制作者に確かめます。
