Web Guide
Web集客の教科書
Review・AggregateRating構造化マークアップ完全ガイド|星評価を正しく出す実装
「検索結果に星マークを出したくて自社サイトに星評価のマークアップを入れたのに、いつまで経っても星が出ない」「Review構造化データを貼ったのにSearch Consoleでエラーが出る」。商品やサービスを提供する熊本の事業者様から、この一年で増えているご相談です。結論から申し上げれば、自社サイトに自社の星評価を貼っても検索結果に星は出ません。Googleは2019年以降、運営者が自分自身を評価する自己評価のマークアップをリッチリザルトの対象外にしているためです。
本記事では、Review・AggregateRatingの星評価リッチリザルトが有効になるtypeと無効になる条件、自己評価NGを正しく回避する設計、実装からテスト・検証までの手順、そして口コミ評価を正攻法で蓄積する運用までを実務目線で整理しました。読み終えたときに「自社のどのページに、どの形で構造化データを入れるべきか」が判断できる構成にしてあります。
SECTION 01
Review・AggregateRatingとは|星評価が検索結果に出る仕組み
検索結果でタイトルの下に黄色い星と「★4.6(128件)」のような評価が並んでいる表示を見かけます。あの表示は、ページに埋め込まれた構造化データをGoogleが読み取って生成しています。星が出ているページと出ていないページの違いは、見た目ではなく裏側のマークアップにあります。
ReviewとAggregateRatingの役割の違い
Reviewは「ある一人が付けた評価とコメント」を構造化したものです。一方でAggregateRatingは「複数の評価をまとめた平均点と総件数」を構造化したものです。検索結果に星と件数を出したい場合は、集計値を示すAggregateRatingが中心になります。両者は併用でき、対象の商品やサービスに紐づけて記述します。
星が表示される条件はGoogleが判断する
構造化データを正しく実装しても、星評価が必ず表示されるわけではありません。Googleはマークアップの正確性に加えて、ページの品質・評価対象の妥当性・自己評価かどうかを総合的に判断します。実装は星表示の必要条件であり、十分条件ではないという前提を最初に押さえておくことが重要です。
リッチリザルトがもたらすクリック率への影響
検索結果に星が表示されると、同じ順位でも視覚的に目立ち、クリックされやすくなる傾向があります。順位を上げる施策とは別軸で、同じ順位での通過率を高める施策として構造化データが機能します。だからこそ、正しいtypeで正しく実装することに価値があります。
星評価の表示はマークアップが必要条件であって十分条件ではありません。正しいtypeで正確に実装したうえで、Googleが品質を含めて表示を判断します。
SECTION 02
自社サイトに自社の星を貼るとなぜ星が出ないのか
最も多い誤解が「会社のトップページや会社概要ページに自社への星評価を貼れば、検索で星が出る」というものです。実際にはこの方法で星は出ません。理由は、評価する側と評価される側が同一になる自己評価を、Googleがリッチリザルトの対象から外しているためです。
2019年のポリシー変更で対象外になった構造
Googleは2019年9月に、LocalBusinessやOrganizationを評価対象とするレビュー構造化データのうち、運営者自身がそのサイトに掲載する自己評価をリッチリザルトの対象外とする変更を行いました。自社が自社を高く評価して星を出す行為は、検索利用者にとって信頼性が担保されないため、表示の対象から外されたという背景があります。
「self-serving」とみなされる典型ケース
自社サイトのトップページに「当社の評価★4.9」と貼る、会社概要にOrganizationのAggregateRatingを付ける、サービス紹介ページにLocalBusinessの星を埋め込む。これらはいずれも評価する主体と評価される主体が同一であり、self-servingとして対象外になります。マークアップ自体は構文として正しくても、リッチリザルトには反映されません。
エラーは出ないが星も出ないという状態
厄介なのは、自己評価のマークアップでもリッチリザルトテストで構文エラーが出ないケースがあることです。構文は正しいため「実装できた」と判断しがちですが、self-servingのため表示対象から外れ、星は永遠に出ません。エラーゼロと星表示は別物だという理解が、無駄な実装を避ける鍵になります。
自社が自社を評価する自己評価のマークアップは、構文が正しくてもリッチリザルトの対象外です。LocalBusinessやOrganizationへの星貼りでは検索結果に星は出ません。
SECTION 03
星評価のリッチリザルトが有効になる対象type
「では星はどうやっても出ないのか」というと、そうではありません。評価される対象が運営者自身でなければ、星評価のリッチリザルトは有効です。自社が販売する個別の商品、提供する講座、出版する書籍などは、評価対象と運営者が別であるため、構造化データで星を示すことに合理性があります。
- 01
Product(商品)|ECサイトの主役
最も一般的な対象typeです。ECサイトや商品ページで、その商品に付いた購入者レビューの平均点と件数を示します。評価対象は「商品」であり運営者自身ではないため、self-servingに該当しません。EC事業者が星を出したい場合の中心になるtypeです。
- 02
Recipe(レシピ)|料理・食品系コンテンツ
レシピページで、そのレシピに対する評価を示します。飲食・食品関連の事業者が、自社が公開する個別レシピへの口コミを構造化する形で利用できます。評価対象はレシピというコンテンツであり、運営者そのものではありません。
- 03
Course(講座)|スクール・講座事業
教室やオンライン講座を提供する事業者が、個別の講座に付いた受講者評価を示せます。スクール運営の会社そのもの(Organization)ではなく、提供する個別Courseを評価対象にすることで、self-servingを回避しながら星を表示できます。
- 04
Book(書籍)・Movie(映画)|作品コンテンツ
出版物や映像作品など、作品単位で評価される対象に使います。作品の評価対象は作品そのものであり、販売元や制作会社という運営者ではないため、リッチリザルトの対象になります。コンテンツ販売を行う事業者向けのtypeです。
- 05
SoftwareApplication(アプリ)|ソフト・アプリ提供
アプリやソフトウェアの紹介ページで、利用者評価を構造化できます。評価対象はアプリというプロダクトであり、開発・提供会社そのものではないため対象になります。自社サービスをプロダクト単位で見せたい場合の選択肢です。
SECTION 04
自己評価NGを正しく回避する設計の考え方
星評価を出したい気持ちから、つい会社サイト全体に星を貼りたくなりますが、それは逆効果です。構造化データのReview・AggregateRatingと、Googleビジネスプロフィールの口コミは、それぞれ星を出す場所と役割が異なります。この役割分担を理解すると、どこに何を実装すべきかが明確になります。
役割分担の基本|ウェブ検索とローカル検索
商品ページの星はウェブ検索のリッチリザルトでProduct等のtypeとして表示されます。一方、店舗や会社そのものの星は、Googleビジネスプロフィールに蓄積された口コミがGoogleマップやナレッジパネルで表示されます。事業そのものの評価はビジネスプロフィール側、個別商品の評価は構造化データ側という分担が正解です。
自社サイトに事業評価を貼らないという判断
会社概要やトップページにOrganizationやLocalBusinessのAggregateRatingを貼っても星は出ないため、これらは実装しないのが正しい判断です。構文エラーが出ないからと放置すると、無効なマークアップがページに残り続けます。実装するなら、星が有効になる対象typeのページに限定します。
商品を持たないサービス業の場合の考え方
士業や店舗型サービスなど、明確な商品ページを持たない業種では、無理にProductマークアップを当てはめるのは避けます。事業そのものの評価はGoogleビジネスプロフィールで口コミを集め、地図検索とナレッジパネルで星を出す方向に集中するのが現実的です。構造化データで星を出すことだけが、星を見せる唯一の方法ではありません。
事業そのものの評価はGoogleビジネスプロフィール、個別商品の評価は構造化データ。星を出す場所を役割で分けることが、自己評価NGを回避する正しい設計です。
SECTION 05
Product向けReview・AggregateRatingの実装手順
実装の中心はJSON-LD形式での記述です。Productに対してaggregateRatingとreviewを紐づけ、ページに掲載済みの口コミの平均点と件数を正確に記述します。以下6ステップが、自己評価NGを回避しながら星を出すための実務手順です。
- 01
評価対象をProductとして特定する
星を出したい個別商品のページを対象に決めます。会社全体や事業ではなく、ひとつの商品を評価対象にすることがself-serving回避の出発点です。商品ページが存在しない場合は、まず商品単位のページを用意するところから設計します。
- 02
ページに実際の口コミを表示する
構造化データに記述する口コミは、ページ上に実際に表示されている必要があります。ユーザーに見えない口コミをマークアップだけで主張するのはガイドライン違反です。購入者レビューの実体をページに掲載したうえで、その内容を構造化します。
- 03
aggregateRatingに平均点と件数を記述する
ProductのaggregateRatingとして、ratingValue(平均点)とreviewCount(件数)を記述します。これらはページに表示されている集計と完全に一致させます。bestRatingで満点(通常5)を明示しておくと、評価スケールが正しく伝わります。
- 04
個別reviewにauthorとratingを記述する
代表的な個別口コミをreviewとして記述し、author(レビュー投稿者)とreviewRating(その口コミの点数)を含めます。authorは実在の投稿者であり、運営者自身ではないことが重要です。複数の口コミを配列で記述できます。
- 05
リッチリザルトテストで検証する
記述したJSON-LDをGoogleのリッチリザルトテストにかけ、Product・AggregateRating・Reviewが有効と認識されるかを確認します。エラーと警告をすべて解消します。構文が通っても、対象typeが正しいかをこの段階で必ず確認します。
- 06
公開後にSearch Consoleで監視する
公開後はSearch Consoleの拡張レポートで、商品スニペットやレビュースニペットが有効と認識されているかを継続監視します。エラーや無効が出た場合は原因を特定して修正します。再クロールを経て星が表示されるかを確認します。
SECTION 06
Review・AggregateRatingの必須プロパティ早見表
Review・AggregateRatingには複数のプロパティがありますが、最低限必要なものは限られています。以下は、Productに紐づけて星評価を出すための主要プロパティの早見表です。記述漏れや不一致がないかを照合してください。
| プロパティ | 所属 | 区分 | 役割 | 記述上の注意 |
|---|---|---|---|---|
| ratingValue | aggregateRating | 必須 | 平均点 | ページ表示と完全一致させる |
| reviewCount | aggregateRating | 必須 | 口コミ総件数 | 実際の掲載件数と一致させる |
| bestRating | aggregateRating | 推奨 | 満点(通常5) | 評価スケールを明示する |
| author | review | 必須 | 口コミ投稿者 | 運営者自身は不可 |
| reviewRating | review | 必須 | 個別口コミの点数 | その口コミ単体の評価 |
| name / itemReviewed | Product | 必須 | 評価対象の商品名 | 事業体ではなく商品を指定 |
必須プロパティが欠けると無効になる
aggregateRatingのratingValueとreviewCount、reviewのauthorとreviewRatingは、いずれも欠けるとリッチリザルトの対象から外れます。特にauthorの欠落はよくあるエラーです。リッチリザルトテストで「フィールドがありません」という警告が出た場合は、その必須プロパティを補ってから公開します。
itemReviewedで評価対象を明示する
AggregateRatingやReviewを単独で記述すると、何を評価しているのかが伝わりません。Productに入れ子で記述するか、itemReviewedで評価対象を明示します。ここで事業体を指定するとself-servingになるため、必ず個別商品を指定することが正しい設計につながります。
JSON-LDとmicrodataのどちらで書くか
構造化データの記述形式にはJSON-LDとmicrodataがありますが、Googleが推奨し管理しやすいのはJSON-LDです。HTMLの構造に縛られず、ページ末尾にまとめて記述できるため、口コミ更新時の保守も容易になります。既存サイトに後付けする場合も、JSON-LDで統一しておくと運用負荷を抑えられます。
SECTION 07
実装後の検証で確認する品質チェック
以下6項目は、Review・AggregateRatingを公開する前後の検証チェックです。一つでも欠けている場合は、その部分を補ってから公開・運用することを推奨します。
- 01
評価対象がself-servingになっていないか
評価対象がOrganizationやLocalBusinessといった事業体になっていないかを最初に確認します。事業体を評価対象にしていれば、構文が正しくても星は出ません。Productなどの対象typeに評価が紐づいているかを点検します。
- 02
ページ表示と数値が一致しているか
ratingValueとreviewCountが、ページに実際に表示されている口コミの平均点と件数に一致しているかを確認します。商品の口コミが増減した場合は、マークアップの数値も同時に更新します。表示と数値の乖離は違反の典型です。
- 03
リッチリザルトテストで有効と認識されるか
Googleのリッチリザルトテストにページまたはコードを入力し、対象typeが有効と認識されているかを確認します。エラーと警告をすべて解消した状態で公開します。プレビューで星が表示されるかも目視します。
- 04
必須プロパティの欠落がないか
ratingValue・reviewCount・author・reviewRating・itemReviewedといった必須プロパティが欠けていないかを確認します。「フィールドがありません」の警告は必須欠落のサインです。補ってから公開します。
- 05
Search Consoleで拡張レポートを監視するか
公開後はSearch Consoleの商品スニペット・レビュースニペットの拡張レポートを定期的に確認します。エラーや無効の件数が増えていないかを監視し、出た場合は速やかに原因を特定して修正します。
- 06
口コミ更新時にマークアップを同期するか
口コミが追加・削除されると平均点と件数が変わります。マークアップの数値が古いまま放置されると不一致になり、違反リスクが生じます。口コミの更新とマークアップの更新を同期させる運用ルールを決めておきます。
SECTION 08
よくある違反パターンとペナルティの回避
星を出したい気持ちが先行すると、ガイドラインを逸脱した実装に陥りがちです。違反は星が出ないだけでなく、サイト全体の評価を下げるリスクを伴います。以下のパターンに該当していないかを確認してください。
数値の水増しと捏造
ページに表示されている口コミより高い平均点を記述する、実在しない件数を記述する、といった操作は明確な違反です。検索利用者を誤認させる行為として、リッチリザルトの対象外や手動による対策の原因になります。数値は常にページ表示と一致させることが原則です。
ページに表示されない口コミのマークアップ
ユーザーに見えない口コミを構造化データだけで主張するのは違反です。構造化データは、ページの可視コンテンツを補足するものであり、可視コンテンツに存在しない情報を主張する用途ではありません。マークアップする口コミは必ずページに掲載します。
事業体への自己評価という根本的な誤り
最も多い無駄な実装が、OrganizationやLocalBusinessに自社評価を貼ることです。これはself-servingとして対象外であり、星は出ません。違反というより、そもそも有効にならない設計です。評価対象を個別商品に変えることが、唯一の正しい回避策になります。
数値の水増し・非表示口コミのマークアップ・事業体への自己評価。この3つを避けることが、星表示を狙いながらリスクを抑える前提です。
SECTION 09
口コミ評価を正攻法で蓄積する運用
マークアップの技術だけを磨いても、肝心の口コミがなければ星は意味を持ちません。事業そのものの評価はビジネスプロフィールで、個別商品の評価は商品ページで集める。この両輪を回す運用が、星表示の本当の土台になります。
- 01
Googleビジネスプロフィールで事業の口コミを集める
店舗や会社そのものの評価は、Googleビジネスプロフィールに口コミを蓄積することで、地図検索とナレッジパネルに星が表示されます。来店客や顧客に口コミ投稿を依頼する仕組みを整え、いただいた口コミには丁寧に返信します。事業評価の星はこちらが正攻法です。
- 02
商品ページに購入者レビューを掲載する
EC商品については、購入者レビューを商品ページに掲載する仕組みを用意します。掲載したレビューの平均点と件数を構造化データに反映することで、ウェブ検索のリッチリザルトに星が出せます。レビュー収集と掲載がマークアップの前提になります。
- 03
口コミと構造化データの更新を運用に組み込む
口コミは増減するため、平均点と件数も変動します。口コミの更新に合わせて構造化データの数値を同期する運用ルールを決めておきます。手動更新が負担になる場合は、口コミ件数と評価を自動で反映する仕組みの導入を検討します。鮮度と正確性を両立させます。
SUMMARY
まとめ|星評価を検索結果に正しく出す要点
自社サイトに自社の星評価を貼っても検索結果に星は出ません。Googleが2019年以降、運営者が自分自身を評価する自己評価のマークアップをリッチリザルトの対象外にしているためです。星評価が有効になるのはProduct・Recipe・Course・Book・Movieなど、評価対象が運営者自身ではないtypeであり、事業そのものの評価はGoogleビジネスプロフィール側に蓄積するのが正しい設計です。重要なのは以下の3点に集約されます。
- 01
事業体への自己評価は星が出ない
OrganizationやLocalBusinessに自社評価を貼るself-servingは、2019年以降リッチリザルトの対象外です。構文エラーが出なくても星は出ません。評価対象を個別商品に変えることが唯一の回避策です。
- 02
個別商品・コンテンツを評価対象にする
星を出したい場合は、Product・Course・Bookなど運営者以外を評価対象とするtypeに、ページ表示と一致した平均点・件数を記述します。何を評価対象にするかが、星が出るか出ないかを分けます。
- 03
事業評価はビジネスプロフィールで蓄積する
店舗や会社そのものの星は、Googleビジネスプロフィールに口コミを集め、地図検索とナレッジパネルで表示させます。構造化データとビジネスプロフィールの役割分担が、正攻法での星表示につながります。
株式会社CREVIAは、熊本県内250社以上の支援実績をもとに、Review・AggregateRatingの設計から自己評価NGを回避した実装、Googleビジネスプロフィールでの口コミ獲得までを一体で支援しています。検索結果に星を正しく出したい場合は、無料の現状診断からご要望に応じて対応可能です。
SECTION 10
よくある質問
Q.自社サイトに自社の星評価を貼れば検索結果に星が出ますか?
原則として出ません。Googleは2019年以降、LocalBusinessやOrganization自身が自社サイトに掲載する自己評価のAggregateRatingをリッチリザルトの対象外にしています。星評価のリッチリザルトが有効なのはProduct・Recipe・Course・Book・Movieなど、評価される対象が運営者自身ではないtypeです。自社事業そのものの評価はGoogleビジネスプロフィール側に蓄積する設計が正しい方法です。
Q.Review・AggregateRatingはどのtypeで使えますか?
Product(商品)、Recipe(レシピ)、Course(講座)、Book(書籍)、Movie(映画)、SoftwareApplication(アプリ)などが代表的な対象typeです。これらは評価される対象と運営者が別であり、第三者の評価を構造化データで示すことに合理性があります。LocalBusinessやOrganizationを評価対象とした自己評価は対象外です。
Q.AggregateRatingに自分で適当な数値を入れても大丈夫ですか?
絶対に避けてください。実際にサイト上に表示されている口コミの集計とマークアップの数値が一致していない場合、構造化データのガイドライン違反となり、リッチリザルトの対象外や手動による対策の原因になります。ratingValueとreviewCountは、ページに実際に掲載されている口コミ件数・平均点と完全に一致させる必要があります。
Q.星評価が検索結果に出るまでどれくらいかかりますか?
正しく実装してもリッチリザルトの表示はGoogleの判断によるため、確実な保証はありません。実装後にリッチリザルトテストとSearch Consoleの拡張レポートで有効と認識されてから、再クロールを経て数日から数週間で表示されることが多い傾向です。表示有無はGoogleが品質を含めて判断するため、実装が正しくても必ず表示されるわけではありません。
Q.口コミが少ない段階でマークアップしてもいいですか?
件数が極端に少ない場合は無理にマークアップする必要はありません。Reviewは個別の口コミ、AggregateRatingは集計値を示すものなので、実際に掲載できる口コミが蓄積してから実装するのが自然です。まずはGoogleビジネスプロフィールで口コミを集める運用を整え、対象商品ページの口コミが揃った段階で構造化データを追加する順序が現実的です。
Q.構造化マークアップの実装をCREVIAに依頼できますか?
株式会社CREVIAが対応可能です。熊本県内250社以上の支援実績で、Review・AggregateRatingを含む構造化マークアップの設計から、自己評価NGを回避した正しい実装、Googleビジネスプロフィールでの口コミ獲得までを一体で支援しています。無料の現状診断からご要望に応じて対応します。
