テストツールで Google リッチ検索結果をプレビューできない丨リッチ検索結果のエラーを修正する方法

簡単に言うと、Google公式のテストツールで確認すると「リッチリザルトは検出されませんでした」と表示されるのに、

Search Console（サーチコンソール）を見ると「offerフィールドが不足しています」（例：製品価格や在庫などの情報が正しくマークされていない）と警告される状態のことです。

Googleがクロールする際、JavaScriptを完全に実行できるページは40%未満であるため、JSで動的に生成された多くの製品（Product）構造化データが、クローラーに捕捉されないことが多々あります。

例えば、ある食品ECサイトでは、レシピ（Recipe）のマークアップに「栄養成分」（nutrition）の項目（カロリーやタンパク質含有量など）を加えなかった結果、表示されるはずだった「栄養情報付きのレシピカード」が半分以上減少し（表示率が62%低下）、毎日数千件のクリックを失いました。

また、あるニュースサイトでは、記事（Article）マークアップ内の「公開日」（datePublished）の形式を間違えた（例：標準の「2023-12-31」ではなく「2023/12/31」と記述）ため、注目ニュースが「強調スニペット」（検索結果ページ上部の目立つカード）に表示されなくなり、多くの露出機会を逃しました。

トラブルシューティングの手順

データで見ると、問題の分布は明確です。プレビュー失敗の約65%は、JSON-LDコードの記述ミスや必須プロパティの不足（記述すべきフィールドがない、形式が正しくないなど）によるものです。

20%は、ページでJavaScriptによるコンテンツの動的読み込みが行われているものの、Googleのクロール時にレンダリングされなかったことが原因です。

残りの15%は、ページの読み込みが遅すぎる、またはログインが必要なために、クローラーがマークアップを読み取れなかったケースです。

テストツールはデフォルトで古いデータのキャッシュを使用することがあり、新しい問題の48%が検出されない可能性があります。「公開URLのテスト」を行ったとしても、JS生成コンテンツのカバー率は35%に過ぎず、多くの動的マークアップが検証されません。

ウェブサイトがHTTPS化されていない場合、構造化データの18%が無視される可能性があります。また、ページの読み込みに5秒以上かかると、Googleクローラーの22%がクロールを途中で断念するため、当然マークアップは読み取られません。

構造化データの構文とプロパティの検証

構造化データの検証では、JSON-LDの構文の正確性（カッコ/引用符/カンマのミスが構文問題の42%-31%を占める）、必須プロパティの網羅性（Productのoffers不足が38%、ArticleのdatePublished不足が29%）、およびタイプのネスト（入れ子）の適切さ（例：RecipeにNutritionInformationがネストされていないために解析失敗率が57%上昇）に焦点を当てる必要があります。

JSON-LDの構文エラー

カッコと引用符の不一致（構文エラーの42%）：

エラーコードの例：

{
“@context”: “https://schema.org”,
“@type”: “Product”,
“name”: “ワイヤレスイヤホン”,
“image”: “https://example.com/headphones.jpg”,
} // 閉じカッコ “}” が不足

修正方法：コードエディタの「カッコのペア表示」機能（VS CodeのBracket Pair Colorizerプラグインなど）を使用し、{}、[]、""が対になっているか一行ずつ確認します。

冗長なカンマ（構文エラーの31%）：

エラーコードの例：

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // この末尾のカンマが不要
“priceCurrency”: “USD”
},

修正方法：JSONの仕様では、オブジェクトや配列の最後のプロパティの後にカンマを付けてはいけません。手動で削除するか、オンライン整形ツール（JSONLintなど）で自動修正します。

データ型の誤り（構文エラーの27%）：

日付形式がISO 8601標準を採用していない（"2023/10/05"ではなく"2023-10-05T08:00:00+08:00"とすべき）、または価格に文字列型を使用していない（"price": 99.99ではなく"price": "99.99"とすべき）などのケースです。

Schema.orgでは、数値型のプロパティも対応する形式に合わせるよう明示されており、そうでない場合は「無効な値」と判定されます。

必須プロパティの網羅性

Schemaのタイプごとに「必須プロパティ」が決まっており、一つでも欠けるとリッチリザルトが生成されない原因になります。

Googleの「リッチリザルト ガイドライン」（2024年版）によると、頻出する必須プロパティと不足時の影響は以下の通りです。

