「構造化データを入れた方がいい」と聞いて調べ始めたものの、種類の多さと情報の古さに戸惑っていませんか。検索結果には2022年ごろの記事と2026年の記事が混在しており、どれを信じて手を動かせばよいか判断しづらい状況です。実際、かつて定番だったFAQやHowToのリッチリザルトはすでに終了しており、古い手順のまま実装すると工数が無駄になります。2026年の構造化データ実装は、終了した種類を避けて、効果が残る種類から優先順位をつけて進めるのが前提です。この記事では、Googleの公式情報を当日付で確認したうえで、JSON-LDの書き方から検証、やってはいけない実装までを、社内で再現できる手順として整理しました。
この記事でわかること
- 2026年時点で実装する価値がある構造化データの種類と優先順位
- FAQ・HowToリッチリザルト終了後の既存データの扱い方
- JSON-LDの書き方・設置場所・検証までの具体的な手順
- 手動による対策の対象になる実装と避け方
まずは、よくある疑問と答えを一覧で確認できるようにしました。
| 疑問 | 短い答え |
|---|---|
| 構造化データとは? | ページの意味を機械向けに宣言する標準形式のデータ |
| SEO効果はある? | 順位の保証はなく、ページ理解の支援とリッチリザルトが主目的 |
| FAQの実装はまだ有効? | 表示は2026年5月に終了。既存データの削除は不要 |
| どの種類から入れる? | Organizationとパンくずリストの2つが出発点 |
| 実装方法は? | プラグイン・支援ツール・JSON-LD直接記述の3つ |
| 検証はどうする? | 公開前はリッチリザルトテスト、公開後はSearch Console |
| 間違えると罰則はある? | 悪質な実装は手動による対策の対象になり得る |
ここからは、定義と現状の整理から実装・検証の手順まで、判断する順番に沿って解説します。
構造化データは検索エンジンにページの意味を伝えるための記述|#i-0
2026年の前提:FAQ・HowToのリッチリザルトは終了した|#i-1
2026年に実装する価値がある種類は用途で絞る|#i-2
実装方法は3つ:プラグイン・支援ツール・JSON-LD直接記述|#i-3
JSON-LDの書き方と設置手順|#i-4
実装後はリッチリザルトテストとSearch Consoleで検証する|#i-5
やってはいけない実装は手動による対策の対象になる|#i-6
AI検索時代も構造化データの役割は意味を伝えることに戻る|#i-7
構造化データ実装のFAQ|#i-8
構造化データは優先順位を絞れば内製で実装できる|#i-9
構造化データは検索エンジンにページの意味を伝えるための記述
そもそも構造化データとは何を書くもので、なぜ必要なのかが曖昧なまま作業に入るのは不安なはずです。結論からいうと、構造化データとは、人間向けの見た目とは別に「これは会社名」「これは記事の公開日」といった意味を機械向けに宣言する記述です。Googleは、構造化データを使ってページの意図を伝えると、そのページをより正確に理解できるようになると説明しています。
まずは、この記事で繰り返し登場する用語を整理します。
- 構造化データ
- ページの内容を検索エンジンが処理しやすい形式で宣言する記述。schema.orgの語彙を使う。
- schema.org
- 構造化データで使う用語(タイプとプロパティ)を定めた共通の語彙集。
- JSON-LD
- 構造化データをscriptタグの中にまとめて書く記法。Googleが推奨する形式。
- リッチリザルト
- 構造化データなどをもとに、通常より情報量の多い形で表示される検索結果。

