構造化データは、構文が正しくても消えることがある ── 手動による対策の条件を確認する14項目

01 何が起きたか — 構文が正しくても、リッチリザルトが出ないことがある

「Rich Results Testを通った」で終わらせてはいけない理由

構造化データを実装するとき、多くのWEBディレクターが最終確認としているのが、GoogleのRich Results Testである。ここでエラーが出なければ「実装は完了した」と考えがちだが、Google Search Centralの「General structured data guidelines」（構造化データに関する一般的なガイドライン）ページは、それだけでは足りないことを明記している。このページはGoogle検索でリッチリザルト（検索結果に表示される拡張表示）の対象になるための必須条件を定めたもので、内容は大きく技術ガイドライン（Format・Access）と品質ガイドライン（Content・Completeness・Location・Specificity・Images）の2つに分かれている。前者はRich Results Testのような自動ツールで確認できるが、後者について公式ドキュメントはこう書いている。

"These quality guidelines are not easily testable using an automated tool. Violating a quality guideline can prevent syntactically correct structured data from being displayed as a rich result in Google Search, or possibly cause it to be marked as spam."

（訳: これらの品質ガイドラインは、自動化ツールで容易にテストすることができない。品質ガイドラインに違反すると、構文的に正しい構造化データであってもGoogle検索でリッチリザルトとして表示されなくなる可能性があり、場合によってはスパムとして判定されることもある。）

つまり、Rich Results Testが「合格」を返しても、それは技術面が正しいことしか確認していない。表示されている内容と一致しているか、実在しないレビューを載せていないかといった品質面は、別の判断基準として存在し、機械的なチェックでは検出できない。このページは2026年7月10日付で更新されており、現時点でGoogleが示している最新の整理である。

この記事では、この2種類のガイドラインの中身を整理したうえで、当サイトが運営している構造化データはAIに読まれているのか？で扱った「マークアップを続ける理由」の一段手前にある、マークアップをどう続けるべきかという条件面を確認する。

「手動による対策」は、順位を下げるものではない

品質ガイドラインに違反した場合の代表的な結果が、手動による対策（マニュアルアクション）である。Google公式ヘルプはこう説明している。

"A structured data manual action means that a page loses eligibility for appearance as a rich result; it doesn't affect how the page ranks in Google web search."

（訳: 構造化データに関する手動による対策とは、そのページがリッチリザルトとして表示される資格を失うことを意味する。Google検索でのそのページの順位には影響しない。）

この一文は誤解されやすい。手動による対策が入っても、通常の検索結果からページが消えるわけではなく、順位も変わらない。失うのは拡張表示の資格だけである。だからこそ気づきにくく、Search Consoleを定期的に開かない限り、いつの間にか資格を失っていても誰も気づかない、という状態が起こりうる。

3段階のどこで止まるかで、結果が変わる

実装から表示までの流れを分解すると、技術面の構文チェックと、品質面の判定は別の段階にあることが分かる。構文チェックはRich Results Testで自動的に完了するが、その先にある品質の判定は、Googleが人的レビューを通じて行うものであり、自動化されていない。結果として、構文チェックを通過した構造化データが、そのまま品質判定の段階で止まり、表示されないままになることがある。

02 なぜ・背景 — 2種類のガイドラインに分かれている理由

「機械が読める形式」と「人が信頼できる内容」は別の課題

構造化データは、もともとページの内容を検索エンジンに機械的に伝えるための仕組みである。だが「機械が正しく読み取れる形式になっているか」と「そこに書かれている内容が本当かどうか」は、まったく別の課題である。前者は文法の問題であり、後者は信頼性の問題だ。Google Search Centralが技術ガイドラインと品質ガイドラインを分けて記載しているのは、この2つの課題を混同させないためだと読み取れる。

この整理は唐突に生まれたものではない。Googleは検索品質を評価するガイドライン自体も年々更新しており、AIによる回答生成が広がるにつれて、何が「操作的なコンテンツ」にあたるかの線引きも変わってきた（検索品質評価ガイドラインは2025→2026でこう変わった）。構造化データも例外ではなく、フェイクレビューのような古典的な手口だけでなく、生成AIを使った内容の水増しや偽装も、広い意味でのスパムポリシーの対象になりつつある。

