この記事でわかること
- Googleが構造化データをどう使っているか（公式の説明）
- JSON-LDが推奨される理由と設置場所
- ガイドライン違反になるマークアップの具体例
- 記事制作フローに組み込んで後付けを避ける方法
Googleは構造化データをどう使っているか
構造化データとは、Googleの説明では「ページに関する情報をさまざまなサイトで活用できるように標準化したデータ形式」です。ページの意図を伝えることで、Googleがそのページをより正確に理解できるようになるとされています（出典：構造化データの仕組みについて｜Google検索セントラル）。
ここで押さえておきたいのは、Googleは順位が上がるとは言っていない点です。同ページではリッチリザルト表示によるクリック率向上の事例は紹介されていますが、検索ランキングの向上効果については記載がありません。
正しい位置づけ：構造化データは順位を上げる施策ではなく、ページの内容を機械が誤解しない形で伝える施策です。生成AIが記事の一部を抜き出して回答を組み立てる場面では、この「誤解されない」ことの価値が従来より大きくなっています。
JSON-LDが推奨される理由
構造化データの記述形式は複数ありますが、GoogleはJSON-LDを推奨しています。理由として挙げられているのは「実装と管理が最も容易」であることです。
| 形式 | Googleの扱い | 特徴 |
|---|---|---|
| JSON-LD | 推奨 | HTMLの head / body 内の script タグに埋め込む。本文と分離できるため管理しやすい |
| microdata | 対応 | HTMLタグに属性を追記する。本文構造と密結合になる |
| RDFa | 対応 | 同上 |
また配置の原則として、Googleは「ページ上の構造化データは、そのページのコンテンツを記述します」とし、「構造化データを保持するためだけに空のページを作成しないでください」と明記しています。
記事ページで最低限入れるもの
コラム記事に実装する3点セット
- Article：記事タイトル、説明、公開日・更新日、著者、発行者
- BreadcrumbList：TOP → カテゴリ → 記事 の階層
- FAQPage：本文に掲載しているFAQと同一の質問・回答
FAQPageは、生成AIが質問に対する回答を抜き出す場面で効きます。ただし次の制約があります。
やってはいけないマークアップ
Googleの明示的な禁止事項：「ユーザーの閲覧しているページ画面に表示されない情報に関する構造化データは、その情報が正確であっても追加しないでください」
これは実務上、最も踏みやすい落とし穴です。FAQをJSON-LDにだけ書いて本文には載せない、という実装をしているサイトは少なくありませんが、上記の方針に反します。構造化データに書く内容は、必ず本文にも同じ内容を掲載してください。
品質面についても記載があります。「完全でないデータ、不正な形式のデータ、不正確なデータを含む多数の推奨プロパティを提供するより、少数であっても完全で正確な推奨プロパティを提供するほうが重要です」。プロパティを埋めることが目的化しないよう注意してください。
なお、ガイドラインに準拠しない構造化データは、Google検索でリッチリザルトとして表示されない場合があるとされています。
実装後の検証
Googleは2段階の確認を推奨しています。
| タイミング | 使うもの | 目的 |
|---|---|---|
| 公開前 | リッチリザルトテスト | 構造化データの有効性を検証し、検索機能をプレビューする |
| 公開後 | リッチリザルトのステータスレポート | デプロイ後にページの正常性が損なわれていないか確認する |
公開後の確認が必要な理由として、Googleは「テンプレートや配信の仕方が原因で、デプロイ後にページの正常性が損なわれることがある」と説明しています。テンプレートを使って記事を量産している場合、1本の実装ミスが全記事に波及するため、この確認は特に重要です。
制作フローに組み込む
構造化データで最も避けたいのは、後付けです。記事が100本たまってから全ページに実装しようとすると、それだけで数十万円規模の作業になります。
記事1本を作る手順に組み込む
- 記事テンプレートにArticle・BreadcrumbList・FAQPageの雛形を埋め込んでおく
- FAQは本文に書き、その内容をそのまま構造化データにも反映する
- 公開日・更新日をテンプレート側で自動的に埋める
- 公開前チェックにリッチリザルトテストを入れる
- sitemap.xmlへの追記まで同じ手順の中で完了させる
この形にすれば、構造化データの実装コストは実質ゼロになります。1本目のテンプレートを整える手間だけで、以降すべての記事に適用されます。
LnXの見解
構造化データは、やれば順位が上がる魔法ではありません。Google自身がランキング向上を明言していない以上、そこに期待するのは筋が違います。価値があるのは、生成AIが記事の内容を誤解せずに抜き出せる状態をつくれることです。
LnXでは、全記事・全事例ページにArticle・FAQPage・BreadcrumbListを付与し、FAQは必ず本文と構造化データの両方に同じ内容を持たせています。llms.txtでサイト構造と各ページの要約も提供しています。これらはすべて記事を作る手順の中に組み込んであるため、追加の作業時間は発生していません。
自社のオウンドメディアでこの運用を約3か月続けた結果、GoogleのAIがユーザーにサイトを表示した回数は約7倍に増え、外部ツールによるAIOスコアは91点（100点満点／Bランク）でした。スコアの内訳では、AI構造化データ・FAQの項目が35点満点中31点となっています。詳しい工程は事例ページにまとめています。
これから記事を増やす予定があるなら、1本目を書く前にテンプレートを整えてください。それが最も安く済むタイミングです。
よくある質問
Q構造化データを追加すれば検索順位は上がりますか？
Googleは構造化データの解説ページで、リッチリザルト表示によるクリック率向上の事例は示していますが、検索ランキングの向上効果については記載していません。順位対策としてではなく、ページの内容を正確に伝えるための実装と考えてください。
Qどの形式で書けばよいですか？
GoogleはJSON-LDを推奨しています。理由として「実装と管理が最も容易」であることを挙げており、HTMLページの head 要素および body 要素の script タグ内に埋め込む形式です。microdataとRDFaにも対応していますが、サイトの設定で許容されている限りJSON-LDの使用が推奨されています。
Q画面に表示していない情報をマークアップしてもよいですか？
いけません。Googleは「ユーザーの閲覧しているページ画面に表示されない情報に関する構造化データは、その情報が正確であっても追加しないでください」と明記しています。FAQをJSON-LDだけに入れて本文に書かない実装は、この点で問題があります。
Qプロパティは多く書いたほうがよいですか？
数より正確さが優先されます。Googleは「完全でないデータ、不正な形式のデータ、不正確なデータを含む多数の推奨プロパティを提供するより、少数であっても完全で正確な推奨プロパティを提供するほうが重要です」としています。
Q実装した後、何で確認すればよいですか？
公開前はリッチリザルトテストで構造化データの有効性を確認し、公開後はリッチリザルトのステータスレポートで状態を確認します。Googleは、テンプレートや配信の仕方が原因でデプロイ後にページの正常性が損なわれることがあるため、公開後の確認も必要だと説明しています。