Google検索でレビュー記事を見ていると、タイトルの下に★4.5のような星評価が表示されている記事を見かけることがあります。
自分もレビュー記事を書いているのに、検索結果にはタイトルとメタディスクリプションしか表示されない。
隣の記事には星が付いている――この差はなんなのか。
結論から言うと、あの星の正体は構造化データ(JSON-LD)です。
この記事では、構造化データとは何か、レビュー記事に必要なスキーマの構造、WordPressでの実装方法、そしてよくある失敗パターンまでを解説します。
WordPressで単一商品のレビュー記事を書いている方向けです。
複数商品の比較記事やランキング記事では、構造化データの扱いが異なります。


ブログ運営 / WordPressカスタマイズ / SEO
バビ
WordPress・SEO・ブログ運営の実践情報を、実体験ベースで発信しています。
検索結果の「星」の正体は構造化データ
構造化データ(JSON-LD)とは
構造化データとは、ページの内容を検索エンジンが理解できる形式で記述するための仕組みです。
人間がページを見れば「これは商品レビューで、評価は4.5点だな」とわかります。
しかし、検索エンジンにとってはHTMLのテキストはただの文字列です。
どこが商品名で、どこが評価なのかを正確に判別するのは簡単ではありません。
そこで、ページの情報をSchema.orgという国際的な規格に沿って記述し、検索エンジンに「これは商品情報です」「評価は4.5です」と明示的に伝えるのが構造化データの役割です。
記述形式はいくつかありますが、Googleが推奨しているのはJSON-LD(JavaScript Object Notation for Linked Data)という形式です。
HTMLの <head> 内に <script type=”application/ld+json”> タグとして埋め込みます。
Googleのリッチリザルトの仕組み
構造化データを正しく実装すると、Googleの検索結果に通常のテキスト以上の情報が表示されることがあります。
これをリッチリザルトと呼びます。
レビュー記事の場合は、検索結果のタイトル下に星評価(★)が表示されるのが代表的なリッチリザルトです。
ここで重要なのは、構造化データを入れれば必ず星が表示されるわけではないということです。
Googleの公式ガイドラインにも
「構造化データを使用して、ある機能が表示されるよう設定することはできますが、その機能が必ず表示されるとは限りません」
と明記されています。
つまり、構造化データはリッチリザルトの「表示対象になるための必須条件」であって、「表示の保証」ではありません。
ただし、構造化データがなければ表示対象にすらなりません。
レビュー記事に必要なスキーマ
ProductとReviewの関係
商品レビュー記事で星評価のリッチリザルトを狙うには、Product(商品情報)とReview(レビュー情報)の2つのスキーマを組み合わせます。
Google公式の商品レビュー記事の例に沿うと、Productの中にReviewを入れ子にする構成が基本です。
{
"@context": "https://schema.org/",
"@type": "Product",
"name": "商品名",
"image": ["https://example.com/product.jpg"],
"review": {
"@type": "Review",
"name": "記事タイトル",
"reviewRating": {
"@type": "Rating",
"ratingValue": 4.5,
"bestRating": 5,
"worstRating": 1
},
"author": {
"@type": "Person",
"name": "レビュアー名"
},
"datePublished": "YYYY-MM-DD",
"positiveNotes": {
"@type": "ItemList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "良い点1" },
{ "@type": "ListItem", "position": 2, "name": "良い点2" }
]
},
"negativeNotes": {
"@type": "ItemList",
"itemListElement": [
{ "@type": "ListItem", "position": 1, "name": "気になる点1" }
]
}
}
}※ `YYYY-MM-DD` は実際の公開日に置き換えてください。
※ Review Snippet自体はレシピや映画など複数のタイプに対応していますが、「商品」のレビュー記事の場合はこのProduct + Reviewの構成が公式例に最も近い形です。
最低限入れておきたい主要項目
リッチリザルトの表示対象になるために入れておきたい項目と、あるとより良い項目をまとめます。
Google公式では、Product snippetsにはreview・aggregateRating・offersのいずれかが必要とされています。
商品レビュー記事ではreviewを使うのが一般的です。
- name(商品名)― Productの名前
- review(レビュー情報)― Review型のオブジェクト
- reviewRating(評価)― ratingValue(数値)、bestRating、worstRating
- author(レビュアー)― レビューを書いた人の名前
- image(商品画像)― 画像を含めると構造化データの情報量が増え、Googleがページ内容をより正確に把握できるようになります
- brand(ブランド名)― 商品のメーカーやブランド
- positiveNotes / negativeNotes(良い点・気になる点)
- datePublished / dateModified ― レビューの公開日・更新日
positiveNotes / negativeNotes の注意点:
Googleのガイドラインでは、良い点(positiveNotes)と気になる点(negativeNotes)は合計2項目以上でないと認識されません。
これはGoogle公式ドキュメントに明記されている要件です。
「良い点1つだけ」では不十分です。
また、JSON-LDに記述した内容はページ上にも表示されている必要があります。
JSON-LDにだけ書いてページ上に見えない情報は、ガイドライン違反になります。
WordPressでの実装方法3パターン
①手動でJSON-LDを書く
最もシンプルな方法は、記事ごとにJSON-LDのコードを書いて <head> に挿入する方法です。
JSON-LDは <head> と <body> のどちらにも埋め込めます。
WordPressでは、テーマのヘッダー出力機能を使って <head> に挿入するか、本文内の「カスタムHTML」ブロックで <body> 側に出力する方法があります。
〇 メリット
- 完全に自分でコントロールできる。
- 外部プラグインが不要。
△ デメリット
- 記事ごとに毎回コードを書く必要がある。
- JSON-LDの記法ミスがあるとGoogleに無視される。
- 記事が増えるほど管理が大変になる。
②functions.phpに追加する
子テーマの `functions.php` にPHPコードを書いて、投稿ページに自動でJSON-LDを出力する方法です。
記事のカスタムフィールドに商品名や評価を入力しておき、PHPでそれを読み取ってJSON-LDを生成する仕組みを自分で作ります。
〇 メリット
- 一度作れば記事ごとの手動作業が減る。
△ デメリット
- PHPのコーディング知識が必要。
- テーマを更新すると子テーマでも互換性が壊れるリスクがある。
- エラーがあるとサイト全体が表示されなくなる場合がある(画面が真っ白になる「WSOD」)。
- SEOプラグインとの二重出力に自分で対処する必要がある。
- コードを書く必要がある。
- JSON-LDの記法ミスがあるとGoogleに無視される。
- 記事が増えるほど管理が大変になる。
実は私も、以前はこの方法で実装していました。
動くには動くのですが、テーマ更新のたびにヒヤヒヤするのと、SEOプラグインとの競合チェックを手動でやるのが面倒で、最終的にプラグイン化しました。
③プラグインを使う
WordPressプラグインを使えば、コードを書かずに構造化データを出力できます。
SEOプラグイン(Yoast SEO、RankMathなど)にも構造化データ機能はありますが、レビュー記事に特化したProduct + Reviewスキーマを出力できるものは限られています。
このブログでは、自作のプラグイン「ReviLD(レビルド)」を使っています。

