Webページにコンテンツを丁寧に作り込んでも、検索エンジンがそのページの「意味」を正確に読み取れなければ、せっかくの情報が正しく評価されません。テキストの量や質だけでは伝えきれない構造的な文脈を、機械が理解できる形で補足する仕組みが求められています。
その解決策が構造化データマークアップです。schema.orgの語彙とJSON-LD形式を組み合わせることで、検索結果にスター評価・FAQ・パンくずリストといったリッチリザルトを表示させ、クリック率(CTR)の向上や、AI Overview(AIO)への引用といったAI時代の検索対応まで一気通貫した施策として実装できます。本記事では、基礎概念から実装コード例・よくある失敗まで体系的に解説します。
こんな方にオススメ
- 構造化データを導入したいが、何から始めればよいか分からないマーケ担当者
- JSON-LDとMicrodataの違いや使い分けを整理したいエンジニア・SEO担当者
- リッチリザルト獲得やAIO対策でオーガニック流入を伸ばしたいスタートアップCMO
この記事を読むと···
- 構造化データマークアップの仕組みとSEOへの影響が体系的に理解できる
- JSON-LDを使った主要マークアップタイプの実装コードがそのまま活用できる
- 実装時の落とし穴と検証方法が分かり、導入後の修正工数を削減できる
目次
構造化データマークアップとは?SEOに与える影響

構造化データマークアップとは、schema.orgの語彙を使って検索エンジンにページ内容を機械的に伝える記述方式です。通常のHTMLはブラウザが「見た目」を解釈するために書かれていますが、構造化データはGoogleやBingなどの検索エンジンクローラーが「意味」を解釈するために書かれます。この二層構造こそが、現代のSEOにおいて情報収集が欠かせない基礎知識です。
構造化データが「意味の橋渡し」をする理由
人間がWebページを読む場合、文脈や前後関係から「この数字は評価点数だ」「このテキストは著者名だ」と自然に判断できます。しかし検索エンジンのクローラーにとって、HTMLのテキストは基本的に文字列の羅列です。たとえば「4.8」という数字が評価レーティングなのか、料金なのか、バージョン番号なのかを正確に判別することは、テキストだけでは困難です。
構造化データマークアップを記述すると、クローラーは「このページの`ratingValue`は4.8で、`reviewCount`は230件である」と明確に理解できます。この意味の橋渡しこそが、リッチリザルト表示の前提条件です。Googleは構造化データを「ページを理解するための手助け」と位置づけており、正しく実装されたページはSERP(検索結果ページ)でより多くの情報面積を獲得できる可能性があります。
リッチリザルトとSEOへの定量的な影響
リッチリザルトとは、通常の「タイトル+説明文+URL」の3行構成を超えて、スター評価・FAQ展開・パンくずリスト・動画サムネイル・レシピ情報などを検索結果に直接表示する形式です。表示面積が大きくなる分、視認性が高まりCTR(クリック率)の改善が期待できます。
一般的に、リッチリザルトが表示されるとCTRが向上する傾向があるとされています。特にFAQリッチリザルトは1つの検索結果枠が縦に大きく展開するため、競合ページよりも目立ちやすくなります。
また、2026年現在においてはAI Overview(AIO)への引用という観点からも、構造化データの有無が引用確率に影響するとされており、コンテンツSEOとAIO対策を掛け合わせて新しい価値を生む施策として注目されています。AIO・LLMO対策で成果を出すための最新手法を徹底解説している記事も参考にしてください。
Googleがサポートするリッチリザルト種別の全体像
Googleが公式にリッチリザルト表示をサポートしているschema.orgタイプは、2026年時点で多数あります。代表的なものを以下の表で整理します。
| スキーマタイプ | 表示形式 | 主な用途 |
|---|---|---|
| FAQPage | Q&A展開リスト | FAQ・よくある質問ページ |
| HowTo | 手順リスト | ハウツー・手順説明記事 |
| Product | 価格・在庫・評価 | ECサイト・商品ページ |
| Article / BlogPosting | 著者・更新日・サムネイル | ブログ・ニュース記事 |
| BreadcrumbList | パンくずナビ | 全サイトタイプ共通 |
| LocalBusiness | 住所・営業時間・評価 | 店舗・地域ビジネス |
| VideoObject | 動画サムネイル・再生時間 | 動画コンテンツページ |
これらはすべてschema.orgが定義する共通語彙を使用しており、実装形式(JSON-LD・Microdata・RDFa)のいずれかで記述します。次のセクションでは、この「実装形式」の選び方を詳しく解説します。
Creative Drive
SEOで集めた読者を、商談まで引き上げられていますか?
PVが増えても問い合わせにならない——それはコンテンツが"集客止まり"だからです。Creative Driveはグロースハック視点でSEOコンテンツを設計し、潜在層を育成・商談化まで引き上げます。
あなたに関連しそうなCreative Driveの機能・サポート一覧
機能・サポート一覧を見る →構造化データの実装形式:JSON-LD・Microdata・RDFaの使い分け

