構造化データとは？SEO効果とJSON-LD実装・型の選び方【2026年時点】

構造化データは、ページに書いてある内容を検索エンジンが機械的に読み取れる形へ翻訳するマークアップです。正しく入れると検索結果に星評価や商品価格、パンくずが並ぶリッチリザルトが出ますが、入れれば順位が上がるという性質のものではありません。この記事では、schema.orgとリッチリザルトの関係、JSON-LDを含む3つの記述方式の使い分け、2026年時点で表示される機能とFAQ廃止後の扱い、実装から検証までの五工程、そして投資すべきサイトと絞ってよいサイトの線引きまでを、発注判断ができる粒度で整理します。

まとめ：構造化データの効果範囲とリッチリザルト投資の優先順位

構造化データの効果は「検索順位」ではなく「検索結果での見え方」に出ます。Googleは構造化データを順位の直接要因として案内しておらず、得られるのはリッチリザルト表示によるクリック率の押し上げです。順位が変わらないままクリック率だけが動く、という理解で予算を組んでください。

投資の優先順位では、扱う情報の型が判断軸です。商品・在庫・価格を持つEC、自社サイトで求人票を出している企業、実店舗を構える事業者は、商品／求人情報／ローカルビジネスの各機能が検索結果の面積に直結するため先に手を付ける価値があります。逆に数十ページ規模のコーポレートサイトなら、パンくずリストと組織の2種類を入れた時点で費用対効果はほぼ頭打ちになります。

形式はJSON-LDを選べば足ります。GoogleがJSON-LDを推奨しており、HTMLの構造と切り離して書けるため保守も楽です。実装の難所はコードの書き方ではなく、テンプレートに動的な値をどう差し込むか、そしてプラグインとテーマの二重出力をどう防ぐかにあります。FAQの構造化データは2026年5月7日に検索結果への表示が止まりました。今から新規に入れる理由はありません。

構造化データの定義とschema.org・リッチリザルトの関係整理

用語が3つ絡むため、まず役割を分けて押さえます。構造化データは「書き方の総称」、schema.orgは「使う語彙の辞書」、リッチリザルトは「その結果として検索画面に出る表示」です。

検索エンジンに意味を機械可読で伝えるマークアップとしての位置付け

ページに「3,980円」と書いてあっても、検索エンジンから見ればただの文字列です。それが商品の税込価格なのか、月額料金なのか、送料の閾値なのかは、本文を読んだだけでは確定しません。構造化データは、この文字列に「これはOfferのprice、通貨はJPY」という札を付ける仕組みです。

札を付ける対象は、価格に限りません。記事の著者と公開日、レシピの調理時間、イベントの開催日時と会場、求人の雇用形態と勤務地。いずれも人間なら本文から読み取れる情報を、曖昧さのない形で明示します。検索エンジン側は推測に頼らずに済み、結果として検索画面での見せ方を変える判断がしやすくなるわけです。

schema.orgが定める語彙と2026年3月公開の30.0系という版管理

札に使う単語を決めているのがschema.orgです。Google・Microsoft・Yahoo!が2011年に共同で立ち上げた語彙で、ProductやArticle、LocalBusinessといった型と、その型が取れるプロパティが定義されています。バージョンは30.0系が2026年3月19日に公開されており、EUのデジタル製品パスポート向けの例示などが追加されました。

ここで注意したいのは、schema.orgに定義があることと、Googleがリッチリザルトとして表示することは別だという点です。schema.orgの語彙は数百の型を持ちますが、そのうち検索結果の見た目を変えるものはごく一部にとどまります。辞書に載っている単語を全部使う必要はありません。

構造化データとリッチリザルトを別物として切り分ける考え方の要点

リッチリザルトは、構造化データを読み取ったGoogleが「この検索結果はこう見せよう」と決めた表示形式です。マークアップは表示の必要条件であって十分条件ではありません。要件を満たしていても、検索クエリや端末、その時のGoogle側の判断によって出ないことは普通に起こります。

