【Google検索セントラル解説】構造化データの一般的なガイドライン｜リッチリザルトの条件・見える内容との一致・手動対策

2026年10月8日

中野輝規

構造化データを入れたのに、検索結果の見え方が変わらない。そんなときに確かめる決まりを、Googleは検索セントラルの1ページにまとめています。

この記事は、そのページ「General structured data guidelines」を英語版の原文から読んで整理します。英日の比べ読み、更新の経緯、弊社のサイトでの確認も書きます。

合同会社謙虚は、3つのドメインを並行して運用し、何を変えると数字が動くかを測り続けています。構造化データは「入れること」より「入れてよい条件を知ること」が先なので、その条件をGoogleの原文で確かめました。

結論：3行で言うと

リッチリザルト（星やパンくずなどの特別な表示）に出る資格を得るには、技術面と品質面の両方の決まりを守る必要があります。正しく書いても表示は保証されないと、このページは明言しています
品質面には、ページを見た人に見える内容と一致させる決まりがあります。構造化データの違反で受ける手動による対策は、リッチリザルトとして表示される資格を失うだけで、ウェブ検索の順位には影響しないと書かれています
1ページに複数の項目（レシピ、動画、パンくずなど）を書くことは認められており、入れ子でも個別でも読まれます。関連する項目は@idでつなぐと書かれています

このページの基本情報

項目	内容
原題（英語）	General structured data guidelines
日本語版の題名	構造化データに関する一般的なガイドライン
英語版の最終更新日	2026年7月10日
日本語版の最終更新日	2026年9月16日
直近の主な更新	2026年7月10日（コード例に image を追加）。2026年1月6日（練習問題に関する1文を削除）

原文はこちらで読めます。英語版／日本語版。

Googleがこのページで言っていること

冒頭：リッチリザルトの資格と、手動による対策

リッチリザルトに出る資格の条件は、2つ挙がっています。Google検索のコンテンツポリシー（スパムに関するポリシーを含む）に違反しないことと、このページの一般ガイドラインを守ることです。

構造化データに問題があると、手動による対策につながることがあります。これは、Googleの担当者が確認して課す措置です（Search Consoleヘルプの説明）。

このページは、構造化データの手動対策を次の1文で説明しています。

“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ウェブ検索でのページの順位には影響しません）

表示は保証されない

「重要」の注記が、リッチリザルトテストの条件に合っていても表示は保証されないと明言し、理由を5つ挙げています。

構造化データは、機能が出る可能性をつくるだけです。検索履歴、場所、端末などに応じて結果が調整され、別の機能やテキストだけの結果が選ばれることもあります
構造化データがページの主な内容を表していないか、誤解を招く可能性があります
リッチリザルトテストでは検出できない誤りが含まれています
構造化データが指す内容が、ユーザーに見えません
このページ、機能ごとのガイドライン、検索の基本事項、コンテンツポリシーのどれかに反しています

技術ガイドライン

技術面の確認には、リッチリザルトテストとURL検査ツールを使えます。技術的なエラーのほとんどは、この2つで見つかるとされています。

形式：JSON-LD（推奨）、Microdata、RDFaのどれかでマークアップします
アクセス：構造化データのあるページを、robots.txt、noindex、そのほかのアクセス制限でGooglebotからブロックしない

品質ガイドライン：コンテンツ

品質ガイドラインは、自動のツールでは簡単に確かめられません。違反すると、構文が正しくてもリッチリザルトとして表示されなかったり、スパムとして扱われたりする可能性があります。

「コンテンツ」の節には、7項目があります。

Googleウェブ検索のスパムポリシーを守る
最新の情報を出す。時間に左右され、もう当てはまらない内容は、リッチリザルトに出ない
自分、またはユーザーが作ったオリジナルの内容を出す
読者に見えない内容をマークアップしない。JSON-LDが出演者を記述するなら、本文でも同じ出演者を記述する
無関係な内容や誤解を招く内容（偽のレビューなど）をマークアップしない
ユーザーを欺かない。なりすましや、所有者・所属・主な目的の偽りも対象
機能ごとのガイドにある追加ルールにも従う。求人の構造化データなら、求人情報のコンテンツポリシー

品質ガイドライン：関連性・完全性・場所・具体性・画像

