構造化データの実装方法｜JSON-LDの書き方と2026年の優先順位【2026年版】

「構造化データを入れた方がいい」と聞いて調べ始めたものの、種類の多さと情報の古さに戸惑っていませんか。検索結果には数年前の古い情報と現在の仕様が混在しており、どれを信じて手を動かせばよいか判断しづらい状況です。実際、かつて定番だったFAQやHowToのリッチリザルトはすでにGoogle検索での表示を終了しており、古い解説記事のまま実装すると貴重な作業工数が無駄になります。2026年の構造化データ実装は、廃止された種類を避け、効果と役割が明確に残る種類へ優先順位を絞って進めるのが鉄則です。この記事では、Googleの公式ドキュメントと更新履歴を厳密に確認したうえで、JSON-LDの基本構文から安全な検証手順、ペナルティを避ける注意点までを社内で迷わず再現できる手順として整理しました。

この記事でわかること

• 2026年現在も実装価値が残る構造化データの種類と優先順位
• FAQやHowToリッチリザルト終了に伴う既存データの安全な扱い方
• Google推奨のJSON-LDによる記述例・設置場所・検証手順
• 手動による対策の対象となるNG実装とその回避策

まずは、現場でよくある疑問と判断の要点を早見表で確認しましょう。

よくある疑問	判断の目安・結論
構造化データとは？	ページの意味を検索エンジン向けに宣言する標準データ
検索順位への効果は？	順位の直接保証はなく、機械理解の支援とリッチリザルトが目的
FAQ実装はまだ有効？	2026年5月に表示終了。既存コードの削除は不要
何から手をつけるべき？	OrganizationとBreadcrumbListの2つから始める
推奨される実装方法は？	Google推奨のJSON-LD直接記述、またはCMSプラグイン
実装後の検証方法は？	公開前はリッチリザルトテスト、公開後はSearch Console
間違えるとペナルティはある？	画面にない情報のマークアップ等は手動対策の対象になる

※各項目の詳細な条件やコードの書き方は本文の該当章で解説します。

ここからは、構造化データの基礎概念から現在の最新仕様、実践的な書き方と検証手順まで、順番に解説していきます。

構造化データは検索エンジンにページの意味を伝えるための記述

構造化データとは、人間向けのWebデザインとは別に、「これは会社名」「これは記事の著者」「これは公開日」といったコンテンツの意味を、検索エンジンのクローラーに向けて標準化された形式で宣言する記述です。

Googleは公式ドキュメントにおいて、構造化データを用いてページの明示的な手がかりを提供することで、ページの内容をより正確に理解できるようになると説明しています。

まずは、構造化データを扱ううえで頻出する4つの基本用語を押さえておきましょう。

構造化データ

Webページの意味や属性を、検索エンジンが誤解なく処理できるように記述したメタデータ。

schema.org

Google、Microsoft、Yahoo!などが共同で策定した、構造化データで用いる共通の用語集。

JSON-LD

JavaScriptのオブジェクト形式を用いて、HTML内のscriptタグにまとめて記述する推奨記法。

リッチリザルト

構造化データなどを参照し、通常の検索結果よりも視覚的に目立つ形式で表示される検索拡張機能。

SEOにおける構造化データの位置づけは、正しく理解しておく必要があります。構造化データを設置したからといって、検索順位が自動的に跳ね上がるわけではありません。Googleも公式ガイドラインの中で、正しくマークアップされたページであっても、リッチリザルトとしての表示や掲載順位の向上を保証するものではないと明記しています。

それでも多くの企業が実装するのは、検索エンジンによる誤認リスクを排除し、サイトのテーマ性やエンティティ情報を正確に伝えられるからです。検索エンジンの基本的な仕組みやSEOの全体像については、SEO対策とは？初心者向けのやり方と基本施策でも詳しく解説しています。

出典：Google 検索セントラル『構造化データ マークアップとは』（最終更新 2025年12月18日）（2026年9月13日確認）
出典：Google 検索セントラル『Google 検索上の構造化データ ガイドライン』（最終更新 2026年2月20日）（2026年9月13日確認）

2026年の前提：FAQ・HowToのリッチリザルトは終了した