この非対称性を発注前に共有しておかないと、実装後に「入れたのに出ない」という食い違いが生じます。表示されるかどうかはGoogleの裁量である、と契約段階で握っておくのが実務上の落としどころです。なお、組織や人物の実体をナレッジグラフ側へ伝える設計は構造化データの応用領域にあたるため、エンティティSEOとナレッジグラフの実装手順で別途扱っています。

JSON-LD・Microdata・RDFaの記述方式ごとの向き不向き

構造化データを書く形式は3つあります。結論から言えば新規実装はJSON-LD一択で、残る2つは既存サイトを引き継ぐときに読む必要が出る、という位置付けになります。

GoogleがJSON-LDを推奨する理由と実装・保守面での差

JSON-LDはscriptタグの中にデータをまとめて書く形式です。Googleは公式ドキュメントで、実装と管理が最も容易でユーザーのミスが少ないとしてJSON-LDを推奨しています。MicrodataとRDFaはHTMLの各要素に属性を付けていくため、マークアップと表示が絡み合います。

保守面の差は運用に入ってから効いてきます。JSON-LDはデータの塊が1箇所にまとまるため、価格改定やロゴ差し替えのときに触る場所が明確です。属性埋め込み型だと、デザイン変更でHTMLを組み替えた際にマークアップも道連れで壊れます。実際、テンプレート改修後にリッチリザルトが消える事故の多くはこの型で起きています。

MicrodataとRDFaを選ぶ場面と既存サイト移行時の注意

新しく選ぶ理由はほぼありません。ただし2015年前後に構築されたECサイトやニュースメディアを引き継ぐと、Microdataで商品情報や記事情報が組まれているケースに出会います。この場合、いきなり全削除してJSON-LDへ差し替えると、移行中に両方が欠けた期間ができてリッチリザルトが落ちます。

順序としては、JSON-LDを先に追加し、リッチリザルトテストで新旧の出力が競合していないことを確かめてから、旧マークアップを外します。同じ型を二重に出すと、Googleがどちらを採用するか不定になるためです。移行対象のテンプレートが10本を超えるなら、一度に切り替えず記事詳細・商品詳細といった単位で区切って進めてください。

2026年時点で表示されるリッチリザルト機能とFAQ廃止後の扱い

どの機能を狙うかで実装工数は大きく変わります。2026年8月時点でGoogleが機能ギャラリーに掲載している構造化データ機能は28種類です。全部を見る必要はなく、自社が持つ情報の型に一致するものだけを拾えば足ります。

記事・パンくず・商品など主要機能とサイト種別ごとの対応判断軸

掲載28機能のうち、日本の一般的な事業会社サイトで現実的に検討対象となるのは次の範囲です。

• 記事：オウンドメディア・コラムを持つ全サイト。著者と公開日を明示する
• パンくずリスト：階層構造を持つ全サイト。実装コストが最も低い
• 組織：コーポレートサイト。ロゴ・所在地・連絡先を1箇所に集約する
• 商品：EC。価格・在庫・レビューが検索結果に出る効果が大きい
• 求人情報：自社採用サイト。求人検索の面に載る条件になる
• ローカルビジネス：実店舗・拠点を持つ事業者
• 動画・イベント・レシピ：該当コンテンツを保有するメディアのみ

この並びは実装コストの低い順ではなく、検索結果での見え方が変わる度合いの順です。着手順に迷ったら、パンくずと組織を先に片付けて土台を作り、そのうえで自社固有の型へ進むと手戻りが出ません。階層の切り方そのものを設計し直したい場合は、パンくずリストのSEO効果と階層設計を先に読むと判断が早まります。

FAQとHowToが取り下げられた経緯と既存マークアップの処遇