関連性：ページの内容を正確に表していることが条件です。悪い例は、ライブ配信サイトが配信を地域イベントと記述する、木工サイトが作り方をレシピと記述する、の2つです
完全性：機能ごとの必須プロパティ（必ず書く項目）はすべて指定します。欠けた項目はリッチリザルトの対象になりません。推奨プロパティが多いほど質が上がります。実際の利用者によらないレビューや評価は、手動による対策につながる可能性があります
場所：別の指定がなければ、説明するページに置きます。内容が同じ重複ページがあるときは、正規ページだけでなく重複ページのすべてに、同じ構造化データを置くことを勧めています
具体性：schema.orgの型とプロパティ名のうち、最も具体的に当てはまるものを使います
画像：置かれているページに関連する画像にします。画像のURLは、クロールとインデックス登録ができる状態にします。確認にはURL検査ツールを使います

ページ上の複数のアイテム

1つのページには、レシピ、作り方の動画、パンくずリストのように、複数の種類の情報が載ることがあります。ユーザーに見える情報は、すべてマークアップできます。

書き方は2通りあり、Google検索はどちらも理解します。

ネスト（入れ子）：主な項目の下に、追加の項目をまとめる書き方です。レシピの下に動画とレビューを置く例が挙がっています
個別：項目ごとに別のブロックとして書く書き方です

レシピと動画のように結びつけたほうが役立つ項目は、両方の項目で@idを使い、動画がそのページのレシピについてのものだと示します。結びつけないと、動画をレシピのリッチリザルトとして出せると認識されない場合があります。

ヒントは2つあります。1つ目は、ページの主な目的に合う主な型を入れることです（動画の構造化データしかないレシピページは、レシピとして出す情報が足りません）。

2つ目は、項目を揃えることです。複数のレビューを入れるなら、見えているレビューをすべて入れます。

英語版と日本語版の違い

2026年10月8日に、保存した英語版と日本語版の本文を通読し、節ごとに突き合わせました。

見出しの順と箇条書きの数は同じです。差は、最終更新日と、意味が少し変わる言い回し4か所でした。

項目	英語版	日本語版	読み取り
最終更新日	2026年7月10日	2026年9月16日	日本語版が68日新しい日付です。9月16日の変更内容は、更新前の日本語版を取得できず、確かめられませんでした。コード例の image の行は、両方にあります
実際の利用者によらない評価	手動による対策につながる可能性がある、という趣旨	「手動による対策とみなされる可能性があります」	英語版の趣旨は、評価の扱いが原因で手動対策を受けうる、です。日本語版は「みなされる」と書いています
手動対策で失うもの	表示される資格を失う	「リッチリザルトとして表示されなくなります」	「資格」という語があるのは英語版だけです。この記事は英語版に従います
必須の項目が欠けたとき	リッチリザルトの対象にならない	「リッチリザルトに表示されません」	上の行と同じ差です
@idでつながないとき	認識されない場合がある	「認識できません」	英語版は可能性、日本語版は言い切りです

更新の経緯

変更履歴と、Internet Archiveに残る過去の版を比べました。

時期	変わったこと	確かめた方法
2020年7月8日	入れ子でも個別でも、Google検索は複数のアイテムを理解する、と明確化されました	変更履歴
2022年11月22日	リッチリザルトに表示される条件の説明が、明確化されました。冒頭の文面が変わっています（下に詳述）	変更履歴と、2022年9月20日更新版（10月11日保存）・11月22日更新版（11月24日保存）の比較
2022年11月22日〜2024年10月31日の間	「plain blue link」が「text result」に変わり、コード例の ratingValue と ratingCount が文字列から数値になりました	11月22日更新版と、2024年10月31日更新版（2025年1月15日保存）の比較
2026年1月6日	練習問題の構造化データのコンテンツ方針に従う、という1文が消えました。「Do not block」が「Don’t block」に変わりました	2025年2月4日更新版（2025年8月1日保存）と、1月6日更新版（2026年6月28日保存）の比較。同日の変更履歴に、練習問題の構造化データのドキュメント削除があります
2026年7月10日	コード例の2つのレシピに image の行が加わりました	1月6日更新版と7月10日更新版（7月11日保存）の比較。変更履歴には載っていません

2022年9月20日更新版は、違反したページについて「順位が不利になるか、リッチリザルトの対象外になることがある」という趣旨を書いていました。11月22日更新版は、これに代えて、手動対策はリッチリザルトの資格を失うだけで、順位には影響しない、と書いています。