「表示されなくなる」で済む場合と、「スパム」として扱われる場合の違い

公式ドキュメントは、品質ガイドライン違反の結果を2段階で示している。1つはリッチリザルトとして表示されなくなるという穏やかな帰結、もう1つはスパムとして判定されるという重い帰結である。どちらに転ぶかは明記された基準があるわけではないが、フェイクレビューやなりすましのように、ユーザーを積極的に欺く意図が明らかなケースほど、後者に近づくと考えるのが自然である。単なるプロパティの記載漏れと、存在しない評価者を捏造することは、同じ「品質ガイドライン違反」という言葉でくくられていても、重さがまったく違う。

Content以外にも、Completeness・Location・Specificity・Imagesという4つの区分がある

品質ガイドラインは、Content（内容）だけでなく、Completeness（充足度）・Location（配置）・Specificity（具体性）・Images（画像）という4つの区分に分かれている。Completenessは、ドキュメントに記載されているすべての必須プロパティを含めることを求めており、推奨プロパティを多く含むほど、ユーザーにとって質の高い結果になるとされている。Locationは、構造化データをそのデータが説明しているページ自体に置くことを基本としつつ、同じ内容を持つ重複ページがある場合には、正規ページだけでなくすべての重複ページに同じ構造化データを置くことを推奨している。これは、Googleが個々のURLを独立してクロール・評価する仕組みを取っているためで、正規ページにだけ構造化データを置いても、重複ページ側が単独で表示された場合にはその恩恵が及ばない。Specificityは、Schema.orgの語彙の中から最も具体的な型とプロパティ名を選ぶことを求めている。たとえばレシピのページで、より具体的な「Recipe」ではなく汎用的な「Thing」や「CreativeWork」を選んでしまうと、レシピ向けのリッチリザルトの対象自体から外れてしまうことがある。Imagesは、画像プロパティに指定するURLがそのページの内容に関連していることに加え、すべての画像URLがクロール可能かつインデックス可能でなければならないと明記している。

この4つは、Contentほど「悪質かどうか」が問われるものではないが、放置すると同じようにリッチリザルトの表示機会を失う原因になる。特にLocationは見落とされやすく、正規ページにしか構造化データを入れていないケースが多い。

03 この記事で出てくる用語

「構造化データ」と「Schema.org」の関係

構造化データそのものは仕組みの名前であり、その中で使う語彙（どんな種類の情報を、どんな名前のプロパティで表すか）を定義しているのがSchema.orgという共通の辞書である。Googleの構造化データガイドラインは、この辞書の中から「最も具体的に当てはまる種類とプロパティ名を使うこと」を求めている。たとえば単に「Thing（もの）」を使うのではなく、それがレシピなら「Recipe」、求人情報なら「JobPosting」というように、より詳細な種類を選ぶことが推奨される。

04 型別 — 適用範囲・この記事が測っていないこと・手順

🅰 適用範囲 — どのページ、どの種類にも共通するルール

「General structured data guidelines」は、その名のとおり特定の種類に限定されない共通ルールである。レシピ・求人情報・レビュー・FAQなど、種類ごとの個別ページ（例えばJob Posting policiesやReview snippetのガイドライン）は別途用意されているが、そのすべてに対して、この一般ガイドラインが土台として適用される。つまり、種類別のページだけを読んで満足していると、この記事で扱う共通部分を見落とすことになる。技術ガイドラインはすべてのページ・すべての種類に一律で適用され、品質ガイドラインも同様に、種類を問わず共通の判断基準として働く。

🅱 この記事が測っていないこと・分からないこと

公式ドキュメントは、正しく実装した場合でも保証がないことをはっきり書いている。

"Google doesn't guarantee that your structured data will show up in search results, even if your page is marked up correctly."

（訳: ページが正しくマークアップされていても、Googleはその構造化データが検索結果に表示されることを保証しない。）

この記事で確認できるのは「表示されなくなる原因を減らすこと」までであり、「必ず表示されるようにすること」ではない。また、品質ガイドラインには具体的な数値基準（何件のフェイクレビューがあれば手動対策になるか、といった線引き）が示されておらず、どこからが違反として扱われるかの境界線は公開されていない。加えて、レビュー・求人情報など種類別に追加される個別の品質基準は、この一般ガイドラインには含まれていない。自分が扱っている種類に個別ページがある場合は、それも別途確認する必要がある。

