リッチリザルトとは？種類・構造化データ・表示確認方法を解説

検索結果で、商品の価格や評価、求人情報、イベントの日時、パンくずリストなどが、通常の青いリンクより詳しく表示されているのを見たことはないでしょうか。こうした拡張表示が「リッチリザルト」です。

自社のページでも同じ表示を狙うとき、構造化データ（ページの内容を検索エンジンに伝えるための決まった形式の記述）をとりあえず追加するだけでは進みません。基本の順番は、まず自社ページがGoogleのどのリッチリザルトに対応できるかを確認し、そのタイプの要件に沿って構造化データを実装し、リッチリザルトテストとSearch Consoleで検証することです。先に対象を決めておけば、Googleが対応していないタイプを実装してしまうおそれを減らせます。

ただし、正しく実装しても表示は保証されません。この記事では、リッチリザルトの意味、代表的な種類、構造化データとの関係、対象タイプの選び方、表示確認の流れを順に整理します。表示されないときの切り分けと、SEO効果の見方もあわせて確認します。

リッチリザルトとは何か？通常の検索結果を拡張する表示

この節では、リッチリザルトが何を指し、なぜ「入れれば表示される」ものではないのかを整理します。

リッチリザルトとは、Google検索で通常のタイトル・URL・説明文だけではなく、画像、価格、評価、日時、パンくずリストなどの追加情報を表示できる検索結果です。

Googleは、リッチリザルトを「通常の青いリンクを超える検索結果」と説明しています。構造化データを使ってページの内容をGoogleへ伝えることで、対応する検索機能に表示される可能性が生まれます。

ただし、構造化データを正しく実装しても、リッチリザルトが必ず表示されるわけではありません。Googleは検索履歴、位置情報、デバイスなど複数の要因を踏まえて検索結果を決定するためです。

そのため実務では、「構造化データを入れたか」だけで判断せず、次の3点を分けて考える必要があります。

ページ内容が対象タイプに合っているか
構造化データがGoogleの要件を満たしているか
実際の検索結果で表示対象として選ばれているか

最初の2点は自社で整えられますが、3点目はGoogleが決めます。次の節では、この違いを構造化データとの関係から見ていきます。

リッチリザルトと構造化データの違いは何か

リッチリザルトは検索結果上の「表示」であり、構造化データはページの意味を検索エンジンへ伝える「データ形式」です。両者は同じものではありません。

次の図は、Webページの情報を構造化データで整理し、検索結果のリッチリザルト表示につなげる関係を示しています。

Webページの情報を構造化データで整理し、検索結果のリッチリザルト表示につなげる関係図

Googleは構造化データを、ページに関する情報を標準化して伝える形式と説明しています。例えば商品ページであれば、商品名、価格、在庫状況、評価などを構造化データとして記述できます。こうして記述した情報により、Googleがページ内容を理解しやすくなり、対応するリッチリザルトへ表示される可能性が生まれます。

実際に企業ブログで記事向け構造化データがどこまで設定されているかは、「企業ブログ19,748記事の構造化データ調査」で、Article系53.9％などの実測結果を確認できます。

両者の違いを、役割・見える場所・自社での制御・確認方法の4つの観点で比べます。

項目	リッチリザルト	構造化データ
役割	検索結果で情報を拡張表示する	ページ内容の意味を機械が理解しやすい形式で伝える
見える場所	Google検索結果	主にページのHTML内
自社で直接制御できるか	表示自体は制御できない	実装内容は自社で管理できる
確認方法	実際の検索結果、Search Console	リッチリザルトテスト、URL検査など

表のポイントは、表示そのものは自社で制御できない一方、構造化データの実装内容は自社で管理できるという点です。構造化データを正しく追加したことと、検索結果でリッチリザルトが表示されたことは、分けて確認しましょう。

Googleがサポートするリッチリザルトの主な種類は何か

Googleがサポートする構造化データの種類は複数あります。すべてのサイトがすべてのタイプを実装する必要はなく、自社ページの内容と一致するものだけを選ぶことが基本です。