数年前の解説記事を参照すると、FAQとHowToが主要機能として紹介されています。この2つは既に検索結果から消えました。2023年8月にGoogleがHowToの表示を廃止し、同時にFAQの表示を政府機関や医療系の著名サイトへ限定しました。FAQはその後さらに縮小し、2026年5月7日に検索結果への表示が停止しています。

後続の整理も進んでいます。2026年6月にはサーチコンソール側の検索での見え方フィルタとリッチリザルトレポート、リッチリザルトテストでの対応が取り下げられ、API経由でFAQのデータを取得していた場合の猶予は2026年8月までとされました。既に入れてあるFAQPageのマークアップは、残しておいても不利益が生じるものではありません。ただし新規案件の見積りにFAQ実装が入っていたら、その工数は削ってよい項目です。廃止の詳しい経緯と代替の打ち手はFAQリッチリザルト廃止後の正しい対応にまとめてあります。

生成AI検索の引用に対して構造化データが果たす役割と現時点の限界

AI Overviewsや生成AIの回答に引用されるために構造化データが効く、という説明を見かけます。現時点で、Googleが構造化データを生成AIの引用条件として公表した事実はありません。過度な期待は禁物です。

とはいえ無意味でもありません。著者・公開日・組織といった発信元の属性が機械可読になっていれば、回答生成側がページの性格を判定する材料は増えます。費用をかけて追加投資する対象というより、通常の実装をしていれば副次的に効く可能性がある、という程度に見積もってください。引用される記事構造そのものを設計したい場合は、AI Overview対策と引用される記事構造のほうが打ち手として直接的です。

構造化データ導入で見込めるCTR改善と検索順位への影響の実際

費用対効果を説明するとき、ここを曖昧にしたまま進めると後で揉めます。効果の出どころと測り方を先に決めてください。

Googleが順位要因として案内していない事実と効果の出どころ

Googleの公式ドキュメントは、構造化データを「リッチリザルトとして表示されるための要件」として説明しており、検索順位を上げる要因としては案内していません。ガイドラインに準拠しない構造化データはリッチリザルトとして表示されない場合がある、という記述にとどまります。

したがって期待値は、同じ順位のままクリック率が動く範囲に置きます。星評価や価格が出れば一覧の中で目に留まりやすくなり、結果としてクリック率が上向く。この経路以外の効果を営業資料に書くと、3か月後の報告で説明がつかなくなります。ページ内容と食い違うマークアップを入れた場合は手動対策の対象になりうるため、盛る方向の実装はむしろ損です。

効果測定でクリック率と表示回数を切り分けて見る指標設計の手順

測定は、実装したページ群だけを抜き出した比較で行います。サイト全体の平均クリック率を見ても、季節変動やクエリ構成の変化に埋もれて構造化データの寄与が読めません。

サーチコンソールでページを絞り込み、実装前後それぞれ同じ日数分のクリック率と表示回数、平均掲載順位を並べます。ここで掲載順位が動いていたら、クリック率の変化は構造化データ以外の要因を含むと判断してください。順位が横ばいでクリック率だけ上がっている、という形が取れて初めて効果と呼べます。効果の判定には最低でも2か月、季節性のある商材なら前年同月との比較も併せて見るのが安全です。

構造化データ実装の五工程とリッチリザルトテストによる検証手順

実装の失敗は、コードの書き方より工程の抜けから生まれます。誰が何を決めるかを工程ごとに割り当ててから着手してください。

対象ページの選定から公開後の監視までをつなぐ実装五工程の全体像

進め方は次の五段階に分かれます。

1. 対象ページ群と狙う機能の決定（発注者側の判断。ここで型が確定する）
2. 選んだ型の必須プロパティと推奨プロパティの洗い出し
3. テンプレートへのJSON-LD組み込みと動的値の差し込み
4. リッチリザルトテストによる検証（開発環境とステージング）
5. 公開後にサーチコンソールのステータスレポートで有効数とエラーを追跡

