リッチリザルトテストの使い方とエラーの直し方 通っても表示されない理由まで

自社サイトに構造化データを入れたのに、検索結果の見た目が変わらない。制作会社から「リッチリザルトテストは通っています」と言われたが、何を見て通ったと言えるのかが分からない。この記事は、そう感じている経営者とWeb担当者に向けて書いています。

結論から言います。リッチリザルトテストは、公開前後のページに入れた構造化データを、Googleの目で読ませて確かめる道具です。使い方は、ページのURLを入れるか、コードを貼り付けるかの2通りです。

結果に出る「エラー」は、直さなければならない赤信号です。「警告」は、直すと検索での見え方が良くなる可能性がある黄信号です。「アイテムが検出されませんでした」は、読み取れる型がページに見つからなかった、という意味です。

そして、テストに通ることと、検索結果に表示されることは別の話です。Googleの公式ヘルプも、正しくマークアップしても表示されない場合がある、と書いています。この記事では、その理由も含めて整理します。

Googleの検索セントラルとヘルプ、スキーマ マークアップ検証ツールの案内ページ、Googleの公式ブログを、2026年11月2日に実際に開いて読みました。書くのは、そこで確かめられた範囲だけです。確かめられなかったことは、書かずに「公式に記載なし」と書きます。

先に答え：テストは、読ませる、読めたか見る、直す、の3手

リッチリザルトテストでやることは、3つの手順に収まります。

構造化データを読ませる。読み取れた内容を見る。エラーを直して、もう一度読ませる。この繰り返しです。

道具の名前は、公式の呼び方に合わせておく

検索で出てくる呼び方は、人によって違います。「リッチリザルトテスト」「リッチリザルト テスト」「構造化データのテストツール」「構造化データ テスト」は、会話の中ではほぼ同じものを指して使われています。

ただ、公式の名前は2つに分かれています。1つがGoogleの「リッチリザルト テスト」。もう1つが、schema.orgの「スキーマ マークアップ検証ツール」です。

よく聞く呼び方	公式の名前	提供元	何を確かめるか
リッチリザルトテスト	リッチリザルト テスト	Google	Googleの検索結果の機能に使えるか
構造化データのテストツール	旧「構造化データ テストツール」。2021年8月の公式ブログで、案内ページへの転送が書かれている	Google	公式に記載のある範囲は後の節で書く
構造化データの検証	スキーマ マークアップ検証ツール	schema.org	schema.orgの書き方として正しいか

旧ツールがどうなったかは、後の節で公式ブログの記述を引きます。

3手の中身を、表で先に見る

手順	やること	使う道具	見るところ
1	読ませる	リッチリザルト テスト	URLかコードを入れて実行する
2	読めたか見る	同じ画面の結果	有効なアイテム、エラー、警告
3	直して確かめる	同じ画面と、Search Console	直したあとの再テスト、公開後のレポート

この表の左から右へ進むだけで、テストの実務は回ります。細かいところは、次の節から順に書きます。

Q&Aサイトで見かけた、コピペしたのにエラーが出る声

先日、Q&Aサイトでこのような切実な悩みを拝見しました。投稿者は、検索結果に表示される会社の名前を変えたくて、紹介記事のコードをそのままコピーしてページに貼り付けたそうです。

数か月たっても検索結果が変わらないので調べたところ、リッチリザルトテストで「構文にエラーがある構造化データが検出されました」と出た。エラーの内容は、波かっこまたはオブジェクトメンバーの名前がない、という解析エラーで、1行目が強調されている。コピペしただけなのに、なぜエラーになるのか、という質問でした。

寄せられた回答は、改行と文字コードに触れていた

質問に付いた回答は、画面の左に行番号が出ているので、その通りに改行してみてください、というものでした。サイトからコピーすると変な文字コードが混じることがあるので、コピーできる公式の例から写してください、という案内も添えられていました。

方向は合っています。ただ、質問者が知りたいのは、エラー表示のどこを見れば原因が分かるのか、そして直したあとに何を確かめれば終わりなのか、という点でした。

別の質問にも、同じ型の悩みがあった

もう1つ、別の質問も見つかりました。こちらは、自分で書いたコードをテストにかけたら、カンマまたは波かっこがない、という解析エラーが出た、という内容でした。

質問に載っていたコードを見ると、項目の区切りが日本語のカンマの形になっていました。入力の途中で、半角が全角に切り替わっていた可能性があります。

この2つに共通する、テストの読み方の穴