SEO効果の位置づけは正確に理解しておく必要があります。構造化データを正しく実装しても、検索順位が上がることをGoogleは保証していません。公式ドキュメントにも、正しくマークアップしたページが必ずリッチリザルトとして表示されるとは限らないと明記されています。それでも実装する価値があるのは、検索エンジンがページ内容を誤解するリスクを減らせるうえ、対象の種類ではリッチリザルト表示の候補に入れるためです。SEO全体の中での位置づけを確認したい方は、基本施策をまとめた解説記事もあわせてお読みください。
出典:Google 検索セントラル『構造化データ マークアップとは』(最終更新 2025年12月18日)(2026年8月24日確認)
出典:Google 検索セントラル『Google 検索上の構造化データ ガイドライン』(最終更新 2026年2月20日)(2026年8月24日確認)
2026年の前提:FAQ・HowToのリッチリザルトは終了した
ネットで見かけた記事にFAQの実装手順が載っていて、今もやるべきか迷っている方は多いはずです。結論として、FAQとHowToのリッチリザルトはすでに終了しており、2026年に新規で実装する理由はほぼありません。一方で、Googleは実装済みデータの削除を求めておらず、慌てて剥がす必要もありません。
変更の流れを時系列で整理します。
| 時期 | 変更内容 | 実装済みデータの扱い |
|---|---|---|
| 2023年8月〜9月 | FAQリッチリザルトが政府・保健衛生系サイト限定になり、HowToは表示終了 | 削除は不要とGoogleが明言 |
| 2024年11月21日 | サイトリンク検索ボックス(WebSiteの検索ボックス用途)が終了 | 削除は不要。サイト名用途のWebSiteは継続サポート |
| 2025年〜2026年初頭 | コース情報・給与推定額・学習用動画・特別なお知らせ・車両リスティング・練習問題などが順次終了 | 各ドキュメントが削除された |
| 2026年5月7日 | FAQリッチリザルトがすべてのサイトで表示終了 | 削除は求められていない。公式ドキュメントは同年6月に削除 |
この表から読み取れるのは、FAQだけが特別に廃止されたのではなく、Googleが検索結果の簡素化を数年かけて段階的に進めてきたという流れです。つまり個別の種類を追いかけるより、「今なにが残っているか」を公式の更新履歴で確かめる習慣の方が長持ちします。

2023年の縮小から2026年の終了までの経緯
Googleは2023年8月8日のブログで、FAQリッチリザルトを信頼のおける政府と医療のウェブサイト限定にすると発表しました。同じ発表の9月14日更新では、HowToリッチリザルトがパソコンでも表示されなくなり、サポートが終了したと明記されています。その後、2026年5月8日の公式更新履歴に、FAQリッチリザルトが2026年5月7日をもってGoogle検索に表示されなくなる旨の記載が追加されました。翌月にはFAQの公式ドキュメント自体が削除されており、機能としての役割は完全に終わっています。
出典:Google 検索セントラル ブログ『HowTo とよくある質問のリッチリザルトにおける変更』(2023年8月8日公開)(2026年8月24日確認)
出典:Google 検索セントラル『Google 検索セントラル ドキュメントの更新履歴・最新情報一覧』(公開日記載なし)(2026年8月24日確認)
実装済みのFAQ・HowToデータをどうするか
すでにサイトへ入っているデータの扱いは、削除しないのが基本方針で問題ありません。Googleは2023年の発表で、使われていない構造化データが検索で問題を起こすことはないと説明しています。剥がす作業にはテーマやプラグインの改修が伴い、他の出力を壊すリスクの方が大きいためです。ただし、これから作る新規ページに追加する理由はないため、テンプレートの新規分からは外していくのが現実的な落としどころになります。
2026年に実装する価値がある種類は用途で絞る
種類が多すぎて、どれから手をつければよいか選べないという声をよく聞きます。結論として、全サイト共通で価値が残るのはOrganization・BreadcrumbList・Article・WebSiteの4つです。ただしWebSiteはサイト名指定の用途に限り、業種に応じてLocalBusinessやProductなどを足していきます。全部やろうとせず、自社のページ種類に対応するものだけを選びます。