構造化データを記述する形式は主に3種類あります。それぞれ記述場所・保守性・Googleの推奨度が異なるため、自社サイトのCMS環境やエンジニアリソースに合わせた選択が重要です。弊社の実装経験から言えば、ほぼすべてのケースでJSON-LDが最善の選択肢となります。
JSON-LDが推奨される3つの理由
JSON-LD(JavaScript Object Notation for Linked Data)は、HTMLのheadタグまたはbodyタグ内に`<script type=”application/ld+json”>`として埋め込む形式です。Google自身がJSON-LDを推奨しており、その理由は保守性・柔軟性・実装コストの低さにあります。
第一に、HTMLの構造と分離されているため、デザイン変更やHTML改修の影響を受けません。第二に、CMSやテンプレートエンジンから動的に生成しやすく、商品ページやブログ記事を大量に運用するサイトでも一元管理できます。
第三に、プログラマーでなくてもJSONのキー・バリュー構造として読みやすく、レビューや修正が容易です。WordPressでいえばfunctions.phpやプラグインでヘッドタグに動的挿入する実装が一般的です。
MicrodataとRDFaを選ぶべき限定的なケース
Microdataは、HTMLタグそのものに`itemscope`・`itemtype`・`itemprop`といった属性を付与して構造化データを表現する形式です。HTMLと一体化しているため、コンテンツとマークアップが常に同期している点が特徴ですが、HTMLが複雑になりやすく保守コストが高くなります。RDFa(Resource Description Framework in Attributes)も同様にHTML属性として記述しますが、JSON-LDに比べると実装者が限られる形式です。
MicrodataやRDFaを採用すべき場面は、CMSの仕様上headタグにscriptを追加できない環境、または既存サイトにMicrodataがすでに実装されており移行コストが見合わない場合に限定されます。新規サイトや新規ページの実装であれば、JSON-LDを選択することを強くお勧めします。
3形式の比較一覧表
| 比較項目 | JSON-LD | Microdata | RDFa |
|---|---|---|---|
| 記述場所 | scriptタグ(分離) | HTMLタグ内属性 | HTMLタグ内属性 |
| Googleの推奨度 | ◎(公式推奨) | ○(サポート) | ○(サポート) |
| 保守のしやすさ | 高(HTML分離) | 低(HTML混在) | 低(HTML混在) |
| 動的生成との相性 | ◎ | △ | △ |
| 新規実装での推奨 | ◎(第一選択) | △(移行困難時のみ) | △(特殊環境のみ) |
主要マークアップタイプ別の実装例

