構造化データ for SEO

TL;DR — 構造化データとは、ページに追加する追加コードで、コンテンツの意味をラベル付けするものです — 「これは価格」「これは著者」「これは調理時間」— 検索エンジンが推測する必要がないようにします。これはschema.orgと呼ばれる共有ボキャブラリを使用し、通常はJSON-LDと呼ばれる形式で記述されます。これにより、ページがより豪華な検索結果（星評価、商品カード）の対象になる可能性がありますが、ページのランキングを上げるわけではありません。

構造化データとは

ウェブページを見ると、電話番号と価格、著者名を一目で見分けられます。検索エンジンにはそれができません — ほとんどがテキストとしてしか見えません。構造化データとは、ページに追加する追加コードで、機械向けに「この部分は商品名」「これは評価」「これは公開日」と明示するものです。

これは**schema.org** と呼ばれる共有辞書を使用します — Google、Microsoft（Bing）、Yahoo、Yandexが共同で合意したボキャブラリで、パブリッシャーは消費者間で同じラベルを使用できます。 Evidence for this claim Schema.org provides a shared vocabulary for structured data, while JSON-LD is one supported encoding format. Scope: Schema.org vocabulary and Google structured-data guidance; this does not imply every type is eligible for a Google search feature. Confidence: high · Verified: 2026-07-14 Schema.org ほとんどの場合、JSON-LDと呼ばれる形式で記述されます。ページのHTML内に配置される小さなコードブロックで、訪問者に対するページの見た目を変えずにコンテンツを説明します。

「構造化データ」「スキーママークアップ」「schema.org」はほぼ同じ意味で使われます。厳密には、schema.orgはボキャブラリであり、構造化データは機械可読なラベルの広い概念です。日常のSEOの話では同じ意味です。

なぜ重要か

構造化データには2つの有用な役割があります：

• リッチリザルト。 Googleがラベルを明確に読み取れると、検索結果がアップグレードの対象になる可能性があります — レビューの下の星評価、商品の価格と「在庫あり」、レシピの調理時間、パンくずリストなどです。これらはリッチリザルトと呼ばれ、クリックされる可能性を高めることができます。 Evidence for this claim Valid structured data can make a page eligible for Google search features, but Google does not guarantee that a rich result will appear. Scope: Google Search structured-data guidance; eligibility is distinct from display and ranking. Confidence: high · Verified: 2026-07-14 Google: Structured data introduction
• エンジンがあなたを理解するのを助ける。 OrganizationやPersonなどのマークアップ — 特にブランドや著者をWikipediaやLinkedInのページにリンクするsameAsプロパティ — は、Googleがあなたの「Apple」を果物と区別し、あなたの著者を同名の他の人と区別するのに役立ちます。

多くの人が誤解していること

構造化データはランキングを直接向上させません。 これは最大の誤解です。スキーマを追加しても、キーワードでページのランキングが上がるわけではありません — GoogleのJohn Mueller氏はこれを何度も述べています。メリットは間接的です：リッチリザルトはクリック数を増やし、明確なエンティティシグナルはGoogleの理解を助けます。しかし、「スキーマを追加すればランキングが上がる」というレバーはありません。

さらに2つの正直な注意点：

• リッチリザルトは保証されません。 完璧なマークアップでも、Googleが拡張表示を表示するかどうかを決定します。すべてを正しく行っても、普通の青いリンクのままの場合があります。
• ページに実際にあるコンテンツのみをマークアップします。 訪問者に見えないコンテンツにスキーマを追加しないでください — それはGoogleのルールに違反し、ペナルティを受ける可能性があります。

詳細版 — 3つの形式、リッチリザルトタイプの完全なリスト、削除されたもの、明示的な手がかりが保証するものとしないもの、次のステップ — をご希望ですか？ Advancedタブに切り替えてください。

