JavaScriptページがインデックスされない：Googleに対するSPAとフレームワークのレンダリングを修正
JavaScriptアプリケーションはブラウザでは完璧に見えますが、Googleは空のページを認識しています。Googleの2波インデックスプロセスがJavaScriptコンテンツをどのように処理するか、何を変更する必要があるかを正確に理解しましょう。
このガイドの内容
React、Vue、Angular、Next.js、その他のJavaScriptフレームワークは数百万のウェブサイトを支えていますが、クライアントサイドレンダリングとGoogleのページのインデックス方法の間には根本的な緊張関係があります。
Googleはページを2つの波で処理します。第1波は生のHTMLを即座に解析します。数時間または数日後に発生する可能性のある第2波はJavaScriptをレンダリングします。HTMLがスクリプトタグを持つ空のdivである場合、Googleの第1波はコンテンツを認識しません。レンダリングキューは数日かかる可能性があり、APIタイムアウトやJSエラーからの失敗は永続的な薄いコンテンツの分類につながる可能性があります。
本ガイドでは、レンダリングベースのインデックス失敗の診断と、すべての主要フレームワーク向けの実用的な解決策をカバーします。
Googleの2波インデックスが実際にどのように機能するか
Googleのレンダリングパイプラインを理解することは、JavaScriptインデックス問題の診断と修正に不可欠です。プロセスは異なる段階で機能し、どの段階の問題もコンテンツがインデックスされるのを妨げる可能性があります。
最初の段階では、googlebotがURLに対してHTTPリクエストを送信し、HTMLレスポンスを受信します。これは、ブラウザでページのソースを表示（Ctrl+U）した場合に見えるものと同じです。googlebotはこのHTMLを解析して、テキストコンテンツ、リンク、metaタグ、canonicalタグ、構造化データを抽出します。この初期HTMLレスポンスに存在するコンテンツは、すぐにインデックスに利用可能です。この段階は高速で、通常のクロールプロセス中に発生します。
2番目の段階では、URLがレンダリングキューに置かれます。Googleはヘッドレス Chromium ブラウザを使用してJavaScriptを実行し、最終的なレンダリングされたDOMを生成するWeb Rendering Service（WRS）を運営しています。WRSはページを読み込み、すべてのスクリプトを実行し、動的コンテンツが読み込まれるのを待ち、最終的なページ状態をキャプチャします。このレンダリングされたDOMは初期HTMLと比較されます。レンダリングされたDOMで発見された新しいコンテンツはGoogleのインデックスに追加されます。
重要な洞察は、レンダリングキューがリアルタイムではないということです。Googleは、JavaScriptの実行がリソース集約的であるため、レンダリングキューに大幅な遅延が発生する可能性があることを認めています。Googleは長年にわたってレンダリング速度を大幅に向上させてきましたが、キューはまだ数時間から数日の遅延を導入する可能性があります。特に、権威の低いドメインや、Googleが頻繁なクロールを優先しないサイトのページではそうです。
第1波と第2波の間の待機期間中、ページは初期HTMLコンテンツのみに基づいて評価される場合があります。その初期HTMLにrootのdiv、ロードアニメーション、JavaScriptバンドル参照しかない場合、Googleはページに意味のあるコンテンツがないと評価します。この評価により、第2波が処理する機会を持つ前に、ページがレンダリングの優先度が低くなったり、薄いコンテンツとして分類されたりする可能性があります。
レンダリングキューは失敗も発生しやすいです。レンダリング中にJavaScriptがエラーをスローした場合、API呼び出しがタイムアウトした場合、ページに認証が必要な場合、またはサードパーティスクリプトが実行をブロックした場合、WRSは不完全または空のレンダリングを生成する可能性があります。Googleは失敗したレンダリングをすぐに再試行しません。これは、レンダリング中の一時的なエラーが長期間にわたってインデックスを妨げる可能性があることを意味します。
GoogleのWRSは、ES6+、async/await、fetch、Web Components、ほとんどの最新のJavaScript APIをサポートする最新バージョンのChromiumを実行します。ただし、すべてのブラウザAPIをサポートしているわけではありません。特に、意味のある方法でlocalStorage、sessionStorage、IndexedDBにアクセスできません。ユーザーインタラクションイベント（スクロール、クリック、ホバー）をサポートしていません。これは、スクロールイベント、クリック展開要素、またはホバートリガーポップアップによって読み込まれるコンテンツがGoogleには見えないことを意味します。WRSにはJavaScript実行のタイムアウトもあります。ページが重要なコンテンツをレンダリングするのに約5秒以上かかる場合、WRSは不完全な状態をキャプチャする可能性があります。
クライアントサイドレンダリング vs SSR vs SSG：インデックスへの影響
JavaScriptアプリケーションに選択するレンダリング戦略は、インデックスの結果に直接的かつ測定可能な影響を与えます。クライアントサイドレンダリング（CSR）、サーバーサイドレンダリング（SSR）、静的サイト生成（SSG）の間のトレードオフを理解することは、情報に基づいたアーキテクチャ上の決定を行うために不可欠です。
クライアントサイドレンダリングは、Create React App、Vue CLI、またはAngular CLIで構築されたシングルページアプリケーションのデフォルトです。サーバーはルート要素とスクリプトタグを含む最小限のHTMLドキュメントを送信します。すべてのコンテンツレンダリングは、JavaScriptが読み込まれて実行された後にブラウザで発生します。Googleの視点から、CSRページはレンダリングキューが処理するまで空であり、上記の遅延と失敗リスクを生み出します。CSRはSEOとインデックスにとって最もリスクの高いレンダリング戦略です。
サーバーサイドレンダリングは、すべてのリクエストに対してサーバー上で完全なHTMLを生成します。googlebotがページをリクエストすると、サーバーはJavaScriptフレームワークを実行し、完全なHTMLを生成し、レスポンスで送信します。Googleの第1波は、レンダリングキューを待つ必要なく、すべてのコンテンツをすぐに認識します。HTMLが実際のユーザーのブラウザに読み込まれた後、JavaScriptはページをハイドレートしてインタラクティブにします。SSRは両方の世界の最良を提供します。Googleへの即時のコンテンツの可用性と、ユーザーへの完全なインタラクティブ性です。Next.js、Nuxt、SvelteKitのようなフレームワークは、SSR機能を組み込みで提供します。
静的サイト生成は、各リクエスト時ではなく、ビルド時にページを事前レンダリングします。結果は、CDNから直接提供される静的HTMLファイルのコレクションです。Googleは完全なHTMLを即座に受け取り、サーバーサイドレンダリングの遅延や失敗はありません。SSGは、リクエストごとに変更されないコンテンツに理想的です。ブログ投稿、ドキュメント、マーケティングページ、リアルタイムではなく定期的に更新される商品カタログです。制限は、SSGがコンテンツを更新するために再構築を必要とすることであり、これがダッシュボード、検索結果、リアルタイム在庫表示のような非常に動的なページには非実用的にします。
Next.jsや類似のフレームワークで利用可能なIncremental Static Regeneration（ISR）は、SSGと定期的な再レンダリングを組み合わせます。ページはビルド時に事前レンダリングされますが、定義された間隔またはコンテンツが変更されたときにオンデマンドで再生成できます。これにより、SSGのインデックス信頼性とSSRのコンテンツの新鮮さが提供されます。定期的に変更される数千の商品ページを持つEコマースサイトの場合、ISRは多くの場合最適な選択です。
実用的な推奨事項は明確です。Googleにインデックスさせたいページに対して、純粋なクライアントサイドレンダリングを避けてください。リクエストごとに変更される動的ページにはSSRを使用し、定期的に変更されるコンテンツにはSSGまたはISRを使用してください。短期的にCSRからSSRに移行することが実現不可能な場合、ブリッジソリューションとして動的レンダリングを実装してください。
JavaScriptレンダリング失敗の診断
JavaScriptレンダリングがインデックス問題を引き起こしているかどうかを特定するには、インデックスパイプラインの各段階でGoogleが正確に何を見ているかを示すツールでの体系的なテストが必要です。
主要な診断ツールは、Google Search ConsoleのURL検査機能です。インデックスされていないJavaScriptレンダリングされたページのURLを入力し、「公開URLをテスト」をクリックします。ツールはページのライブクロールとレンダリングを実行し、Googleの実際の処理パイプラインをシミュレートします。2つの出力を確認します。レンダリングされたページのスクリーンショット（JavaScript実行後にGoogleが見るものを示す）と、テストされたページの詳細（生のHTMLとリソース読み込みエラーを示す）です。スクリーンショットをブラウザで見えるものと比較します。スクリーンショットに不完全なコンテンツ、欠けているセクション、または空白のページが表示される場合、GoogleはJavaScriptを正しくレンダリングできていません。
2番目の診断ステップは、生のHTMLソースを調べることです。ブラウザでページURLを開き、Ctrl+Uを押してレンダリングされていないソースを表示します。これがGoogleが最初のインデックス波で見るものです。ソースに意味のあるコンテンツ（タイトル、見出し、テキスト段落、リンク）が表示されている場合、コンテンツはすぐに利用可能です。「root」や「app」のようなIDのdivとスクリプトタグのみが表示されている場合、コンテンツは完全にJavaScriptレンダリングに依存しています。
第三に、レンダリングを妨げる可能性のあるJavaScriptエラーを確認します。ブラウザの開発者ツールで、コンソールタブを開き、ページを再読み込みします。赤いエラーメッセージに注意してください。これらの同じエラーがGoogleのレンダリング環境で発生し、コンテンツの読み込みを妨げる可能性があります。一般的な犯人には、適切な認証ヘッダーなしのリクエストを拒否するサーバーへのAPI呼び出し（Googleのレンダラーはクッキーや認証トークンを送信しません）、サードパーティリソースのCORSエラー、ヘッドレスChromiumに存在しないブラウザ固有のAPIへの参照が含まれます。
第四に、レンダリング速度をテストします。GoogleのWRSにはJavaScript実行のタイムアウトがあります。ブラウザの開発者ツールで、パフォーマンスタブを開き、ページ読み込みを記録します。重要なコンテンツが初期HTMLの読み込み後に表示されるのに3〜5秒以上かかる場合、Googleはコンテンツがレンダリングされる前にタイムアウトする可能性があります。遅いAPIレスポンス、大きなJavaScriptバンドル、複雑なレンダリングロジックは、ページをレンダリングタイムアウトを超えて押し進める可能性があります。
第五に、インタラクションゲートの後ろにあるコンテンツを確認します。一部のJavaScriptアプリケーションは、ユーザーインタラクションに応じてのみコンテンツを読み込みます。「もっと読み込む」ボタンをクリック、しきい値を超えてスクロール、またはタブを選択することです。Googleのレンダラーはこれらのインタラクションを実行しません。インタラクション要件の後ろに隠されたコンテンツはGoogleには決して見えません。インデックスさせたいすべてのコンテンツが、ユーザーインタラクションを必要とせずに初期ページレンダリングで表示されることを確認してください。
一般的なインデックスブロッカーに対するフレームワーク固有の修正
各JavaScriptフレームワークには、インデックス問題を引き起こす独自の一般的なパターンセットがあります。フレームワーク固有の落とし穴と修正を知ることで、デバッグの数時間を節約できます。
Create React App（CRA）で構築されたReactアプリケーションでは、アプリケーション全体がデフォルトでクライアントサイドレンダリングされます。組み込みのSSR機能はありません。推奨される移行パスは、同じReactコンポーネントモデルを使用しながら、SSRとSSGをすぐに使えるNext.jsに移行することです。Next.jsへの移行が実現不可能な場合は、Googleのクローラー用に静的HTMLスナップショットを生成する事前レンダリングサービスを使用して動的レンダリングを実装してください。
Next.jsアプリケーションの場合、ほとんどのインデックス問題は、サーバーサイドのデータ取得（getServerSidePropsまたはgetStaticProps、または新しいApp Routerのサーバーコンポーネント）の代わりに、クライアントサイドのデータ取得（useEffect + fetch）のみを使用するページに起因します。ページのコンテンツがuseEffectフック内で読み込まれる場合、サーバーレンダリングされたHTMLには表示されません。データ取得をサーバー層に移動します。App Routerでは、デフォルトでサーバーコンポーネントを使用し、本当にインタラクティブ性が必要なコンポーネントにのみ「use client」を追加します。Pages Routerでは、動的データにgetServerSideProps、静的データにgetStaticPropsを使用します。
Nuxtを使用するVueアプリケーションの場合、同様の原則が適用されます。クライアントサイドのみのfetch呼び出しではなく、サーバーコンテキストでasyncDataまたはuseFetchを使用します。NuxtのデフォルトSSRモードはサーバー上でコンテンツをレンダリングしますが、クライアント側でのみ実行されるプラグインやコンポーネントは、レンダリングされた出力に穴を作る可能性があります。クライアント側のみのコンテンツには明示的にClientOnlyラッパーコンポーネントを使用し、重要なインデックス可能なコンテンツの周囲に使用されていないことを確認します。
Angularアプリケーションの場合、Angular Universalがサーバーサイドレンダリングを提供します。Angular Universalを実装し、メインコンテンツコンポーネントがサーバー上でレンダリングされることを確認します。window、document、navigatorのようなブラウザ固有のオブジェクトを直接参照するコンポーネントに注意してください。これらはサーバーサイドレンダリング中にエラーをスローし、ページが完全にレンダリングされないようにする可能性があります。
すべてのフレームワークについて、遅延読み込みとコード分割に特別な注意を払ってください。オンデマンドでコンポーネントを読み込む動的インポート（React.lazy、VueとAngularの動的インポート）は、コンテンツが初期サーバーレンダリングに存在するのを妨げる可能性があります。重要なファーストビューコンテンツは決して遅延読み込みしないでください。主要なコンテンツコンポーネントをメインバンドルに移動して、初期HTMLレスポンスでレンダリングされるようにします。
Web Componentsには独自の課題があります。Googleは標準のWeb Componentsをレンダリングできますが、複雑なShadow DOM構造と深くネストされたカスタム要素はWRSで確実にレンダリングされない可能性があります。URL検査ツールを使用してWeb Componentsのレンダリングを明示的にテストし、より良いインデックス信頼性のために重要なコンテンツをShadow DOMから平坦化することを検討してください。
ブリッジソリューションとしての動的レンダリング
動的レンダリングは、サーバーが受信したリクエストが検索エンジンクローラーからのものか通常のユーザーからのものかを検出し、それに応じて異なるコンテンツを提供する手法です。クローラーリクエストはページの完全に事前レンダリングされた静的HTMLバージョンを受け取り、ユーザーリクエストは通常のJavaScriptアプリケーションを受け取ります。Googleは、完全なSSRを実装できないサイトの許容できるアプローチとして動的レンダリングを明示的に支持しています。
セットアップには3つのコンポーネントが含まれます。まず、サーバーまたはCDNでgooglebotや他の検索エンジンクローラーからのリクエストを識別するユーザーエージェント検出メカニズムです。googlebotは「googlebot」を含むユーザーエージェント文字列で自分自身を識別し、これは簡単にマッチできます。次に、JavaScriptページの静的HTMLスナップショットを生成してキャッシュする事前レンダリングサービス（Puppeteer、Rendertron、Prerender.ioのような商用サービスなど）です。第三に、検出されたクローラーリクエストに事前レンダリングされたHTMLを提供し、他のすべてのリクエストに通常のJavaScriptアプリケーションを提供するルーティングロジックです。
動的レンダリングは明示的にクローキングではなく、Googleのガイドラインに反するものではありません。クローキングは、ランキングを操作するためにユーザーとクローラーに完全に異なるコンテンツを表示することを含みます。動的レンダリングは、異なる技術的形式で同じコンテンツを表示します。事前レンダリングされたHTMLスナップショットには、JavaScriptレンダリングバージョンとまったく同じテキスト、画像、リンク、構造化データが含まれている必要があります。Googleはこの区別を繰り返し確認しています。
実装アプローチはインフラストラクチャによって異なります。Node.jsサーバーの場合、ユーザーエージェントヘッダーをチェックし、googlebotリクエストをPuppeteerまたはRendertronを介してルーティングするミドルウェアを使用できます。CloudflareのようなCDNの背後にあるサイトの場合、エッジワーカーを使用してgooglebotリクエストを傍受し、キャッシュされた事前レンダリングされたページを提供できます。APIバックエンドを持つ静的ホスティングの場合、事前レンダリングサービスはビルドまたはデプロイメントプロセス中にHTMLスナップショットを生成できます。
事前レンダリングされたページのキャッシュ戦略は重要です。事前レンダリングされたスナップショットは、コンテンツが変更されるにつれて古くなります。ブログ投稿やドキュメントのような静的コンテンツの場合、スナップショットは数日または数週間キャッシュできます。価格と在庫状況が変化する商品ページのような動的コンテンツの場合、スナップショットは少なくとも毎日再生成する必要があります。株価や生のスコアのようなリアルタイムコンテンツの場合、キャッシュされたスナップショットが常に古くなるため、動的レンダリングは適切ではない可能性があります。
動的レンダリングは、永続的なアーキテクチャではなく、過渡的なソリューションと見なすべきです。長期的なベストプラクティスは、すべてのユーザーとクローラーが同じレスポンスを受け取るように、ネイティブのサーバーサイドレンダリングを実装することです。動的レンダリングは複雑さ、メンテナンスの負担、および潜在的な障害点を追加します（事前レンダリングサービスがダウンすると、googlebotは壊れたページを認識します）。SSRまたはSSGに移行する間のブリッジとして使用してください。
ステップバイステップガイド
現在のレンダリング戦略を判断する
インデックスされていないページの1つを開き、HTMLソースを表示します（開発者ツールのインスペクターではなく、Ctrl+U）。本文のコンテンツを見ます。「root」または「app」のようなIDを持つ単一のdivと1つ以上のスクリプトタグが見える場合、ページは純粋なクライアントサイドレンダリングを使用しています。見出し、段落、構造化データを含む完全なHTMLコンテンツが見える場合、ページは少なくとも部分的にサーバーレンダリングされています。サイトの各セクションがどのレンダリング戦略を使用しているかを文書化します。多くの最新のアプリケーションは混合を使用します。サーバーレンダリングされたナビゲーションとレイアウトに、クライアントレンダリングされたコンテンツエリアです。
GoogleのURL検査ツールでページをテストする
Google Search Consoleで、インデックスされていないページのURLを入力し、「公開URLをテスト」をクリックします。テストが完了するのを待ち、結果を確認します。レンダリングされたページのスクリーンショットを調べて、コンテンツが表示されるかを確認します。「詳細情報」セクションで、リソース読み込みエラー、JavaScriptエラー、またはブロックされたリソースを確認します。スクリーンショットに完全なページコンテンツが表示されているが、ページがまだインデックスされていない場合、レンダリングは機能していますが、他の問題（薄いコンテンツ、noindexタグ、canonicalの競合）がある可能性があります。スクリーンショットに欠けているコンテンツまたは空白のページが表示されている場合、レンダリングの失敗がインデックスをブロックしています。サイトのさまざまなセクションにわたって5〜10ページをテストして、パターンを特定してください。
JavaScriptレンダリングエラーを特定して修正する
URL検査ツールの結果で、ブロックされたリソースとページリソースエラーを確認します。一般的な問題には、Googleのレンダラーが認証クッキーを送信しないために失敗するAPI呼び出し、CORSブロックされたクロスオリジンリソース、Googleのヘッドレスレンダラーで利用できないブラウザAPI（window.localStorage、navigator.geolocation）への参照、レンダリングをブロックするサードパーティスクリプトが含まれます。各エラーについて、重要なコンテンツに影響するかどうかを判断します。コンテンツデータ用のパブリックエンドポイントを提供して、API認証を修正します。ブラウザ固有のAPI呼び出しをサーバーサイドの代替に置き換えるか、APIが利用できないときのフォールバック動作を提供してください。
サーバーサイドレンダリングまたは静的生成を実装する
フレームワークに基づいて、適切なサーバーレンダリング戦略を実装します。React CRAプロジェクトの場合、App RouterとサーバーコンポーネントでNext.jsに移行します。Vue CLIプロジェクトの場合、組み込みSSRでNuxtに移行します。Angularプロジェクトの場合、Angular Universalを実装します。クライアントサイドのデータ取得を使用する既存のNext.jsまたはNuxtプロジェクトの場合、データ取得をサーバーサイド関数（getServerSideProps、getStaticProps、サーバーコンポーネント、またはasyncData）に移動します。SSRまたはSSGを実装した後、ページソースを表示し、JavaScript実行なしで生のHTMLにコンテンツが表示されることを確認してください。
必要に応じて動的レンダリングを短期的な修正として実装する
SSRへの移行がすぐに実現不可能な場合は、ブリッジソリューションとして動的レンダリングを実装します。事前レンダリングサービス（Puppeteer、Rendertron、またはPrerender.io）をセットアップします。サーバーまたはCDNを構成して、ユーザーエージェント文字列でgooglebotリクエストを検出し、事前レンダリングされたHTMLにルーティングします。googlebotユーザーエージェント文字列を持つcurlを使用してテストし、事前レンダリングされたHTMLが正しく提供されることを確認します。事前レンダリングされたHTMLを通常のページと比較して、コンテンツの一致を確認します。コンテンツに合わせてスナップショットを最新の状態に保つために、自動化された事前レンダリングキャッシュ更新をセットアップしてください。
修正を確認してインデックスのために送信する
SSR、SSG、または動的レンダリングを実装した後、URL検査ツールでページを再テストします。レンダリングされたスクリーンショットが完全なコンテンツを示し、リソースエラーが報告されないことを確認します。ページソースを表示して、コンテンツが初期HTMLにあることを確認します。確認したら、URL検査ツールを使用して、最も優先度の高いページのインデックスをリクエストします。JavaScriptレンダリング問題の影響を受けるページが多いサイトの場合、IndexBoltを使用して修正されたすべてのURLを一括送信して、迅速なインデックス化を行います。次の2週間にわたってページレポートを監視し、インデックスの回復を追跡してください。
レンダリングのリグレッションに対する継続的な監視をセットアップする
JavaScriptレンダリング問題は、コードデプロイ、依存関係の更新、またはAPIの変更後に再び現れる可能性があります。リグレッションを早期に検出するために自動化された監視をセットアップします。CI/CDパイプラインでLighthouse CIや類似のツールを使用して、主要ページのサーバーレンダリングされたHTML出力をテストします。事前レンダリングサービスのレンダリング失敗のアラートを構成します。Google Search Consoleのページレポートの毎週のチェックをスケジュールして、「クロール済み — インデックス未登録」ページの新しい急増を検出します。これはレンダリングのリグレッションを示す可能性があります。新しいチームメンバーが誤ってクライアントサイドのみのコンテンツパターンを導入しないように、レンダリングアーキテクチャとSSR要件を文書化してください。
よくある問題と解決方法
URL検査ツールでReactアプリが空白のページまたはロードスピナーを表示する
原因： アプリケーションは純粋なクライアントサイドレンダリング（Create React Appまたは類似）を使用し、サーバーが空のHTMLシェルを送信し、JavaScriptがブラウザでページ全体を構築します。Googleの最初のインデックス波はコンテンツを認識せず、レンダリングキューはAPIエラー、長い読み込み時間、またはリソース集約的なレンダリングのためにページの処理に失敗する可能性があります。
解決方法： 組み込みのサーバーサイドレンダリングのためにNext.jsに移行します。その間、Prerender.ioまたはセルフホストされたRendertronインスタンスで動的レンダリングを実装します。Googleのレンダラーがデータをフェッチできるように、アプリケーションが使用するAPIエンドポイントが認証なしで公開アクセス可能であることを確認します。すぐに移行することが不可能な場合、少なくともJavaScriptが読み込まれる前にサーバーが送信する静的HTMLテンプレートに重要なmetaタグ（title、description、canonical）と主要な見出しテキストを追加してください。
Next.jsページはインデックスされているが、Googleの結果で古いコンテンツが表示される
原因： 静的サイト生成（getStaticProps）を使用するページはビルド時に事前レンダリングされ、Googleはビルド時のバージョンをキャッシュしています。ビルド間でコンテンツが変更されると、インデックスされたバージョンは古くなります。これはレンダリングの失敗ではなく、新鮮さの問題です。Incremental Static Regenerationを使用するページも、再検証間隔がGoogleのクロール頻度より長い場合、古いコンテンツを表示する可能性があります。
解決方法： 頻繁に変更されるコンテンツを持つページの場合、SSGからSSR（getServerSidePropsまたは動的App Routerページ）に切り替えます。ISRを使用するページの場合、コンテンツ更新頻度に合わせて再検証間隔を短縮します。大規模なコンテンツ更新後、IndexBoltまたはSearch Consoleを使用して更新されたページの再クロールをリクエストし、Googleが最新バージョンを取得できるようにします。時間ベースの再検証に頼るのではなく、コンテンツが更新されたときにページ再生成をトリガーするオンデマンドISRの実装を検討してください。
ハッシュベースルーティングのシングルページアプリケーションで内部ページがインデックスされない
原因： ハッシュベースルーティング（yourdomain.com/#/about、yourdomain.com/#/productsのようなURL）はGoogleには見えません。Googleは#の後のすべてをフラグメント識別子として扱い、サーバーに送信しません。すべてのハッシュベースURLはGoogleの視点から同じページに解決されます。GoogleのWRSはハッシュルート間を移動しないため、初期ページコンテンツのみがレンダリングされます。
解決方法： ハッシュベースルーティングからヒストリーベースルーティング（yourdomain.com/about、yourdomain.com/productsのようなクリーンなURL）に移行します。React RouterでHashRouterからBrowserRouterに切り替えます。Vue Routerでモードを「hash」ではなく「history」に設定します。すべてのルートパスを処理し、任意のURLパスに対してアプリケーションのHTMLを返すようにサーバーを構成します。移行後、新しいクリーンなURLをGoogle Search ConsoleまたはIndexBolt経由で送信し、各ルートのインデックスを監視してください。
遅延読み込みされたコンポーネントと画像がGoogleのレンダリングに表示されない
原因： React.lazy()、動的インポート、またはintersection observerベースの遅延読み込みを介して読み込まれるコンテンツは、スクロール位置またはビューポート交差イベントに依存している場合、GoogleのWRSでレンダリングされない可能性があります。Googleのレンダラーはページを読み込みますが、スクロールしたりビューポートをリサイズしたりしないため、スクロールイベントによってトリガーされるコンテンツは読み込まれないままです。
解決方法： 重要なファーストビューコンテンツを決して遅延読み込みしないでください。インデックスさせたいファーストビュー下のコンテンツの場合、スクロールイベントを必要とするJavaScriptベースのintersection observer遅延読み込みではなく、Googleがサポートするネイティブの遅延読み込み（画像のloading="lazy"属性）を使用します。インデックス可能なコンテンツを含む動的にインポートされたコンポーネントの場合、サーバーサイドではイーガーにロードし、パフォーマンスのためにクライアントサイドでのみ遅延読み込みします。最大のレンダリング回復力のために、重要なコンテンツを含むnoscriptフォールバックを含めてください。
APIに認証が必要なため、APIドリブンのコンテンツページがレンダリングに失敗する
原因： 多くのJavaScriptアプリケーションは、認証トークン、ヘッダーのAPIキー、またはセッションクッキーを必要とするAPIからコンテンツを取得します。GoogleのWRSはあなたの認証システムにアクセスできず、ログインできず、認証クッキーを送信しません。Googleのレンダリング中に401または403エラーを返すAPI呼び出しは、空のコンテンツエリアになります。
解決方法： 公開アクセス可能であるべきコンテンツの場合、認証を必要としないパブリックAPIエンドポイントを作成します。Googleが見る必要のあるページコンテンツをパブリックエンドポイントから提供し、ユーザー固有のデータ（アカウント詳細、パーソナライゼーション）を認証済みエンドポイントの背後に保ちます。サーバーがAPIで認証し、ブラウザに送信する前にHTMLレスポンスにコンテンツを含めるサーバーサイドのデータ取得を実装します。これにより、レンダリング中のクライアントサイドのAPI認証の必要性が排除されます。
プロのヒント
よくある質問
GoogleはJavaScriptページを確実にレンダリングできますか？+
GoogleのWRSは最新のChromiumを使用し、ほとんどのJSコンテンツをレンダリングしますが、即時ではなく（キューの遅延）、100%信頼できるわけではなく（API失敗は不完全なレンダリングを引き起こす）、ユニバーサルでもありません（インタラクションAPIなし）。重要なページの場合、JSレンダリングに完全に依存することはリスクがあります。SSRは、コンテンツが常に初期HTMLにあることを保証することで、そのリスクを排除します。
サーバーサイドレンダリングはSEOに必要ですか、それとも推奨されているだけですか？+
技術的には必要ありません。GoogleはCSRコンテンツをインデックスできます。しかし、SSRは劇的に優れた信頼性、速度、カバレッジを提供します。CSRページはレンダリングキューの遅延、失敗リスク、クロールの優先度低下に直面します。SSRコンテンツは第1波で即座に評価されます。オーガニックトラフィックが重要なページについては、SSRが強く推奨されます。CSRは認証済みダッシュボードや管理パネルには問題ありません。
GoogleがJavaScriptページを正常にレンダリングしているかどうかをどのように知りますか？+
Google Search ConsoleのURL検査ツールを使用して、Googleが正確に何をレンダリングするかを確認します。URLを入力し、「公開URLをテスト」をクリックし、レンダリングされたスクリーンショットをブラウザで見えるものと比較します。コンテンツが一致する場合、レンダリングは機能しています。Googleが受け取ったHTMLの「クロールされたページ」セクションと、リソース読み込みエラーの「詳細情報」セクションも確認してください。継続的な監視には、ページレポートで送信されたページ（サイトマップ内）とインデックスされたページの比率を追跡します。大きなギャップは、レンダリングまたは品質の問題がインデックスを妨げていることを示唆します。
googlebotはレンダリングにどのバージョンのChromeを使用しますか？+
GoogleのWeb Rendering Serviceは、最新の安定版Chromeリリースで最新の状態を保つことを意味する、エバーグリーンバージョンのChromiumを実行します。2026年現在、これは最新のJavaScript（ES2022+）、CSS Grid、Flexbox、Web Components、動的インポート、IntersectionObserver、ほとんどの最新ウェブプラットフォーム機能の完全なサポートを意味します。ただし、レンダリング環境はユーザーインタラクションAPI（クリック、スクロール、ホバー、キーボードイベントなし）をサポートしておらず、決済または通知APIをサポートしておらず、localStorage／sessionStorageのサポートが限られています。サポートされている＆サポートされていないAPIの現在のリストについては、Googleの公式ドキュメントを確認してください。
動的レンダリングを使用するか、サーバーサイドレンダリングに切り替えるべきですか？+
SSRを実装するエンジニアリングリソースがある場合、それは常に長期的に良い選択です。SSRは検索エンジンクローラーだけでなく、すべてのユーザーに利益をもたらします（より高速な初期ページ読み込み、より良いアクセシビリティ、改善されたCore Web Vitals）。動的レンダリングは、SSRに迅速に移行できないチームの有効な短期的なソリューションですが、メンテナンスの複雑さを追加し（事前レンダリングサービスを稼働させ続けてキャッシュを新鮮に保つ必要があります）、ユーザーとクローラーが技術的に異なるレスポンスを見るシステムを作成します。SSR移行を計画して実行する間のブリッジとして動的レンダリングを使用してください。
Next.jsアプリはサーバーコンポーネントを使用しています。なぜページがまだインデックスされていないのですか？+
Next.jsのサーバーコンポーネントはデフォルトでサーバーレンダリングされ、優れたインデックスを提供するはずです。一般的な問題には以下があります。メインコンテンツをラップする「use client」を持つコンポーネントをインポートする（クライアントでレンダリングするように強制する）、サーバーコンポーネントからプロパティとして渡すのではなくクライアントコンポーネント内でデータを取得する、サーバーレンダリング中にコンテンツの代わりにスケルトンを表示するloading.tsxファイルがある、または異なるページにgooglebotをリダイレクトするミドルウェアです。コンポーネントツリーを確認し、主要なコンテンツ持ちのコンポーネントがサーバーコンポーネント（「use client」ディレクティブなし）であり、データ取得がサーバーレベルで発生することを確認してください。