Google検索セントラルでは、2026年9月時点で、記事、パンくずリスト、カルーセル、コースリスト、データセット、ディスカッションフォーラム、イベント、求人情報、商品、レシピ、レビュー、動画などの構造化データ機能が案内されています。

代表例を、ページの内容ごとに整理すると次のようになります。右の列は、そのページで検討しやすい構造化データ・表示の目安です。

ページの内容	検討しやすい構造化データ・表示
ECの商品ページ	商品スニペット、販売者のリスティング
求人ページ	求人情報
イベント告知ページ	イベント
レシピページ	レシピ
記事・ニュース	記事
商品・サービスなどの評価情報	レビュースニペット
サイト階層	パンくずリスト
動画が中心のページ	動画
フォーラム	ディスカッションフォーラム
プロフィール情報	プロフィールページ

ここで注意したいのは、過去の記事や古い実装例だけを見て判断しないことです。Googleが対応する検索機能や表示条件は変更されるため、実装前に必ず最新のGoogle検索セントラル「構造化データギャラリー」を確認してください。

自社ページで狙うリッチリザルトはどう決めるか

狙うタイプは「検索結果で目立ちそうだから」ではなく、ページの主目的と実際に掲載している情報から決めます。次の2つを順に確認します。

まずページの中心情報と一致するタイプを選ぶ

商品を販売しているページなら商品、求人募集ページなら求人情報、開催日時と場所が決まったイベントページならイベントというように、ページの中心情報を基準にします。

Googleは、構造化データがページの主要な内容を表していない場合、リッチリザルトとして表示されない可能性があると説明しています。そのため、ページ内に存在しない情報を構造化データだけに追加したり、ページ内容より大きな意味を持つタイプを無理に付けたりするのは避けるべきです。

次にGoogleが現在サポートしているタイプか確認する

中心情報に合うタイプが見つかっても、そのまま実装には進みません。schema.orgに存在する構造化データが、すべてGoogleのリッチリザルトに対応しているわけではないためです。

実装候補を決めるときは、次の順で確認すると迷いにくくなります。

自社ページの種類を整理する
Googleの構造化データギャラリーで対応タイプを探す
各タイプの必須・推奨プロパティを確認する
自社ページ上に必要情報が実際に掲載されているか確認する
実装後にリッチリザルトテストで検証する

この順番にすれば、コードを書く前に「そもそも狙えるタイプなのか」を判断できます。

リッチリザルトの適格性は3段階で確認する

リッチリザルトの実装では、「コードがエラーになっていない」だけでは不十分です。ここでいう適格性は、リッチリザルトの表示対象になれる状態を指します。ページ内容、構造化データ、Googleからの取得状態の3つを分けて確認します。

図のとおり、ページ内容との適合、構造化データの実装、Googleによる取得・認識の3段階で確認します。それぞれの確認内容と手段は、次の表のとおりです。

確認段階	確認すること	主な確認手段
1. 対象適合	ページ内容がリッチリザルトの対象に合うか	Google公式ガイド
2. 実装適合	必須項目・推奨項目を満たしているか	リッチリザルトテスト
3. Google認識	Googleが公開ページを取得・認識できているか	Search Console、URL検査

段階ごとに、結果の読み方が異なります。例えば、リッチリザルトテストで「有効」と判定されても、表示が保証されるわけではありません。実装適合の確認を通っただけで、Googleが実際に表示するかどうかは別だからです。

一方、重大なエラーで無効になっている場合は、表示対象になる前に修正が必要です。3段階目のGoogle認識については、Search Consoleで有効・無効な構造化データ項目や問題の種類を確認できます。

実装直後はリッチリザルトテストで状態を確認する

構造化データを追加したら、まずGoogleの「リッチリザルトテスト」で確認します。

リッチリザルトテストでは、公開URLまたはコードを入力し、ページからどのリッチリザルトタイプが検出されるか、重大なエラーや警告がないかを確認できます。確認の流れは次のとおりです。

Googleのリッチリザルトテストを開く
公開済みならURL、公開前ならコードを入力する
検出されたリッチリザルトタイプを確認する
「無効」や重大なエラーがないか確認する
必須プロパティの不足を修正する
必要に応じて推奨項目も追加する
再テストする