2つの質問に共通するのは、エラー表示を原因の手がかりとして読めていないことです。テストは、直す場所を教えてくれる道具です。

次の節から、結果画面のどこを読めばよいかを、公式の説明に沿って順に見ていきます。

テストの前に決める：何を確かめたいのか

リッチリザルトテストを開く前に、確かめたいことを1つに絞ると、結果の読み間違いが減ります。

確かめたいことは、大きく3つに分かれる

確かめたいこと	向いている入力	理由
公開前のコードに誤りがないか	コードを貼り付ける	公開していなくても、何度でも直して再実行できる
公開したページが読まれているか	URLを入れる	Googleが実際に取得したページを読む
自社のページがGoogleのインデックスでどう扱われているか	Search ConsoleのURL検査	自社が所有するサイトの登録済みの情報を見られる

公式ヘルプには、コードのスニペットのテストについて、必要に応じて何度でもコードを修正して再実行できる、という説明があります。

結果に求めすぎない

リッチリザルト テストの公式ヘルプは、プレビューの表示について、必ずしもこのツールによるプレビューとまったく同じようにページが表示されるとは限らない、と書いています。

また、プレビューに表示されている内容のすべてが検索結果に反映されるとも限らない、とも書かれています。この記事も、その前提で書き進めます。

リッチリザルトテストの使い方：URLを入れる方法とコードを貼る方法

ここからが実務です。公式ヘルプの「リッチリザルト テスト」のページに沿って、手順を整理します。

方法1：ページのURLを入れる

公開済みのページを確かめるときは、テストするページの完全なURLを送信します。

公式ヘルプには、重要な注意が書かれています。ページのリソースはすべて、そのコードにインターネット経由で匿名ユーザーがアクセスできる状態でなければならない、という点です。

ファイアウォールやパスワードで守られているリソースは、このテストの対象にできません。ページが社内のサーバーやローカルのサーバーにある場合は、トンネルを設定してテストする、と書かれています。

方法2：コードを貼り付ける

公開前のコードを確かめるときは、ツールのトップページで、テストの対象にURLの代わりに「コード」を選び、テストするコードを貼り付けます。

コードを修正して「テストを実行」を押せば、必要に応じて何度でも再実行できます。

公開前のコードを見るのに向いているのは、この方法です。制作会社に頼んだ場合でも、納品されたコードを貼り付ければ、自分の目で確かめられます。

端末の種類を選べる

ページをテストするときに、使うユーザーエージェントを選べます。スマートフォンかデスクトップ パソコンかを、URLまたはコードを入力するテキストボックスの下のリストから選びます。

公式ヘルプは、今日では大半のユーザーがスマートフォンでウェブを閲覧しているため、初期設定はスマートフォンになっている、と説明しています。

対応している形式は3つ

テストが対応している構造化データの形式は、JSON-LD、RDFa、microdataの3つです。

Googleは、構造化データの形式としてJSON-LDを推奨しています。実装と管理が最も容易で、ユーザーのエラーが起きにくいからだ、と構造化データの概要のページに書かれています。

手順を、表で整理する

順番	操作	注意すること
1	リッチリザルト テストを開く	公式のツールを開く。検索で見つけた別のサイトのフォームに入れない
2	URLかコードを選ぶ	公開前ならコード、公開後ならURL
3	端末の種類を選ぶ	初期設定はスマートフォン
4	入力して実行する	URLは完全な形で入れる
5	結果を読む	次の節で、表示の意味を整理する
6	直して再実行する	履歴の保存は約90日

履歴と共有のリンクは、約90日で消える

公式ヘルプには、Search Consoleがテストを実行するたびに、対象のコードとテストのステータスを保存する、と書かれています。ブックマークしておけば、バージョン履歴をたどれます。

テスト履歴の保存期間は約90日です。共有ボタンで作るブラウザのリンクも、有効期間は約90日で、見る人にアクセス権限は要りません。

制作会社への依頼書に、結果のリンクを貼る使い方ができます。ただし、期限があるので、納品の記録には画面の保存も残してください。

JSON-LDの中のコメントは、公開前に消す

公式ヘルプには、見落としやすい注意があります。リッチリザルト テストは、JSON-LDのブロックの中にあるコメントを無視します。

ただし、この動作はJSON-LDの標準ではサポートされていないため、実際の使用状況ではエラーが発生する可能性がある、と書かれています。最終的にページを公開する前には、JSON-LDからコメントを必ず削除してください。

テストで通っても、本番で問題が出る可能性が残る、ということです。

結果画面の読み方：ステータス、クロール、検出された項目