優先順位の考え方を、用途と対象サイト別に一覧へまとめました。
| 種類 | 主な用途 | 対象サイト | 優先度の目安 |
|---|---|---|---|
| Organization | 会社名・ロゴ・連絡先をGoogleへ伝える | 全サイト | ◎ 最初に実装 |
| BreadcrumbList | サイト階層を伝える(表示はパソコン限定) | 全サイト | ◎ 最初に実装 |
| Article | 記事の見出し・著者・日付を伝える | ブログ・オウンドメディア | ○ 記事型サイトは早めに |
| WebSite | 検索結果に出るサイト名を指定する | 全サイト | ○ 名称の表記揺れが気になる場合 |
| LocalBusiness | 店舗の所在地・営業時間を伝える | 実店舗・地域ビジネス | ○ 該当するなら早めに |
| ProductやレシピなどI | 各分野のリッチリザルト対象 | ECや専門サイト | △ 該当業種のみ |
表で注意してほしいのは、定番とされてきた種類にも条件がついている点です。パンくずリストのリッチリザルトは、2025年1月からモバイルでは表示されずパソコン限定になりました。それでもサイト階層を伝える役割は残るため、優先度は下げていません。WebSiteも、かつての主用途だった検索ボックスは2024年11月21日に終了しており、現在有効なのはサイト名を指定する用途だけです。古い記事の手順を流用するときは、この2点の条件を読み替えてください。
なお、現在サポートされている種類の一覧は、Google検索セントラルの「すべての構造化データ機能」のページで確認できます。実装前にこの一覧へ目を通し、対象の種類がまだ掲載されているかを確かめる手順を社内ルールにしておくと、終了済み機能への投資を防げます。
出典:Google 検索セントラル『Google 検索セントラル ドキュメントの更新履歴・最新情報一覧』(公開日記載なし)(2026年8月24日確認)
出典:Google 検索セントラル ブログ『サイトリンク検索ボックスを終了します』(公開日記載なし)(2026年8月24日確認)
実装方法は3つ:プラグイン・支援ツール・JSON-LD直接記述
自分のスキルでできる方法はどれか、という不安が実装前の最大のつまずきどころです。結論として、WordPressサイトならプラグインが現実解になり、静的サイトや細かい制御が必要な場合はJSON-LDの直接記述を選びます。Googleの支援ツールは、仕組みを学ぶ用途と割り切るのが向いています。
| 方式 | 向く環境 | 必要な知識 | 注意点 |
|---|---|---|---|
| プラグイン | WordPressサイト | 管理画面の操作 | 自動生成の範囲外は結局手書きになる。テーマとの二重出力に注意 |
| JSON-LD直接記述 | 静的サイトや細かい制御が必要な場合 | HTMLの基礎とJSONの構文 | テンプレート化しないと更新漏れが起きやすい |
| マークアップ支援ツール | 学習用途や単発ページ | 管理画面の操作 | 大量ページへの展開には向かない |
この表の使い方として、まず自社サイトがWordPressかどうかで大きく分岐します。GoogleもCMS利用時は設定画面やプラグインで構造化データを指定できる場合があると案内しています。つまりHTMLを直接編集しない実装は、公式に想定された選択肢だと考えて問題ありません。プラグイン方式の特徴を両面から整理します。
プラグイン方式のメリット
- 管理画面の入力だけで基本の種類を自動生成できる
- テンプレート全体へ一括適用でき更新漏れが起きにくい
- HTMLやJSONの知識がなくても始められる
プラグイン方式のデメリット
- 対応範囲外の種類や業種特有の項目は手書きが必要
- テーマ側の出力と重複して二重になることがある
- プラグイン更新や乗り換えで出力仕様が変わり得る
WordPressでのプラグイン選定や初期設定の全体像は、WordPressのSEO設定をまとめた記事で扱っているため、そちらを参照してください。
WordPressはプラグインで基本を自動化する
WordPress運用のサイトなら、SEO系プラグインの設定画面へ会社情報を入力するだけで済む場合が多くあります。OrganizationやBreadcrumbListの出力は、この方法で自動化できます。担当者が実装後に行うべきことは、後述するリッチリザルトテストでの出力確認です。プラグインが何をどのページに出しているかを一度把握しておくと、次の手書き実装との重複を避けられます。
自由度が必要ならJSON-LDを直接書く
業種特有の項目を扱いたい場合や、プラグインを増やしたくない方針の場合は、JSON-LDを直接テンプレートへ記述します。GoogleはJSON-LDを推奨形式としており、その理由をウェブサイト所有者にとって実装と管理が最も容易であるためと説明しています。書き方の具体的な手順は次の章で扱います。
出典:Google 検索セントラル『構造化データ マークアップとは』(最終更新 2025年12月18日)(2026年8月24日確認)
プラグインに頼らない方がよいケース
プラグイン方式が常に正解とは限りません。テーマ自体が構造化データを出力している場合、プラグインと二重に出力されて内容が食い違うことがあります。また、医療や不動産など業種特有のタイプを使いたい場合、プラグインの対応範囲外になることが少なくありません。二重出力の疑いがあるとき、または業種特化の項目が必要なときは、出力箇所をひとつに絞ったうえで直接記述へ切り替える判断が安全です。
JSON-LDの書き方と設置手順
実際のコードをどう書けばよいのか、という点が最も知りたい部分のはずです。結論として、JSON-LDはscript要素のtype属性にapplication/ld+jsonを指定したブロックとして書きます。設置場所はページの<head>内または<body>内のどちらでも問題ありません。最小構成から始めて、必須プロパティを埋めれば動きます。
書き方の全体像として、OrganizationとArticleを最小構成で書いた実例を図にまとめました。図中の会社名やURLの部分を自社の値へ差し替えれば、そのまま使える構成です。