ただし、テスト結果のプレビューと実際のGoogle検索の表示が完全に一致するとは限りません。テストは「実装がGoogleの対象機能として解釈可能か」を確認するものと考えると分かりやすいでしょう。

また、実装形式についてGoogleはJSON-LD、microdata、RDFaをサポートしており、一般的にはJSON-LDを推奨しています。

リッチリザルトだけでなく、構造化データのエラー・本文との不一致・重複を詳しく点検する場合は、構造化データの確認方法も確認してください。

公開後はSearch Consoleで検出状況を確認する

公開後は、Google Search Consoleで、Googleが構造化データをどう検出しているかを確認します。

実装直後に使うリッチリザルトテストと公開後に使うSearch Consoleの役割を比較した図

リッチリザルトテストは実装直後の適格性確認に、Search Consoleは公開後のGoogleによる検出状況の確認に使います。

Search Consoleでは、Googleがサイト上で検出した有効・無効な構造化データ項目を、対応するリッチリザルトタイプごとに確認できます。特に見るべきポイントは次のとおりです。

有効な項目が検出されているか
無効な項目が増えていないか
重大な問題の内容は何か
修正後の検証が完了しているか
対象URLがGoogleに取得されているか

注意したいのは、Search Consoleのリッチリザルトレポートが、サイト上のすべての構造化データを完全に一覧表示するものではない点です。レポートに表示されないURLについては、Googleが案内しているとおり、URL検査ツールで構造化データの検出状況を確認します。

リッチリザルトが表示されないときは何を確認するか

構造化データを実装したのに表示されない場合は、すぐに「実装ミス」と決めつけず、原因を段階的に切り分けます。次の5つを上から順に見ていきます。最初の4つは原因の確認で、最後の1つは「問題がなくても表示されないことがある」という前提の整理です。

対象タイプが現在もGoogleでサポートされているか

古い記事や過去の実装例では、現在のGoogle検索での扱いと一致しない場合があります。まずGoogle検索セントラルの構造化データギャラリーで、現在サポートされているタイプとガイドを確認してください。

ページ内容と構造化データが一致しているか

構造化データで示している情報は、原則としてユーザーがページ上で確認できる内容と一致させます。商品価格、イベント日時、求人条件などがページ本文と構造化データで食い違っている場合は、正しい情報へ揃える必要があります。

リッチリザルトテストで重大なエラーがないか

必須プロパティの欠落や構文エラーがあると、対象タイプが無効になる場合があります。「警告」と「エラー」は分けて確認してください。警告は必ずしも適格性を失うものではありませんが、重大な問題は修正が必要です。

Googlebotがページへアクセスできるか

Googlebotは、Googleのクローラー、つまりページを巡回して内容を取得するプログラムです。robots.txt、noindex、ログイン制限などでGoogleがページを取得できない場合は、構造化データを評価できません。URL検査ツールで、Googleがページを取得できているかを確認します。

有効でも表示されない場合があることを前提にする

Googleは、正しくマークアップされたページでもリッチリザルトが必ず表示されるわけではないと明記しています。つまり、実装の成功条件は「毎回必ず表示されること」ではありません。

まずは、次の4点がそろった状態を目指します。

対象タイプとして適切
必須要件を満たす
Googleが取得できる
Search Consoleで重大な問題がない

そのうえで、実際の検索結果やSearch Consoleの表示データを継続して確認します。

リッチリザルトのSEO効果は順位上昇と分けて考える

表示を確認する方法に続いて、リッチリザルトに取り組む意味を、順位との関係から整理します。

リッチリザルトは、検索順位を直接上げるための仕組みとして考えるべきではありません。

構造化データには、Googleがページ内容を理解しやすくする役割があります。また、リッチリザルトとして表示されれば、通常の検索結果より多くの情報を提示できるため、検索ユーザーがページ内容を判断しやすくなる可能性があります。

Googleは構造化データ導入事例として、クリック率やアクセス、滞在時間などが改善した企業例を紹介しています。ただし、これは個別事例であり、同じ改善幅がすべてのサイトで再現されることを意味しません。