ここからは実務で最も頻繁に使われる主要なスキーマタイプの実装コードを、JSON-LD形式で具体的に解説します。各実装例はコピーして使える形で記述しています。実装後は必ずGoogleの「リッチリザルトテスト」で検証することが、成功への生命線です。
FAQPageの実装:質問と回答を構造化する
FAQPageは、よくある質問(Q&A)ページや記事末尾のFAQセクションに実装するスキーマです。検索結果でQ&Aが折りたたみ展開形式で表示されるリッチリザルトを獲得でき、1つの検索枠の表示面積が縦に大きく広がります。
以下のJSON-LDを`<script type=”application/ld+json”>`タグで囲み、headまたはbodyに埋め込みます。
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "構造化データマークアップとは何ですか?",
"acceptedAnswer": {
"@type": "Answer",
"text": "schema.orgの語彙を使って検索エンジンにページ内容を機械的に伝える記述方式です。JSON-LD形式で実装するのが一般的です。"
}
},
{
"@type": "Question",
"name": "JSON-LDとMicrodataはどちらを選ぶべきですか?",
"acceptedAnswer": {
"@type": "Answer",
"text": "新規実装ではGoogleが公式推奨するJSON-LDを選択してください。HTMLと分離して記述できるため保守性が高く、CMS連携も容易です。"
}
}
]
}
注意点として、FAQPageスキーマに記述するQ&Aの内容は、ページの本文中にも同等の情報が存在している必要があります。本文に存在しない情報をスキーマだけに記述することは、Googleのガイドライン違反となりリッチリザルトが剥奪される可能性があります。
HowToの実装:手順をステップ単位で構造化する
HowToスキーマは、作業手順・料理レシピ・DIY手順など「ステップを踏む作業」を説明するページに適しています。各ステップの画像・説明・所要時間まで記述できるため、検索結果で手順リスト付きのリッチリザルトが表示される可能性があります。
{
"@context": "https://schema.org",
"@type": "HowTo",
"name": "JSON-LDで構造化データを実装する方法",
"description": "schema.orgのJSON-LDを使ってWebページに構造化データを実装し、リッチリザルトを獲得するための手順です。",
"totalTime": "PT30M",
"step": [
{
"@type": "HowToStep",
"position": 1,
"name": "実装するスキーマタイプを決定する",
"text": "ページの内容に合ったschema.orgのタイプ(FAQPage・HowTo・Product等)を選択します。"
},
{
"@type": "HowToStep",
"position": 2,
"name": "JSON-LDコードを作成する",
"text": "選択したタイプに必要なプロパティをJSON-LDで記述します。必須プロパティと推奨プロパティを確認してください。"
},
{
"@type": "HowToStep",
"position": 3,
"name": "headタグにscriptとして埋め込む",
"text": "<script type='application/ld+json'>タグで囲んでheadまたはbody内に配置します。"
},
{
"@type": "HowToStep",
"position": 4,
"name": "リッチリザルトテストで検証する",
"text": "Google Search ConsoleのリッチリザルトテストURLでエラーがないか確認します。"
}
]
}
`totalTime`はISO 8601形式(PT30M = 30分)で記述します。ステップ数が多い場合は`HowToSection`で複数のステップをグループ化することもできます。
Article・BreadcrumbListの実装:E-E-A-Tを高める基礎スキーマ
ArticleスキーマとBreadcrumbListスキーマは、コンテンツメディア・ブログ・オウンドメディアを運営するすべてのサイトに実装すべき基礎スキーマです。Articleスキーマは著者情報・公開日・更新日・サムネイル画像を構造化することで、Googleが評価するE-E-A-T(経験・専門性・権威性・信頼性)のシグナルを補強します。
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "構造化データマークアップ完全ガイド",
"description": "schema.orgを使ったリッチリザルト獲得方法を解説します。",
"image": "https://example.com/images/structured-data-guide.jpg",
"author": {
"@type": "Person",
"name": "Yuki Toki",
"url": "https://example.com/author/yuki-toki"
},
"publisher": {
"@type": "Organization",
"name": "CreativeDrive",
"logo": {
"@type": "ImageObject",
"url": "https://creative-drive.jp/logo.png"
}
},
"datePublished": "2026-01-15",
"dateModified": "2026-06-01"
}
BreadcrumbListは別のJSON-LDブロックで記述し、同じページに複数のJSON-LDを配置することが可能です(`@graph`を使って1つのブロックにまとめることもできます)。パンくずのURLはcanonical URLと一致させることが重要です。
構造化データ実装の手順:導入から検証まで