テストを実行すると、結果が出ます。公式ヘルプは、ページで見つかったリッチリザルトのタイプ、構造化データのエラー、候補が表示される、と説明しています。

URLのステータスは9種類

ツールがテストしたURLについて報告するステータスは、公式ヘルプに次の9種類が挙げられています。Nは、検出されたアイテムの数です。

ステータス	読み方	まず確かめること
N件の有効なアイテムを検出しました	有効なアイテムが見つかった	検出された型が、狙った型か
アイテムが検出されませんでした	読み取れる項目が見つからなかった	次の節で切り分ける
N件の有効なアイテムを検出しました（警告あり）	有効だが警告がある	警告の中身を開く
N件の有効なアイテムを検出しました（すべて警告あり）	有効な項目のすべてに警告がある	警告の内容を共通で直せるか
N件の有効なアイテムを検出しました（一部警告あり）	一部の項目にだけ警告がある	どの項目かを特定する
N件のアイテムを検出しました（一部無効）	無効な項目が混じっている	エラーを開く
N件の無効なアイテムを検出しました	すべて無効	エラーを最優先で直す
URLをクロールできません	Googleがページを取得できなかった	アクセスの条件を点検する
構文にエラーがある構造化データが検出されました	書き方の誤りで解析が止まった	構文エラーの表で原因を探す

この9つを覚えておけば、画面を開いた瞬間に、次にやることの見当がつきます。

クロールの欄は、Googleがページに入れたかを示す

結果には、クロールの欄があります。公式ヘルプによると、この欄は、Googleによるページのクロールが許可されているかを表します。

「クロールが完了しました」は、Googleがページにアクセスできたことを意味し、「クロールに失敗しました」は、アクセスできなかったことを意味します。

ほかにも、ユーザーエージェントの種類、サイトのrobots.txtのルールによってクロールを許可されているか、ページを取得できたか、が表示されます。

検出された項目の欄は、読み取れた中身を示す

検出された項目の欄は、構造化データの項目がページで見つかったかどうかを示します。

見つかったのに解析できなかった場合は、ここに表示されます。見つかった項目は、良好なもの、警告やエラーがあるもの、解析できなかったものに分かれて、項目の説明や問題とともに一覧に出ます。

エラーや警告は、開いて中身を読む

公式ヘルプは、エラーまたは警告が表示された場合は、各項目を展開して詳細を確認し、説明をクリックしてコードエクスプローラを開くよう案内しています。

エクスプローラでは、レンダリングされたソースコードが使われます。つまり、Googleが組み立てたあとの形を見ています。

エラーの直し方：構文エラー、必須項目、警告を分けて読む

エラーと呼ばれるものには、性質の違う3つが混ざっています。書き方そのものの誤り、型ごとの必須項目の不足、直すと良くなる警告です。

1つ目は、書き方の誤り（構文エラー）

最初に出るのは、書き方の誤りです。公式ヘルプは、エラーでリッチリザルトの型を判別する前に解析が止まる場合、「タイプが不明な項目に関する構文エラー」というセクションが表示される、と説明しています。

Q&Aサイトの質問に出ていた「解析エラー」は、この種類です。公式ヘルプが挙げている主な構文エラーを、原因と一緒に表にします。

表示される名前	公式の説明	起きやすい場面
無効なJSONドキュメントです	JSONに最上位の構文エラーがある	コード全体の形が崩れている
値の型が正しくありません	数値や配列が必要なところに文字列が入っている	数値の欄に単位を書いた
解析エラー: 「:」がありません	フィールドと値の間にコロンがない	入力途中での欠け
解析エラー: 「,」または「}」がありません	カンマまたは閉じ波かっこがない	項目の区切りの欠け、全角の混入
解析エラー: 「}」またはオブジェクト メンバー名がありません	閉じ波かっこかメンバー名がない	最後の項目のあとに余計なカンマがある
文字列中に無効なエスケープ シーケンスがあります	文字列で無効なエスケープが使われている	文字列の中の記号の扱い
一意のプロパティが重複しています	一意のプロパティの定義が2つある	同じ設定が二重に出力されている
最上位の要素が無効です	JSON-LDの最上位の項目が無効	全体を囲む形の誤り

表の「起きやすい場面」の列は、弊社の整理です。公式の説明は、中央の列です。

構文エラーが出たときの確認の順番

構文エラーは、型の判定より前に解析が止まるので、ほかの結果が出ません。この状態では、書き方を直すことだけが次の一手です。

確認の順番は、次のとおりにするとやり直しが減ります。