TL;DR — 構造化データは、schema.org ボキャブラリを、JSON-LD（Google推奨）、Microdata、RDFaの3つの形式のいずれかでページに適用します。検索システムに明示的な手がかりを与え、対応する検索機能でページを利用可能にすることができます。表示やCTRは保証されず、Knowledge Graphへの掲載、AI引用、曖昧性解消を約束するものではありません。直接のランキング要因ではありません — Mueller氏も繰り返し述べています。対応するリッチリザルトのリストは縮小し続けており、2023年にFAQとHowToが削除され、2025年6月にさらに7つのタイプが削除され、FAQリッチリザルトは2026年5月までに完全に削除されました。表示されているコンテンツのみをマークアップし、最も広いパーサーカバレッジを得るために生のHTMLでJSON-LDを優先し、sameAsを含むすべてのプロパティを正確かつページでサポートされている状態に保ってください。

構造化データとは — ボキャブラリと形式

よく混同される2つのことを、最初に明確にしておきましょう。

• schema.orgはボキャブラリ — 型（Product、Article、Recipe、Organization）とプロパティ（price、author、cookTime、sameAs）の共有辞書です。Google、Microsoft、Yahoo、Yandexの共同プロジェクトであり、800以上の型を持つ巨大なものです。Googleはリッチリザルト用にその一部のみをサポートしています。
• JSON-LD、Microdata、RDFaは形式 — そのボキャブラリをページに実際に書き込む3つの方法です。同じ意味を伝える交換可能なキャリアです。

Google自身の定義: “Structured data is a standardized format for providing information about a page and classifying the page content.” (翻訳) 「構造化データは、ページに関する情報を提供し、ページのコンテンツを分類するための標準化された形式です。」

3つの形式 — そしてなぜJSON-LDが勝つのか

3つすべて機能します。GoogleはJSON-LDを*“the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).”* (翻訳) 「ウェブサイト所有者が大規模に実装・維持するのに最も簡単なソリューション（つまり、ユーザーエラーが発生しにくい）」と推奨しています。 Evidence for this claim Google Search supports JSON-LD, Microdata, and RDFa for structured data and generally recommends JSON-LD. Scope: Google Search documentation; individual features can impose additional requirements. Confidence: high · Verified: 2026-07-14 Google: Structured data introduction 自己完結型のブロックであるため、タイプミスがページレイアウトを壊すことはなく、表示されるコンテンツに触れることなく追加、更新、削除が可能です。

人々がつまずく実装上の注意点: JSON-LDはJavaScript（例: Googleタグマネージャー経由）で注入でき、GoogleはJavaScript生成の構造化データのサポートを文書化しています。他のクローラープロバイダーは、完全なJavaScriptレンダリング契約を公開していないのが一般的です。広範な機械可読性が重要なら、JSON-LDをサーバーサイドでレンダリングし、生のHTMLレスポンスに含めてください — これはカバレッジの選択であり、名前付きのAIクローラーがすべてJavaScriptを実行できないという証明ではありません。これについてはSchema Markup for AIで詳しく説明しています。

構造化データがサポートできるもの

サポートされる用途1: 検索機能。 構造化データは、ページを拡張されたSERP表示の対象にすることができます。Googleのケーススタディは、名前付き実装の結果を報告しています: Rotten TomatoesはCTRが25%向上、NestléはリッチリザルトページでCTRが82%向上、Food Networkは訪問数が35%増加しました。ただし、対象という言葉に注意してください — Googleは明示的に次のように述べています: “Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly.” (翻訳) 「Googleは、ページが正しくマークアップされていても、構造化データが検索結果に表示されることを保証しません。」 これらのケーススタディは、別のサイトで同じ表示やCTRの変化を保証するものではありません。

対応する用途2：明示的な手がかり。 外観に加えて、Googleは構造化データを理解のために使用すると述べています — 「ウェブと世界一般に関する情報、例えばマークアップに含まれる人物、書籍、企業に関する情報を収集するため」。この記述は、ナレッジパネル、ナレッジグラフへの掲載、AI Overviewとの関連付け、ブランド認知の変化、引用を約束するものではありません。sameAs は同じ実体に関する別のURLを識別します。正確に使用してください。ただし、これを保証された曖昧性解消の手段と呼んではいけません。