構造化データの実装は「書いて終わり」ではありません。実装→検証→モニタリングという一気通貫したプロセスを確立することで、継続的にリッチリザルトを維持・拡大できます。以下のステップに沿って進めることで、実装後のトラブルを最小化できます。
STEP1:ページタイプ別スキーマ選定のフレームワーク
実装を開始する前に、対象ページの「コンテンツタイプ」を明確にすることが成功への生命線です。よくある失敗が、コンテンツの実態と合わないスキーマを選定してしまうケースです。たとえば、単なるブログ記事にProductスキーマを実装しても、Googleは正しく認識せずリッチリザルトは表示されません。
選定の基本フレームワークは「ユーザーがそのページで何を解決するか」から考えることです。
| 情報を調べる(What/Why系) | Article・BlogPosting・FAQPageが候補 |
| 手順を知りたい(How系) | HowToが第一候補。ステップが3つ以上あれば有効 |
| 商品を購入・比較したい | Product(ItemList・AggregateRatingと組み合わせ) |
| 店舗・場所を探している | LocalBusiness・Place |
| 動画を観たい | VideoObject |
| 求人情報を探している | JobPosting |
1つのページに複数のスキーマを組み合わせることも可能です。たとえば「ハウツー記事」にArticleとHowToとFAQPageを同時に実装するケースは有効な戦略です。ただし、相互矛盾するプロパティが生じないよう注意が必要です。
STEP2〜3:JSON-LDコード作成と実装のポイント
JSON-LDを作成する際、必須プロパティと推奨プロパティを区別して把握することが重要です。Googleのリッチリザルトテストで「必須プロパティが欠けている」というエラーが出ると、リッチリザルトは表示されません。推奨プロパティは「あると表示が豊かになる」もので、必須ではありませんが積極的に実装すべきです。
WordPressサイトでの実装方法は主に3通りあります。①プラグイン(Yoast SEO・All in One SEO等)を使う方法は設定画面から操作できるため非エンジニアでも扱いやすい反面、高度なカスタマイズが難しいことがあります。
②functions.phpに`wp_head`アクションフックで動的にJSON-LDを出力する方法は、投稿データを使った動的生成が可能で最も柔軟性があります。③テーマテンプレートに直接記述する方法はシンプルですが、テーマ更新で消える可能性があるため、子テーマを使用することが推奨されます。
STEP4〜5:検証とSearch Consoleモニタリング
実装後の検証には、GoogleのリッチリザルトテストツールにURLまたはコードを入力することで、エラー・警告・有効なプロパティの3段階で評価を確認できます。エラーは修正必須、警告は推奨プロパティの未実装を示します。
本番公開後はGoogle Search Consoleの「検索での見え方」→「リッチリザルト」レポートでページごとのステータスを監視します。「有効」「警告あり」「エラー」の3ステータスで管理でき、エラーが増加したタイミングでHTMLやCMSの変更と照合することで原因を特定しやすくなります。
なお、実装してからリッチリザルトが実際に表示されるまでには数日〜数週間かかることが一般的です。また、構造化データが正しく実装されていてもGoogleがリッチリザルト表示を保証するわけではない点も理解しておく必要があります。
AI時代の構造化データ戦略:AIO・LLMOへの応用
2026年現在、構造化データマークアップの意義は「検索結果のリッチリザルト獲得」だけにとどまりません。GoogleのAI Overview(AIO)やChatGPT・Perplexityなどの生成AI検索への引用を高める施策として、構造化データはAIO・LLMO対策と深く結びついています。
AI OverviewsはなぜJSONLDを参照するのか
AI Overviewsは検索クエリに対して複数のWebページから情報を収集し、要約回答を生成します。このとき、ページの「意味」を素早く正確に把握するために、構造化データが有力なシグナルとなる可能性があります。特にFAQPageスキーマのQ&A・HowToスキーマのステップ・Articleスキーマの著者情報は、AIが「信頼できる情報源」と判断する際の根拠として機能するとされています(仮説ベース・検証中)。
弊社では、FAQPageスキーマを実装したページがAI Overviewsに引用される傾向があることを自社メディアの運用を通じて確認しています。特に質問文が「自然言語型の検索クエリ」と一致するFAQは、AI検索の回答に採用されやすい傾向があります。これはコンテンツSEOとAI対策を掛け合わせて新しい価値を生む実証例と言えます。
SpeakableSpecificationとAIO最適化の実装
SpeakableSpecificationは、GoogleアシスタントやAI Overviewsがページの「読み上げに最適な箇所」を特定するために設計されたschema.orgのプロパティです。記事の要約・直接回答ブロック・FAQをSpeakableとして指定することで、AI検索での引用確率を高める可能性があります。
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "構造化データマークアップ完全ガイド",
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [".answer-block", "h1", ".article-summary"]
},
"mainEntity": {
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "構造化データマークアップはSEOに効果がありますか?",
"acceptedAnswer": {
"@type": "Answer",
"text": "はい。正しく実装することでリッチリザルトが表示され、CTRの向上が期待できます。また2026年現在はAI Overviewsへの引用シグナルとしても機能する可能性があります。"
}
}
]
}
}
`cssSelector`で指定するクラスは、HTMLに実際に存在するクラス名と一致させる必要があります。AIはJavaScriptなしで取得できる静的HTMLを優先的に参照するため、Speakableブロックのコンテンツは必ず静的HTMLとして出力することが重要です。AIO・LLMO対策の最新手法についてはこちらの記事も参照ください。
CreativeDriveが実践するコンテンツ×構造化データの統合アプローチ
弊社CreativeDriveでは、月50本規模のAI記事生成パイプラインに構造化データの自動生成を組み込んでいます。記事タイプ(HowTo・FAQ・Article)に応じたJSON-LDテンプレートをCMSが自動選択し、著者情報・公開日・カテゴリ情報を動的に挿入することで、記事公開と同時に構造化データが有効になる体制を構築しています。
さらに、潜在顧客が情報収集フェーズにある段階(まだ購買を検討していない段階)からFAQページ経由でサイトに流入し、14ヶ月にわたるリードナーチャリングで顕在化を待つトラッキング設計と、構造化データによる検索流入の最大化を組み合わせることで、費用対効果の高いグロース設計が可能になります。こうしたAIエージェント×データによる一気通貫したアプローチに関心をお持ちの方は、ぜひ弊社のサービス内容をご確認ください。
よくある失敗パターンと対策
構造化データの実装で多くのサイトが陥る失敗には共通のパターンがあります。弊社の支援経験から頻出する失敗を整理し、具体的な対策とセットで解説します。実装後に「リッチリザルトが表示されない」「Search Consoleでエラーが増えた」という状況になってから対処するより、最初から回避する方が工数は大幅に削減できます。
失敗①:本文と構造化データの内容の乖離
最も多い失敗は、HTMLの本文には記載されていない情報をJSONLDに記述するケースです。たとえば、本文では評価点数を表示していないのに`ratingValue: 4.8`とスキーマに書いたり、FAQスキーマの質問がページのどこにも表示されていないケースが該当します。
Googleのガイドラインでは「構造化データはページの実際のコンテンツを反映していなければならない」と明記されています。この違反を検知するとGoogleはリッチリザルトの表示を停止し、悪質と判断された場合はマニュアルペナルティの対象となる可能性もあります。
対策は単純で、スキーマに記述するすべての情報がページ本文にも表示されている状態を確認することです。CMSで動的生成している場合は、テンプレートの本文とJSONLDが同一データソースから生成されているかを確認します。
失敗②:必須プロパティの不足によるエラー
各スキーマタイプにはGoogleが定めた「必須プロパティ」と「推奨プロパティ」があります。必須プロパティが1つでも欠けると、そのページではリッチリザルトが表示されません。たとえばProductスキーマの場合、`name`は必須ですが`offers`(価格情報)がなければレビュー付きリッチリザルトは表示されません。
対策として、Googleの公式ドキュメント(developers.google.com/search/docs/appearance/structured-data)でタイプごとの必須・推奨プロパティを確認することを習慣にしましょう。また実装後は必ずリッチリザルトテストを使い、「必須プロパティが不足」というエラーが出ていないことを確認します。チームで実装する場合は、必須プロパティのチェックリストをコードレビューのテンプレートに組み込むと効果的です。
失敗③:CMS更新・リニューアルでのスキーマ消失
WordPressのテーマ更新・CMSのバージョンアップ・サイトリニューアル時に、functions.phpやテンプレートファイルに直接記述していたJSONLDが消失するトラブルは頻繁に発生します。特にテーマをゼロから切り替えるリニューアルでは、旧テーマに実装した構造化データがすべて失われるケースがあります。
根本的な対策は、プラグインまたは子テーマを使って構造化データを管理することです。親テーマのファイルを直接編集せず、子テーマのfunctions.phpにhookを記述することで、テーマ更新の影響を受けなくなります。
さらに、Search Consoleの「リッチリザルト」レポートを定期モニタリングし、「有効数」が急減したタイミングで即座に異常を検知できる体制を整えることが重要です。これは502 Bad Gatewayなどのサーバーエラー発生時と同様に、定期的な健全性確認が欠かせない運用上の課題です。
まとめ:構造化データ実装チェックリスト
構造化データマークアップは、検索エンジンとコンテンツの間の「意味の橋渡し」を担う技術です。JSON-LDで正しく実装することでリッチリザルトを獲得し、CTRを改善する可能性があります。さらに2026年現在は、AIO・LLMO対策との掛け合わせで検索とAI両方の流入経路を強化できます。
実装の成否は「正しいスキーマ選定→必須プロパティの記述→検証→モニタリング」というサイクルの定着にかかっています。以下のチェックリストを実装フローに組み込むことで、典型的な失敗を回避できます。
- 対象ページのコンテンツタイプに合ったスキーマタイプを選定した
- Googleの公式ドキュメントで必須プロパティを確認した
- JSON-LDの全プロパティ値がHTMLの本文にも表示されている
- リッチリザルトテストでエラー・警告がゼロであることを確認した
- Search Consoleの「リッチリザルト」レポートに登録されている
- CMS更新時にスキーマが消失しない管理方法(子テーマ・プラグイン)を採用している
- FAQスキーマの質問文がAI検索の自然言語クエリと一致するよう調整した
- 月次でSearch ConsoleのリッチリザルトステータスをモニタリングするKPIを設定した
構造化データとコンテンツSEOを組み合わせた本格的なグロース施策を検討したい場合、あるいはAI記事生成パイプラインへの組み込みを相談したい場合は、CreativeDriveまでお気軽にご相談ください。潜在顧客の情報収集フェーズからの接点設計と、AI時代のオーガニック流入最大化を支援します。


