GSC URL検査
Search ConsoleでURLを入力し、「公開URLをテスト」をクリックしてHTMLソースを比較し、レンダリング後に主要なコンテンツが消失していないか確認します。
テキスト差分比較
「ページのソースを表示」と「検証（要素の検査）」のテキスト文字数を比較します。テキストの差分率が20%を超える場合、インデックス未登録の極めて高いリスクが存在します。
リッチリザルトテスト
Googleのリッチリザルトテストツールを使用してスクリーンショットを確認し、ファーストビューの重要なコンテンツが5秒のレンダリングウィンドウ内に完全に読み込まれていることを確認します。
Google公式ツール
Google Search Console (GSC) の「URL検査ツール」は、Googlebotによるクロールの実況状況を確認するための入り口です。
「公開URLをテスト」を実行することで、60〜90秒以内にWRS (Web Rendering Service) が呼び出され、完全なDOM構造が生成されます。
GSCでは、レンダリング後のHTML、スクリーンショット、および読み込まれたリソースのリストが提供されます。
現在、Googlebotは最新のChrome安定版カーネルを採用していますが、個別のページにおけるスクリプト実行には約5秒のしきい値が設けられています。
「リッチリザルトテスト」と組み合わせることで、元のレスポンスと最終的なレンダリング結果のバイト数の差を比較し、Robots.txtによるブロックが原因の403または404スクリプト読み込みエラーを特定できます。
Google Search Console
Google Search Consoleのサイドバーナビゲーションで特定のURLを入力すると、システムはGoogleのインデックスデータベースから最新のクロールデータのスナップショットを抽出します。
ステータスが「URLはGoogleに登録されています」と表示されている場合、その時点のクロールでHTML解析エラーやモバイルフレンドリーの問題が発生していなかったかを確認できます。
JavaScriptのレンダリングに起因するコンテンツの欠落を深く調査するには、「公開URLをテスト」ボタンをクリックする必要があります。
この操作によりWRS（Web Rendering Service）が起動し、最新の安定版Chromiumカーネルに基づいたヘッドレスブラウザで対象ページにリアルタイムでアクセスします。
WRSはレンダリング実行時、ビューポートの幅を1280ピクセルに設定し、モバイルファーストインデックスの戦略を採用します。
「レンダリングされたページを表示」パネルのHTMLタブには、スクリプト実行完了後の完全なDOM構造が表示されます。
技術者は、ここに表示されるHTMLの行数や文字バイト量を、ブラウザの右クリックで確認できる「ページのソースを表示」（元のサーバーレスポンス）と定量的に比較すべきです。
元のHTMLがわずか2KBで、レンダリング後のHTMLが50KBに増加している場合、そのページはクライアントサイドレンダリングに高度に依存していることを示しています。
レンダリング後のHTMLに主要なテキストコンテンツや商品リストタグが含まれていない場合は、レンダリング失敗と判定されます。
Googlebotは個別のページのスクリプト実行に対して限られた計算リソースを割り当てています。公式な期限は示されていませんが、多くの実験により、コンテンツの読み込み時間が5秒を超えると、そのデータがインデックス段階で漏れる確率が大幅に高まることが示されています。
「GooglebotはJavaScriptがすべての非同期タスクを完了するのを無期限に待つわけではありません。レンダリング予算は、ページの読み込み速度、サーバーのレスポンス遅延（TTFB）、およびスクリプト解析の複雑さによって制限されます。APIのレスポンス時間が2000ミリ秒を超えると、レンダリングスナップショットの生成時にコンテンツがまだ読み込み中（Loading）状態になることがよくあります。」
「詳細情報」タブの「ページリソース」リストには、読み込みに失敗したすべてのJSおよびCSSファイルが表示されます。
ステータスコード403または404は、サーバーの権限設定エラーまたはリソースパスの無効を明確に示していますが、最も注意すべきは「Robots.txtによりブロック済み」というステータスです。
多くのシングルページアプリケーション（SPA）では、ルーティングロジックやデータレンダリングロジックが特定のスクリプトファイルにカプセル化されています。サイトの/robots.txtファイルにDisallow: /assets/などのルールが存在し、Googlebotが主要なスクリプトを取得できない場合、WRSは完全なDOMツリーを構築できません。
その結果、ユーザーのブラウザではページが完全に表示されていても、検索エンジンのクロール視点では、そのページが空白であるか、基礎的なフレームワークのみが含まれている状態になる可能性があります。
スクリプトエラーの調査は、「JavaScriptコンソールメッセージ」領域に焦点を当てるべきです。
ここでは、WRSがコードを実行した際にスローされた例外が記録されます。
開発チームがポリフィル（Polyfill）処理されていないES6+の新機能（BigInt、ResizeObserverなど）を使用しており、クロール時のChromiumバージョンが一部の非標準APIに完全に対応していない場合、コンソールにUncaught ReferenceErrorやSyntaxErrorが表示されます。
このようなエラーはスクリプト解析プロセス全体の中断を引き起こし、その後のすべてのコンテンツ注入ロジックが無効になります。
エラーログに記載されている具体的な行番号やファイル名を確認することで、どのライブラリファイルやビジネスロジックがクロールを妨げているかを正確に特定できます。
レンダリング後の「スクリーンショット」も重要な定量的検証手段です。
例えば、一部のスクリプトが要素の高さや透明度を動的に計算する場合、スクリーンショットでページが大きく空白になっていると、HTMLタグ内に文字が存在していても、Googleのアルゴリズムはそのページをユーザーフレンドリーではないと判断し、インデックスの優先順位を下げる可能性があります。
動的な要素が強いサイトを扱う際は、ファーストビュー（Above the Fold）にあるすべてのコンテンツが2秒以内にレンダリングを完了するようにする必要があります。
リッチリザルトテスト
リッチリザルトテストツールはGoogleが提供する公開検証環境です。サイトの所有権確認が必要なSearch Consoleとは異なり、このツールは誰でもウェブ上の任意のURLや貼り付けたコードスニペットを解析できます。
URLを入力してテストを開始すると、システムは最新の安定版Chromiumカーネルに基づくヘッドレスブラウザを起動し、Googlebot SmartphoneまたはGooglebot Desktopのアクセス動作をシミュレートします。
React、Angular、Vue.jsなどのJavaScriptフレームワークで構築されたシングルページアプリケーション（SPA）にとって、このツールが提供する「テスト済みのページを表示」機能は、コンテンツがDOMツリーに正常に反映されたかどうかを判断する基準となります。
Googlebotがスクリプトを処理する際の計算リソース割り当てには上限があるため、ページの初期化段階で大量の計算を実行したり、20個以上の非同期APIリクエストを発行したりすると、WRSはスクリプト実行完了前にHTMLのキャプチャを終了してしまう可能性があります。
リアルタイムテストを実行すると、システムはレンダリング後のHTMLスナップショットを生成します。
このスナップショットを通じて、技術者は元のサーバーが返したバイト数と最終的なレンダリング後のバイト数の差を正確に比較できます。
例えば、純粋なクライアントサイドレンダリング（CSR）ページでは、元のHTMLは通常5KB未満の基礎テンプレートコードのみですが、このツールでレンダリングした後のHTMLが100KB以上になれば、Googlebotが正常にスクリプトを実行し、動的コンテンツを取得したことを意味します。
逆に、レンダリング後のHTMLが5KB程度のままで主要なテキストタグが含まれていない場合は、WRSレベルでスクリプト実行が中断されたことを示します。
Googleのレンダリングエンジンは、個別のリソースのダウンロードに対して厳格なタイムアウト設定を設けており、通常、単一のJSファイルの読み込み時間は2000ミリ秒を超えないようにすべきです。
ページが参照しているサードパーティライブラリやAPIレスポンスが遅すぎる場合、テスト結果の「ページリソース」タブに対応する読み込み失敗ステータスが表示されます。
- コードスニペットテストモード：未公開のHTMLコードを貼り付けてテストできます。これは、ステージング環境の段階でJSレンダリングロジックがクロール仕様に準拠しているか確認するために非常に重要です。これにより、コードをメインブランチにマージする前に、動的に生成されたSchemaマークアップが正しく解析されるかを定量的に確認できます。
- ユーザーエージェントの切り替え：デフォルトはモバイルクロールですが、複雑なレスポンシブロジックを持つサイトでは、デスクトップデバイスへの切り替えシミュレーションにより、CSSの読み込み優先度がJS実行順序に与える影響を発見できます。
- レンダリングスナップショット比較：提供されるスクリーンショットは視覚的なリファレンスであるだけでなく、「コンテンツのズレ（Layout Shift）」や「レイアウトのガタつき」が発生していないかを判断する根拠にもなります。激しいレイアウト変動は、Googlebotにページの利便性が低いと誤認させる原因になります。
「リッチリザルトテストは構造化データを検証するだけでなく、動的コンテンツの可視性を確認するためのラボでもあります。ページ上のテキストがJSで非同期に読み込まれる場合、『テスト済みのページを表示』内でそのテキストを検索して存在を確認することが、SEOインデックスの成功率を検証する最短の方法です。」
ページにスクリプト注入されたJSON-LDやマイクロデータ（Microdata）が含まれている場合、ツールはレンダリング後のDOMからこれらの構造化情報を抽出します。
コードに構文エラーがある場合、またはJSエラーによりSchemaマークアップ注入前にスクリプトが停止した場合、ツールは「リッチリザルトは検出されませんでした」という警告を出します。
ECサイトやレビューサイトにおいて、このチェックは特に重要です。Googleはインデックスと同時に、価格、在庫状況、評価などの特定の属性を認識する必要があるからです。
これらの属性が「テスト済みのページ」のHTML内で欠落している場合、フロントエンドで正常に表示されていても、検索結果ページ（SERP）に星評価や価格のプレビューは表示されません。
WRS環境のメモリ制限は一般的なユーザーのブラウザよりも厳しいため、コンソールのエラーログには特に注意を払う必要があります。
スクリプトが過剰なCPUリソースを消費すると、Googlebotはそのページのレンダリングを破棄し、インデックスには空のシェルテンプレートのみが残る結果を招く可能性があります。
- 読み込まれるリソースの総数：単一ページのリクエストJSリソースは50個以内に抑えることを推奨します。並列リクエストが多すぎると、WRSのスケジューリング遅延が発生し、レンダリング失敗のリスクが高まります。
- スクリプト実行エラーの監視：
ReferenceErrorやTypeErrorなど、レンダリングチェーンを断ち切る致命的な例外を捕捉します。ポリフィル不足によるES仕様の不互換エラーが見られる場合は、ビルドツールのコンパイルターゲットを直ちに調整する必要があります。 - APIレスポンスの有効性：リソースリストを通じて、動的に取得されるすべてのコンテンツのAPIエンドポイントを確認します。ステータスが「ブロック済み」または「タイムアウト」の場合、Googlebotがファイアウォールで遮断されているか、APIのパフォーマンスがクロールのしきい値を満たしていないことを示します。
このテストツールで生成されるレポートの各「警告」や「エラー」は、実際のインデックス環境におけるGooglebotの挙動を反映しています。
ツールが「一部のスクリプトを読み込めませんでした」と提示した場合、たとえ一般的なユーザーのChromeブラウザで正常に動作していても、重視する必要があります。これはGooglebotのクローラーIPアドレスがそれらのリソースにアクセスする際、サーバー側でレート制限（Rate Limiting）を受けている可能性があるためです。
Chrome DevTools
ローカル開発環境において、Chrome DevToolsの「ネットワーク条件（Network conditions）」パネルは、Googlebotのクロール挙動をシミュレートする出発点です。
F12キーを押すか、右クリックで「検証」を選択してツールバーを開き、右上の3つの点メニューからその他のツール（More tools） -> ネットワーク条件（Network conditions）に移動します。
このパネルで「ブラウザのデフォルト設定を使用する」のチェックを外し、ドロップダウンリストから手動で「Googlebot」を選択します。
この操作により、ブラウザが送信するユーザーエージェント（User-Agent）文字列が変更されます（例：Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)）。
この手順の目的は、サーバーがクローラー専用の特殊なロジックを適用していないかを確認することにあります。
サーバーがUAに応じて異なるHTMLコードを返すように設定されている場合、ローカル環境で即座に一般ユーザーとは異なるレスポンス結果が表示されます。
技術者はこの時のレスポンスヘッダーを確認し、Content-Typeやキャッシュ制御（Cache-Control）に変更がないかチェックすべきです。
サーバーがGooglebotに対して403アクセス拒否や意図しない301リダイレクトを返している場合、サーバーレベルで検索エンジンのインデックスが阻害されていることを示します。
Googlebotの「第1波のインデックス（First-wave indexing）」をシミュレートするには、JavaScriptを無効にした状態での挙動をテストする必要があります。
DevToolsの設定（Settings）を開き、プリファレンス内のデバッガー（Debugger）セクションで「JavaScriptを無効にする（Disable JavaScript）」にチェックを入れます。
ページを更新すると、ブラウザはサーバーから返された元のHTML構造のみを表示します。
シングルページアプリケーション（SPA）アーキテクチャを採用しているサイトでは、この操作によりページが完全に空白になるか、ローディングアニメーションのみが表示されることがよくあります。
主要なテキスト情報、ナビゲーションメニュー、商品リストがスクリプト無効化後に消失する場合、検索エンジンがコンテンツを取得するためには、複雑な「第2波のインデックス」であるWRSレンダリング段階を待たなければならないことを意味します。
この際、元のHTMLのバイト数（例：15KBの基礎フレームコード）を記録し、完全にレンダリングされたDOMと比較して、JSによって注入されるコンテンツの規模を特定すべきです。
「ローカルシミュレーションにおいて、JavaScriptの無効化は最も基本的なストレステストです。元のHTMLに主要な意味情報を含むH1タグや本文段落が欠けている場合、ネットワーク環境の変動やGoogleのレンダリング枠が逼迫した際に、空白のページとしてインデックスされるリスクが極めて高くなります。」
Googlebotが動作する環境は高性能なデスクトップコンピュータではありません。DevToolsの「パフォーマンス（Performance）」パネルを利用することで、Googlebotの計算能力をよりリアルにシミュレートできます。
パフォーマンス設定で、CPUスロットリング（CPU Throttling）を4倍速または6倍速の減速（4x or 6x slowdown）に調整します。
高性能なMacBookでわずか800ミリ秒で完了するレンダリングタスクが、6倍の減速下で5500ミリ秒に伸びた場合、Googlebotの一般的な5秒のレンダリングしきい値に触れていることになります。
フレームグラフ内のロングタスク（Long Tasks）を確認することで、どの巨大なJSライブラリがメインスレッドをブロックし、レンダリングを遅延させているかを特定できます。
この環境下で合計ブロック時間（TBT）などの指標が2000ミリ秒を超えている場合、通常、Googlebotがコンテンツの完全生成を待たずに、不完全なDOMスナップショットをキャプチャしてしまう可能性が高いことを示唆しています。
ブラウザによる手動検証
手動検証では、初期HTML（Initial HTML）とレンダリング後DOM（Rendered DOM）のデータ差を比較することでレンダリング状態を確認します。
Googlebotは最新のChromeレンダリングエンジンを採用していますが、JSの実行が5秒のしきい値を超えたり、単一ページのリソースリクエストが50個を超えたりすると、コンテンツがインデックスされない可能性があります。
手動テストではリソース読み込みチェーンに注目し、クローラーの巡回経路を確保するために、<a>タグのhref属性がHTMLソース内に最初から存在し、onclickイベントなどで動的に生成されていないことを確認する必要があります。
ソースコードとリアルタイムDOM
ブラウザでview-sourceから確認できるコードは、サーバーが送信した元のテキストストリームを反映しています。一方、デベロッパーツールのElementsパネルに表示されるのは、レンダリングエンジンによって解析され、スクリプトが実行・修正された後のメモリ上のオブジェクトモデル（DOM）です。
SPAアーキテクチャを採用しているサイトでは、元のソースコードはid="app"やid="root"を持つ空のコンテナタグと、合計サイズが500KBを超えるいくつかのスクリプト参照のみであることが多いです。
ソースコード内のプレーンテキストの文字数とレンダリング後のDOM内の文字数を比較し、その比率が1:20を超える（つまり元のHTMLに100単語しかなく、レンダリング後に2000単語になる）場合、検索エンジンの第1波のクロールでは有効な意味情報をほとんど取得できません。
このような差異は、インデックス初期段階でのコンテンツ真空状態を招き、レンダリングキューでの二次処理を待つ必要が生じます。
| 比較項目 | 初期HTML (Initial HTML) の特徴 | レンダリング後DOM (Rendered DOM) の特徴 | 技術的差異によるインデックスへの影響 |
|---|---|---|---|
| DOMノード総数 | 通常50ノード未満で、構造は極めてフラット。 | 1500ノードを超えることがあり、階層が深くなる。 | ノード数の激増は、コンテンツ生成が完全にJS実行に依存していることを示す。 |
| Metaタグの状態 | 汎用的なタイトルやハードコードされたプレースホルダ。 | スクリプトによって注入されたページ固有のSEOタグ。 | クローラーがスクリプト実行前に誤ったメタデータを記録する可能性がある。 |
| Canonicalタグ | 欠落しているか、固定のトップページURL。 | 現在のページの正規絶対パスに動的に更新される。 | タグの不一致は、検索エンジンによるページ属性の解析競合を招く。 |
| JSON-LD構造化データ | コード内が空、または基礎的なフレームのみ。 | 完全な製品価格、レビュー、在庫データが充填される。 | SERPにリッチスニペットが表示されるかどうかを決定する。 |
| 内部リンク | ナビゲーションバーが空、またはリンク未生成。 | 完全な<a>タグと動的なカテゴリパスを含む。 |
クローラーがサイト内の深い階層のURLを発見する効率に影響する。 |
詳細な比較を行う際は、コンソールにdocument.body.innerText.lengthと入力してレンダリング後の総文字数を取得し、ソースコードファイルのバイトサイズと比較します。
ソースコードが30KBであっても、レンダリング後のinnerTextが15,000文字に達している場合、主要なテキストの重みはすべてレンダリング層に集中しています。
このとき、スクリプト内に実行に200ms以上かかる再帰関数があったり、読み込みに2.0s以上かかる外部APIを参照していたりすると、Googlebotのレンダリングエンジンはリソース割り当て戦略に基づき、コンテンツが完全に注入される前に記録を停止してしまう可能性があります。
| 定量指標 | リスクしきい値 | クロールとインデックスへの実際の影響 |
|---|---|---|
| コード・テキスト差分率 | テキストの80%以上がJS生成 | スクリプト無効環境で「低品質コンテンツ」と判定されやすい。 |
| リンク抽出成功率 | ソース内の有効な<a>タグが5個未満 |
クロール予算（Crawl Budget）が無意味な待機時間に費やされる。 |
| スクリプト実行メモリ使用量 | スタックメモリ消費が50MB超過 | レンダリングサーバーがメモリ制限によりタスクを強制終了することがある。 |
| ファーストビューHTML完成度 | ソース内で視認可能な内容が10%未満 | 低速ネットワークのユーザーに長時間白板を見せ、掲載順位シグナルが悪化。 |
Elementsパネルでナビゲーションメニューを確認し、リンクが<a href="javascript:void(0)" onclick="navigateTo('/page')">のようになっている場合、レンダリング後のDOM上ではリンクに見えても、検索エンジンのクローラーにとっては追跡不能な行き止まりとなります。
標準的なhref属性は、サーバーが返した元のHTML内に最初から存在するか、スクリプト実行後に標準的な<a href="/target-path">形式として生成される必要があります。
完全な初期HTMLリンク構造を持つサイトは、リンクを完全にJS注入に依存しているサイトよりも、新ページのインデックス速度が通常40%〜70%速くなります。
ソースコードにnoindexのメタタグが存在し、スクリプトでそれを削除してindexに置き換えようとする手法は、多くの場合無効です。
検索エンジンは通常、初期HTMLで発見された命令を優先するため、ページが正常なインデックスプロセスに入れない原因となります。
環境シミュレーション検証
Chromeブラウザでデベロッパーツール（DevTools）を開き、Ctrl+Shift+Pでコマンドメニューを呼び出し、Disable JavaScriptと入力して実行します。これが検索エンジンの初回クロール状態をシミュレートする起点です。
スクリプトを無効にした状態でページを再読み込みし、画面が空白または基礎フレームのみになる場合、サーバー側の初期HTMLには実質的なテキストコンテンツが含まれていないことを意味します。
100KBのHTMLファイルにおいて、テキスト内容の90%が後から読み込まれる2MBのJavaScriptに依存している場合、ネットワークの遅延やスクリプトエラーが発生した際、検索エンジンは空のコンテナタグのみを記録する可能性が非常に高くなります。
| シミュレーションパラメータ | 設定基準と数値 | 観察結果とデータ指標 |
|---|---|---|
| ネットワークスロットリング | Fast 3G (下り1.5 Mbps, 遅延40ms) | メインコンテンツの完了が5000ms (5秒)を超えると、Googleの待機が終了する可能性がある。 |
| CPU制限 | 4x slowdown (モバイルCPU性能を想定) | スクリプト解析時間が1.5秒を超えると、スレッド占有によりレンダリングが停滞する。 |
| ユーザーエージェント | Googlebot Smartphone (Chrome/W.X.Y.Z) | サーバーが403エラーを返したり、特定のモバイル用コードを返したりしないか確認。 |
| ビューポートサイズ | 411 x 731 ピクセル (標準モバイル幅) | クリックやスクロールなどの操作なしでコンテンツが自動読み込みされるか確認。 |
ブラウザのユーザーエージェント文字列をMozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)に変更します。
NetworkパネルでDisable cacheにチェックを入れ、Googlebotとしてのリソース読み込みチェーンを観察します。
標準的なクロールプロセスにおいて、Googlebotは通常すべてのメディアファイルを読み込むわけではなく、テキストと構造化データの解析を優先します。
ページがスクリプトでUAを検知して異なるロジック（クローラー向けに非同期APIを閉じるなど）を適用している場合、ElementsパネルのDOM構造が一般ユーザーが見るものと全く異なる結果になります。
Networkパネルで通信速度をFast 3Gに、CPU性能を4x slowdownに制限します。
Googlebotのレンダリングサーバーが世界中の膨大なページを処理する際、1ページに割り当てられる計算リソースは有限です。Performanceパネルで読み込みプロセスを記録し、特にMainスレッドの活動を確認してください。
Evaluate Scriptによるロングタスク（50ms超）が合計で読み込みサイクルの70%以上を占めている場合、実際のクロール環境では、コンテンツが完全に充填される前にスナップショットの記録が完了してしまう恐れがあります。
First Contentful Paint (FCP)とLargest Contentful Paint (LCP)の間隔が、JS実行の長期化により3秒以上に広がった場合、検索エンジンが不完全なページをキャプチャする確率は約40%増加します。
デベロッパーツールの下部にあるSensorsタブを利用して、異なる地理的場所（サンフランシスコやロンドンなど）を手動でシミュレートします。
Googlebotのクロールノードは主に米国内に分布しています。サイトのJSロジックにIPアドレスによる自動リダイレクトやローカルタイムスタンプに基づくコンテンツ生成が含まれている場合、取得されるページのバージョンがターゲット層の地域と不一致になる可能性があります。
Consoleパネルでエラー情報、特にReferenceErrorやTypeErrorを確認します。
Googleのレンダリングエンジン（Evergreen Googlebot）は更新され続けていますが、極めて新しいWeb API（最新のWebGPUや特定バージョンのWebAssemblyなど）についてはサポート状況が異なる場合があります。
コード内でポリフィルによる互換性処理がなされていないと、スクリプトが実行途中でクラッシュし、DOMツリーの構築が停止します。
- リクエスト数の制限：レンダリング完了までに発行されるネットワークリクエスト総数を集計します。単一ページで50個以上のJSやCSSリソースをリクエストしている場合、ブラウザの並列制限やクローラーの割り当て制限により、一部のスクリプトが適時に読み込まれない可能性があります。
- Shadow DOMの状態：Elementsパネルで
#shadow-root (closed)マークがないか確認します。GooglebotはOpenモードのShadow DOMを解析できますが、Closedモードの内容はクローラーには見えません。すべてのWebコンポーネントがOpen状態であることを確認してください。 - リンク形式の検証：レンダリング後のDOM内で
<aタグを検索します。すべての遷移リンクに完全なhref属性が含まれているか確認してください。window.location.hrefやrouter.pushなどのJSイベントで遷移を制御し、HTMLに標準的なアンカーを残していない場合、検索エンジンはそれらの子ページを発見できません。 - 画像の遅延読み込み（Lazy Load）：スクロールなしの状態で、
<img>タグのdata-srcの内容がsrc属性に置き換わっているか確認します。Googlebotはある程度のスクロールをシミュレートできますが、複雑なscrollイベントリスナーに依存するスクリプトの動作は不安定です。標準のloading="lazy"属性を使用するのがより安全です。
初期HTMLとレンダリング後DOMのバイトサイズおよびテキストノード数を比較します。
両者のテキストカバー率の差が80%を超え、大部分のテキストがDOMContentLoadedイベント以降に注入されている場合、そのサイトのSEOはレンダリング効率に高度に依存しています。
テスト中にTotal Blocking Time (TBT)を記録することを推奨します。この数値が300msを超えると、スクリプト実行がクローラーによるDOM解析を妨げる前兆となります。
ChromeのCoverageパネルでJSファイルの利用率を確認します。500KBのスクリプトのうち80%のコードが初回読み込み時に実行されていない場合、それらの冗長なコードはレンダリングサーバーの計算量を無駄に消費し、インデックス速度に影響を与えます。
プロフェッショナル向けクローラーツール
プロフェッショナル向けのクローラーツール（Screaming Frog v20+など）はChrome環境をシミュレート可能です。
データによると、スクリプトを実行するクロールコストは静的なHTMLよりも20倍高くなります。
「レンダリング前」と「レンダリング後」のHTML文字数の差が10%を超える場合、または内部リンクの認識数に5%以上の差がある場合、インデックス成功率は通常低下します。
検証では5秒以内のレンダリング完了率や、403ステータスコードによるスクリプト読み込み失敗に注目する必要があります。
Screaming Frog SEO Spider
Screaming Frogを使用して大規模なクロールを行う際、レンダリングモードを「テキストのみ（Text Only）」から「JavaScript」に切り替えると、クローラーの挙動は単純なHTTPリクエストから完全なブラウザシミュレーションへと変化します。
ソフトウェアはバックグラウンドでHeadless Chromeインスタンスを起動し、ページ上のすべてのスクリプトファイルを解析します。
技術的な設定として、Configuration > Spider > RenderingメニューでJavaScriptオプションを明示的に選択する必要があります。
データ面での変化は顕著で、JavaScriptを実行するクロールプロセスにおけるメモリ（RAM）の需要は、通常5〜10倍に増加します。
例えば、複雑なReactやAngularで構築された10万ページをクロールする場合、ソフトウェアに少なくとも16GB〜32GBのメモリを割り当てることを推奨します。そうしないと、Chromeレンダリングプロセスがリソース不足でクラッシュする可能性があります。
クローラーは実行中にChromeのレンダリングエンジンバージョンを模倣し、取得されるDOM構造がGooglebotが現在使用している「Evergreen Chrome」と一致するようにします。
| 指標カテゴリ | 元のHTML (Source) | レンダリング後HTML (Rendered) | 推奨される差分しきい値 |
|---|---|---|---|
| 単語数 (Word Count) | 基礎フレームとメタデータのみ | 非同期読み込みテキストを含む | 差分 > 15% の場合は目視確認が必要 |
| 内部リンク数 | 0 またはごく少数のプレースホルダ | 動的生成されたナビ・製品リンク | 差分 > 0 はクロールリスクの存在を示唆 |
| Canonicalタグ | 欠落またはデフォルト値 | JS修正後の最終バージョン | 必ずレンダリング後を基準とする |
| ページサイズ | 通常 < 50 KB | 500 KB – 2 MB に増加することがある | 過大すぎるとGoogleにより切り捨てられる恐れ |
ソフトウェアがスクリプトを実行する際、AJAX Timeout（非同期読み込みタイムアウト）のデフォルト設定は通常5秒であり、これはGooglebotの挙動に似ています。
ページのデータAPIのレスポンスが遅く、コンテンツが5秒後になって初めてDOMに充填される場合、Screaming Frogが取得する結果は「空の殻」のページになります。
Word Count列のデータを比較することで、この現象を定量化できます：
レンダリング後の単語数がソースコードの単語数よりも少なくなっている場合、あるいは両者が完全に一致しているが実際にはページに大量のテキストがある場合は、通常、レンダリングスクリプトが規定時間内に完了しなかったことを示しています。
ECサイトのテストにおいて、製品リストが無限スクロールで読み込まれる場合は、クローラーの「Window Size」設定やスクロール動作のシミュレーションを構成することでスクリプト実行を誘発し、本来隠れている商品情報を取得することが可能です。
大規模サイトのテクニカル監査では、「Bulk Export」機能内の「JavaScript Rendering Table」を利用して、全サイトのレンダリング差分レポートをエクスポートできます。
このレポートには、各URLにおけるレンダリング前後のTitle、Meta Description、H1タグの変化が一行ずつリストアップされます。
実際のケースで、レンダリング後のH1タグが「Loading…」や「Undefined」になっていることが判明した場合、それは検索エンジンが最終的なコンテンツではなく中間状態のコードを取得している証拠となります。
ソフトウェアの「Resource」タブには、各スクリプトファイル（.js）およびスタイルシート（.css）のHTTPステータスコードが記録されます。
一部の機能スクリプトが403 Forbiddenを返している場合、通常はサーバーのファイアウォール（WAF）がクローラーのHeadless Chromeの挙動を悪意のある攻撃と誤認してブロックしていることが原因であり、ページ全体のレイアウトやコンテンツが正常に表示されない結果を招きます。
| レンダリングリソースの状態 | 発生原因 | クロールへの影響 |
|---|---|---|
| Blocked by robots.txt | スクリプトパスが非許可設定 | Googlebotがスクリプトを読めずレンダリング失敗 |
| Status Code: 429 | リクエスト頻度超過による制限 | リソースの一部が読み込まれずコンテンツ欠落 |
| Status Code: 404 | スクリプトファイルのパスが無効 | 当該スクリプトに依存するコンポーネントが表示不可 |
| Timeout (Exceeded 5s) | API遅延またはスクリプトが複雑 | 取得HTMLが空、またはエラーメッセージを含む |
ソフトウェアが提供する「Rendered Page」ビューでは、元のコードスナップショットとレンダリング後のビジュアルスナップショットを並べて比較できます。
これにより、JavaScriptによって隠されているコンテンツ（例えば、クリック後に表示されるタブ内のテキストなど）を直感的に発見できます。
ページのテキスト内容のうち、初期HTMLに含まれる割合が20%未満で、80%がレンダリング依存である場合、そのページのGoogleインデックスにおける安定性は課題に直面することになります。
Screaming FrogはConsole Errors（コンソールエラー）も捕捉できます。読み込み中に致命的なJavaScript構文エラーが発生した場合、レポート内でハイライト表示されます。
数十万件のURLを処理する場合は、「Store Images」と「Store Rendered HTML」オプションを有効にすることを推奨します。これにより、クロール終了後にいつでも任意のページのレンダリングスナップショットを呼び出すことができます。
「Link Discovery」の差分を分析することで、スクリプトを実行しなければ発見できなかった内部リンクの割合を算出できます。
この割合が30%を超えている場合、サイトのクロール深度（Crawl Depth）はスクリプト実行の遅延によって制御不能になる可能性があります。
Lumar (DeepCrawl)
Lumarは分散型クラウドコンピューティングを採用しており、数百万のURLを持つ大規模サイト向けに自動スキャンを提供しています。
JavaScriptの実行が必要なタスクでは、バックグラウンドで数千のブラウザインスタンスを介して動作します。
一般的なローカルツールは物理メモリに制限されますが（例：32GBメモリのPCでは通常20〜50の並列スレッドが限界）、Lumarはクラウド上で動作するため、タスク規模に応じて500以上のスレッドまで自動拡張し、24時間以内に100万ページの完全なレンダリングクロールを完了させることができます。
ページのスクリプト実行が5000ミリ秒（5秒）を超えると、システムはそのURLを「高コストページ」としてマークします。実際のGooglebotのアクセスにおいて、単一のリソースに長く待機しすぎないため、インデックス内でコンテンツが空白になる原因となるからです。
標準的なReactやVueプロジェクトでは、初期HTMLは2KB〜5KBの基礎コードのみですが、レンダリング後のDOMツリーは300KB〜800KBまで膨張することがあります。
このような100倍以上のバイト数増加は、そのページがスクリプトに高度に依存していることを示しています。
Lumarが提供する指標にはDOMノード総数（DOM Node Count）が含まれます。ノード数がGoogleの推奨する1500個を超えると、レンダリング効率が著しく低下します。
クラウド上でTime to Interactive（操作可能時間）やTotal Blocking Time（合計ブロック時間）を記録することで、どのJSファイル（例：500KBを超える単一のvendor.jsなど）がコンテンツ表示を妨げているかを特定できます。
大規模なECサイトやグローバルサイトでは、異なる地域のサーバーノードからリクエストを発行することで、レンダリング用スクリプトがCDNの設定ミスによって特定の地域で読み込めていないかどうかをチェックできます。
データレポートには、4xxおよび5xxステータスコードのスクリプトリソース比率が記載されます。
ページ内のスクリプトの20%が403エラーを返している場合（通常はrobots.txtのブロックやファイアウォールによるもの）、そのページのレンダリング結果は不完全なものになります。
Lumarのレポートシステムは「レンダリング差分マップ」を生成し、JavaScriptの有効・無効時における内部リンク数の変化を詳細に表示します。
スクリプトをオフにした際にリンク数が200個から0個に減少する場合、そのサイトのリンク構造が完全に動的実行に依存していることを意味し、Googlebotが新ページを発見する速度に悪影響を与えます。
また、このプラットフォームは取得したレンダリングデータをGoogle Search ConsoleのAPIと統合することも可能です。
データ上でレンダリング後の単語数が300%増加しているにもかかわらず検索トラフィックが向上していない場合、動的に挿入されたコンテンツがGoogleによって有効に認識されていない可能性があります。
LumarはRendered Page Word Count指標を出力し、それをSource HTML Word Countと比較します。
比率の差（Ratio Gap）が大きいページほど、クロール頻度が不安定になる傾向があります。50万サンプル以上の観察によると、Rendering Gapが80%を超える場合、ページのインデックス遅延は通常3〜7日間増加します。