1と2を飛ばして3から入る現場が多く、その場合は必須プロパティ不足で後戻りします。商品ならnameとofferのprice・priceCurrency・availability、記事ならheadlineとdatePublished、といった具合に、型ごとの必須項目を先に表へ落としてから実装へ渡してください。工程4と5は別物で、テストは書き方の妥当性を、レポートは実際のクロール結果を見ています。

WordPressと自社CMSで分かれる出力箇所と二重出力の防ぎ方

WordPressの場合、テーマとSEOプラグインの双方が構造化データを自動出力します。All in One SEOやYoast SEOは組織・記事・パンくずを既定で吐くため、そこへ手動でJSON-LDを追加すると同じ型が2つ出ます。まず現状の出力をリッチリザルトテストで確認し、足りない型だけを補う。これが最短です。

自社CMSやスクラッチ開発のシステムでは、テンプレート側でJSON-LDを組み立てます。価格や在庫のように更新頻度が高い値は、画面表示と同じデータソースから流し込む設計にしてください。表示は在庫ありなのにマークアップは在庫なし、という不一致は、別々の変数を参照している構造から生まれます。

必須プロパティ不足やページ内容との不一致で起きる典型的な失敗

現場で繰り返し見るのは3つの型です。1つ目は必須プロパティの欠落で、リッチリザルトテストでは警告扱いになるものの表示条件は満たさない状態になります。2つ目はページに書いていない情報のマークアップ。掲載していないレビュー評価を入れるといった実装は、ガイドライン違反として扱われます。

3つ目が、テンプレート改修時の置き去りです。デザイン刷新でHTMLを組み替えたのに構造化データ側を更新せず、旧仕様の値が残り続ける。公開後のレポート監視を工程に組み込んでおけば、有効数の急減としてこの手の事故を検知できます。監視を誰が見るかまで決めておくと、放置期間が短くなります。

構造化データに投資すべきサイトの条件と着手を見送ってよい場面

ここは判断を言い切ります。構造化データは全サイトが等しく取り組むべき施策ではなく、投資対効果がはっきり分かれる施策です。

商品・求人・店舗情報を持つサイトが構造化データを先に入れる理由

優先すべきは、検索結果の表示面積そのものが変わるサイトです。ECなら価格・在庫・レビュー評価が一覧に並び、比較検討中のユーザーが商品ページへ入る前に判断材料を得ます。自社採用サイトで求人票を公開しているなら、求人情報の構造化データはGoogleの求人検索へ掲載される条件を兼ねます。実店舗を持つ事業者のローカルビジネスも同様です。

これらに共通するのは、構造化データが「見え方の改善」ではなく「新しい掲載面への参加資格」になっている点です。求人検索の面に載るかどうかは、マークアップの有無で決まります。該当する情報を持っているなら、他のSEO施策より先に着手してかまいません。

数十ページ規模のコーポレートサイトで投資を絞ってよい判断の根拠

一方、BtoBのサービス紹介を中心とした数十ページ規模のコーポレートサイトでは、構造化データに工数を割く優先度は低いままです。会社概要・サービス紹介・事例といった構成に対して、リッチリザルトとして表示されうる機能はパンくずリストと組織、そしてコラムがあれば記事に限られます。この3つはテンプレートに1回入れれば全ページへ効きます。

逆に、ここから先へ広げるのは過剰投資です。サービスページにProductを付ける、事例にReviewを付けるといった実装は、掲載していない情報のマークアップに近づくうえ、表示上の見返りもありません。この規模のサイトなら、構造化データに追加費用を積むより、テクニカルSEOの施策と優先順位で挙げた内部構造やインデックス周りの整備に予算を回したほうが成果が出ます。予算に上限があるなら、パンくずと組織を入れた時点でいったん止めてください。

内製で足りる範囲と外部に委ねるべき範囲を分ける発注時の線引き