図の内容を自社サイトへ落とし込む手順は次のとおりです。
実装する種類を決める
前章の表を参照優先順位表からOrganizationなど1〜2種類を選びます。
必須プロパティを公式で確認する
所要10分ほど選んだ種類の公式ドキュメントで必須と推奨のプロパティを控えます。
型に自社の値を入れる
図4を参照会社名・URL・ロゴ画像などの差し替え箇所を実際の値へ置き換えます。
scriptブロックとしてページへ設置する
headまたはbody内複数の種類は配列でまとめても、別ブロックに分けても認識されます。
リッチリザルトテストで検証する
所要5分ほどエラーが出た行を修正してから本番へ公開します。

設置場所について補足すると、Googleは<head>と<body>のどちらの<script>タグ内でもJSON-LDを読み取ると明記しています。CMSのウィジェットなどでページへ動的に挿入されるJSON-LDも読み取り対象とされているため、テンプレートの都合に合わせて設置箇所を選んで構いません。1ページに複数のアイテムを入れる場合は、レシピと動画のように親子関係があるものはネストし、記事とパンくずリストのように独立したものは並記します。
出典:Google 検索セントラル『構造化データ マークアップとは』(最終更新 2025年12月18日)(2026年8月24日確認)
出典:Google 検索セントラル『Google 検索上の構造化データ ガイドライン』(最終更新 2026年2月20日)(2026年8月24日確認)
実装後はリッチリザルトテストとSearch Consoleで検証する
正しく入ったかどうか、目に見える変化がないだけに不安が残るところです。結論として、公開前はリッチリザルトテスト、公開後はSearch Consoleのレポートという二段構えで確認します。エラーと警告では対処の重みが異なり、直すべきはエラーの方です。
リッチリザルトテストへURLかコードを入力する
公開前・所要5分重大なエラーをゼロにしてから公開します。警告は改善推奨の扱いです。
URL検査ツールで検出状況を確認する
公開後Googleがページ上の構造化データを検出したかをSearch Consoleで確認します。
リッチリザルトのステータスレポートを定期確認する
月1回目安テンプレート起因のエラー増加を早期に発見できます。
手動による対策レポートを確認する
異変時のみリッチリザルトが急に消えた場合の確認先です。