Web上の古い解説記事を読んでいると、「アコーディオン形式のQ&Aを作ってFAQ構造化データを入れよう」と勧められることが多々あります。しかし、FAQとHowToのリッチリザルト表示はすでに完全に廃止されています。これから新規に実装するメリットはほとんどありません。

Google検索におけるリッチリザルト簡素化の変遷を、時系列で確認してみましょう。

実施時期	Googleによる仕様変更の内容	実装済みコードの扱い
2023年8月〜9月	FAQリッチリザルトが政府・医療機関限定へ縮小、HowTo表示が全面終了	コード削除は不要と案内
2024年11月21日	サイトリンク検索ボックス（WebSite検索枠）のサポート終了	削除不要。サイト名指定は継続
2025年〜2026年初頭	学習用動画、特別なお知らせ、練習問題などのリッチリザルトが順次終了	公式ドキュメントが削除
2026年5月7日	FAQリッチリザルトがすべてのサイトで表示終了	削除不要。翌月ドキュメント完全削除

※Google検索セントラルの公式アナウンスおよびドキュメント更新履歴に基づきます。

この流れから分かるように、Googleは検索結果画面をシンプルに保つため、過度なアコーディオン展開を許すリッチリザルトを段階的に整理してきました。個々の流行を追いかけるのではなく、「現在サポートされている公式機能」に絞って対応することが重要です。

2023年の縮小から2026年の終了までの経緯

Googleは2023年8月に、FAQリッチリザルトの表示対象を権威ある政府機関や保健衛生機関のサイトに限定し、HowToの表示を終了しました。さらに2026年5月7日をもって、検索結果上におけるFAQリッチリザルトの表示が全サイトで完全に終了したことが公式更新履歴に明記されました。翌月には該当のドキュメント自体が削除されています。

出典：Google 検索セントラル ブログ『HowTo とよくある質問のリッチリザルトにおける変更』（2023年8月8日公開）（2026年9月13日確認）
出典：Google 検索セントラル『Google 検索セントラル ドキュメントの更新履歴・最新情報一覧』（2026年9月13日確認）

実装済みのFAQ・HowToデータをどうするか

すでにサイト内に埋め込まれているFAQやHowToの構造化データを、慌てて削除する必要はありません。Google公式のアナウンスでも、使われなくなった構造化データがページに残っていても検索上の悪影響はないと説明されています。

無理にコードを撤去しようとしてテンプレートやプラグインの設定を崩してしまうリスクの方が高いため、既存ページはそのまま放置し、今後新設するテンプレートから除外していく運用が最も安全です。

2026年に実装する価値がある種類は用途で絞る

構造化データのボキャブラリーは数百種類以上存在しますが、中小企業やWeb担当者が優先して取り組むべきものはごく一部に限られます。

自社のサイト形態に合わせて、必要な種類だけを選び出しましょう。

スキーマの種類	主な役割と表示面	対象となるWebサイト	優先度の目安
Organization	法人名・ロゴ・代表URL・SNSを明示	すべてのWebサイト	◎ 最優先で設定
BreadcrumbList	サイトの階層構造を伝える（PC表示中心）	すべてのWebサイト	◎ 最優先で設定
Article	記事の見出し・公開日・更新日・著者情報	ブログ・メディア・コラム	○ 記事ページに必須
WebSite	検索結果に表示されるサイト名を指定	すべてのWebサイト	○ 表記揺れ防止に推奨
LocalBusiness	店舗の所在地・電話番号・営業時間	実店舗・地域密着ビジネス	○ 地域集客に重要
Product	商品価格・在庫状況・レビュー評価	ECサイト・物販ページ	△ 該当サイトのみ

※Google検索セントラルの最新サポート状況に基づく優先度分類です。

定番とされてきた種類にも、現在の仕様に合わせた注意点があります。例えばパンくずリスト（BreadcrumbList）は、2025年以降モバイル検索結果での表示が縮小され、主にパソコン検索での表示となっています。ただし、クローラーへサイトの階層構造を伝えるシグナルとしては依然として有用なため、優先度を落とす必要はありません。

また、WebSite構造化データは、かつてサイト内検索窓を検索結果に出すために使われていましたが、その機能（サイトリンク検索ボックス）は2024年11月に終了しました。現在は「検索結果におけるサイト名の表示ゆれを防ぐ用途」として利用します。