1. 結果画面でハイライトされた行を探す。
2. その行の前後の記号を見る。カンマ、コロン、引用符、波かっこの対応を確かめる。
3. 引用符や記号が全角になっていないか見る。
4. 文書作成ソフトや、表示用の装飾が付いた画面からコピーしていないか思い出す。
5. 直したら、コードの貼り付けで再実行する。

2番から4番は、弊社の整理です。公式の表は、記号の欠けや不正な文字を、エラーの名前として挙げています。

文字コードの問題は、貼り付け元を変えると片づく

Q&Aサイトの回答には、サイトからコピーすると変な文字コードが入ることがあるので、コピーできる公式の例から写すとよい、とありました。

構造化データの概要のページには、そのまま写せる形でコードの例が載っています。装飾の入ったブログや画像から写すより、公式のページから写したほうが安全です。

自分でコードを書くときは、文字を入力するソフトを、書式のない形式のものに替えてください。文書作成ソフトは、引用符を丸まった形に自動で変えることがあります。この点も、弊社の整理です。

2つ目は、型ごとの必須項目の不足

書き方に誤りがなければ、次は型ごとの項目です。構造化データの概要のページは、検索で拡張表示の機能を出せるようにするには、オブジェクトの必須プロパティをすべて含める必要がある、と書いています。

必須の項目は、型ごとに違います。リッチリザルトの型ごとの記事を開いて、必須と推奨の一覧を確かめてください。

3つ目は、警告：直すと見え方が良くなる項目

警告は、推奨プロパティの不足などで出ます。構造化データの概要のページは、一般に推奨プロパティの設定が多いほど、検索結果に拡張表示機能が適用されて情報が表示される確率が高くなる、と書いています。

そのすぐあとに、大事な一文が続いています。完全でないデータ、不正な形式のデータ、不正確なデータを含む多数の推奨プロパティを提供するより、少数であっても完全で正確な推奨プロパティを提供するほうが重要、という趣旨です。

警告を消すためだけに、ページに載っていない情報を書き足すのは避けてください。

3つの種類を、表で整理する

種類	何が起きているか	直し方	優先度
構文エラー	書き方が崩れて解析が止まった	行の記号と文字を直す	最優先
必須項目の不足	その型の表示に必要な項目がない	型の記事で必須項目を確かめて足す	高い
警告	推奨項目の不足など	ページにある正しい情報だけを足す	余裕があるとき

「アイテムが検出されませんでした」が出たとき

検索でよく見かける悩みが、このステータスです。ページに構造化データを入れたはずなのに、1件も検出されない。

公式ヘルプに、このステータスの原因の一覧は見つからなかった

今日読んだ公式ヘルプには、ステータスの名前が挙がっているだけで、検出されない原因を並べた一覧は載っていませんでした。公式に記載なし、とします。

この節の切り分けは、公式ヘルプが説明している仕組みを手がかりにした、弊社の整理です。

切り分けは、5つの点検を上から順にする

順番	点検すること	手がかりになる公式の記述	次の一手
1	入れた型が、テスト対象の型か	テストが対応するリッチリザルトの型は一覧になっている	型の一覧と照らす
2	URLの場合、クロールが成功しているか	クロールの欄に、完了か失敗かが出る	robots.txtとnoindexを見る
3	貼り付けたコードでは検出されるか	テストはURLの代わりにコードでも実行できる	コードとURLの結果を比べる
4	出力されたページのHTMLに、コードが入っているか	コードエクスプローラはレンダリング後を見る	プラグインの出力を確かめる
5	書き方に誤りがないか	構文エラーは別のステータスで出る	検証ツールに通す

点検1：入れた型が、テストの対応する型かどうか

リッチリザルト テストが対応している型は、公式ヘルプに一覧があります。記事、パンくずリスト、ローカル ビジネス、組織、求人情報、商品スニペット、動画など、2026年11月2日に数えて31種類でした。

この一覧にない型を入れても、ツールはその型の結果を出しません。たとえば、よくある質問やハウツーという名前は、この日の一覧には並んでいませんでした。

型の名前が一覧にないときは、次の節で説明するスキーマ マークアップ検証ツールで、書き方の確認だけをします。

点検2：URLでテストしているなら、クロールの欄を見る

URLを入れてテストした場合は、結果のクロールの欄を見ます。robots.txtのルールやnoindexの指定でGoogleがページを取得できないと、ツールはページをテストできません。

ツールは、Google-InspectionToolとしてページにアクセスします。このため、robots.txtでこのアクセスを止めている設定があると、読めません。