排除すべき神話：構造化データはランキング要因ではない

これはトピック全体の正確性の要です。構造化データはオーガニック検索結果の直接的なランキングシグナルではありません。 John Muellerは長年にわたってこれを何度も確認しています。ページはスキーマがあるからといって上位にランクされるわけではありません。SEO上の価値は、サポートされている検索機能への適合性と、より明確な機械可読な手がかりにあります。外観、CTRへの影響、エンティティの扱い、ランキングの変化はすべて個別に観察する必要があります。

ツールや代理店が「スキーマを追加すれば上位表示される」と売り込む場合、その仕組みは間違っています。リッチリザルトは表示を変えるかもしれません。実際の効果を測定してください。

Googleがサポートするリッチリザルトの種類 — そして削除されたもの

GoogleはサポートされているタイプのSearch Galleryを維持していますが、そのリストは時間とともに縮小しており、オンラインの記事のほとんどは古くなっています。ギャラリーの最終更新（2026-06-15）時点で、サポートされているセットは25タイプです：Article、Breadcrumb、Carousel、Course info、Dataset、Discussion forum、Education Q&A、Employer aggregate rating、Event、Image metadata、Job posting、Local business、Math solver、Movie、Organization、Product、Profile page、Q&A、Recipe、Review snippet、Software app、Speakable、Subscription/paywalled content、Vacation rental、Video。

削除されたもの — ここがほとんどのガイドが間違っている点です：

• HowTo リッチリザルトは2023年にデスクトップから削除され、その後制限されました。
• FAQ リッチリザルトは2023年に政府および医療サイトに制限され、その後2026年5月までに完全に削除されました。 FAQPage タイプは依然として有効なマークアップです — 大多数のサイトでSERP拡張を生成しなくなっただけです。
• 2025年6月にさらに6つのタイプが削除されました： Claim Review、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing、および旧形式の単一コース「Course Info」です。Googleは同じバッチで7つ目 — Book Actions — を発表しましたが、実際の2025年9月の削除からは除外され、Googleは後にそのドキュメントから非推奨バナーを削除しました。これは依然として狭い登録制の機能です（詳細はBook schemaを参照）。

結論：存在しなくなったリッチリザルトを中心に戦略を構築せず、視覚的な拡張がなくなったからといって有効なマークアップを慌てて削除しないでください。

構造化データの実装方法

信頼できる手順：

1. ページに実際にあるものに合った正しいタイプを選ぶ（商品ページにはProduct、ブログ記事にはArticle、ロケーションページにはLocalBusiness）。
2. JSON-LDを書く — 手書き、ジェネレーター（GoogleのStructured Data Markup Helper、Dentsuのジェネレーター）、またはCMSプラグイン（Yoast、Rank Math）を使用。
3. 必須プロパティを最初に、次に推奨プロパティを埋める。 Google：「可能な限りすべての推奨プロパティを提供しようとするよりも、少なくても完全で正確な推奨プロパティを提供する方が重要です。」 正確さは網羅性に勝ります。
4. リッチリザルトテストとschema.orgバリデーターで検証する。
5. レンダリング段階を文書化していないパーサーには、生のHTML配信を優先する。
6. デプロイ後にGoogle Search Consoleのリッチリザルトレポートを監視する。

そして重要なポリシー：表示されるコンテンツのみをマークアップし、正確に保つこと（偽のレビューや評価を付けない）、構造化データのページをGooglebotからブロックしないこと、そしてページの正規版と重複版の両方に同じマークアップを適用することです。

構造化データとAI検索