出典：Google 検索セントラル『Google 検索セントラル ドキュメントの更新履歴・最新情報一覧』（2026年9月13日確認）
出典：Google 検索セントラル ブログ『サイトリンク検索ボックスを終了します』（2026年9月13日確認）

実装方法は3つ：プラグイン・支援ツール・JSON-LD直接記述

構造化データをWebサイトへ組み込む方法は、大きく分けて3通りあります。サイトの構築環境や運用体制に合わせて、最適な手法を選択してください。

実装方式	向いているサイト環境	必要なスキル	運用の注意点
CMSプラグイン	WordPressなどのCMSサイト	管理画面の操作スキル	テーマ側の機能と重複して二重出力になるリスクあり
JSON-LD直接記述	静的HTMLサイト・独自システム	HTMLとJSONの基礎知識	更新漏れを防ぐためテンプレート共通化が必要
マークアップ支援ツール	学習目的・単発の静的ページ	画面上のGUI操作	ページ数が多いサイトでは手動作業の負荷が大きい

※自社のCMS環境やコード編集の権限に応じて選択します。

WordPressで運用されているWebサイトであれば、SEO系プラグインやテーマ標準の入力機能を利用するのが最も現実的です。HTMLコードを直接編集するリスクを避けながら、主要なスキーマを自動出力できます。

WordPressにおけるプラグインの選定やSEOの初期設定手順については、WordPressのSEO対策で詳しく解説しています。

WordPressはプラグインで基本を自動化する

WordPressサイトの場合、All in One SEOやYoast SEO、あるいは国内主要テーマ（SWELL、Cocoonなど）の設定画面から組織名やロゴ画像を登録するだけで、OrganizationやBreadcrumbListが自動出力されます。

担当者が行うべき作業は、後述のリッチリザルトテストを用いて「意図した情報が重複なく出力されているか」を確認することです。

自由度が必要ならJSON-LDを直接書く

独自開発のWebシステムや、業種特有のプロパティを柔軟に設定したい場合は、JSON-LDをHTMLテンプレートへ直接書き込みます。GoogleはHTML要素にインラインで属性を付与するMicrodata形式よりも、ページ内のどこにでも独立して配置できるJSON-LD形式を強く推奨しています。

出典：Google 検索セントラル『構造化データ マークアップとは』（最終更新 2025年12月18日）（2026年9月13日確認）

プラグインに頼らない方がよいケース

プラグインが常に最善とは限りません。テーマ側ですでにパンくずリストが出力されている状態でプラグイン側でも同じ出力を行うと、二重マークアップとなって警告の原因になります。

また、医療機関や不動産業など、より細分化されたschema.orgのプロパティを正確に記述したい場合は、プラグインの自動出力を一部オフにし、専用のJSON-LDを直接埋め込む方が安全かつ確実です。

JSON-LDの書き方と設置手順

JSON-LDは、HTML内のscript要素（type=”application/ld+json”）の中に記述します。

もっとも汎用的な「組織情報（Organization）」の最小記述例は以下のとおりです。