ReviLDは、投稿画面のサイドバーに商品名・評価・良い点・気になる点を入力するだけで、Schema.org準拠のJSON-LDを自動生成します。
- コード不要 ― サイドバーの入力欄に情報を入れるだけでJSON-LDが自動生成
- レビューボックスの自動表示 ― JSON-LDの内容を記事本文にも表示(Googleの「ページ上にも表示」要件を自動で満たす)
- 二重出力の自動検知 ― Yoast SEO・RankMathなどが同じスキーマを出力していたら自動停止
- ショートコードで自由配置 ― [revild] で記事内の好きな位置にレビューボックスを配置可能
- 表示項目のON/OFF ― 商品名・評価・良い点・気になる点を個別に表示/非表示
- 全記事の共通設定 ― デフォルトの表示設定を一括管理、記事ごとに上書きも可能
- カスタムCSS対応 ― レビューボックスのデザインを自由に調整
- 自動アップデート ― WordPress標準の更新画面から最新版に更新可能
Pros/Consの2項目ルールも自動で判定し、条件を満たさない場合は出力しません。ガイドライン違反を自動で防ぐ仕組みです。

よくある失敗と注意点
構造化データを実装しても、リッチリザルトが表示されないことがあります。よくある原因をまとめます。
二重出力(SEOプラグインとの競合)
最も見落としやすい問題です。
Yoast SEOやRankMathなどのSEOプラグインが、すでにProductスキーマを出力しているケースがあります。
ここに自分で追加した構造化データが重なると、同じスキーマが2つ出力されてしまい、Googleに両方とも無視される可能性があります。
確認方法: ページのソースコード(Ctrl+U)を開いて、application/ld+json で検索してください。同じ @type: Product が2つ見つかったら二重出力です。
Pros/Consが1項目しかない
positiveNotes(良い点)とnegativeNotes(気になる点)は、合計で2項目以上が必要です。
これはGoogle公式ドキュメントに明記されている要件です。
「良い点を1つだけ書いた」場合、JSON-LDに含めてもGoogleには認識されません。
JSON-LDの内容がページ上に表示されていない
Googleのガイドラインでは、構造化データの内容はページ上でもユーザーに見えている必要があります。
JSON-LDに「評価4.5」と書いたのに、記事本文のどこにも評価が表示されていなければ、ガイドライン違反と判断される可能性があります。
ratingValueの範囲
ratingValueは bestRating と worstRating の範囲内である必要があります。
5段階評価なら1.0〜5.0の範囲です。0や6のような範囲外の値を入れるとエラーになります。
Googleのクロール待ち
構造化データを正しく実装しても、検索結果にすぐ反映されるわけではありません。
Googleがページをクロール(再取得)するまで数日〜数週間かかることがあります。
実装後の確認は、Googleのリッチリザルトテスト(https://search.google.com/test/rich-results)を使いましょう。
ここでエラーなしと表示されれば、構造化データとしては正しく実装できています。

Search Consoleでは「拡張」→「商品スニペット」でGoogleが実際に認識しているかも確認できます。
ただし、このレポートが表示されない場合もあるので、その場合は「URL検査」ツールで個別ページを確認してください。
これらの失敗パターン――二重出力、Pros/Consの項目数ルール、ページ上への表示要件――は、手動で管理していると見落としやすいポイントです。
ReviLDはこれらをすべて自動で処理します。
まとめ
レビュー記事の検索結果に星評価を表示するには、構造化データ(JSON-LD)の実装が必要です。
ポイントを整理すると、
- 商品レビュー記事ではProductの中にReviewを入れ子にする構造が基本形であること
- positiveNotes/negativeNotesは合計2項目以上が必要なこと
- JSON-LDの内容はページ上にも表示する必要があること
そしてSEOプラグインとの二重出力に注意が必要だということです。
WordPressでの実装方法は手動・functions.php・プラグインの3パターンがありますが、ガイドライン準拠の安全性と運用の手軽さを考えると、専用プラグインの利用がおすすめです。
構造化データを正しく実装すれば、Googleのリッチリザルト表示の対象になります。
表示が保証されるわけではありませんが、対象になるための第一歩は「正しい構造化データを入れること」です。
ReviLDは、レビュー記事の構造化データ出力に特化したWordPressプラグインです。
zipをインストールして、記事ごとに商品名と評価を入力するだけ。
Googleガイドライン準拠のJSON-LDが自動生成されます。
二重出力の自動検知、レビューボックスの自動表示、ショートコード対応、自動アップデートまで、面倒な部分はすべて自動で処理します。
こちらもおすすめ