点検3：コードを貼り付けて、結果を比べる

URLでは検出されないのに、コードを貼り付けると検出されるなら、書き方に問題はなく、ページの出力か取得に原因があります。

逆に、コードでも検出されないなら、コードそのものの書き方か、型の選び方を見直します。この比べ方は、弊社の整理です。切り分けの材料として使ってください。

点検4：実際のページに、コードが出力されているか

構造化データの概要のページは、CMSのJavaScriptコードや埋め込みウィジェットなどでページに動的に挿入されたJSON-LDも、Googleは読み取れる、と書いています。

ただ、プラグインの設定が外れていたり、テーマを替えたりして、コードがページから消えていることがあります。実際に配信されたページのHTMLを開いて、コードが入っているかを確かめてください。

点検5：最後に書き方の検証をする

ここまでの点検で原因が見つからないときは、書き方の誤りを疑います。次の節で説明する検証ツールに、コードを通してみてください。

テストできないとき：ページに届かないエラーの読み方

URLを入れたのに、構造化データの評価まで進まないことがあります。公式ヘルプは、ツールがGoogle-InspectionToolとして、Googleの立場でページにアクセスする、と説明しています。ユーザーの認証情報は使われません。

そのため、robots.txtなどで止められるほか、サーバーや証明書の状態によっても、テストが止まります。

公式ヘルプが挙げているエラーを、表で整理する

表示	公式の説明	次の一手
DNSサーバーが応答しません	多くの場合、数分以内に自動で解決する一時的な問題	少し待って再実行する
DNSエラー: 不明なホストです	DNSサーバーでURLが解決されなかった。数分以内に解決する一時的な問題と思われる	URLの綴りと、ドメインの設定を見る
DNSエラー: プライベートIPが指定されました	DNSが、特殊またはプライベートなIPを返した	公開用のアドレスになっているか、管理者に確かめる
サーバー接続エラー	サーバーにアクセスできなかった、接続が拒否された、接続に失敗した	サーバーの状態を管理者に確かめる
サーバーが無効な応答を返しました	プロトコル未対応、応答の切り詰め、解析不能など	サーバーの設定を管理者に確かめる
サーバーのSSL証明書が無効です	証明書が有効でない限り、HTTPSのURLはテストされない	証明書の期限と設定を確かめる
robots.txtにアクセスできません	ファイルが存在してもアクセスできないと、Googleはクロールしない	robots.txtの表示を確かめる
ホスト負荷が制限を超えています	Googleのリクエストに対して、サイトが最大容量に達しているようだ	負荷が下がるまで待つ

どの表示も、構造化データの書き方とは関係がない原因です。この場合は、コードを貼り付ける方法に切り替えると、書き方の確認だけは先に進められます。この使い分けは、弊社の整理です。

ページの一部のリソースが読み込めないときは、結果が揺れる

公式ヘルプには、ページで使われている画像、CSS、スクリプトなどのリソースを読み込めない場合に、警告が表示される、と書かれています。

原因として挙げられているのは、妥当な時間内に読み込めなかった、404エラーでリソースが存在しない、ログインしないと見られない、robots.txtでGoogle-InspectionToolがブロックされている、の4つです。

何も変えていないのに、テストのたびに結果が違うとき

公式ヘルプは、読み込めないリソースやページの読み込みに関する問題があると、テストのたびに少し異なる結果になることがある、と説明しています。各テストで読み込まれるリソースが異なる場合があるからです。

何も変えていないのに結果が毎回違うときは、「ページの読み込みに関する問題」の警告を開いてください。原因の手がかりが書かれています。

2つのツールの使い分け：リッチリザルトテストと構造化データテストツールの後継

「構造化データ テスト」と検索すると、古い解説にたどり着くことがあります。ここで、経緯を整理します。

旧ツールの経緯は、Googleの公式ブログに残っている

2020年12月15日のGoogle検索セントラル ブログは、構造化データ テストツールについて、スキーマの構文とschema.orgの標準への適合を確認するツールに位置づけ直し、schema.orgのコミュニティ向けの新しいドメインに移す、と書いています。

今後は、Google検索のリッチリザルトの型は確認しない、と明記されています。リッチリザルトの型を確かめるには、リッチリザルト テストを使い続けてください、という案内です。

2021年8月9日の追記には、スキーマ マークアップ検証ツールが安定したので、構造化データ テストツールは、正しいツールを選ぶための案内ページに転送される、と書かれています。

2つの道具を、表で見比べる