“`html

自社サイトへ実装する具体的な流れは、以下の5ステップで進めます。

Googleの仕様上、JSON-LDのscriptタグは要素内だけでなく、要素内の末尾などに配置しても問題なくクローラーに読み取られます。

また、1つのページに「記事情報（Article）」と「パンくずリスト（BreadcrumbList）」のように複数の独立したスキーマを共存させる場合は、別々のscriptタグとして並列に並べるか、配列形式で1つのscriptブロックにまとめて記述します。

出典：Google 検索セントラル『構造化データ マークアップとは』（最終更新 2025年12月18日）（2026年9月13日確認）
出典：Google 検索セントラル『Google 検索上の構造化データ ガイドライン』（最終更新 2026年2月20日）（2026年9月13日確認）

構造化データは画面上に直接表示されないため、公開前の構文テストと公開後のインデックス監視という二重の検証が不可欠です。

テスト結果において、赤色の「エラー」は必須プロパティの不足を意味するため修正が必須です。一方、黄色の「警告」は推奨プロパティの欠落を示しており、入力可能な情報がなければそのまま公開してもペナルティを受けることはありません。

本番公開前の最終確認チェックリスト

• リッチリザルトテストで致命的な構文エラー（赤色）がゼロになっている
• マークアップしたテキストが、Webページ上の目に見える本文と完全に一致している
• 指定したロゴ画像やアイキャッチ画像のURLに正常にアクセスできる
• テーマ機能とプラグインによる同一スキーマの重複出力が発生していない

なお、会社名で検索しても自社のホームページが検索結果に表示されないといった根本的なトラブルを抱えている場合は、構造化データの前にインデックス登録や技術的基盤の不備を疑う必要があります。心当たりのある方は、会社名で検索してもホームページが出てこない原因と対処法をご確認ください。

出典：Google 検索セントラル『Google 検索上の構造化データ ガイドライン』（最終更新 2026年2月20日）（2026年9月13日確認）

構造化データの実装において、検索エンジンを欺くような不正な記述を行うと、Googleの手動対策（ペナルティ）を受けるリスクがあります。

手動対策を受けたページはリッチリザルトの表示権利を剥奪されます。公式ガイドラインで厳しく禁止されている代表例は以下のとおりです。

手動対策の対象となる悪質なマークアップ

• Webページを閲覧している人間の目には見えない隠しコンテンツをマークアップする行為
• ページの内容と無関係なキーワードや、架空の偽装レビュー・評価スコアを記述する行為
• 実在しない組織や人物を装ったり、自社の提供実態と異なる権限・所属を偽る行為

ペナルティを回避する鉄則は、「画面上に文字や画像として存在している情報だけをマークアップする」ことです。テンプレートに記述した内容が実際のページ上で視認できるかを、公開前に目視で点検しましょう。

万一手動対策が適用された場合は、Search Consoleの「セキュリティと手動による対策」から警告内容を確認し、問題のあるコードを完全に取り除いたうえで再審査リクエストを提出する必要があります。

出典：Google 検索セントラル『Google 検索上の構造化データ ガイドライン』（最終更新 2026年2月20日）（2026年9月13日確認）
出典：Google 検索セントラル『構造化データ マークアップとは』（最終更新 2025年12月18日）（2026年9月13日確認）

「リッチリザルトの表示が縮小されているなら、もはや構造化データは不要なのではないか」という疑問を抱く方もいるでしょう。しかし、その認識は正確ではありません。

リッチリザルトという派手な装飾表示の枠組みは整理されたものの、「Webページに書かれている実体（企業名、商品、著者など）の意味を検索エンジンに正しく認識させる」という構造化データ本来の役割は、AI検索時代においてむしろ重要性を増しています。

生成AIや大規模言語モデルが検索結果を要約する環境下でも、参照元となるWebサイトの情報が整理されていれば、誤った情報として処理されるリスクを減らせます。AI検索時代の全体的なSEO戦略については、LLMO対策とは？SEOとの違いと対策方法で詳しく解説しています。

企業の現場からよく寄せられる実践的な質問と回答をまとめました。

Q. 構造化データを設置すれば検索順位は上がりますか？

A. 順位の直接的な上昇は保証されていません。検索エンジンにページ内容を正確に理解させ、対応するリッチリザルトの表示資格を得ることが主目的となります。

Q. HTMLやJavaScriptの専門知識がなくても設置できますか？

Q. リッチリザルトテストでエラーがなければ必ず検索結果に表示されますか？

Q. 1つのページに複数の構造化データを記述しても問題ありませんか？

Q. パンくずリストの構造化データを設置する場合、画面上のナビゲーションも必要ですか？

無数にあるスキーマの種類に惑わされる必要はありません。終了した古い機能を切り捨て、自社サイトに必要な数種類に絞り込めば、社内リソースだけでも十分に安全な実装が可能です。

構造化データ実装の重要ポイント総括

• FAQやHowToなどの終了済みリッチリザルトに新規工数を割かない
• 全サイト共通の基本としてOrganizationとBreadcrumbListから着手する
• 記述形式はGoogleが推奨するJSON-LDを採用する
• 本番公開前にリッチリザルトテストで構文エラーをゼロにしておく
• Webページ上に表示されていない隠しテキストは絶対にマークアップしない

まずは自社の代表的なページURLを「リッチリザルトテスト」に入力し、現在どのようなデータが検索エンジンに伝わっているかを可視化することから始めてみてください。現状を把握できれば、次に補強すべき項目はおのずと明確になります。

自社サイトの構造化データ設計や技術的な内部SEOの改善に不安がある場合は、専門家への相談も検討してみてください。