7月10日に image が加わった理由は、書かれていません。

私の読み取りでは、必須の image が欠けていたコード例を直したように見えます。Googleのレシピのページ（英語版、2026年9月8日更新）で、image が必須であることを確かめました。

このページから、言えること・言えないこと

言えること	言えないこと（よくある誤解）
決まりを破ると、構文が正しくてもリッチリザルトの資格を失う可能性がある	正しく書けば、必ずリッチリザルトに表示される（ページは保証しないと明言しています）
構造化データの手動対策では、リッチリザルトの資格を失う。ウェブ検索の順位には影響しない、と書かれている	構造化データの違反で、サイト全体の順位が下がる（このページはそう書いていません。ほかの手動対策は、このページの範囲外です）
見えない内容、無関係な内容、誤解を招く内容は、マークアップしてはいけない	検索エンジンに向けてだけ、画面に出ない情報を足してよい

中小企業の視点で、どう受け取るか

ここからはGoogleの説明とは別の、私の読み取りです。

種類の選び方や入れ方といった実務の手順は、構造化データとは非エンジニアでもわかる実装ガイドに書きました。この記事は、守るべき決まりを公式ページから読む側の解説です。

1. 構造化データの中身が、画面に見えているかを確かめる

品質の決まりでいちばん重いのは、見える内容との一致です。会社名、住所、営業時間、価格、口コミ、よくある質問が構造化データにあるなら、同じページに表示されている必要があります。

確認は、ページを開いて右クリックの「ページのソースを表示」から「ld+json」を検索し、見つかった記述の文言を画面の文言と1行ずつ突き合わせます。

2. 星や口コミは、実際の利用者のものだけにする

完全性の節は、実際の利用者によらないレビューや評価が、手動による対策につながる可能性があると書いています。自社で用意した星の数や、画面に出ていない口コミを足す運用は、この記述に触れます。

3. 検査ツールを通っても、品質面は人の目で見る

リッチリザルトテストとURL検査ツールは、技術面のエラーのほとんどを見つけます。

品質ガイドラインは自動のツールで確かめにくい、とこのページは書いています。検査のあとは、1の手順で内容の一致を目で確かめます。

4. ページの主役の型を先に入れる

ヒントの節は、ページの主な目的に合う型を入れるよう勧めています。記事のページなら記事の型、商品のページなら商品の型を先に整え、パンくずリストなどの補助の項目はそのあとに足します。

AIの回答に引用されるかどうかとの関係は、構造化データを入れればAIに引用されるのかで確かめました。

弊社のサイトで確かめたこと

2026年10月8日に、kenkyo.aiの2ページ（構造化データを解説した記事とトップページ）に対して、次の確認を行いました。

確認	やったこと	結果
アクセス	curl -sL https://kenkyo.ai/robots.txt を読み、Pythonのrobotparserで記事ページと画像のURLを検査。curl -sI で2ページの応答ヘッダーを取得し、HTMLの meta robots を読む	robots.txtの禁止は /wp-admin/ だけで、記事ページと画像のURLはGooglebotに許可されていました。応答は200で、X-Robots-Tagヘッダーはなく、meta robots は max-image-preview:large だけです。noindex はありません
形式	記事ページのHTMLから、JSON-LD・Microdata・RDFaを数える	JSON-LDが1ブロックで、Microdata（itemtype）とRDFa（typeof）は0件でした
複数のアイテム	記事ページのJSON-LDを読み込み、項目の型を一覧にする	1ブロックの中に6項目あります（BlogPosting、BreadcrumbList、Organization、Person、WebPage、WebSite）。トップページは4項目（BreadcrumbList、Organization、WebPage、WebSite）でした
@idでのつなぎ	記事ページの項目どうしの参照を読む	BlogPostingは著者をPerson、発行元をOrganization、メインのページをWebPageへ@idで指しています。WebPageはパンくずリストとWebSiteを@idで指しています
見える内容との一致	JSON-LDの値と、画面のH1・日付を比べる。画像とロゴのURLに curl -sI も実行	見出し（headline）はH1の文言と一致しました。公開日2026年8月29日と更新日2026年10月2日も、画面と同じでした。画像とロゴのURLは、どちらも200でした