schema.orgの構造化データは、仕様どおりに書けても「Googleに反映されない」「スパム扱いされる」といった実装後の失敗が起きがちです。原因は大きく、Google非対応スキーマへの無駄な工数、必須プロパティの欠落や@type誤記述、そしてページに見えない情報をマークアップするスパム扱いの3つに集約されます。本記事では代表的な7つの注意点を、原因から回避策、検証方法まで一気通貫で整理し、Google公式ガイドラインに沿った正しい実装へ修正するためのチェックリストを提示します。
- 実装失敗の原因は「非対応・誤記述・スパム扱い」の3つに集約される
- FAQ縮小・HowTo廃止など仕様変更に無駄な工数をかけない
- 検証は二層構造で、公式ツールとSearch Consoleで継続監視する
Google公式ポリシーに沿えば、リッチリザルトやAI検索での正確な理解につながる実装へ修正できます。
schema.org実装はなぜ失敗する？原因は3つに集約される
schema.org実装の失敗は、突き詰めると「Google非対応・仕様変更のスキーマに工数をかけている」「必須プロパティ欠落や@typeなどの誤記述」「ページに見えない情報や無関係な情報をマークアップするスパム扱い」の3つに分類できます。まずはこの全体像を押さえると、原因の切り分けが一気に進みます。
TechSuite株式会社の「AI検索パートナーズ」は、生成AIが引用・推薦する仕組み（構造化データ・意味的文脈・エンティティ認識・想定質問の分解）を技術的に捉えて施策へ落とし込み、schema.orgを一次情報設計まで踏み込んで整備する支援を行っています。
そもそも構造化データ・schema.orgとは？
構造化データとは、ページの内容を検索エンジンが理解できる形式で記述する共通ボキャブラリで、schema.orgはその語彙の標準規格です。構造化データはページ内容を機械可読にして、リッチリザルトや検索エンジンの正確な理解を促す土台になります。GoogleはJSON-LDを推奨しており、リッチリザルトの表示可否はこの記述の正確さに左右されます（Google検索セントラル）。
実装が失敗する3大原因とは？
失敗の多くは、仕様は書けても「Googleが表示する条件」を満たしていないことに起因します。構文的に正しくても品質ガイドラインに違反すればリッチリザルトは表示されません。品質ガイドライン違反は自動ツールで検出しにくく、スパム扱いされる可能性もあると公式が明記しています（構造化データの一般的なガイドライン）。
この記事で扱う7つの注意点は？
本記事は次の7点を順に検証します。実装前後の見直しに使えるよう、原因と回避策をセットで解説します。
失敗を防ぐ7つの注意点は以下のとおりです。
- Google非対応・仕様変更スキーマに工数をかけていないか
- 必須プロパティ欠落や@type誤記述がないか
- 見えない情報・無関係な情報をマークアップしていないか
- 過剰マークアップやコンテンツとの矛盾がないか
- 記法と配置場所が適切か
- 実装方法に起因する事故を防げているか
- 検証・監視を継続できているか
まずは「非対応・誤記述・スパム扱い」の3分類で原因を切り分けるのが近道ですね。
Google非対応・仕様変更のスキーマにどう対処する？
schema.orgに定義があっても、Googleがリッチリザルトとして表示するとは限りません。FAQやHowToのように縮小・廃止された種別に工数をかけないことが、最初の注意点です。仕様は年単位で変わるため、最新の公式アナウンスを起点に判断することが欠かせません。
TechSuite株式会社の「AI検索パートナーズ」は、LLMO/GEO/AEOの仕様変化を研究とデータで継続的に追従し、非対応スキーマへの無駄な投資を避けながら効果が残る構造化データへ再設計する支援を行っています。
schema.orgに書けてもGoogleが表示するとは限らない？
schema.orgは検索エンジン共通の語彙であり、Googleが対応する種別は公式ドキュメントで別途規定されています。本家仕様に存在する種別でも、Googleのリッチリザルト対象でなければ表示されません。「書けること」と「Googleが検索結果で表示すること」は別問題だと理解するのが出発点です。
FAQは縮小・HowToは廃止された？
2023年8月、Googleは検索体験の整理のため、FAQリッチリザルトの表示を縮小し、HowToをデスクトップ限定へ変更すると発表しました（Google検索ブログ）。FAQリッチリザルトは権威ある政府・医療系サイトのみが表示対象となり、多くのサイトでは表示されなくなりました。表示を前提に工数を割いていた場合は見直しが必要です。
data-vocabulary.orgは書き換えが必要？
パンくずリストの旧仕様であるdata-vocabulary.orgは非推奨（deprecated）となり、Search Consoleで「data-vocabulary.org schema deprecated」の警告が出ます（ITRA）。古い仕様はschema.orgのBreadcrumbListへ早めに書き換える必要があります。古いテンプレートを流用しているサイトで特に見落とされがちです。
表示されなくなったスキーマは削除すべき？
結論として、無理に削除する必要はありません。Googleは、使われない構造化データを残しても検索上の問題はないとしています（Google検索ブログ）。機械可読性の観点からは残す価値もあるため、更新コストと相談して判断すると良いでしょう。
「書けるか」より「Googleが表示するか」を公式で確認する癖をつけたいところです。
AI検索パートナーズでは、
AIに”選ばれる”ための戦略設計から実行まで支援！
必須プロパティ欠落や誤記述をどう防ぐ？
リッチリザルト対象外になる典型は、必須プロパティの欠落と@type・@contextの誤記述です。各リッチリザルトには必須プロパティ（required properties）があり、これを満たさないアイテムは対象外になります（Google品質ガイドライン）。まずは対象種別の必須項目を仕様書で確認することが基本です。
TechSuite株式会社の「AI検索パートナーズ」は、技術実装を担う人材とコンテンツ制作人材が一つのチームで連携し、@typeの階層設計から必須プロパティの充足、効果測定までを一気通貫で伴走します。
@type・@contextの誤りとは？
@contextの指定漏れや、@typeのスペルミス・大文字小文字の相違は、構造化データが認識されない代表的な誤記述です。@typeとプロパティ名はschema.orgの正確な表記に合わせないと機械が解釈できません。入れ子（nesting）で親子関係が崩れているケースも多く、階層の整合性を検証ツールで必ず確認します。
必須プロパティと推奨プロパティの違いは？
必須プロパティは満たさないとリッチリザルト対象外になる項目、推奨プロパティは表示品質を高める任意項目です。両者の違いは次の表のとおりです。
| 区分 | 役割 | 欠落した場合 |
|---|---|---|
| 必須プロパティ | 表示に不可欠 | リッチリザルト対象外 |
| 推奨プロパティ | 表示品質の向上 | 表示はされうるが情報が減る |
まずは必須を満たし、次に推奨で情報量を高める順序が効率的です。
最も具体的なtypeを選ぶ理由は？
Googleは、schema.orgで定義された中で最も具体的なtypeとプロパティ名を使うことを推奨しています（Specificity）。曖昧な上位typeより具体的なtypeを選ぶほど検索エンジンの理解が正確になります。たとえば汎用的なThingではなく、商品ならProduct、店舗ならLocalBusinessのように内容に即した種別を選ぶことが望ましいとされています。
必須を満たし、具体的なtypeを選ぶ。この2点だけでも認識率はぐっと上がります。
AI検索パートナーズでは、AIに”選ばれる”ための戦略設計から実行まで一気通貫で支援！
AI検索パートナーズでは、AI検索の専門知識と支援実績を持つ専任コンサルタントが、AIに“引用される・選ばれる”ための戦略設計からコンテンツ最適化、効果測定・改善まで一気通貫でご支援いたします。
ご興味のある方は、ぜひ資料をダウンロードして詳細をご確認ください。
スパム扱い・過剰マークアップをどう回避する？
スパム扱いを避ける絶対ルールは、ページに見えない情報や無関係な情報をマークアップしないことです。Googleは、読者に見えないコンテンツをマークアップしてはならないと明記しています（Content・Relevanceガイドライン）。構造化データはページの真の表現でなければなりません。
TechSuite株式会社の「AI検索パートナーズ」は、サイト・コンテンツ・検索導線の構造を捉えてスパムリスクのボトルネックを特定し、業種や商材に合わせた回避策を個別設計して実行まで伴走します。
見えない情報・無関係な情報はなぜNG？
JSON-LDはブラウザに表示されず実コンテンツと独立するため、偽の情報を検索エンジンにだけ見せるスパムが技術的に容易だと指摘されています（鈴木謙一氏ブログ）。ページに存在しない評価や、記事と関連性のない情報をマークアップすると品質ガイドライン違反になります。木工手順をレシピとして記述するような不一致はRelevance違反にあたります。
手動対策を受けるとどうなる？
スパム行為のある構造化マークアップで手動対策を受けても、クロール・インデックス・ランキングには悪影響が出ないとされます（鈴木謙一氏ブログ）。順位は下がりませんが、リッチスニペットは検索結果から消えます。影響範囲を正確に切り分けることで、過度に恐れず正しく修正できます。
評価の水増しなどやりがちなNGは？
典型的な違反は、レビューが無いのに評価をマークアップして星を表示させる、記事と無関係なレシピを記述するなどです。回避には、実コンテンツと構造化データを常に一致させる原則を守ります。修正後は再審査リクエストで手動対策が解除されます。
スパム扱いを避けるチェックリストです。
- ページに実在する情報だけをマークアップしているか
- 評価・レビューは実データと一致しているか
- ページ主題と関連する種別だけを使っているか
- ユーザーに見えない非表示情報を記述していないか
「ページに書いてあることだけを記述する」。この原則さえ守れば大半のリスクは防げます。
記法と実装方法で失敗しないには？
記法はJSON-LDが推奨で、実装方法ごとに事故のパターンが異なります。GoogleがサポートするのはJSON-LD・Microdata・RDFaの3形式で、JSON-LDはユーザー可視テキストと分離できるため推奨されています（Google検索セントラル）。配置場所の原則も併せて押さえます。
TechSuite株式会社の「AI検索パートナーズ」は、AIを活用した高度なコンテンツ制作の仕組みを「バクヤスAI記事代行」で培っており、その制作エンジンとナレッジを転用して、検索意図の分解に沿った構造化データとコンテンツを大量かつ高速に設計します。
JSON-LDが推奨される理由は？
JSON-LDはscriptタグ内に記述でき、本文HTMLとマークアップを分離できるため保守性が高い形式です。Googleはユーザーテキストとデータをきれいに分けられるJSON-LDを推奨しています。一方で、同じ内容がHTMLとJSON-LDに二重登場するとコードの肥大化や表示速度低下につながる場合があるため、出力の重複には注意します（鈴木謙一氏ブログ）。
実装方法ごとの事故をどう防ぐ？
実装方法は主に、CMS/EC標準機能での自動出力、テンプレートへの直接記述、GTMでの挿入の3系統で、保守性と誤出力リスクが異なります（tryangle）。標準機能とプラグインの二重出力や、GTM挿入がクロール時に拾われないリスクに注意が必要です。テンプレート直書きでは変数やエスケープのミスも起きやすいので検証が欠かせません。
| 実装方法 | メリット | 主なリスク |
|---|---|---|
| CMS/EC標準機能 | 自動出力で手間が少ない | 二重出力・古い仕様の混入 |
| テンプレート直書き | 柔軟に制御できる | 変数・エスケープのミス |
| GTM挿入 | 改修なしで追加可能 | レンダリング依存で未検出 |
構造化データはどこに置く？
構造化データは、それが説明するページ自体に置くのが原則です（Location）。重複ページがある場合は、canonicalだけでなく全複製ページに同じ構造化データを置くことが推奨されています（Google品質ガイドライン）。配置ミスは認識漏れの原因になるため確認しましょう。
記法はJSON-LD、置き場所は当該ページ。実装手段による事故は検証でつぶしましょう。
検証・監視とAI検索時代の位置づけは？
検証は二層構造で行い、本番反映後も継続監視することが「入れて終わり」を防ぎます。リッチリザルトテストはGoogleでの見え方を、Schema.org Validatorはデータ構造としての正しさを確認する役割で、目的が異なります。さらにAI検索時代には、リッチリザルトが出なくても機械可読性として残す価値が高まっています。
TechSuite株式会社の「AI検索パートナーズ」は、自社サイトでAI Share of Voiceが高水準にあり、支援事例でAI Overviewの引用率を改善した実績を踏まえて、構造化データを検索とAI双方に効く資産として設計します。
リッチリザルトテストとValidatorの違いは？
両ツールは役割が異なり、併用が前提です。リッチリザルトテストはGoogle表示可否、Schema.org Validatorは構文の正しさを確認します。Schema.org ValidatorはBingやYahooも参照する本家仕様のツールで、Google未対応の拡張スキーマやMicrodata形式の構文チェックにも使えます（tryangle）。
Search Consoleで本番監視するには？
本番反映後は、Search Consoleの拡張レポートで検出タイプ・エラー・警告を継続的に監視するのが推奨されます（second-order）。テスト合格で終わらせず、本番の警告を定点観測することが安定運用の鍵です。仕様変更や誤出力は本番で初めて顕在化することもあるため、定期チェックの運用に落とし込みます。
AI検索時代にも残す価値は？
構造化データは、リッチリザルトが出なくても機械可読性として生成AIや音声検索の正確な理解を助けます。AI検索時代の構造化データは、引用や推薦の精度を高める一次情報設計として価値が残ります。詳しくはAI検索対策の進め方やLLMO対策のチェックリスト、GEOの基礎解説も参考になります。
二層で検証し、本番を監視し、AI時代の資産として残す。ここまでが実装の完成形と言えます。
よくある質問
- FAQPageのマークアップはもう無意味ですか？
多くのサイトではFAQリッチリザルトが表示されなくなりましたが、無理に削除する必要はありません。機械可読性としての価値は残るため、更新コストと相談して判断するのが現実的です。
- MicrodataからJSON-LDに変更すべきですか？
GoogleはJSON-LDを推奨しています。ただし既存のMicrodataが正しく機能していれば必須ではありません。二重記述で内容が矛盾しないよう、どちらか一方に統一するのが安全です。
- 構造化データでペナルティを受けると順位は下がりますか？
スパム行為のある構造化マークアップで手動対策を受けても、順位・クロール・インデックスに悪影響はないとされています。ただしリッチスニペットは消えるため、修正後に再審査リクエストで解除します。
まとめ
schema.org実装の失敗は、Google非対応スキーマへの無駄な工数、必須プロパティ欠落や@type誤記述、見えない情報のマークアップによるスパム扱いの3つに集約されます。まずは公式ガイドラインを基準に、対象種別と必須項目を確認しましょう。
記法はJSON-LDを軸に、実コンテンツと構造化データを常に一致させることがスパムリスク回避の要です。実装方法ごとの二重出力や未検出にも注意が必要です。
最後にリッチリザルトテストとSchema.org Validatorで二層検証し、Search Consoleで本番を継続監視すれば、AI検索時代にも通用する機械可読な資産として構造化データを残せます。
参考にした情報源