マークアップのタイプ	必須プロパティ	不足率	影響の例
Product	name, image, offers	38%	価格や購入リンクが表示されない
Article	headline, datePublished, author	29%	強調スニペットが表示されない
LocalBusiness	name, address, telephone	35%	マップカードに場所が紐付けられない
Recipe	name, description, recipeIngredient	41%	材料リストや手順が表示されない

事例：あるグルメサイトでは、RecipeマークアップにrecipeIngredient（必須プロパティ）が欠けていたため、リッチリザルトの表示率が12%から5%に低下しました。

修正後、材料リスト（例："recipeIngredient": ["小麦粉 200g", "卵 2個"]）を補充したところ、3日以内に表示率は10%まで回復しました。

タイプのネスト（入れ子）規則

複雑なSchemaタイプでは、ネスト構造によって意味的な関連付けを行う必要があります。正しくネストされていないと、Googleはプロパティがどの項目に属しているか識別できません。

Schema.orgの2023年のデータでは、ネストのエラーがプロパティ検証失敗の49%を占めています。典型的な例は以下の通りです。

Recipeの栄養情報：Recipeの直接のプロパティとしてではなく、NutritionInformationタイプの中にネストする必要があります。

// 誤り（ネストされていない）
“calories”: “350 kcal”

// 正解（NutritionInformationをネスト）
“nutrition”: {
“@type”: “NutritionInformation”,
“calories”: “350 kcal”,
“fatContent”: “12g”
}

Eventの場所情報：Placeタイプをネストし、その中に住所や地理座標などのサブプロパティを含める必要があります。

“location”: {
“@type”: “Place”,
“name”: “会議センター”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “San Francisco”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7749”,
“longitude”: “-122.4194”
}
}

検証方法：Schema.org検証ツールの「Nested Entities」タブを使用して、ネストの階層が仕様に合致しているか（例：NutritionInformationがRecipeの直接の子タイプになっているか）確認します。

GoogleとSchema.orgによるダブルチェック

Google構造化データテストツール：「リッチリザルトとの互換性」を重視し、「このマークアップではリッチリザルトを生成できません」といった具体的な理由（例：「offersフィールドが不足しています」）を提示します。Schema.org検証ツール：「意味論的な仕様への準拠」を重視し、プロパティの値が仕様に合致しているか（例：priceCurrencyがISO 4217通貨コードか）をチェックします。

テストツールの限界

Googleのテストツールは、キャッシュの仕組み（48%に古いデータが残る）や、リアルタイムテストのカバー率（動的コンテンツの35%-50%のみ）に制限があります。データによると、テストツールだけに頼ると、実際の問題の22%を見落とす可能性があります。

キャッシュの仕組み

Google構造化データテストツールはデフォルトでページのマークアップをキャッシュします。そのため、テスト結果の48%に48時間前の古いデータが表示されることがあります（Search Consoleヘルプセンター、2023年）。

最近JSON-LDを修正したとしても、キャッシュをクリアしない限り、テスト結果には修正前のエラー状態が表示され続ける可能性があります。

事例：ある教育サイトがコース情報のCourseマークアップを更新した後も、テストツールは「descriptionフィールドが不足しています」と警告し続けました。キャッシュをクリアしたところ、結果は正常に戻りました。

対応策：

• テストのたびに、ツールの右上にある「キャッシュをクリア」（ゴミ箱アイコン）を手動でクリックし、履歴データの影響を避けます。
• 更新頻度の高いページ（ECの製品ページなど）では、テスト時にタイムスタンプパラメータ（例：?v=20240315）を付与して、ツールに最新バージョンを強制的に取得させます。

リアルタイムテスト

「公開URLのテスト」機能は、GooglebotのクロールをシミュレートしてページのJavaScriptを実行しますが、その能力には限界があります。動的に生成されたマークアップの35%-50%しかキャプチャできません（Googleエンジニアブログ、2024年）。

キャプチャできない原因には以下が含まれます。

• JSの実行遅延：マークアップが非同期リクエスト（fetchなど）で生成される場合、テストツールの待機時間が不足することがあります（デフォルトのタイムアウトは3秒）。
• フレームワークの互換性：ReactやVueなどのSPAフレームワークのハイドレーション（hydration）プロセスが完全にシミュレートされず、マークアップがDOMに挿入されないことがあります。

あるニュースサイトでは、Reactを使用してArticleマークアップを生成していましたが、リアルタイムテストでは「リッチリザルトなし」と判定されました。しかし実際にはレンダリング後にマークアップが存在していました。これはJSの実行に4.2秒かかり、ツールの待機時間を超えていたためです。

対応策：

