リッチリザルトとは？
リッチリザルト（Rich Results）とは、Googleの検索結果に表示される通常のスニペット（タイトル・URL・説明文）を拡張し、画像やレビュー評価、価格、調理時間、カルーセルなど、テキスト以外の追加要素を含めて表示できる検索結果の形式です。一般的なオーガニック検索のスニペットよりも多くの情報を視覚的に伝えられるため、検索ユーザーの注目を集めやすく、クリック率の向上に寄与する施策として広く活用されています。
Googleが2009年に「リッチスニペット」として発表したのが始まりで、当初はレビュー評価や人物情報などごく限られたパターンのみが対象でした。その後、対応データタイプが拡張されていく中で、2017年頃から名称が「リッチリザルト」に統一され、現在では商品、レシピ、求人、イベント、動画など、数十種類のデータタイプが公式にサポートされています（出典：Google検索セントラル）。
リッチリザルトを表示させるためには、ページ上に構造化データと呼ばれる、検索エンジン向けにコンテンツの意味を伝える標準化されたマークアップを記述する必要があります。たとえばレシピであればカロリーや調理時間、商品であれば価格やレビュー評価といった情報をschema.orgのボキャブラリに基づいてマークアップすることで、Googleがその情報を抽出し、検索結果に拡張表示する候補として扱います。構造化データとリッチリザルトの関係や具体的なマークアップ方法については、後続の章で詳しく解説していきます。
なお、構造化データをマークアップしていれば必ずリッチリザルトとして表示されるわけではありません。Googleはマークアップ内容に加えて、ページの品質やガイドライン遵守、検索クエリとの関連性などを総合的に判断したうえで表示可否を決定しています。また、後述するFAQやハウツーのように、過去にはサポートされていたタイプが縮小・廃止されるケースもあり、最新の仕様を継続的に追いかけることが重要です。
構造化データとは？
構造化データ（Structured Data）とは、ウェブページに含まれる情報を検索エンジンが理解しやすい形に整理して伝えるための、標準化されたデータ形式です。通常のHTMLは「見出し」「段落」「リンク」といった文書構造を表現しますが、それだけでは「このテキストはレシピの調理時間なのか、商品の価格なのか、レビューの評価なのか」までは機械的に判別できません。そこで、要素ごとに意味（セマンティクス）を付与するためのマークアップが構造化データです。
構造化データの語彙（ボキャブラリ）として広く使われているのが schema.org です。schema.orgはGoogle・Microsoft・Yahoo!・Yandexが共同で策定した共通仕様で、Recipe（レシピ）、Product（商品）、Article（記事）、Organization（組織）、Person（人物）など、ウェブ上で扱う主要な概念をタイプとして定義しています。各タイプには「name」「price」「ratingValue」「author」といったプロパティが用意されており、ページ内の情報をこれらの語彙で記述することで、検索エンジンはコンテンツの意図を正確に把握できるようになります。
記述形式（シンタックス）は複数ありますが、Googleが現在最も推奨しているのは JSON-LD（JavaScript Object Notation for Linked Data）です。JSON-LDはHTMLのbodyやheadにscriptタグとしてまとめて埋め込めるため、既存のマークアップを大きく改変せずに導入できる利点があります。このほか、HTMLタグの属性として直接書き込む Microdata や RDFa もサポートされていますが、保守性の観点からJSON-LDが主流です（出典：Google検索セントラル）。
重要なのは、構造化データはあくまで「検索エンジンに対する追加の手がかり」であり、ユーザーに見える本文の内容と一致している必要があるという点です。ページ上に存在しない情報を構造化データだけで宣言することはGoogleのガイドラインに違反し、リッチリザルトの表示停止や手動による対策の対象となる場合があります。あくまで実際のコンテンツを正しく機械可読化するための仕組み、と捉えるのが正解です。
そして、この構造化データを正しくマークアップしておくことが、前章で紹介したリッチリザルト表示の前提条件となります。次章以降では、具体的にどのようなリッチリザルトが現在の検索結果で利用できるのかを順に見ていきましょう。
検索結果におけるリッチリザルトの表示例
リッチリザルトは、構造化データによってGoogleにページの意味を伝えることで初めて表示候補となります。ここでは現時点で代表的な表示例を整理し、あわせてFAQやハウツーのように縮小・廃止された機能の経緯も整理します。自サイトに導入する際の優先度判断にお役立てください。
なお、構造化データをマークアップしていないページでもGoogleは自動的に情報を読み取り、リッチリザルトを表示することがあります。
代表的なリッチリザルトと現在の対応状況
| 種類 | 表示内容 | 現在の対応状況 |
|---|---|---|
| 日付情報 | 公開日・更新日の表示 | 対応中（最終的な表示はGoogleが判断） |
| パンくずリスト | サイト階層をURLの代わりに表示 | 対応中 |
| 価格 | 商品価格・在庫・通貨 | 対応中（Product / Offer） |
| カロリー・調理時間 | レシピのカロリーや所要時間 | 対応中（Recipe） |
| レビュー評価・件数 | 星評価とレビュー数 | 対応中（自己提供レビューやLocalBusiness/Organizationは対象外） |
| FAQ | 質問と回答のアコーディオン | 2026年5月7日に完全終了予定（政府・医療系の一部のみ残存） |
| ハウツー（HowTo） | 手順のステップ表示 | 2023年9月に廃止 |
| 著者情報 | プロフィール写真・著者名 | 表示終了（Article構造化データで著者情報の伝達は可能） |
日付情報
記事の公開日や更新日は、構造化データでマークアップすることでGoogleに正確に伝えられます。ただし検索結果に表示される日付は、Googleのアルゴリズムが「ユーザーにとって適切」と判断した日付であり、必ずしもマークアップで指定した値がそのまま出るわけではありません。公開日（datePublished）と更新日（dateModified）の両方を記述しておくと、より適切な情報をGoogleに伝えられます（出典：Google検索セントラル）。
パンくずリスト
パンくずナビゲーションをBreadcrumbList構造化データでマークアップすると、検索結果のURL部分がサイト階層に置き換わって表示されます。ユーザーがページの位置づけを直感的に理解できるため、ECサイトや大規模メディアでは導入効果が高い項目です（出典：Google検索セントラル）。
価格
ProductやOfferの構造化データを使うことで、検索結果に価格や在庫状況、通貨を表示できます。商品ページや料金ページのCTR改善に直結する代表的なリッチリザルトです。
カロリーと調理時間
Recipe構造化データを使えば、レシピページのカロリーや調理時間、評価などを検索結果に表示できます。レシピ系コンテンツでは、ほぼ必須と言える項目です。
レビュー評価と件数
商品やサービスの星評価、レビュー件数を表示するリッチリザルトです。ただし、自社サイト上で自社について書いた「自己提供レビュー」は対象外で、LocalBusinessとOrganizationのスキーマタイプでは、自身のウェブサイトに直接記述したレビューや、サードパーティのレビューウィジェットを埋め込んだレビューはいずれもリッチリザルト表示の対象外となります（出典：Google検索セントラルブログ）。
FAQ（縮小・終了予定）
かつてFAQページ構造化データを設置すれば最大5件の質問と回答が検索結果に展開表示され、SERPの占有面積を大きく取れる施策として広く活用されていました。しかし2023年8月のGoogleの発表により、政府・医療など信頼性の高い一部のサイトを除いてFAQリッチリザルトは大幅に縮小されました（出典：Google検索セントラルブログ）。さらに、その後の方針変更によりFAQリッチリザルトは2026年5月に完全終了する見通しです。詳しくは次の章で解説します。
ハウツー（HowTo・廃止済み）
ハウツー（HowTo）の手順をステップ表示するリッチリザルトも、FAQと同じ2023年の発表で扱いが大きく変わりました。当初はモバイル限定に縮小、その後2023年9月をもって完全に廃止され、現在はHowTo構造化データを設置しても検索結果に手順は表示されません（出典：Google検索セントラルブログ）。
著者情報（過去採用）
2011年頃のGoogleは、検索結果に著者のプロフィール写真と氏名を表示する「オーサーシップ」を導入していましたが、CTRへの影響が限定的だったため2014年6月に表示を終了しました。現在はArticle構造化データのauthorプロパティを使うことで、Googleに著者情報そのものは伝えられます。E-E-A-Tの観点でも著者情報は重要視されているため、検索結果に直接出ないとしても記述しておく価値があります（参考：YMYLとE-E-A-Tの概要）。
【最新情報】FAQリッチリザルトが2026年5月に完全終了
Googleは、検索結果におけるFAQ（よくある質問）リッチリザルトの表示と、関連ツールでのFAQPage構造化データのサポートを段階的に終了することを公式アナウンスしました。最終的な完全終了日は2026年5月7日とされており、FAQ構造化データを実装しているサイトのSEO担当者は、対応スケジュールを早めに把握しておく必要があります（出典：Google検索セントラル ブログ）。
これまでの経緯：2023年からの段階的縮小
FAQリッチリザルトの縮小は突然始まったわけではなく、数年にわたる段階的なプロセスを経ています。Googleは2023年8月の発表で、FAQリッチリザルトの表示対象を「よく知られていて信頼のおける政府・医療系サイト」に限定し、その他のサイトでは表示しないと明言しました。同じタイミングでHowTo（ハウツー）リッチリザルトも廃止されています（出典：Google検索セントラル ブログ）。
つまり、一般的な企業サイトやメディアにとってのFAQリッチリザルトはすでに2023年時点で実質的に「表示されないもの」となっており、今回の発表はその流れの延長線上で、機能そのものを完全に終了させる最終ステップだといえます。
関連ツールのサポート終了スケジュール
FAQPage構造化データの取り扱いは、検索結果の表示終了だけでなく、Search Console、リッチリザルトテスト、URL検査API などの関連ツールでも順次サポートが打ち切られます。実装済みのサイトでは、エラー通知やレポートの扱いも変わるため、以下のスケジュールを押さえておきましょう。
| 時期 | 対象 | 変更内容 |
|---|---|---|
| 2023年8月 | 検索結果のFAQリッチリザルト | 政府・医療系サイト以外では表示を停止 |
| 2026年5月7日 | 検索結果のFAQリッチリザルト | すべてのサイトで表示を完全終了 |
| 2026年5月7日 | Search Console の拡張レポート | FAQリッチリザルトのレポート提供を終了 |
| 2026年5月7日 | リッチリザルトテスト／URL検査API | FAQPage構造化データの検出・レポート機能を終了 |
完全終了後は、FAQPageマークアップを残していてもエラー扱いにはなりませんが、検索結果に表示されることはなく、各種ツールでの検証もできなくなります。コードとして「無害だが無効」な状態になると考えればよいでしょう。
SEO担当者が取るべき対応
FAQ構造化データを実装しているサイトでは、2026年5月までに以下のチェックポイントを順に確認しておくことを推奨します。残しておくこと自体にペナルティはありませんが、不要なコードはメンテナンスコストを増やすため、この機会に整理しておくのが賢明です。
- サイト内でFAQPage構造化データを実装しているページを洗い出す（テンプレート単位での実装も含めて確認）
- Search Console の「拡張」レポートで現在の検出状況とエラーの有無を確認しておく
- CMSのテーマやプラグインが自動でFAQPageマークアップを出力していないかを点検する
- 政府・医療系サイトに該当しない場合は、FAQPageマークアップの削除または出力停止を検討する
- FAQコンテンツ自体は残し、ユーザー向けのアコーディオンUIや内部リンク導線として活用を継続する
- 代替としてArticle、Product、HowTo以外のサポート対象タイプ（該当する場合）に注力し、サイト構造に合った構造化データを再設計する
- AI Overviews（AIによる概要の最適化）など、新しい検索体験での情報抽出に耐えるコンテンツ設計に切り替える
注意したいのは、FAQ形式のコンテンツ自体が不要になったわけではないという点です。ユーザーの疑問を整理して回答する構成はUX上も有効であり、AI Overviews や生成AI検索の引用元としても機能します。終了するのはあくまで「FAQPage構造化データに紐づく検索結果上のリッチリザルト表示」であり、ページ内のQ&Aコンテンツそのものは引き続きSEOに寄与します。
2026年5月の完全終了までにはまだ時間がありますが、サイト規模が大きいほどテンプレート修正やQA工数がかかります。Search Console のレポートを定期的に確認しつつ、計画的に対応を進めていきましょう。
セマンティック検索という技術と概念
リッチリザルトや構造化データの実装を進める前に、その背景にある「セマンティック検索」という考え方を押さえておきましょう。なぜ構造化データが重要なのかを理解するうえで、欠かせない前提知識となります。
セマンティック検索とは何か
セマンティック検索とは、検索クエリやコンテンツに含まれる単語の「意味」や「文脈」、さらには検索ユーザーの「意図」までを理解したうえで、最適な検索結果を返そうとする検索技術の総称です。以前の検索エンジンは、検索ユーザーが入力した文字列とページ内のテキストとを照合することが中心で、単語そのものの意味や、その背後にある意図までは十分には把握できていませんでした。
たとえば「Apple Price」と検索したユーザーが知りたいのは果物の相場なのか、特定企業の株価なのか、文字列だけでは判断が難しい場面があります。セマンティック検索では、周辺の文脈や過去の検索動向、エンティティ（実体）同士の関係性を踏まえ、ユーザーが本当に求めている情報を推定して結果を返します。
ハミングバードとランクブレイン
セマンティック検索の流れを象徴するアルゴリズムが、2013年に導入された「ハミングバード」と、2015年に投入された「ランクブレイン」です。ハミングバードは会話型の長いクエリや質問形式のクエリに対する理解を大幅に改善し、ランクブレインは機械学習を用いて、過去に見たことがないクエリの意味を推測する仕組みを検索ランキングに組み込みました（出典：Google The Keyword）。
さらに2019年には、自然言語処理モデル「BERT」が検索に導入され、前置詞やニュアンスを含む文脈の理解が一段と高まりました。これらの流れは、Googleが「文字列」から「意味」へと検索の軸足を移してきたことを示しています。
構造化データはセマンティック検索を補助する
機械学習や自然言語処理が進化しても、Webページ上の情報を完全に正確に解釈できるわけではありません。そこで役割を果たすのが構造化データです。schema.orgのボキャブラリに沿ってマークアップすることで、「これは商品名」「これは価格」「これは著者」「これはレビュー評価」といった意味情報を、検索エンジンに対して明示的に伝えられます（出典：Google検索セントラル）。
これはセマンティック検索の精度を補助する作業とも言えます。Googleがコンテンツの意味をより確信を持って理解できれば、適切なクエリで表示されやすくなり、リッチリザルトのような視認性の高い表示形態にも乗りやすくなります。検索クエリの意図を理解しようとする検索エンジンの努力に対して、サイト側から「このページはこういう意味のコンテンツです」と橋渡しをするのが構造化データの本質的な役割です。
近年はAIによる概要やAI Modeなど、生成AIを活用した検索体験も広がっています。生成AIにコンテンツを正確に引用してもらうためにも、ページの意味情報を機械可読な形で提供しておく価値はますます高まっていると言えるでしょう。背景にあるこうした技術潮流を踏まえたうえで、リッチリザルトと構造化データの活用を検討していきましょう。
リッチリザルト表示のメリット
リッチリザルトを獲得する最大の意義は、検索結果画面（SERP）における視認率の向上です。レビュー評価の星、価格、画像、調理時間といった補足情報がスニペットに加わることで、通常の青リンクのみの掲載枠よりも圧倒的に目立ち、ユーザーの視線を引きつけやすくなります。結果としてクリック率（CTR）の向上が期待でき、同じ掲載順位でも流入数に差が生まれます。ただしメリットだけでなく、構造化データには注意すべき副作用やリスクもあります。ここでは「視認率・CTR」「順位への影響」「Googleの理解促進」という3つの観点でメリットを整理し、最後にゼロクリック化のリスクにも触れます。
視認率は向上、ただし流入が増えるとは限らない
リッチリザルトはSERP上で枠が広くなり、画像や評価などビジュアル要素が加わるため、視認率の向上は明確なメリットです。CTRも上がりやすく、特にECサイトのProduct構造化データやレシピサイトのRecipe構造化データでは効果を実感しやすい領域です。ECサイトのSEOにおいては、価格・在庫・レビューが検索結果に表示されるだけで競合との差別化要因となります。
一方で「視認率が上がる＝流入が増える」とは限りません。SERP上でユーザーが必要な情報を得てしまい、サイトを訪問せずに離脱する「ゼロクリック化」のリスクが伴います。たとえばFAQ形式の質問の答えがそのまま検索結果に表示されると、ページを開かなくても疑問が解決してしまうケースが起こり得ます。
順位への直接的な影響はないが、間接的に有利になりうる
構造化データのマークアップ自体は、Googleのランキング要因として直接働くわけではありません。GoogleのJohn Mueller氏も、構造化データの使用が一般的な順位上昇に直結するわけではないと繰り返し述べています。ただし、Googleがページの内容をより正確に理解できるようになるため、適切なクエリにマッチさせやすくなるという間接的な効果はあると説明しています。
構造化データの使用は、一般的な順位上昇には繋がりません。ただし、構造化データはそのページが何であるかの理解を手助けし、適切な場面で簡単に表示できるようになります。（ターゲティングの向上、適切な用語での順位付けもあるかもしれない）
John Mueller（Google）
逆に、実際にページに存在しない情報をマークアップする、ユーザーから見えない位置に情報を記述するといった構造化データのスパム的な使い方は、リッチリザルト表示の対象外となるだけでなく、手動による対策（manual action）の対象になるとGoogleが明言しています（出典：Google検索セントラル）。手動対策を受ければ順位に直接的なマイナス影響が出るため、構造化データはあくまでページの実態に即して正しく実装することが大前提です。
Googleがコンテンツを理解しやすくなる
構造化データを実装する最も本質的なメリットは、Googleに対してページの意味を曖昧さなく伝えられる点にあります。テキストだけでは「これは商品名なのか、ブランド名なのか、レビュー対象なのか」が機械的には判別しづらい情報も、schema.orgのプロパティで明示すれば一意に解釈できます。これは前章で触れたセマンティック検索の文脈とも直結する利点です。
近年はAI Overviews（AIによる概要）やAI Modeなど、生成AIが検索体験の中核に入り始めており、機械可読な構造化データの重要性は従来以上に高まっています。AIが情報を正確に抽出・要約するためには、ページの構造が明示されていることが望ましく、構造化データはその基盤となります。AIによる概要を最適化するベストプラクティスにおいても、構造化データの整備は重要な施策のひとつです。
まとめると、リッチリザルトの活用は「視認率の向上」「Googleの理解促進」という直接・間接の両面でメリットがある一方、ゼロクリック化やスパム的実装による手動対策といったリスクも併存します。導入の際は、自サイトのKPI（CTR、流入数、コンバージョン）を継続的に計測しながら、マークアップの追加・調整・削除を柔軟に判断する姿勢が求められます。
商品レビュー記事の長所・短所を構造化データで伝える
商品レビュー記事の検索結果では、レビュー対象の「長所（Pros）」と「短所（Cons）」を要約した形で表示されることがあります。従来 Google はページ本文から自動的にこれらを抽出して表示していましたが、現在は positiveNotes と negativeNotes という構造化データのプロパティを使い、サイト運営者側から明示的に伝えることが可能になっています。自動抽出よりも構造化データで指定した内容が優先されるため、レビュー記事を運営している場合は導入を検討する価値があります（出典：Google検索セントラル）。
対象となる記事タイプと利用できるプロパティ
長所・短所のマークアップが利用できるのは、編集者（または個人）が単一の商品をレビューしている「エディトリアル・プロダクト・レビュー」が対象です。ユーザー投稿型のレビューや、複数商品を比較するまとめ記事ではなく、ある製品について書き手が評価を下しているタイプの記事を想定したものです。
使用できる構造化データの型は Product、Review、ClaimReview です。長所は positiveNotes、短所は negativeNotes プロパティとして ItemList 形式で記述し、各項目を ListItem として並べます。順序を意味する position も指定でき、リスト先頭の項目から優先的に検索結果に取り上げられる傾向があります。
実装時のチェックリスト
Google のガイドラインを踏まえると、実装時に確認しておきたいポイントは次のとおりです。マークアップしただけでは表示されず、ページ本体の作りにも条件があるため、抜け漏れがないか順に点検してください。
- レビュー対象は単一の商品で、書き手による「エディトリアル」なレビュー記事になっているか
- 長所・短所のいずれかを使う場合、その項目を 最低2件 用意できているか（1件のみの実装は推奨されない）
- 構造化データに記述した長所・短所が、ページ本体にもユーザーから見える形で表示されているか（ページに無い情報を構造化データだけに書くのは違反）
@typeがProduct、Review、ClaimReviewのいずれかになっているか- 各項目は短く要点を絞った文になっているか（長文の段落をそのまま入れない）
- 長所と短所を逆に入れていないか、優先度の高い項目を
position: 1に置けているか - Search Console の拡張レポートとリッチリザルトテストでエラー・警告が出ていないか
注意点と運用のポイント
注意したいのは、構造化データの内容とページ本文の内容が乖離していると、Google のスパムポリシーに抵触する可能性がある点です。レビュー本文に書かれていない長所を構造化データだけに盛り込む、あるいは短所を意図的に省くといった操作は、リッチリザルト掲載の機会を失うだけでなく、手動による対策の対象となる場合もあります（出典：Google検索セントラル スパムに関するポリシー）。
また、長所・短所を表示するかどうかは最終的に Google のアルゴリズムが判断します。マークアップしたからといって必ず検索結果に出るとは限らないため、まずはレビュー本文そのものの質を高めたうえで、補助的に構造化データで意味付けを行うという順序で取り組むのが現実的です。商品レビューのコンテンツ要件については、レビューズ アップデートもあわせて確認しておくとよいでしょう。
Googleがサポートするリッチリザルトのデータタイプ
構造化データは schema.org に基づいて任意のタイプをマークアップできますが、検索結果でリッチリザルトとして実際に表示されるのは Google が公式にサポートしているタイプに限られます。サポート対象は随時更新されており、最新の一覧は Google 検索セントラルの「検索ギャラリー」で確認できます（出典：Google 検索セントラル）。
2025年時点で Google がサポートする代表的なデータタイプには、以下のようなものがあります。自サイトのコンテンツ種別に合致するものを選んで実装することが基本です。
- Article（記事／ニュース／ブログ）— 著者・公開日などを伝える
- Breadcrumb（パンくずリスト）— 検索結果のURL欄に階層を表示
- Product（商品）— 価格・在庫・レビュー評価などを表示
- Recipe（レシピ）— カロリー・調理時間・材料などを表示
- Review／AggregateRating（レビュー・評価）— 星評価と件数を表示
- Event（イベント）— 開催日時・場所を表示
- Video（動画）— サムネイル・再生時間・主要シーンを表示
- LocalBusiness（地域ビジネス）— 営業時間・所在地を表示
- Organization（組織）— ロゴ・SNS・問い合わせ先などを伝える
- JobPosting（求人）— Google しごと検索向けの情報
- Course／LearningVideo（教育コンテンツ）
- Dataset／Book／SoftwareApp など専門領域向けタイプ
レビュー評価の数値はドット表記が必須
レビュー評価（ratingValue）を実装する際に意外と見落としやすいのが、数値の小数点表記です。Google は ratingValue の値を半角ドット（ピリオド）の小数点で記述することを要件としています。日本語環境で「4,5」のようにカンマで区切ったり、全角の「．」を使うと、構造化データテストで無効と判定されリッチリザルト表示の対象から外れます（出典：Google 検索セントラル「レビュー スニペット」）。
また、bestRating（最高評価値）と worstRating（最低評価値）の指定範囲、レビュー件数（reviewCount または ratingCount）が1件以上必要である点も基本要件です。LocalBusiness と Organization タイプについては、自社サイト上に自前で記述したレビューや、サードパーティ製ウィジェットを埋め込んだだけのレビューはリッチリザルト表示の対象外となるため、対象タイプとの組み合わせにも注意が必要です。
複数タイプの併用は「ページ内容に合致する範囲で」
1ページに複数の構造化データタイプを併用することは可能です。たとえばレシピ記事であれば、Recipe に加えて Breadcrumb、Article、レビュー件数があれば AggregateRating を併記するといった構成は自然です。ECの商品ページであれば、Product と Breadcrumb、Organization を組み合わせるのが定石です。
一方で、ページの実際の内容と無関係なタイプを追加するのはガイドライン違反です。Google は「ユーザーに表示されていないコンテンツ」「ページの主題と関係ないデータ」のマークアップを禁止しており、違反すると手動による対策（リッチリザルト除外やランキングへの影響）の対象になり得ます（出典：Google 検索セントラル「構造化データに関する一般的なガイドライン」）。複数併用する場合は、それぞれのタイプの必須プロパティをすべて満たし、かつページの表示内容と整合させることが原則です。
実装後は リッチリザルトテストと Search Console の「拡張」レポートで、サポート対象として認識されているか、警告やエラーが出ていないかを必ず確認しましょう。
リッチリザルトが表示されない場合の注意点
構造化データを実装したのにリッチリザルトが表示されない、というケースは珍しくありません。原因は大きく「技術的な記述ミス」「Googleガイドライン違反」「コンテンツ品質の問題」「クロール・レンダリング上の制約」の4つに分類できます。ここでは、それぞれの観点から自己診断のチェックポイントを整理します。
1. 構文・必須プロパティのミスを疑う
最も多い原因は、JSON-LDの記述ミスや必須プロパティの欠落です。schema.orgのタイプごとに、Googleが「必須」と定めるプロパティと「推奨」プロパティが分かれており、必須項目が欠けているとリッチリザルトの対象になりません。まずはGoogleのリッチリザルトテストでURLまたはコードを検証し、エラー・警告の有無を確認しましょう（出典：Google 検索セントラル）。
- JSON-LDの括弧やカンマの閉じ忘れ
- 必須プロパティ（例：Productなら
name、Recipeならimageなど）の欠落 - 値の型違い（数値で渡すべき箇所を文字列で渡している等）
- レビュー評価のドット表記（
4.5を4,5と記述している等のロケール起因のミス）
2. ガイドライン違反・スパム判定
構造化データの内容が「ページ上に表示されていない情報」を含む場合、Googleはガイドライン違反と判断します。たとえばユーザーには見えない位置に書かれたレビュー、実在しない価格、誇張された評価などです。悪質な場合は手動による対策の対象となり、リッチリザルトどころか通常検索の順位にも影響します（出典：Google 構造化データに関する一般的なガイドライン）。
- マークアップした情報がページ本文に表示されているか
- 自社サイトに自社レビューを掲載していないか（LocalBusiness・Organizationは自己レビュー対象外）
- 無関係なタイプを乱用していないか
3. コンテンツ品質・E-E-A-Tの問題
構文が正しくても、リッチリザルトが表示されるかどうかは最終的にGoogleのアルゴリズム判断に委ねられます。コンテンツ品質が低い、重複が多い、サイト全体の信頼性が不足しているといった要素があると、対象機能であってもリッチリザルトが付与されないことがあります。YMYLとE-E-A-Tの観点から、著者情報や運営者情報の明示など、サイト全体の信頼性向上にも取り組みましょう。
4. JavaScriptレンダリングとクロールの制約
構造化データをクライアントサイドのJavaScriptで動的に挿入している場合、Googlebotがレンダリング後のDOMに到達できないと構造化データを認識できません。リッチリザルトテストやSearch Consoleの「URL検査」で、レンダリング後のHTMLに<script type="application/ld+json">ブロックが含まれているかを確認してください。また、robots.txtでJSや外部リソースをブロックしているとレンダリングが失敗します（出典：Google JavaScript SEO の基本）。
5. 反映までの時間とSearch Consoleでの監視
実装直後はGoogleが再クロール・再インデックスする時間が必要です。数日〜数週間経っても表示されない場合は、Search Consoleの「拡張」レポート（パンくず、商品、レシピなど機能ごとのレポート）でエラーや有効ページ数を継続的に確認しましょう。エラー件数の推移を見ることで、テンプレート由来の問題か個別ページの問題かを切り分けできます。
構造化データマークアップの準備
構造化データを実装するにあたっては、まず「どの語彙（ボキャブラリ）」を「どの記述形式（シンタックス）」で書くのか、という2つの前提を押さえておく必要があります。ここを整理しないままコードを書き始めると、Googleがサポートしていないタイプを使ってしまったり、検出されない記法で記述してしまったりと、後戻りが発生しがちです。本章では、実装前に押さえておきたい基礎知識をまとめます。
語彙はschema.orgが事実上の標準
構造化データの語彙（タイプとプロパティの集合）として、現在のウェブで事実上の標準となっているのがschema.orgです。Google、Microsoft（Bing）、Yahoo!、Yandexが2011年に共同で立ち上げた取り組みで、Article、Product、Recipe、LocalBusiness、Event、FAQPage、BreadcrumbListなど、ウェブ上で表現したい事物の大半をカバーするタイプ階層が定義されています。（出典：Google検索セントラル）
ただし、schema.orgで定義されているタイプ・プロパティのすべてがGoogleのリッチリザルト対象になっているわけではありません。Googleがリッチリザルトとして扱うタイプは検索セントラルのドキュメントに一覧化されており、各タイプごとに「必須プロパティ」「推奨プロパティ」が定められています。実装前に、対象タイプのリファレンスを必ず確認しておきましょう。
記述形式は3種類、GoogleはJSON-LDを推奨
schema.orgの語彙をHTMLに埋め込む方法（シンタックス）は、主に次の3つがあります。
- JSON-LD：JSON形式で構造化データを記述し、
<script type="application/ld+json">タグ内にまとめて配置する方式。表示用HTMLとは独立して書けるのが特徴です。 - Microdata：HTMLタグに
itemscopeitemtypeitempropといった属性を付与し、表示要素とマークアップを一体化させる方式。 - RDFa：HTML5に準拠した属性ベースのマークアップ。Microdataと似た発想ですが、より汎用的なセマンティックウェブ標準に基づいています。
Googleは3つの形式すべてをサポートしていますが、公式ドキュメントではJSON-LDを強く推奨しています。表示用のHTMLと分離して記述できるため保守性が高く、CMSやタグマネージャーから差し込みやすいこと、JavaScriptで動的に挿入してもGoogleが認識可能なことが主な理由です。（出典：Google検索セントラル）
| シンタックス | 記述場所 | 特徴 | Googleのサポート |
|---|---|---|---|
| JSON-LD | <head> または <body> 内の <script> タグ | HTMLと分離して記述でき、保守性・拡張性が高い。動的挿入も可能。 | サポート／推奨 |
| Microdata | HTML要素の属性として埋め込み | 表示HTMLとマークアップが一体。修正時に表示崩れの懸念。 | サポート |
| RDFa | HTML要素の属性として埋め込み | HTML5準拠のセマンティックウェブ標準。記述はやや冗長。 | サポート |
実装前に揃えておきたい3つの準備
コードを書き始める前に、以下の3点を整理しておくと作業がスムーズです。
- 対象ページの種類を決める：記事ならArticle、ECの商品ページならProduct、レシピならRecipeなど、コンテンツの性質に合致するタイプを選びます。1ページに複数タイプを併用することも可能です。
- 必須プロパティを満たせるか確認する：たとえばProductであれば
name、レビュー付きならreviewやaggregateRatingなど、Googleが要求する必須項目をページ上のコンテンツで提供できるかチェックします。 - 検証ツールを準備する：実装後はリッチリザルトテストとschema.org Validatorで構文と要件適合をチェックし、公開後はSearch Consoleの拡張レポートで継続監視します。
なお、構造化データを記述したファイルやスクリプトのサイズが極端に大きくなることは通常ありませんが、HTML全体のファイルサイズや読み込み速度の最適化とあわせて、JSON-LDの肥大化にも目を配っておくと安心です。
構造化データのマークアップ方法
構造化データを実装する方法は、大きく分けて「HTMLに直接マークアップを記述する方法」と、Search Console上で操作するだけで設定できる「データハイライター（旧機能）を使う方法」の2通りがありました。現在、Googleが推奨しているのは前者のJSON-LDによるHTML記述ですが、それぞれの特徴を理解した上で自サイトに合った実装方法を選びましょう。
方法1：HTMLに直接マークアップを記述する
もっとも一般的かつGoogle推奨の方法が、ページのHTMLソースに構造化データを直接記述するやり方です。シンタックスはMicrodata・RDFa・JSON-LDの3種類が利用できますが、Googleは JSON-LD を強く推奨しています（出典：Google検索セントラル）。JSON-LDは <script type="application/ld+json"> タグ内にJSON形式でまとめて記述できるため、既存のHTML構造に手を加えずに済み、テンプレートやCMS側でも管理しやすいのが利点です。
具体的な手順は次のとおりです。
- 表現したいコンテンツに合うタイプ（Article、Product、Recipe、BreadcrumbList など）を schema.org で確認する
- Google検索セントラルのガイドラインで、必須プロパティと推奨プロパティを確認する
- JSON-LDでコードを記述し、対象ページの
<head>もしくは<body>に挿入する - リッチリザルトテストとSchema Markup Validatorでエラーや警告がないかを検証する
- 公開後、Search Consoleの「拡張」レポートで対象タイプの有効ページ数とエラーを監視する
WordPressであればテーマや「Yoast SEO」「Schema & Structured Data for WP & AMP」「SEO SIMPLE PACK」などのプラグイン側で記事タイプやパンくず、サイト情報のJSON-LDを自動出力できます。自前でテンプレートに埋め込む場合も、PHPやJavaScript側で変数を差し込む形にしておくと運用が安定します。
方法2：データハイライターを使う（提供終了）
もう一つは、かつてSearch Consoleに搭載されていた「データハイライター」を使う方法です。HTMLを編集せずに、Search Console上で対象ページを開き、タイトル・日付・著者・価格などの要素をマウスでハイライトしてタグ付けするだけで、Googleが構造化データとして認識してくれる仕組みでした。CMSの制約でHTMLを直接編集できないサイトや、エンジニアリソースが限られるサイトにとっては手軽な選択肢でした。
ただし、データハイライターは 2023年をもって提供を終了 しており、現在は新規利用も既存設定の維持もできません（出典：Google検索セントラルブログ）。すでに利用していたサイトは、JSON-LDによる直接マークアップへの移行が必要です。
どちらを選ぶべきか
結論として、現在はJSON-LDによる直接マークアップ一択です。データハイライターが終了した今、Googleがサポートする全リッチリザルトの種類に対応できるのはHTMLへの直接記述のみであり、商品レビューの長所・短所（positiveNotes / negativeNotes）など新しいプロパティもJSON-LDでしか実装できません。テンプレート単位でJSON-LDを動的生成する仕組みを整え、リッチリザルトテストとSearch Consoleの拡張レポートで継続的に検証する運用フローを作っておくのが、もっとも堅実な進め方と言えます。
よくある質問（FAQ）
- Q. リッチリザルトと強調スニペットの違いは何ですか？
- A. リッチリザルトは構造化データのマークアップに基づき、価格やレビュー、画像などの追加情報を検索結果に表示する仕組みです。一方の強調スニペットは、ユーザーの質問に対する回答部分をGoogleがページ本文から自動抽出して検索結果の上部に表示するもので、構造化データの実装は必須ではありません。両者は表示の仕組みも目的も異なります。
- Q. リッチリザルトは表示されるとSEOの順位が上がりますか？
- A. リッチリザルト自体は直接的なランキング要因ではないとGoogleは公表しています。ただし、検索結果での視認性やCTRが向上することで、間接的に評価へ影響する可能性があります。また、構造化データによってページ内容が正確に伝わるため、Googleのコンテンツ理解の助けになります。
- Q. FAQリッチリザルトはいつ完全に終了しますか？
- A. GoogleはFAQリッチリザルトのサポートを2026年5月7日付で完全終了すると発表しています。同日以降はSearch Consoleのレポート、リッチリザルトテスト、関連APIでのFAQタイプのサポートも順次終了します。FAQPage構造化データを実装している場合は、対応方針の見直しが必要です。
- Q. 構造化データを実装するならJSON-LDとMicrodataのどちらが良いですか？
- A. Googleが推奨しているのはJSON-LDです。HTMLのbody内またはhead内にスクリプトとしてまとめて記述できるため、既存のマークアップを書き換えずに導入でき、メンテナンス性も高くなります。Microdataも利用可能ですが、新規実装ではJSON-LDを選ぶのが一般的です。
- Q. 構造化データをマークアップしてもリッチリザルトが表示されないのはなぜですか？
- A. 構造化データの記述ミスやガイドライン違反、コンテンツ品質の不足、JavaScriptで描画されていてクロール時に読み取れない、などが主な原因です。リッチリザルトテストやSearch Consoleの拡張レポートでエラーを確認し、Googleの構造化データガイドラインに準拠しているかを順番にチェックしましょう。また、構造化データを正しく実装しても必ず表示が保証されるわけではありません。
- Q. 商品レビューのpositiveNotesとnegativeNotesは何を書けばよいですか？
- A. positiveNotesにはレビュー対象の商品の長所、negativeNotesには短所を、それぞれ箇条書きの内容として記述します。レビュー記事において読者の判断材料となるポイントを簡潔にまとめることで、検索結果に長所・短所が表示される可能性があります。エディトリアルなレビューが対象で、ユーザー投稿型の評価には適用されない点に注意が必要です。