スキーマがAI回答で引用される鍵だと思い込むのは魅力的です。しかし、最良の証拠はそれが直接的なレバーではないことを示しています — Ahrefsの1 885ページの調査では、JSON-LDを追加してもどのプラットフォームでもAI引用はほとんど動きませんでした。GoogleはAI機能のために*「追加する必要のある特別なschema.org構造化データはない」*と述べています。正確なスキーマは明示的な機械可読なアサーションを提供しますが、プロバイダーの利用、エンティティの解決、引用の結果は保証されておらず、別途証拠が必要です。詳細はAI向けスキーママークアップをご覧ください。

Bingは構造化データを使用しますか？

はい。Bingは3つの形式すべてでschema.orgマークアップを読み取り、独自のリッチ結果（レシピ、イベント、商品、FAQ、ハウツー、動画）に使用し、エンティティの曖昧性解消のためにSatoriナレッジベースにフィードします。Bing Webmaster Toolsにはマークアップバリデータが含まれており、MicrosoftのFabrice Canel氏はスキーマがBingのLLMがコンテンツを理解するのに役立つと述べています — これを公式に確認した唯一のAIプラットフォーム担当者です。

次に進む場所

このハブは地図です。このサブクラスターの詳細な解説：

• スキーママークアップ — schema.orgボキャブラリー自体：すべてのSEO担当者が知っておくべき一般的なタイプ （Organization、Product、Article、BreadcrumbList）、@idと@graphが それらをどのように接続するか、そしてページに適したタイプの選び方。
• JSON-LD — 推奨される 形式を詳しく：構文、<script>ブロックの配置場所、サーバーサイドと クライアントサイドのレンダリング、そしてその記述と検証方法。
• リッチ結果 — SERPの拡張機能自体：どのタイプがまだ存在するか、対象資格、 削除・非推奨、そしてSearch Consoleでの追跡方法。
• ImageObjectスキーマ — 単独で、またProduct/Article/Recipe内にネストされて使用されるメディアタイプ。
• カルーセルのリッチ結果 と**ItemListスキーマ** — Googleのカルーセル機能の背後にあるメカニズムと、その下にある汎用リストタイプ （BreadcrumbListを含む）。
• MerchantReturnPolicy と**OfferShippingDetails** — Merchant Centerのリスティングがますます要求するOfferレベルのプロパティ。
• Speakableスキーマ — 音声アシスタントの読み上げ用の、狭くまだベータ版のマークアップ。
• @idと@graphによるスキーマのネスト — エンティティを再宣言する代わりにリンクするためのより深いハウツー。
• 一般的な構造化データエラー — リッチリザルトテストとSearch Consoleが実際にフラグを立てるものと、その修正方法。
• スキーマとリッチ結果の非推奨 — 何が削除または縮小されたかの、継続的で日付付きのタイムライン。

このサブクラスターは、より広い オンページSEO クラスター内にあります — メタタグ、ヘッダータグ、画像SEO、その他のオンページシグナルと並んでいます。密接に関連するエンティティの作業は、エンティティSEOと AI向けスキーママークアップにあります。

AIまとめ

Advancedバージョンの簡潔な見解:

• 語彙と形式。 schema.orgは共有語彙（800以上のタイプ）です。 JSON-LD、Microdata、RDFaはそれを運ぶ3つの形式です。Googleは JSON-LDを最もエラーが少ないものとして推奨しています — 3つすべてがサポートされています。
• 文書化された価値: サポートされている検索機能の対象となることと、ページの意味に関する明示的な手がかり。表示、CTR向上、Knowledge Graphへの掲載、AI引用、ランキング変更は保証されません。sameAsは正確でなければなりませんが、約束された手段ではありません。
• ランキング要因ではない。 構造化データはランキングを直接改善するものではありません — Mueller氏が繰り返し述べています。機能の表示やその他の結果には、個別の測定が必要です。
• サポートされるリストは縮小しています。 HowToはデスクトップから削除（2023年）;FAQは2023年に制限され、2026年5月までに完全に削除されました（FAQPageタイプは有効のまま）;2025年6月に6つのタイプが削除されました（Claim Review、Estimated Salary、Learning Video、Special Announcement、Vehicle Listing、旧Course）;Book Actionsは同じバッチで発表されましたが、実際には削除されませんでした。
• 実装: 適切なタイプを選び、必須プロパティを最初に埋め、検証し（リッチリザルトテスト + schema.orgバリデーター）、広範なパーサーカバレッジのために生のHTML配信を優先し、Search Consoleで監視し、表示されているコンテンツのみをマークアップします。
• AI検索: スキーマはエンティティのインフラストラクチャであり、引用の手段ではありません — GoogleはAI機能のための「特別なスキーマはない」と述べています;Ahrefsの1 885ページの調査では引用の向上は見られませんでした。
• Bingは自社のリッチリザルトとSatoriナレッジベースのためにスキーマを読み取ります;Fabrice CanelはそれがBingのLLMに役立つことを確認しました。
• 次に進む場所: schema-markup（語彙）、json-ld（形式）、rich-results（SERPの拡張機能）。