検証で見落としやすい点を、公開前のチェックリストにまとめます。
公開前のチェックリスト
- リッチリザルトテストで重大なエラーがゼロになっている
- マークアップした内容がページの表示と一致している
- 必須プロパティがすべて埋まっている
- 同じ種類のデータがテーマとプラグインで二重出力されていない
なお、テストを通過してもリッチリザルトの表示は保証されません。Googleのアルゴリズムは検索履歴や位置情報などの要因で表示を調整するため、正しい実装と表示の有無は別問題として扱ってください。また、FAQ関連はテストやレポートのサポートも終了に向かっているため、古い記事にあるFAQの検証手順は現在の画面と一致しない場合があります。そもそもページ自体が検索結果に出ていない場合は、構造化データ以前にインデックスの問題を切り分ける必要があります。
出典:Google 検索セントラル『Google 検索上の構造化データ ガイドライン』(最終更新 2026年2月20日)(2026年8月24日確認)
やってはいけない実装は手動による対策の対象になる
間違えるとペナルティがあるのか、という心配には正確に答えておく必要があります。結論として、悪質な構造化データはGoogleの手動による対策の対象となり、対策を受けたページはリッチリザルトとして表示されなくなります。一方で、Googleは手動による対策がウェブ検索の掲載順位そのものには影響しないと説明しており、順位降下の罰則と混同しないことが大切です。
公式ガイドラインで禁止されている実装は次のとおりです。
ガイドライン違反になる実装
- ページの読者に表示されないコンテンツをマークアップする
- ページの内容と関係のないデータや虚偽のレビューをマークアップする
- 他人や組織になりすます、または所属や目的を偽る記述をする
うっかり違反を避けるコツは、マークアップを書く前にそのページの画面を開き、書こうとしている内容が実際に表示されているかを目視することです。手動による対策を受けたかどうかは、Search Consoleの手動による対策レポートで確認でき、リッチリザルトが急に消えた場合の一次切り分けにも使えます。
出典:Google 検索セントラル『Google 検索上の構造化データ ガイドライン』(最終更新 2026年2月20日)(2026年8月24日確認)
出典:Google 検索セントラル『構造化データ マークアップとは』(最終更新 2025年12月18日)(2026年8月24日確認)
AI検索時代も構造化データの役割は意味を伝えることに戻る
リッチリザルトが減っていくなら、そもそも構造化データは不要になるのではないか、という疑問は自然です。編集部の見解として、リッチリザルトという見返りは縮小したものの、機械にページの意味を正確に伝えるという本来の役割は残ると考えています。根拠のひとつは、Googleが終了した種類についても一貫して削除不要と案内している事実です。表示に使わなくなったデータを害とみなしていない姿勢がうかがえます。
一方で、AI検索の回答生成に構造化データがどの程度使われるかについて、確定的なことは現時点で語れません。過度な期待も不要論も避け、ページ理解を助ける基礎整備として淡々と実装するのが現実的な距離感です。AI検索がSEO全体へ与える影響や対策の考え方は、LLMO対策の解説記事で詳しく扱っています。
構造化データ実装のFAQ
実装前後に寄せられやすい質問をまとめました。本文で扱いきれなかった細かい疑問はこちらで確認してください。
A. 順位への直接の効果は保証されていません。ページ理解の支援とリッチリザルト表示の候補になることが主な目的です。
A. WordPressならプラグインの設定画面から入力する方法があり、コードを書かずに基本の種類を実装できます。
A. 失敗とは限りません。正しい実装でも表示はアルゴリズム次第であり、まずはテストでエラーがないことを確認してください。
A. 問題ありません。関連が深いものはネストし、記事とパンくずリストのように独立したものは並記します。
A. 構造化データは画面に表示される内容を記述するのが原則のため、画面上のパンくず表示とセットで実装するのが安全です。
構造化データは優先順位を絞れば内製で実装できる
種類の多さに圧倒されがちな構造化データも、終了済みの機能を除外して優先順位をつければ、内製チームで十分に扱える施策です。この記事の要点を整理します。
- 2026年の実装はFAQ・HowTo終了後の優先順位で考える
- 最初はOrganizationとBreadcrumbListの2種類で十分
- 形式はJSON-LDに統一し、必須プロパティは公式ドキュメントで確認する
- 公開前テストと公開後レポートの二段構えで検証する
- 画面に表示されない内容のマークアップは手動による対策の対象になり得る
次の一歩としては、自社サイトの任意のページをリッチリザルトテストへ入力し、現状なにが出力されているかを把握することから始めてください。現状把握ができれば、優先順位表のどこから着手すべきかが自然に決まります。テクニカルな部分を含めて自社のSEO体制づくりに不安がある場合は、外部の専門家へ壁打ちする選択肢もあります。