🅲 手順 — 自分のサイトで確認する流れ

確認の流れは、大きく3段階に分けられる。まず対応形式（JSON-LD・Microdata・RDFaのいずれか）とアクセス可否（robots.txtやnoindexでブロックしていないか）という技術面をRich Results TestとURL検査ツールで確認する。次に、表示されている内容とマークアップの内容が一致しているか、必須プロパティが揃っているかという品質面を、人の目で1件ずつ確認する。最後に、Search Consoleにログインし、左側メニューの「セキュリティと手動による対策」から「手動による対策」レポートを開き、すでに何らかの通知が来ていないかを確認する。この3段階のうち、自動ツールで完結するのは最初の1段階だけであることを踏まえておく必要がある。

1ページに複数の項目を載せる、3つの形

1つのページに複数の構造化データを載せる場合、公式ドキュメントは3つの形を示している。複数アイテムは、種類の違う複数の情報（例えばレシピと動画とレビュー）が同じページに存在する場合で、表示されている情報のすべてに対応するマークアップを行うと、複数の検索機能に表示されるチャンスが広がる。ネストは、メインとなる項目の下に、関連する項目を階層としてまとめる方法で、グループ化に向いた関係を表すときに使う。個別アイテムは、独立した複数の項目を同じページ上に並べる方法で、項目同士を関連づけたい場合には、双方に@idを指定して相互参照させる必要がある。これを怠ると、Google検索がその項目同士の関係を認識できないことがある。

どの形を選ぶ場合でも、ページの主要な目的を明確にするため、そのページの主な内容を反映する構造化データの種類を必ず含めておくことが推奨されている。たとえばレシピが主題のページであれば、動画やレビューの構造化データだけでなく、Recipe自体の構造化データも欠かせない。

05 明日、自分のサイトで確認できることチェックリスト

チェックリストの観点と、かかる時間の目安

ここまでの内容を、今日から手を動かせる作業に翻訳した。観点は、技術面の確認（4項目）、内容の突き合わせ（6項目）、体制面の確認（4項目）の3つに分かれる。チェックの状態はブラウザ内にのみ保存され、サーバーには送信されない。

• 代表的なページを1件選び、Rich Results Testに入力して、必須プロパティの欠落を示す警告が出ていないか確認する
• そのページで実装している構造化データの種類（Recipe・FAQPage・Reviewなど）をすべて数え上げる
• 使用している形式がJSON-LD・Microdata・RDFaのいずれかであるか、ページのソースを開いて確認する
• robots.txtを開き、構造化データを入れているページのパスがDisallowに含まれていないか確認する
• マークアップした各プロパティの値を、実際にブラウザで表示されている本文と1つずつ突き合わせる
• レビューや評価点を含むページがあれば、マークアップされている件数と、ページに表示されているレビューの件数が一致しているか数える
• 画像を含む構造化データのimageプロパティのURLを、別タブで直接開いて表示できるか確認する
• 同じ内容を掲載している重複ページ（PC版・別URLなど）がある場合、両方のページに同じ構造化データが入っているか比較する
• 使用しているSchema.orgの種類が、内容にとって最も具体的な種類になっているか、より詳しい種類が存在しないか確認する
• 1ページに複数の項目（例：レシピと動画）がある場合、@idを使って項目同士が関連づけられているか確認する
• ページに実在しない人物・組織になりすました情報や、実際には存在しない評価者名を使っていないか、内容を読み直す
• Search Consoleにログインし、左側メニューの「セキュリティと手動による対策」から「手動による対策」を開き、構造化データに関する通知が届いていないか確認する
• 過去に公開したページから3件を選び、上記の項目を実際に確認する
• ここまでで見つかったずれを1件ずつ書き出し、優先度の高いものから3件を選んで今週中に直す

14項目の内訳は次のとおりである。最初の4項目は技術面の確認、5番目から10番目までは内容の突き合わせ、11番目以降は体制面の確認に対応している。すべてに目を通す時間の目安は1ページあたり20分程度である。9番目・10番目は、複数の種類を組み合わせていないページでは対象外として読み飛ばしてよい。

