口コミパーツのリッチリザルト実装で大切なこと

Last updated at 2025-12-01Posted at 2025-12-01

SEO担当としてQiitaの自社メディア記事の作成を行なっています。

今回は、口コミパーツで使うリッチリザルト（構造化データ）について、エンジニアのみなさんと認識を合わせておきたいポイントをまとめました。

SEOチームとエンジニアの皆さんがスムーズにやり取りできるよう、お互いに理解しておきたい仕様や、実装時につい見落としがちな注意点を共有できればと思います。

なお、本記事は2025年11月時点での勉強中の内容をもとにまとめています。専門的な部分はまだ学習中のため、誤りがある可能性があります。
今後も随時アップデートしていく予定ですので、参考としてお読みください。

はじめに：schema.orgの体系に基づくリッチリザルト

口コミパーツによるリッチリザルトは、Googleが推奨するSchema.org の構造化データ仕様に準拠してマークアップすることが前提となります。

Schema.orgは、Webサイトの情報に「意味」を持たせるための共通ルール集です。

SEOで使う構造化データは、このルールに沿って記述する必要があります。

この記事で紹介する「タイプ」や「プロパティ」はすべてこのSchema.orgのルールに基づいています。

したがって、実装時はGoogleの拡張仕様を含めつつも、基本のschema.orgの定義を理解した上で進めることが重要です。

構造化データマークアップはSchema.orgに準拠しますが、GoogleはSchema.orgのすべての仕様をサポートしているわけではありません。
SEOの観点からは、リッチリザルトとして表示させるために、Googleがサポートするスキーマのみを用いて実装するのがベストプラクティスです。

口コミパーツはGoogleのリッチリザルトとして評価される重要な要素です。

決まったschema.orgのタイプ・プロパティのフォーマットに準拠する必要があります。

口コミに関わる主な「タイプ」と「プロパティ」と、その役割は以下のとおりです。

項目	schema.orgのタイプ	プロパティ	ポイント
総合評価点数	AggregateRating	ratingValue	5点満点など、動的に変わる総合評価。固定値にしないことが重要です。
評価の最大値	AggregateRating	bestRating	最大値の明示が無いと、評価が正しく理解されません。
評価の最小値	AggregateRating	worstRating	通常は1点ですが、デフォルトだと思わずに確認が必要です。
口コミ本文	Review	reviewBody	口コミの本文。長文なら「続きを読む」の省略機能も実装検討してください。
レビュアー名	Review	author	投稿者名。匿名投稿の場合の取り扱いも合わせて確認しましょう。
投稿日時	Review	datePublished	投稿日時。ISO 8601形式で正確に扱うことが必須です。
口コミタイトル	Review	name	レビュータイトル。含めるとリッチリザルトの表現がより良くなります。
口コミ対象	Review	itemReviewed	口コミ対象の商品やサービスの正確な名称を渡しましょう。

口コミデータが十分に揃っていない状態でのマークアップは、リッチリザルトが正しく表示されず、SEO評価に悪影響を及ぼす恐れがあります。
例としては以下の対応が望ましいです。

これらのルールを初期段階で決めておくことが、トラブル回避に繋がります。

コードだけでなく、以下のポイントもSEOおよびユーザー体験に影響します。

口コミパーツのリッチリザルト実装は、Google及びschema.orgの仕様理解と、例外処理対応が不可欠です。
「タイプ」と「プロパティ」の両面から正確にマークアップし、UI仕様も併せてチーム内で認識を合わせることが、品質の高いSEO成果に繋がります。

今回のポイントを共有し、チームで認識を合わせながら進めていければと思います。