公式ドキュメント

検索エンジンとschema.orgからの一次情報のドキュメント。

Google

• 構造化データマークアップの仕組みの紹介 — 定義、3つの形式、JSON-LDを選ぶ理由、リッチリザルトのビジネスケース。
• 構造化データ検索ギャラリー — サポートされているリッチリザルトタイプの現在のリスト（リストが変更される際の正規の情報源）。
• 構造化データの一般的なガイドライン/ポリシー — 可視性、正確性、スパムのルール;リッチリザルトの「保証なし」。
• AI機能とあなたのウェブサイト — 「追加する必要のある特別なschema.org構造化データはない」という記述。

Bing / Microsoft

• 構造化データでサイトをマークアップする — Bing Webmasterヘルプ — Bingの構造化データガイダンス;JSON-LD推奨、ページのコンテキストと一致する必要があります。
• Bing Webmaster Tools — マークアップバリデーター — スキーマをテストするためのBingのツール（Webmaster Tools内）。

schema.org

• schema.org — 共有語彙そのもの。
• Organization · Product · Article · sameAs — 一般的なタイプと同一エンティティのURL関係。

ソースからの引用

Googleとschema.orgからの公式声明。ページがテキストを公開している場合、リンクは引用された箇所にジャンプするディープリンクです。

Google — 構造化データとは何か、そして何をするのか

• “Structured data is a standardized format for providing information about a page and classifying the page content.” (翻訳) 「構造化データは、ページに関する情報を提供し、ページのコンテンツを分類するための標準化された形式です。」 — Google Search Central. 引用にジャンプ
• “Google uses structured data that it finds on the web to understand the content of the page, as well as to gather information about the web and the world in general, such as information about the people, books, or companies that are included in the markup.” (翻訳) 「Googleは、ウェブ上で見つけた構造化データを使用して、ページのコンテンツを理解するだけでなく、マークアップに含まれる人物、書籍、企業などの情報を含む、ウェブと世界一般に関する情報を収集します。」 引用にジャンプ
• On JSON-LD: the recommended format is “the easiest solution for website owners to implement and maintain at scale (in other words, less prone to user errors).” (翻訳) 「ウェブサイト所有者にとって、大規模に実装および維持するのが最も簡単なソリューション（つまり、ユーザーエラーが発生しにくい）です。」 引用にジャンプ
• “It is more important to supply fewer but complete and accurate recommended properties rather than trying to provide every possible recommended property with less complete, badly-formed, or inaccurate data.” (翻訳) 「不完全で、形式が不適切で、不正確なデータで可能な限りすべての推奨プロパティを提供しようとするよりも、少なくても完全で正確な推奨プロパティを提供する方が重要です。」 引用にジャンプ

Google — 「保証なし」ルールとポリシー

• “Google does not guarantee that your structured data will show up in search results, even if your page is marked up correctly.” (翻訳) 「ページが正しくマークアップされていても、Googleは構造化データが検索結果に表示されることを保証しません。」 引用にジャンプ
• “Don’t block your structured data pages to Googlebot using robots.txt, noindex, or any other access control methods.” (翻訳) 「robots.txt、noindex、その他のアクセス制御方法を使用して、構造化データページをGooglebotにブロックしないでください。」 引用にジャンプ