実務では、順位、視認性、クリック率（CTR）、運用の4つの観点に分けて評価すると安全です。

観点	判断
検索順位	リッチリザルト実装だけで順位上昇を保証しない
視認性	通常結果より情報量が増える可能性がある
クリック	検索ユーザーの判断材料が増え、CTRへ影響する可能性がある
運用	仕様変更やエラーを継続確認する必要がある

検索結果での見え方を改善したい場合は、順位だけでなく、どのページでどの検索機能を狙えるかを整理することが重要です。

リッチリザルト対応は「対象選定→実装→確認」の順で進める

初めてリッチリザルト対応を進める場合は、次の順番がおすすめです。

図のとおり、先に対象タイプを決めてから実装し、テストとSearch Consoleで確認した後も、仕様変更やエラーを継続的に確認します。手順にすると、次の8つです。1〜3が対象選定、4〜5が実装、6〜7が確認で、8は公開後も続けます。

自社サイトのページ種類を分類する
Googleの構造化データギャラリーと照合する
対象になり得るリッチリザルトを選ぶ
各タイプの必須・推奨項目を確認する
ページ内容と構造化データを一致させる
リッチリザルトテストで検証する
公開後にSearch Consoleで検出状況を確認する
エラーや仕様変更を継続的に確認する

ここまでが「実装前〜初期の理解・対象選定・表示確認」の範囲です。

すでに多数のページへ構造化データを実装しており、適用範囲、構文、本文との不一致、重複、取得状態をサイト横断で確認したい場合は、個別のリッチリザルト理解ではなく、構造化データ監査として扱う方が整理しやすくなります。

構造化データを含む技術要件を、クロール・正規化・表示速度などとあわせて点検する場合は、テクニカルSEOの全体像も確認してください。

まとめ

リッチリザルトとは、Google検索で通常の青いリンクより多くの情報を表示できる検索機能です。

対応を始めるときは、構造化データを先に書くのではなく、まず自社ページの内容がGoogleのどのリッチリザルトに対応するかを確認します。その後、公式ガイドに沿って実装し、リッチリザルトテストで適格性を確認し、公開後はSearch ConsoleとURL検査でGoogleの検出状況を確認します。

また、正しい構造化データを実装しても、リッチリザルトの表示は保証されません。そのため、対象タイプとの適合、実装の状態、Googleによる取得、実際の検索結果での表示の4つを分けて確認します。表示されないときは、どの段階で止まっているかを見ます。

最初の一歩は、自社サイトのページ種類を分類し、Googleの構造化データギャラリーと照合することです。自社サイトのテクニカルSEO課題をまとめて整理したい場合は、無料資料を使って確認項目を洗い出す方法もあります。

参考文献・データ元

この記事で参照した情報を確認できます。

・Google検索セントラル「Google 検索がサポートする構造化データマークアップ」
https://developers.google.com/search/docs/appearance/structured-data/search-gallery?hl=ja
使用内容：Googleがサポートする構造化データ機能、各タイプの確認

・Google検索セントラル「Google 検索における構造化データのマークアップの概要」
https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data?hl=ja
使用内容：構造化データの定義、リッチリザルトとの関係、導入事例

・Google検索セントラル「構造化データに関する一般的なガイドライン」
https://developers.google.com/search/docs/appearance/structured-data/sd-policies?hl=ja
使用内容：表示保証がないこと、技術要件、Googlebotのアクセス、JSON-LD等の対応形式

・Google Search Console「リッチリザルトテスト」
https://search.google.com/test/rich-results?hl=ja
使用内容：テスト対象、リッチリザルトの定義、URL・コードによる確認

・Search Consoleヘルプ「リッチリザルトレポートの概要」
https://support.google.com/webmasters/answer/7552505?hl=ja
使用内容：有効・無効項目、対応レポート、URL検査の使い分け

‹ 親記事: テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト

リッチリザルトとは？種類・構造化データ・表示確認方法を解説

リッチリザルトとは何か？通常の検索結果を拡張する表示

リッチリザルトと構造化データの違いは何か

Googleがサポートするリッチリザルトの主な種類は何か