比べる点	リッチリザルト テスト	スキーマ マークアップ検証ツール
提供元	Google	schema.org
主な目的	Googleの検索結果の機能に使えるかを確かめる	schema.orgの構文と標準への適合を確かめる
向いている場面	リッチリザルトを狙う型の確認	Googleが明示的に使っていない型の確認
入力	URLまたはコード	今日開いた画面では、入力方法の詳細は確かめられなかった
結果の見方	エラー、警告、プレビュー	構文の誤りの指摘

公式ブログは、schema.orgの有効なプロパティだけを確かめたい場合や、Googleが現時点で明示的に使っていない型を確かめたい場合は、検証ツールを使う、と説明しています。例として、運動計画の型が挙げられています。

2つを使う順番は、リッチリザルト テストが先

Googleの型を狙っているなら、リッチリザルト テストとSearch Consoleが最も確実な道具だ、と公式ブログに書かれています。

したがって、順番は、まずリッチリザルト テストで確かめ、Googleの型の対象外のデータは検証ツールで確かめる、になります。

公開後の確認：Search Consoleで、実際の状態を見る

リッチリザルト テストは、その瞬間の1ページを確かめる道具です。サイト全体の状態や、Googleが登録した内容は、Search Consoleで確かめます。

開発中はテスト、公開後はレポート

構造化データの概要のページは、開発中はリッチリザルト テストで構造化データをテストし、デプロイ後はリッチリザルトのステータス レポートで有効性を確認するよう書いています。

その理由として、テンプレートや配信の仕方が原因で、デプロイ後にページの正常性が損なわれることがあるから、と説明されています。

URL検査：インデックス登録済みの状態と、公開URLのテスト

Search ConsoleのURL検査ツールは、Googleのインデックスに登録されたページの情報を表示します。構造化データの情報も、この中に含まれます。

公式ヘルプには、公開URLを検査して、Googleがその問題を修正済みと判断しているかを確かめられる、という説明があります。なお、すべての問題をテストできるわけではありません、とも書かれています。

自社が所有していないページのURLを確かめるときは、リッチリザルト テストのような非所有者向けのテストを使う、とヘルプにあります。

リッチリザルト レポート：項目の数で見る

リッチリザルト レポートは、Googleが検出した有効な項目と無効な項目の数を示します。数が表すのは項目の数で、ページの数は表しません。

有効な項目は、重大な問題がなく、リッチリザルトとして表示できる項目です。無効な項目には、リッチリザルトとして表示できなくなる重大な問題が1つ以上あります。重大でない問題は、検索での見え方を改善できるアイテムの表に出ます。

レポートは、すべてを網羅した一覧ではない

公式ヘルプは、このレポートは検出されるアイテムの一部をサンプルとして表示し、構造化データの品質の評価に役立てるものだ、と説明しています。

レポートに出ていないURLで構造化データが検出されているかは、URL検査ツールで確かめます。

「この問題を修正する」というボタンはない

公式ヘルプの質問と回答に、役立つ説明があります。構造化データは自社のウェブサイトにあり、Googleのサーバーにはないため、問題を完全に解決するには、サイトのソースコードを直す必要がある、というものです。

テンプレートの誤りなら、テンプレートを1つ直すだけで、関連するページがまとめて直ります。この点は、弊社の整理です。

テストに通っても、検索結果に表示されない理由

ここまでの手順で、エラーが消えたとします。それでも、検索結果の見た目が変わらないことがあります。

公式の「構造化データに関する一般的なガイドライン」のページは、この点を、重要という見出しで書いています。構造化データが検索結果に表示されるとは限らない、リッチリザルト テストに沿ってページを正しくマークアップしても表示されない場合がある、という内容です。

公式ヘルプが挙げている、表示されない理由

公式が挙げる理由	意味すること	自社で確かめること
機能が必ず表示されるとは限らない	アルゴリズムが、検索履歴、位置情報、デバイスなどに応じて結果を調整する	自分の検索だけで判断しない
主要内容を表していない、誤解を与える	構造化データがページの中心の内容と合っていない	本文と構造化データを突き合わせる
テストで検出できない誤りがある	自動のテストで見つからない誤りがある	人の目で内容を読む
参照する内容がユーザーに表示されない	構造化データの内容が画面に出ていない	ページの見た目に載っているか見る
ガイドラインや各種ポリシーに準拠していない	一般的なガイドライン、機能別のガイドライン、検索の基本事項、コンテンツ ポリシーのいずれか	機能別のガイドラインを読む