• ページのJS実行時間を確認し（LighthouseやChrome DevToolsのPerformanceタブを使用）、マークアップが3秒以内に読み込まれるようにします。
• SPAサイトの場合は、window.__INITIAL_STATE__などのプリレンダリング技術を使用するか、テストツール内でJSの実行を手動でトリガー（ページのインタラクションボタンをクリックするなど）します。

カバレッジレポート

テストツールの「カバレッジ」レポート（結果ページの下部）にはGoogleのページ解釈が表示されますが、あくまで表面的な結論（例：「条件を満たすマークアップが見つかりません」）のみで、具体的なエラーの詳細は説明されません。

よくある曖昧なヒントとその意味：

事例：あるレシピサイトのテストで「一部のマークアップが無視されました」と表示されましたが、Schema検証ツールで調べたところ、RecipeのnutritionフィールドがNutritionInformationタイプに正しくネストされていないことが判明しました。修正後、レポートは「すべてのマークアップが有効」に更新されました。

サードパーティツールの補完

Googleのテストツールだけに依存すると、実際の問題の22%を見落とす可能性があります（HTTP Archive, 2023）。他のツールと組み合わせたクロスバリデーションが必要です：

• Schema.org 検証ツール：語彙の規範性をチェックします（例：priceCurrencyがISO 4217コードに準拠しているか）。ある越境ECサイトでは、priceCurrencyに「USD」ではなく「US」を誤用していました。Googleのテストツールではエラーになりませんでしたが、Schema検証ツールがこの問題を検出し、修正後にリッチリザルトの表示率が19%向上しました。
• curlコマンドによるテスト：curl -H "User-Agent: Googlebot" URLを使用してGooglebotのクロールをシミュレートし、元のHTML内のマークアップが正しく出力されているか確認します（特にサーバーサイドレンダリングページに有効です）。

ページのアクセシビリティとクロール

ページのアクセシビリティは、リッチメディアリザルト生成の「土台」です。Googlebotがページをクロールまたはアクセスできない場合、マークアップも認識されません。

Googleの2023年「検索品質評価ガイドライン」では、リッチリザルトのプレビュー失敗の60%がページのアクセシビリティ問題と強く関連していると明記されています。

公開アクセシビリティ

ページはGooglebotに対して完全に公開されている必要があり、ログインウォール、会員限定、または地域ブロックがあってはなりません。

データによると、プレビュー失敗の15%はページが特定のユーザーにのみ開放されていることに起因しています（Search Console ヘルプセンター, 2024）。

シナリオ：

• ある会員制グルメサイトがRecipe詳細ページを「登録後に閲覧可能」に設定したため、GooglebotがrecipeIngredientなどの必須フィールドをクロールできず、テストツールでは常に「結果なし」と表示されました。ログイン制限を解除した後、3日以内にリッチリザルトの表示率は0%から8%に回復しました。
• ある越境コスメブランドが東南アジアのユーザーに対して価格情報を非表示にしていたため、Productマークアップ内のoffersフィールド（価格を含む）がクロールできなくなっていました。修正後、東南アジア地域でのリッチリザルトのクリック数は25%増加しました。

検証方法：

• Chromeのシークレットモード（Cookieとログイン状態を無効化）でページにアクセスし、コンテンツが完全に表示されるか確認します。
• AccessiBeを使用して異なる地域のIPをシミュレートし、地域限定の制限（例：「米国ユーザーのみ閲覧可能」）がないかチェックします。

ページ読み込み速度

HTTP Archiveの2023年のレポートによると、読み込み時間が5秒を超えるページでは、クローラーの22%がクロールを早期に終了します。

具体的な影響：

• Productマークアップが製品ページの下部にある場合、読み込みタイムアウトによりGooglebotがその部分を直接見落とすことになります。
• 非同期で読み込まれるArticleマークアップ（AJAXで生成された著者情報など）も、時間がかかりすぎると同様に無視されます。

検証：

• PageSpeed Insightsを使用してモバイル/デスクトップの「LCP（最大コンテンツの描画）」指標をテストします。2.5秒以内（Googleのパフォーマンス要件）に抑える必要があります。
• 最適化アクション：
  • 画像を圧縮：WebP形式をJPG/PNGの代わりに使用することで、ファイルサイズを50%削減できます（例：1MBのJPGをWebPに変換すると400KB程度になります）。
  • 非重要リソースの遅延読み込み：下部広告、サイドバーのコメントなどを「可視領域までスクロールしてから読み込む」ように設定します。
  • Gzip圧縮を有効化：サーバー設定（Nginxのgzip on;など）を通じてHTML/CSSのファイルサイズを削減します。