Google — AI機能向けの特別なスキーマは不要

• “You don’t need to create new machine readable files, AI text files, or markup to appear in these features. There’s also no special schema.org structured data that you need to add.” (翻訳) 「これらの機能に表示するために、新しい機械可読ファイル、AIテキストファイル、またはマークアップを作成する必要はありません。追加する必要がある特別なschema.org構造化データもありません。」 — Google Search Central、AI機能のドキュメント。 ソース

構造化データ実装チェックリスト

構造化データが正しく、適格で、実際に読み取り可能であることを確認するためのパス：

• ページに適した型 — 商品ページにはProduct、投稿にはArticle、 ロケーションページにはLocalBusiness。ページに一致しない型は追加しない。
• 表示されているコンテンツのみをマークアップ — ページにないものを説明するフィールドは含めない （Googleのポリシー。不一致は手動による対策のリスク）。
• 形式はJSON-LD — Googleの推奨。最もエラーが発生しにくい。
• 必須プロパティを最初に記入し、次に推奨プロパティ — 網羅性と正確性が 広さに勝る。
• サーバーサイドでレンダリング — 生のHTML（ソースの表示 / curl）に含まれていることを確認し、 クライアントサイドのJS / タグマネージャー経由でのみ注入されないようにする。これにより、AIクローラーや レンダリングしないパーサーが読み取れる。
• Organizationマークアップをサイト全体に設定し、sameAs配列（Wikidata、 Wikipedia、LinkedIn）を入力 — また、すべてのsameAs値を再確認し、エンティティを 誤った組織にリンクしないようにする。
• 削除されたリッチリザルトに依存しない — FAQ（2026年5月までに完全に削除）と HowTo（2023年以降デスクトップで非対応）は、ほとんどのサイトでSERP拡張を生成しなくなった。 これらを中心に戦略を構築しない。
• リッチリザルトテスト と schema.orgバリデーター で検証済み。
• 正規ページ + 重複ページ間で一貫性 — すべてのバージョンで同じマークアップ。
• 時間に敏感なデータを最新に保つ — 古い情報（過去のイベント、古い 価格）はリッチリザルトの表示を妨げる。
• Search Consoleで監視 — デプロイ後にリッチリザルト / 拡張レポートで エラーと警告を確認。
• 期待値を設定 — スキーマはリッチリザルトの対象となる（決して 保証されない）ものであり、エンティティの理解を助ける。直接のランキング要因ではない。

構造化データ — チートシート

語彙 vs. 形式

現在サポートされているGoogleリッチリザルトの種類（25種類、GoogleのSearch Galleryによる、最終更新日：2026年6月15日）

記事 · パンくずリスト · カルーセル · コース情報 · データセット · ディスカッションフォーラム · 教育Q&A · 雇用主の総合評価 · イベント · 画像メタデータ · 求人情報 · ローカルビジネス · 数学ソルバー · 映画 · 組織 · 商品 · プロフィールページ · Q&A · レシピ · レビュースニペット · ソフトウェアアプリ · Speakable · サブスクリプション/ペイウォール コンテンツ · バケーションレンタル · 動画。

削除 / 非推奨 — これらを中心に戦略を構築しない

早わかり

• ランキング要因ではない — 表示とCTRへの影響は測定する必要がある。
• JSON-LDが推奨。<script type="application/ld+json">ブロックに配置する。
• 生のHTML配信を推奨 — プロバイダーのレンダリングサポートは異なり、多くの場合 文書化されていない。クローラー固有の主張をする前に、名前付きクローラーを検証する。
• sameAs は同じエンティティに関する別のURLを識別する。結果の約束は避ける。
• リッチリザルトは決して保証されない、完璧なマークアップでも。
• 検証: リッチリザルトテスト + schema.orgバリデーター。監視: Search Consoleの拡張レポート。