切り分けの基準は、値が静的か動的かです。組織やパンくずのように、値がほぼ固定でテンプレート1〜2本に収まる範囲なら、社内のWeb担当者がプラグイン設定と検証まで回せます。外部へ出すほどの工数ではありません。

委ねるべきなのは、商品在庫や価格、求人の募集状況のように基幹データと連動する実装です。データソースの特定、更新タイミングの同期、テスト環境での検証まで含めると、CMSとバックエンド双方への理解が前提です。ここを内製で無理に進めると、表示とマークアップの不一致という最も避けたい失敗を招きます。実装範囲の切り分けから測定設計までを含めて相談したい場合は、SEO内部施策とキーワード設計の支援で受け付けています。

よくある質問

構造化データの導入検討でよく寄せられる質問を、判断に直結する順で5つ挙げます。

構造化データを入れると検索順位は上がりますか？

順位が上がるとは言えません。Googleは構造化データを、リッチリザルトとして表示されるための要件として説明しており、検索順位の直接的な要因としては案内していないためです。効果はリッチリザルトが表示されたときのクリック率に出ます。効果測定では、掲載順位が横ばいのままクリック率が動いているかを見てください。順位も一緒に動いている場合は、構造化データ以外の要因が混ざっています。

JSON-LDはheadとbodyのどちらに書くべきですか？

どちらでも読み取られます。Googleはheadとbodyのいずれに置かれたJSON-LDも処理すると案内しており、JavaScriptで動的に挿入されたものも対象です。実務ではheadにまとめる構成が保守しやすく、テンプレートの共通部分に置けば全ページへ一括で反映できます。ただしJavaScriptによる挿入を選ぶ場合は、レンダリング後に確かに出力されているかをリッチリザルトテストで確認してください。

FAQの構造化データは今から削除すべきですか？

急いで消す必要はありません。FAQPageのマークアップが残っていても不利益は生じず、Google側も既存の記述をそのままにしてよいとしています。ただし2026年5月7日に検索結果への表示が止まり、6月にはレポートやテストの対応も取り下げられました。表示される見返りはもうありません。新規案件でFAQ実装が見積りに入っていたら、その工数は削ってかまいません。

WordPressのプラグインだけで足りますか？

コーポレートサイトやオウンドメディアなら足りることが多いです。主要なSEOプラグインは組織・記事・パンくずを自動で出力するため、必要な型がすべて揃っている場合はそれで完了します。まずリッチリザルトテストで現状の出力を確認し、足りない型だけを補ってください。注意したいのはテーマ側との二重出力で、同じ型が2つ出ていると採用される側が不定になります。ECのように在庫や価格を連動させる場合は、プラグインだけでは届きません。

構造化データが正しく認識されたかはどう確認しますか？

2段階で確認します。開発中はリッチリザルトテストにURLまたはコードを入力し、検出された型と警告・エラーを潰します。公開後はサーチコンソールのリッチリザルト ステータスレポートで、有効なアイテム数とエラー数の推移を追ってください。テストは書き方の妥当性、レポートは実際のクロール結果という違いがあり、片方だけでは検知できない事故があります。テンプレート改修の直後は特に、有効数の急減が起きていないかを見る運用にしておくと安全です。

関連記事

• テクニカルSEOとは？主要施策と優先順位つきチェックリスト：構造化データを含む技術面の施策を、着手順で整理しています
• SEO内部対策とは？クロール・インデックス・UXの3分類で解説：構造化データより先に手を付けるべき内部施策の全体像です
• エンティティSEOとは？構造化データとナレッジグラフの実装手順：組織や人物の実体を検索エンジンへ伝える応用的な設計です
• パンくずリストとは？SEO効果と構造化データの実装・階層設計：最初に着手すべき機能の設計を詳しく扱っています
• FAQリッチリザルトとは？2026年の廃止で何が変わったか：FAQ構造化データの現状と代替の打ち手をまとめています