事例：ある電子製品ECページでは初期読み込み時間が6.2秒、LCPが3.8秒でした。最適化後、読み込み時間は3.5秒に短縮され、LCPは2秒未満となりました。これによりGooglebotのクロール成功率は75%から92%に向上し、Productのリッチリザルト表示率は19%増加しました。

HTTPS暗号化

構造化データに関連するすべてのURL（画像、詳細ページリンク、offers.url）はHTTPSを使用する必要があります。

Googleは、非HTTPSリソースは「安全でない」と判定される可能性があり、プレビュー失敗の18%を招くと明記しています（Google 開発者ドキュメント, 2023）。

よくある間違い：

• 画像リンクにHTTPを使用（例：http://example.com/headphones.jpg）。これによりProductのimageフィールドが無効になります。
• Articleのurl属性がHTTP版（例：http://blog.example.com/post-123）を指しており、Googleに無視される。

検証：

• すべてのマークアップ内のURLを手動でチェックし、「https://」で始まっていることを確認します。
• SSL LabsでウェブサイトのSSL証明書をテストします。期限切れや設定ミス（TLS 1.2以上が未有効など）がないことを確認します。

修正：あるファッションサイトですべてのHTTP画像リンクを修正した後、Productのリッチリザルト表示率は12%から30%に向上し、Search Consoleの「マークアップリソースが無効」というエラー表示が完全に消えました。

よくあるエラータイプの修正

よくあるエラーの修正は、主に以下の4つのカテゴリーに焦点を当てる必要があります：

• JSON-LD構文エラー（38%を占める）
• 必須プロパティの欠落（29%）
• ネストの不備（22%）
• 動的コンテンツの未捕捉（11%）

データによると、これらを一つずつ修正することで、リッチリザルトのプレビュー成功率は45%から82%まで向上します（Google 2024 事例）。

JSON-LD構文エラー

JSON-LD構文エラーは構造化データ問題の38%を占め、主な原因はカッコの不一致（42%）、冗長なカンマ（31%）、データ型の誤り（27%）です。修正により、マークアップ認識率は95%以上に向上します（Google 2024 データ）。

Googleの2024年「構造化データエラーレポート」によると、リッチリザルトのプレビュー失敗の38%がJSON-LD構文エラーに起因しています。

カッコと引用符の不一致

カッコ（{}）や引用符（""）の不一致は、最も一般的な構文問題であり、全JSON-LDエラーの42%を占めます（Schema.org 2023 検証データ）。

この種のエラーは通常、コーディング時の不注意、例えば閉じ記号の忘れや引用符のペアが揃っていないことから発生します。

具体的事例：あるオンライン教育プラットフォームのCourseマークアップで、閉じ中カッコの書き忘れにより、Googleテストツールで「無効なJSON」と表示されました：

{
“@context”: “https://schema.org”,
“@type”: “Course”,
“name”: “デジタルマーケティング基礎”,
“description”: “SEOとSEMスキルの学習” // 最後の “}” が抜けている

修正方法：

• コードエディタの「シンボルマッチング」機能（VS CodeのBracket Pair Colorizerプラグインなど）を使用します。色の異なるカッコにより、閉じられていない箇所が視覚的にわかります。
• オンラインツール（JSONLintなど）にJSONコードを貼り付けます。ツールがエラー箇所を直接指摘します（例：「Expected ‘}’, got ‘EOF’」）。

修正効果：このプラットフォームでの修正後、Courseマークアップが正常に解析され、リッチリザルトの表示率は0%から7%に回復し、Search Consoleの「無効な構造化データ」エラーが消えました。

冗長なカンマ

冗長なカンマとは、オブジェクト（{}）や配列（[]）の最後のプロパティの後に余分なカンマが付いていることを指し、構文エラーの31%を占めます（Google 開発者ドキュメント, 2024）。

典型的なシーン：あるECサイトのOfferマークアップで、priceフィールドの後に不要なカンマが付いていました：

“offers”: {
“@type”: “Offer”,
“price”: “99.99”, // 末尾のカンマが冗長
“priceCurrency”: “USD”
}

パーサーがこのカンマに遭遇すると、後に続くプロパティがあると思い込みますが、実際にはないため、offersオブジェクト全体が無効と判定されます。

修正方法：

• JSONLintなどのツールを使用してコードを自動フォーマットします。ツールが冗長なカンマを削除します。
• 手動チェック：オブジェクトや配列の最後のプロパティの後に絶対にカンマを置いてはいけません（JSON仕様の厳格な要件）。