自分でテスト: 構造化データ

構造化データがSEOに与える影響——そして与えない影響——についての5つのクイッククエスチョン。それぞれ答えを選んで、確認してください。

時間をかける価値のあるリソース

私の構造化データに関する記事

• 構造化データ：その概要と使い方 — スキーマタイプ、実装方法、検証ツール、AI検索の観点、sameAsのリスクを解説した私のAhrefsガイド。
• 技術的SEOの初心者向けガイド — 構造化データがより広い技術的全体像の中でどのように位置づけられるか。

公式

• Googleの構造化データマークアップの仕組みの紹介 — 定義、形式、JSON-LDを選ぶ理由、ビジネスケースを解説する標準的なリファレンス。
• Googleの構造化データ検索ギャラリー — サポートされているリッチリザルトタイプの最新リスト。
• Googleの構造化データの一般的なガイドライン — ポリシー（可視性、正確性、「保証なし」）。
• schema.org — 語彙そのもの。

業界の情報源から

• 構造化データでサイトをマークアップする — Bing Webmaster Help — Bingの構造化データガイダンスとMarkup Validator。
• Microsoft Bing/CopilotがLLMにスキーマを使用 — Search Engine Land — スキーマがBingのLLMに役立つというFabrice Canel氏の確認を報じた記事。
• Googleが検索からFAQリッチリザルトを削除 — Search Engine Journal — FAQリッチリザルトの削除と、引き続き有効なものを報じた記事。
• スキーママークアップがAI検索にどう適合するか — 誇張なしで — Search Engine Land — スキーマは引用レバーではなくエンティティインフラストラクチャであるという主張。
• Dentsu Schema Markup Generator — 一般的なタイプのJSON-LDを生成するための無料ツール。

マークアップが有効かつ対象であることを証明する

ここでは2つの異なる問題が発生し、それぞれ異なるテストが必要です。マークアップは構文解析は正常でも、必須プロパティが欠落しているためにリッチリザルトの対象外となることがあり、またテンプレートの変更によって動作していたマークアップが静かに壊れることがあります。有効 ≠ 対象 ≠ 表示。

テスト1 — JSON-LDがエラーなく構文解析される

• 実行するテスト — URLまたはJSON-LDをスキーマバリデータ（またはschema.orgのバリデータ）に貼り付けます。
• 期待される結果 — タイプが検出され、構文/解析エラーがないこと — 有効なJSON-LD、正しい@type、不正なネストがないこと。
• 失敗の解釈 — 解析エラーは通常、テンプレートのバグを意味します — エスケープされていない引用符、文字列が期待される場所でのnull値、またはページ上の競合する2つのブロック。
• 監視期間 — 即時。
• ロールバックのトリガー — テンプレートデプロイ後にバリデータがタイプをまったく検出できない場合 — マークアップがレンダリングされていません。テンプレートの変更をロールバックしてください。

テスト2 — ページがリッチリザルトの対象である

• 実行するテスト — URL を リッチ結果適合性チェッカー と Google の リッチ結果テスト に通します。
• 期待される結果 — 対象の機能が、必須プロパティをすべて備えた状態で 「適合」 と報告されること（推奨プロパティの警告は問題ありません）。
• 失敗の解釈 — 「有効だが適合しない」とは、その機能に必須プロパティが欠けていることを意味します。適合性は Google が結果を 表示する ことを保証するものではなく、一部のタイプ（例: FAQ）はリッチ結果として完全に非推奨になっていることに注意してください。
• 監視期間 — 適合性については即時。結果が実際に 表示される かどうかを追跡する場合は、GSC の リッチ結果拡張レポート と検索表示を 2〜4 週間にわたって監視します。
• ロールバックのトリガー — テンプレート変更後に GSC 拡張レポートの有効な項目が減少する、または「適合」がエラーに変わる場合、必須プロパティを壊す変更があったことを意味します。元に戻して再テストしてください。

変更履歴