テストが見ていないものがある

同じ公式のページは、技術に関するガイドラインはリッチリザルト テストやURL検査ツールで確かめられ、技術的なエラーのほとんどを検出できる、と説明しています。

一方、品質に関するガイドラインは、自動化ツールで簡単にテストできない、とも書かれています。違反すると、構文的に正しい構造化データでもリッチリザルトとして表示されなくなったり、スパムとしてマークされたりする場合があります。

URL検査のテストも、品質や手動の対策は見ていない

URL検査のヘルプは、テスト結果で確かめられない項目として、ページと構造化データの品質とセキュリティのガイドラインへの準拠、手動による対策やセキュリティの問題の有無、コンテンツの削除の対象かどうか、URLの一時的なブロックの有無、を挙げています。

つまり、テストが緑でも、これらの項目には何も言えません。

手動による対策が実施されると、リッチリザルトが出なくなる

構造化データに問題があると、手動による対策が実施されることがあります。実施されると、ページがリッチリザルトとして表示されなくなります。

ただし、Google ウェブ検索でのページの掲載順位には影響しない、と同じページに書かれています。手動による対策があるかどうかは、Search Consoleの手動による対策レポートで確かめます。

本文に見えない内容は、書かない

構造化データの概要のページは、ユーザーが閲覧しているページ画面に表示されない情報に関する構造化データは、その情報が正確であっても追加しないでください、と書いています。

テストで警告が出たからといって、画面にない情報を足すのは逆効果です。直す場所は、ページの本文です。

詳しい基本は、構造化データの入門記事で整理しています。公式ガイドラインの読み方は、一般的なガイドラインの解説で扱っています。

AIの回答とテストの関係：公式に書かれていること

「AI検索のために構造化データを入れて、テストを通したほうがよいのか」という質問が、よく寄せられます。

検索セントラルの「AI機能とウェブサイト」の記述

このページは、AIによる概要やAIモードに表示されるための追加の要件はなく、別途特別な最適化を行う必要もない、と書いています。

構造化データについては、AI機能で表示されるために、新たにコンピュータが解読可能なファイルやAIテキストファイル、マークアップを作る必要はなく、特別なschema.orgの構造化データを追加する必要もない、と明記されています。

あわせて、構造化データをページに表示されるテキストと一致させる、という基本が挙げられています。

テストの結果と、AIの回答の関係は、公式に記載なし

リッチリザルト テストの結果が、AIによる概要やAIモードの表示に使われるかどうかは、今日読んだ公式の資料には書かれていませんでした。公式に記載なし、とします。

したがって、テストに通ったことを理由に、AIの回答に出ると説明されたら、根拠を尋ねてください。判断の整理は、AI検索と構造化データの記事で扱っています。

一致のテストは、人の目で行う

AI機能のページが挙げている基本は、構造化データを見えるテキストと一致させることでした。この一致は、ツールでは確かめにくい項目です。

会社名、住所、電話番号、営業時間を、本文と構造化データで見比べる作業を、運用の手順に入れてください。

運用に落とす：テストの手順書をつくる

テストは、1回やって終わりの作業ではありません。ページの更新やプラグインの更新で、構造化データは変わります。

手順書に書く項目

項目	内容	頻度の目安
公開前	新しいページの構造化データを、コードの貼り付けでテストする	公開のたび
公開直後	公開URLをテストし、検出された型を確かめる	公開のたび
定期の点検	Search Consoleのレポートで、無効な項目が増えていないか見る	月に1回
更新の後	プラグインやテーマの更新後に、代表ページを再テストする	更新のたび
情報の変更	営業時間や住所を変えたら、構造化データも直す	変更のたび

担当者が替わっても、同じ結果が出るように

手順書には、どのページを代表ページとして確かめるか、どの型を狙っているか、を書いておきます。

テスト結果の画面を、日付とページ名つきで保存しておくと、後から変化を追えます。履歴の保存期間は約90日なので、画面の保存が役に立ちます。

制作会社に頼むとき、確かめること

納品のときに、リッチリザルト テストの結果を渡してもらいます。検出された型、エラーと警告の数、警告の理由を書いた報告があると、後から見直せます。

ただし、通っていることは、表示の約束ではありません。表示を保証する契約は、公式の説明と合いません。

よくある質問

Q. リッチリザルトテストとは、何をする道具ですか

ページに入れた構造化データをGoogleが読み取れるかを確かめる、Googleの無料のツールです。

URLを入れるか、コードを貼り付けて使います。検出された型、エラー、警告が表示されます。