06 代替・他の選択肢（表で）

構造化データの状態を確認する4つの手段

構造化データが正しいかどうかを確認する手段は1つではない。以下は、それぞれの手段が「できること」と「できないこと・限界」を整理した表である。

4つの手段のうち、機械的な検査だけで完結するのは最初の2つである。手動による対策レポートは「起きた後」を知る手段であり、事前の予防にはならない。当サイトの🔧 構造化データ自動作成ツールは、技術面の記載漏れを減らす役には立つが、それだけで品質ガイドラインをすべて満たせるわけではない点は変わらない。

07 起きやすい落とし穴 — 「表示されている情報の一部だけ」が招く不整合

落とし穴1 — マークアップは全部入れたのに、本文の一部だけ更新した

ページを更新するとき、本文だけを直して構造化データを直し忘れる、あるいはその逆が起きやすい。公式ドキュメントは「非表示のコンテンツをマークアップしてはいけない」と明記しており、逆に言えば、表示されているのにマークアップされていない情報があること自体が、品質ガイドラインの想定から外れる。FAQのように内容を頻繁に更新するタイプの構造化データほど、このずれが起きやすい。当サイトも、FAQ用の構造化データが壊れていたことに後から気づいた経験がある（FAQPageスキーマが壊れていた）。この事例では、本文の更新に構造化データ側の更新が追いついていなかったことが原因だった。

落とし穴2 — 「フェイクレビュー」のつもりがなくても、実在しない評価者名は同じ扱いを受ける

公式ドキュメントが挙げる「フェイクレビュー」の例は、悪意を持って捏造したものだけではない。テスト用に仮の評価者名を入れたまま公開してしまう、あるいはサンプルとして用意した数値をそのまま残してしまうケースも、結果として実在しない情報をマークアップしていることに変わりはない。意図の有無にかかわらず、内容が実在しなければ違反として扱われる可能性がある。公開前には、テスト用のダミーデータが残っていないかを必ず確認する必要がある。

落とし穴3 — 「自動チェックが通ったから安心」という思い込み

自社ブログの内部リンクを点検し、「リンク切れ0本」という結果に一度安心しかけたものの、実際にはリンク先の59.2%がnoindexページを指していた、という調査結果がある（「リンク切れ0本」を確認して、安心しかけた）。これは構造化データの品質ガイドラインと同じ構図である。自動ツールが「エラーなし」と返しても、それが確認しているのは限られた一部の条件だけであり、確認していない範囲があることを忘れると、実際には問題が残ったまま放置されることになる。

落とし穴4 — 種類ごとの追加ルールを見落とす

求人情報やレビューには、この一般ガイドラインに加えて、種類ごとの追加ルールが個別ページで定められている。一般ガイドラインだけを確認して対応済みと判断すると、種類固有の条件を見落とすことになる。自分が扱っている構造化データの種類に、専用のドキュメントが存在するかどうかを、まず確認しておく必要がある。

08 このテーマの、これまで

「壊れていたことに、後から気づいた」回

FAQ用の構造化データが実際には壊れていたことに気づき、修正した経緯を公開した回がある（FAQPageスキーマが壊れていた）。04章で触れた「表示されている情報の一部だけがマークアップされていない」という状態は、この回で扱った事例そのものである。

「スパムの定義が広がった」回

Googleが生成AIによる回答の操作をスパムと定義した経緯と、当サイトがあえて埋めなかった項目を確認した回がある（埋められる穴と、埋めてはいけない穴）。02章で触れた「フェイクレビューのような古典的な手口だけでなく、生成AIによる水増しも広い意味でのスパムに含まれつつある」という論点は、この回の内容と重なる。

「確認したつもりで、確認できていなかった」回

「リンク切れ0本」という結果に安心しかけたが、実際には内部リンクの半数以上がnoindexページを指していたという調査を、実際の数を数え直して確認した回がある（「リンク切れ0本」を確認して、安心しかけた）。07章の落とし穴3で触れた「自動チェックが通ったから安心」という思い込みは、この回で確認した構図と同じである。