あるアパレルECでは、冗長なカンマが原因で製品マークアップの30%が無効になっていましたが、修正後に有効マークアップ率が95%に向上し、Productリッチリザルトの表示回数が22%増加しました。

“`

データ型の誤り

JSON-LDでは、属性値がSchema.orgで定義されたデータ型と厳密に一致している必要があります。この種のエラーは構文エラーの27%を占めています（Schema.org 2023）。

よくある誤りには以下が含まれます：

• 日付形式の誤り：ISO 8601標準を使用していない（"2023/10/05"や"October 5, 2023"ではなく、"2023-10-05T08:00:00+08:00"とすべきです）。
• 数値型の誤り：価格や評価などの属性に、文字列ではなく数値を使用している（例："price": 99.99は"price": "99.99"に、"ratingValue": 4.5は文字列形式に保つ必要があります）。

事例紹介：あるグルメブログのArticleマークアップにおいて、datePublishedには"2023-10-05"（正解）を使用していましたが、reviewRating.ratingValueを文字列の"4.5"ではなく数値の4.5と誤記していました。

Googleのテストツールは「無効な評価値」と警告し、その結果、強調スニペットが生成されませんでした。

修正後、評価値を文字列に変更したところ、強調スニペットの表示率は10%から28%に向上しました。

検証の根拠：Schema.orgでは、ratingValueは「Text」型（文字列）であると明確に規定されています。内容が数字であっても引用符で囲む必要があり、これは多くの開発者が見落としやすい詳細です。

必須プロパティの欠落

必須プロパティの欠落は、構造化データエラーの29%を占めています。マークアップのタイプによって欠落率は異なり（Productのoffers不足は38%、ArticleのdatePublished不足は29%）、Schemaの仕様に従ってフィールドを補完することで、80%以上のケースでリッチリザルトの表示が回復します（Google 2024 事例）。

Product

ProductはECサイトで最も頻繁に提供されるマークアップであり、必須プロパティはname、image、offersです（Schema.org定義）。

特にoffers（商品のオファー情報）は核心部分であり、price（価格）、priceCurrency（通貨）、availability（在庫状況）などのサブプロパティを含む必要があります。この欠落率は38%に達します（Google Search Console 2023 データ）。

欠落の影響：あるアパレルECでProductマークアップにoffersが長期的に欠落していた結果、以下の問題が発生しました：

• テストツールで「リッチリザルトなし」と表示される。
• 検索結果にタイトルと説明文のみが表示され、価格や購入ボタンが表示されない。
• クリック率が、完全な商品カードを表示している競合他社より40%低くなる。

修正アクション：offersフィールドを追加し、価格と在庫を明記しました：

“offers”: {
“@type”: “Offer”,
“price”: “89.99”,
“priceCurrency”: “USD”,
“availability”: “https://schema.org/InStock”
} これにより、3日以内にリッチリザルトの表示率は0%から15%に回復し、検索クリック率は22%、コンバージョン数は18%増加しました。

Article

Article（記事/ブログ）の必須プロパティは、headline（見出し）、datePublished（公開日）、author（著者）です。

中でもdatePublishedはGoogleがコンテンツの「フレッシュさ」を判断する鍵であり、その欠落率は29%です（Google 2024 コンテンツエコシステムレポート）。

欠落の影響：あるテックブログでArticleマークアップにdatePublishedが含まれていなかった結果、以下の問題が発生しました：

• 「強調スニペット」（Featured Snippet）がトリガーされない。
• 検索結果において、同時期に公開された競合記事（公開日が表示されている）よりも順位が下がる。
• 日付のないコンテンツは「古い」と見なされ、ユーザーの信頼度が低下する。

修正アクション：ISO 8601形式の公開日を追加しました：

“datePublished”: “2024-03-15T10:00:00+08:00” これにより、強調スニペットの表示率は10%から35%に向上し、記事のクリック率は25%増加しました。また、検索順位で上位3位に入る確率が19%上昇しました。

LocalBusiness

LocalBusiness（ローカルビジネス）の必須プロパティは、name、address、telephoneです。中でもaddress（詳細な住所）は、Googleがマップカードと関連付けるための核心要素であり、欠落率は35%です（Google My Business 2023 データ）。

欠落の影響：あるカフェのLocalBusinessマークアップで住所が不完全（市名のみ）だった結果、以下の問題が発生しました：

• 検索結果にマップカードが表示されない。
• ユーザーが店まで直接ナビゲーションできない。
• ローカル検索からのトラフィックが、周辺の競合店より50%低くなる。

修正アクション：PostalAddress型で詳細な住所を補完しました：

“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Main St”,
“addressLocality”: “Seattle”,
“addressRegion”: “WA”,
“postalCode”: “98101”
} これにより、24時間以内にマップカードが表示され、ローカル検索トラフィックは40%、来店コンバージョン数は28%増加しました。

Recipe

Recipe（レシピ）の必須プロパティは、name、description、recipeIngredient（材料リスト）です。

中でもrecipeIngredientはレシピの「メインコンテンツ」であり、欠落率は41%に上ります（AllRecipes 2024 ユーザー調査）。

欠落の影響：あるグルメサイトでRecipeマークアップに材料が列挙されていなかった結果、以下の問題が発生しました：

• 材料リストや手順が表示されない。
• ユーザーがそのレシピが自分のニーズに合っているか判断できない。
• お気に入り登録数が競合サイトより60%低くなる。

修正アクション：構造化された材料リストを追加しました：

“recipeIngredient”: [
“小麦粉 200g”,
“卵 2個”,
“牛乳 150ml”,
“砂糖 50g”
] これにより、材料リストと手順の表示率は8%から25%に向上し、お気に入り登録数は32%増加、さらにGoogleの「人気レシピ」に選ばれる確率が21%上昇しました。

タイプネストの不備

構造化データの「タイプネスト」はSchema.orgの論理構造です。親タイプが子タイプを包含することで意味的な関連付けを伝えます。例えば、Recipe（レシピ）はnutritionフィールドを通じてNutritionInformation（栄養情報）子タイプをネストすることで、Googleに「このカロリーはこの料理のものだ」と理解させることができます。

ネストエラーの本質

Schema.orgのタイプ体系は「ツリー状の階層構造」です。親タイプがコア属性を定義し、子タイプが具体的な詳細を拡張します。

例：

• Recipe（親タイプ）は「料理のレシピ内容」であり、nutritionフィールドを通じてNutritionInformation（子タイプ）を関連付け、「カロリーや脂肪分」などの詳細を伝えます。
• Event（親タイプ）は「イベント情報」であり、locationフィールドを通じてPlace（子タイプ）を関連付け、「住所や座標」などの位置情報を伝えます。

エラーの影響：子タイプをスキップして属性を直接親タイプの下に置くと、Googleは「属性の帰属が不明」と判断し、その部分を無視します。

例えば、あるグルメサイトのRecipeマークアップで、NutritionInformationをネストせずに直接"calories": "350 kcal"と記述した場合、Googleのテストツールは「カロリーフィールドを認識できません」と警告し、リッチリザルトに栄養成分が表示されません。

よくある4つのネストエラー

（1）Recipe：栄養情報がNutritionInformationにネストされていない

誤ったシナリオ：あるグルメブログで、カロリーや脂肪を直接親タイプの下に記述していました：

{
“@type”: “Recipe”,
“name”: “トマト卵炒め”,
“nutrition”: { // 誤り：nutritionは親の属性であり、子タイプをネストする必要があります
“calories”: “350 kcal”,
“fatContent”: “12g”
}
}
問題点：Googleはnutrition下の属性が「栄養情報」に属することを認識できず、リッチリザルトに表示されません。

修正アクション：栄養情報をNutritionInformation子タイプの中にネストしました：

{
“@type”: “Recipe”,
“name”: “トマト卵炒め”,
“nutrition”: {
“@type”: “NutritionInformation”, // 子タイプを追加
“calories”: “350 kcal”,
“fatContent”: “12g”
}
} 効果：そのブログのレシピリッチリザルトにおいて、栄養成分の表示率は8%から25%に向上し、ユーザーのお気に入り登録数は32%増加しました（AllRecipes 2024 データ）。

（2）Event：場所情報がPlaceおよびPostalAddressにネストされていない

誤ったシナリオ：ある会議サイトのEventマークアップで、住所を階層化せず文字列として直接記述していました：

{
“@type”: “Event”,
“name”: “デジタルマーケティングサミット”,
“location”: “サンフランシスコ・コンベンションセンター” // 誤り：locationはPlaceとPostalAddressのネストが必要です
}
問題点：Googleは住所の構造化情報を解析できず、マップカードが表示されません。

修正アクション：Place（場所）とPostalAddress（住所）の子タイプをネストしました：

{
“@type”: “Event”,
“name”: “デジタルマーケティングサミット”,
“location”: {
“@type”: “Place”,
“name”: “サンフランシスコ・コンベンションセンター”,
“address”: {
“@type”: “PostalAddress”,
“streetAddress”: “123 Mission St”,
“addressLocality”: “San Francisco”,
“addressRegion”: “CA”,
“postalCode”: “94105”
},
“geo”: {
“@type”: “GeoCoordinates”,
“latitude”: “37.7890”,
“longitude”: “-122.4030”
}
}
} 効果：修正後、検索結果にマップカードが表示されるようになり、イベントのクリック率は40%、申し込み数は28%増加しました（Google Events 2023 データ）。

（3）Product：評価情報がReviewまたはAggregateRatingにネストされていない

誤ったシナリオ：あるECプラットフォームで、評価スコアを直接Productに記述し、AggregateRating（総合評価）タイプをネストしていませんでした：

{
“@type”: “Product”,
“name”: “ワイヤレスイヤホン”,
“reviewScore”: “4.5” // 誤り：reviewScoreはAggregateRating下にネストすべきです
} 問題点：Googleは「4.5」が商品の総合評価であることを認識できず、星評価が表示されません。

修正アクション：AggregateRating子タイプをネストしました：

{
“@type”: “Product”,
“name”: “ワイヤレスイヤホン”,
“aggregateRating”: {
“@type”: “AggregateRating”,
“ratingValue”: “4.5”,
“reviewCount”: “120”
}
} 効果：商品リッチリザルトの星評価表示率が15%から50%に向上し、コンバージョン数は19%増加しました（Shopify 2024 データ）。

（4）Article：著者情報がPersonにネストされていない

誤ったシナリオ：あるテックブログのArticleマークアップで、著者の名前を直接記述し、Person（個人）タイプをネストしていませんでした：

{
“@type”: “Article”,
“name”: “2024年SEOトレンド”,
“author”: “張三” // 誤り：authorはPerson子タイプのネストが必要です
} 問題点：Googleは著者の属性情報を認識できず、「著者」ラベルが表示されません。

修正アクション：Person子タイプをネストしました：

{
“@type”: “Article”,
“name”: “2024年SEOトレンド”,
“author”: {
“@type”: “Person”,
“name”: “張三”,
“url”: “https://example.com/author/zhangsan”
}
} 効果：記事の「著者」ラベル表示率が20%から60%に向上し、ユーザーの信頼度が25%上昇しました（Google Authorship 2023 データ）。

動的コンテンツの未捕捉

動的コンテンツとは、JavaScript（JS）、AJAX、またはシングルページアプリケーション（SPA）フレームワークを通じてリアルタイムで生成されるコンテンツを指します。例えば、React/Vueで構築されたページ、無限スクロールの記事リスト、ボタンクリック後に読み込まれるレシピの手順などです。

これらのマークアップ（Product価格、Articleコメントなど）は初期HTMLには存在せず、クライアントサイドのJSによって動的に挿入されます。

しかし、Googlebotの仕組みは「まず初期HTMLを取得し、その後にJSを実行する」というものです。JSの実行が遅すぎたり、コンテンツがクライアントサイドレンダリングに依存しすぎていると、リッチリザルトが生成されません。

Googleエンジニアブログ（2024）によると、動的ページの40%はプリレンダリングが行われていないため、マークアップがクローラーに読み取られていません。

動的コンテンツがクロールされない理由

Googlebotのクロールプロセスは2段階に分かれています：

1. 初期HTMLのダウンロード：ページの基礎構造（JS生成分を除く）を取得します。
2. JSの実行：ブラウザでの動作をシミュレートしてJSを実行し、動的コンテンツを取得します（JSの完了を待機する必要があります）。

しかし、クローラーの「忍耐」には限界があります：

• JSの実行時間が3秒を超えると、Googlebotは早期に終了する可能性があり、動的マークアップが読み取られません（Lighthouse 2023 データ）。
• コンテンツが「ユーザー操作」（「もっと読み込む」をクリックするなど）に依存している場合、クローラーはその部分をスキップします。

事例：あるニュースサイトがReactでSPAを構築しており、記事のコメント欄がJSで動的に読み込まれていました。

テストツールでは「リッチリザルトなし」と表示されました。実際にはコメントのマークアップは存在していましたが、Googlebotのクロール時にJSの実行が完了しておらず、初期HTMLにコメントが含まれていなかったためです。

3つの頻出する問題

（1）SPA（シングルページアプリケーション）：初期HTMLが空でマークアップが含まれない

SPAは「1つのページでコンテンツを動的に差し替える」仕組みであり、初期HTMLは通常 <div id="root"></div> のように空で、すべての内容はJSによって注入されます。

プリレンダリングが行われていないと、Googlebotが取得する初期HTMLには構造化データが含まれず、当然マークアップは認識されません。データ：ある旅行サイトのTourマークアップはReactで生成され、初期HTMLは空でした。

Search Consoleで「条件を満たすマークアップが見つかりません」と表示され、表示率は0%でした。サーバーサイドレンダリング（SSR）に修正し、初期HTMLに直接マークアップを含めたところ、表示率は0%から28%に上昇しました。

（2）AJAX読み込み：コンテンツを非同期で取得し、クローラーが完了を待たない

AJAXはコンテンツ（無限スクロールの商品リストやコメントなど）を動的に読み込むために使われますが、クローラーはAJAXリクエストの完了を待ちません。読み込み時間が「タイムアウトの閾値」（約3秒）を超えると、マークアップは見落とされます。

事例：あるECプラットフォームの「おすすめ商品」リストをAJAXで読み込んでおり、ProductマークアップをJSで生成していました。

テストツールでは「一部のマークアップが無視されました」と表示されました。これはGooglebotのクロール時にAJAXリクエストが完了せず、商品情報が含まれなかったためです。

プリレンダリングツール（Prerender.ioなど）を使用して、完全な商品リストを含むHTMLを生成するようにしたところ、マークアップ認識率は60%から95%に向上しました。

（3）遅延読み込み：コンテンツの表示がトリガー式で、待機時間を超える

遅延読み込み（Lazy Load）はページ速度の最適化（可視領域に入ってからHowToの手順や材料リストを読み込むなど）に使われます。しかし、遅延時間が長すぎる（例：2秒以上）と、クローラーはその内容を逃す可能性があります。

データ：あるインテリアサイトでHowToマークアップ（「本棚の組み立て方」など）を2秒遅延させて読み込んでいました。

Googleテストツールは「手順フィールドを認識できません」と警告しました。クローラーが読み込み完了を待たなかったためです。

遅延時間を1秒以内に短縮したところ、手順の表示率は18%から43%に向上しました。

3つの修正方法

（1）プリレンダリング：サーバー側で完全なHTMLを生成しクローラーに渡す

プリレンダリングとは、サーバー側でJSを実行して動的コンテンツを含む完全なHTMLを作成し、それをクローラーに送信することです。

Prerender.ioやNginxのプリレンダリングモジュールなどは、クローラーのリクエストを自動的に識別してプリレンダリング済みHTMLを返します。

効果：あるECのSPAでプリレンダリングを導入したところ、Productマークアップのクロール成功率は75%から92%に、表示率は5%から28%に上昇しました。

（2）サーバーサイドレンダリング（SSR）：フレームワークで直接JSコンテンツを描画する

SSRは、Next.js (React) や Nuxt.js (Vue) などのフレームワークを使い、サーバー側でJSコンポーネントをHTML文字列としてレンダリングしてからクライアントに送信する手法です。

これにより初期HTMLに完全なマークアップが含まれるため、クローラーはJSの実行を待つ必要がありません。

事例：あるニュースサイトをNext.jsで再構築し、コメント欄をSSRで生成するようにしました。

Googlebotはクロール時に直接コメントのCommentマークアップを取得でき、強調スニペットの表示率は10%から50%に、コメントのインタラクション数は35%増加しました。

（3）JS実行時間の最適化：マークアップを3秒以内に読み込む

プリレンダリングやSSRが導入できない場合は、JSの実行時間を最適化し、動的マークアップが3秒以内に読み込まれるようにする必要があります。

LighthouseやChrome DevToolsのPerformanceタブで読み込み時間を確認します：

• JSファイルの圧縮：WebpackやRollupでコードを圧縮し、ファイルサイズを削減します。
• 非クリティカルなJSの遅延：マークアップに影響しないスクリプト（広告や計測など）を async または defer に設定します。
• リソースのキャッシュ：CDNでJSファイルをキャッシュし、読み込み時間を短縮します。

データ：あるメディアサイトでJS実行時間を4.2秒から2.5秒に短縮したところ、Googlebotのクロール成功率は68%から90%に向上し、Articleのリッチリザルト表示率は22%上昇しました。

最後に：正解となる一行のJSON、仕様に沿ったネスト、適切なプリレンダリング。その一つひとつが、リッチリザルトを「なし」から「あり」へと変える力になります。