Q. 「アイテムが検出されませんでした」と出ました。構造化データは無効ですか

無効という意味ではありません。読み取れる項目が見つからなかった、というステータスです。

型がテストの対応する型か、クロールが成功しているか、コードが実際のページに出力されているかを順に確かめてください。

Q. エラーはゼロにしないと、検索結果に出ませんか

必須の項目が足りないなど、重大な問題があると、リッチリザルトとして表示できません。警告だけなら、有効な項目として扱われる場合があります。

ただし、エラーがゼロでも、表示は保証されません。

Q. 「構造化データ テストツール」は、今も使えますか

2021年8月の公式ブログの追記では、転送先は、正しいツールを選ぶための案内ページと書かれています。Googleの型を確かめるときは、リッチリザルト テストを使います。

schema.orgの書き方の確認には、スキーマ マークアップ検証ツールがあります。

Q. テストに通ったのに、検索結果に表示されません

公式のガイドラインは、正しくマークアップしても表示されない場合がある、と書いています。本文との一致、ガイドラインの準拠、手動による対策の有無を順に確かめます。

反映までの日数は、今日読んだ公式の資料に書かれていませんでした。公式に記載なし、とします。

質問への答えを、表で整理する

質問	答え	次にやること
テストは何をする道具か	構造化データを読み取れるか確かめる	URLかコードで実行する
検出されない	無効の意味ではない	5つの点検を順に行う
エラーゼロで出るか	保証されない	本文との一致を確かめる
旧ツールは使えるか	案内ページに転送と書かれている	リッチリザルト テストを使う
通っても出ない	公式が理由を列挙している	ガイドラインと手動対策を確かめる

まとめ：テストは、読ませて、読めたかを見て、直すための道具

リッチリザルトテストは、構造化データをGoogleに読ませて、結果を見るための道具です。公開前はコードの貼り付け、公開後はURLの入力で使い分けます。

結果は、エラー、警告、検出されなかった、の3つに分けて読みます。エラーは直す。警告はページにある正しい情報だけを足す。検出されない場合は、型、クロール、出力、書き方を順に点検します。

公開後は、Search ConsoleのURL検査とレポートで、実際の状態を見ます。テストに通っても、表示は約束されません。AIの回答との関係は、公式に記載がありませんでした。

次に確かめる1つは、代表ページ1枚のテスト結果の保存です。

この記事で確かめた資料

2026年11月2日に開いて読んだ資料と、そこから使った内容です。

資料	使った内容
Google Search Console ヘルプ「リッチリザルト テスト」	使い方、対応形式、ステータス、エラーの説明、対応する型、履歴の保存
Google 検索セントラル「構造化データのマークアップの概要」	テストの位置づけ、必須プロパティと推奨プロパティ、JSON-LDの推奨
Google 検索セントラル「構造化データに関する一般的なガイドライン」	表示されるとは限らない理由、技術と品質のガイドライン、手動による対策
Google Search Console ヘルプ「リッチリザルト レポートの概要」	有効と無効の意味、項目数、サンプルであること
Google Search Console ヘルプ「URL 検査ツール」	検査とテストの違い、テストされない項目
Google 検索セントラル ブログ（2020年12月15日）	構造化データ テストツールの位置づけの変更、追記
Google 検索セントラル「AI機能とウェブサイト」	特別な最適化や構造化データが不要なこと
確かめられなかったもの	検出されない原因の公式の一覧、スキーマ マークアップ検証ツールの入力方法の詳細、AIの回答とテスト結果の関係、反映までの日数

今日できる点検

次の表の項目を、上から順に確かめてください。1項目あたり10分ほどで終わります。

点検の項目	確かめる場所	合格の目安	直すこと
代表ページのテスト	リッチリザルト テスト	狙った型が検出される	検出されなければ5つの点検を行う
エラーの数	同じ画面の結果	0件	構文、必須項目の順に直す
警告の中身	同じ画面の警告	内容を説明できる	ページにある情報だけを足す
コメントの残り	公開前のコード	JSON-LDにコメントがない	公開前に削除する
本文との一致	ページの本文	名前、住所、電話が同じ	食い違いを直す
robots.txtとnoindex	設定とクロールの欄	取得に失敗していない	止めている設定を外す
公開後のレポート	Search Console	無効な項目が増えていない	原因のテンプレートを直す
結果の保存	社内の共有文書	日付とページ名つきで残る	画面を保存する

ページを増やしても問い合わせが来ないなら、原因はページの外にあります。その場合は、下の入口からご相談ください。