言語

レンダリング

GoogleのWebレンダリングサービスが、インデックスするページを構築するためにJavaScriptを実行する仕組みと、レンダリングオプション（CSR、SSR、SSG、ハイドレーション、ISR、エッジ、動的）とそのSEO上のトレードオフについて解説します。

初回公開：2026年6月23日 · 最終更新：2026年8月20日 · Advanced
言語
AI執筆者：AI v2
このページには証拠シグナルが1件あります

レンダリングとは、GoogleがインデックスするDOMを構築するために、常緑のヘッドレスChrome（Webレンダリングサービス）でJavaScriptを実行するステップです。これは基本的にすべてのページで発生し、通常は数秒から数分以内に行われるため、古い「2段階のインデックス」モデルはほぼ時代遅れであり、ページごとのレンダリング予算はありません。レンダラーはステートレスで、ページと対話せず、ハードにキャッシュします。レンダリングオプションによってSEOリスクが決まります。SSR、静的/プリレンダリング、ハイドレーションは安全です。完全なクライアントサイドレンダリングはリスクが高く、動的レンダリングは回避策です。

TL;DR — Google は、エバーグリーンでヘッドレスの Chromium（Web Rendering Service）で JS をレンダリングし、インデックスする DOM を構築します。これは基本的にすべてのページで発生し、通常は数秒から数分以内に行われるため、“2 段階インデックス”はほぼ時代遅れであり、ページごとのレンダリング予算はありません。WRS はステートレスで、権限プロンプトを拒否し、ページと対話せず、積極的にキャッシュします。レンダリングオプションが SEO リスクを決定します：SSR / 静的 / プリレンダリング / ハイドレーションは低リスク、完全な CSR はリスクが高く、動的レンダリングは Google が推奨しない回避策です。これによって生じる実践的な JS の問題については、JavaScript SEO を参照してください。

レンダリングの位置づけ

Googleは、JavaScriptアプリが3つのフェーズを経ることを明確に述べています：「Googleは JavaScriptウェブアプリを3つの主要なフェーズで処理します：1. クロール 2. レンダリング 3. インデックス。」 Evidence for this claim Google documents crawling, rendering, and indexing as the three main phases for processing JavaScript web apps. Scope: Google Search processing of JavaScript web applications; the phases can overlap operationally. Confidence: high · Verified: Google Search Central: Understand the JavaScript SEO basics レンダリングは橋渡しです。クロールは生のHTMLを取得し、レンダリングはJavaScriptを実行して 完成したDOMを構築し、インデックスはそのレンダリングされたDOMを読み取り、レンダラーが見つけた新しいリンクは クロールにフィードバックされます。Googleの言葉を借りれば：「クロール中、 Googleはページをレンダリングし、見つけたJavaScriptを最新バージョンの Chromeで実行します。これは、ブラウザが訪問したページをレンダリングする方法と似ています。」

Rendering is the bridge between fetching a URL and indexing its finished DOM; parity, interaction, state, and timing can break that bridge. 出典： JavaScript SEO

Google crawls a URL, renders its JavaScript to build the DOM, and indexes the result. Four practical failure modes branch from rendering: parity when the rendered DOM differs from expectations, interaction when content requires a scroll or click, state when content relies on cleared cookies or storage, and timing when content is deferred behind slow JavaScript.

© Patrick Stox LLC · CC BY 4.0 ·

Webレンダリングサービス

Googleは**Webレンダリングサービス（WRS）**でレンダリングします。これはヘッドレスChromeで、 エバーグリーンです：「Google検索はエバーグリーン版のChromiumでJavaScriptを実行します…」 現在のChromeに追従しているため、最新のJavaScriptおよびCSS機能が動作します。

問題は、WRSが特殊なブラウザであり、その癖が実際の問題のほとんどを引き起こすことです：

  • ステートレスです。 私がJavaScript SEOガイド で述べたように、 「Googleは各ページを新しい読み込みのようにステートレスで読み込みます。」 Googleのドキュメントはその構成要素を明確にしています：「ローカルストレージとセッションストレージのデータはページ読み込み間でクリアされます」 および*「HTTP Cookieはページ読み込み間でクリアされます。」* コンテンツを提供するためにクライアント側で永続化されたものに依存しないでください。
  • 権限を拒否します。 「Googlebotがユーザー権限リクエストを拒否することを期待してください。」 地理位置情報、通知、またはカメラのプロンプトの背後にあるコンテンツはレンダリングされません。
  • 操作しません。 スクロール、クリック、ホバーはありません。そのため、これらのイベントのいずれかでのみ読み込まれるコンテンツは、デフォルトでは見えません。（これは、ほとんどの遅延読み込みおよび無限スクロールのバグの根本原因です。修正はJavaScript SEOページにあります。）
  • 積極的にキャッシュします。 「Googlebotはネットワークリクエストとリソース使用量を減らすために積極的にキャッシュします。WRSはキャッシュヘッダーを無視する場合があります。」 つまり、Googleは古いバージョンのJSまたはCSSを実行する可能性があります。ファイルフィンガープリンティングで修正します。ファイル名をバージョン管理し（app.4f2a9c.js）、コンテンツの変更が新しいフェッチを強制するようにします。

2026年の実験：5秒は厳格な実行の壁ではない

2026年7月に報告されたサードパーティのWRS実験では、5秒のタイムアウトを想定するのではなく、遅延したJavaScriptとネットワークアクティビティをテストしました。観察されたレンダラーは仮想クロックを使用し、実時間で約6〜12秒かかる遅延リクエストを完了しました。有用な結果は狭いものです：正確に5秒後に発生するものはすべてGoogleに自動的に見えないという一般的な監査ルールに矛盾します。すべての遅延依存関係が完了すること、Googleが無期限に待つこと、または遅いクライアント側配信が安全であることを証明するものではありません。

Googleの公式声明（レンダーキューのタイミングに公開された固定遅延はない）とともに、実験とその方法論 をサードパーティの証拠として読んでください。実際には、最終的なDOMと要求されたリソースをテストしてください。APIレスポンスの欠落、操作要件、ブロックされたスクリプト、または状態依存性は、ストップウォッチベースの「5秒ルール」が適用されない場合でも、実際のレンダリング失敗のままです。

「2波のインデックス」はまだ存在するのか？

長年、メンタルモデルは**「2波のインデックス」**でした：Googleは最初に生のHTMLをインデックスし、その後数日または数週間後に戻ってきてJavaScriptコンテンツをレンダリングしてインデックスするというものです。そのモデルは現在、ほぼ時代遅れです。Martin Splittは、2波のアイデアはますます役割を果たさなくなっており、多くのページがJavaScriptに依存していなくてもレンダーフェーズを通過し、クロール、レンダリング、インデックスは時間とともに収束していると述べています。

実際には、レンダリングはほぼすべてのページで行われ、通常は高速です。 Googleの現在のドキュメントには、“The page may stay on this queue for a few seconds, but it can take longer than that.” (翻訳) 「ページはこのキューに数秒間留まる場合がありますが、それ以上かかることもあります」とあります。公開されている固定の遅延やタイムアウトはありません。 Evidence for this claim Google says a crawled page may stay on the rendering queue for a few seconds, but it can take longer than that. Scope: Google's rendering queue for a page that returns a 200 status and is eligible for rendering. The source gives a variable duration, not a fixed timeout or service-level guarantee. Confidence: high · Verified: Google Search Central: rendering-queue duration Supports: A page may remain on the rendering queue for a few seconds or longer. 歴史的なデータポイントとして、Googleのスタッフ（Martin Splitt氏とTom Greenaway氏）はかつて、中央値で約5秒、90パーセンタイルで数分と述べています — 古い懸念が示唆していた「数週間」ではありません。私はその数値をJavaScript SEOガイド で引用していますが、現在の公開メトリクスではなく、日付のあるカンファレンスのデータポイントとして扱ってください — Googleはそれを継続的な数値として再公開しておらず、上記のキュータイミングの引用が現在の公式な枠組みです。

そして、人々が想像するようなレンダリング予算はありません。Googleは、節約する必要のあるページごとの「レンダリングにどれだけコストがかかったか」というスコアを追跡していません。レンダリングはGoogleのスケールでは安価です — 幻のレンダリング予算ではなく、ユーザーとパフォーマンスのために最適化してください。

レンダリングのオプション

「HTMLはどこで構築されるのか？」という質問が、SEOリスクを左右します。完全なメニューは次のとおりです：

The useful distinction is where initial HTML is produced and what work remains for the browser. 出典： Rendering

Static generation produces HTML at build time. Server-side rendering produces it per request. Client-side rendering relies on browser JavaScript. Hydration attaches client behavior to server or static HTML. Dynamic rendering varies output by requester and is treated as a workaround.

© Patrick Stox LLC · CC BY 4.0 ·

  • クライアントサイドレンダリング（CSR）。 サーバーはほぼ空のシェルを送信し、ブラウザ（またはWRS）がJavaScriptを実行してすべてを構築します。これは*「最も問題のあるもの…すべてのレンダリングがブラウザで行われる完全なクライアントサイドレンダリング」*です。機能する可能性はありますが、レンダリングの成功にすべてを賭けており、インデックスされるまで最も遅い方法です。
  • サーバーサイドレンダリング（SSR）。 サーバーは各リクエストに対して完全なHTMLを構築します。コンテンツは生のHTMLにあるため、検索にとってリスクが低いです。
  • 静的サイト生成（SSG）/プリレンダリング。 HTMLはデプロイ時に一度構築されます。最もリスクが低い — コンテンツは生のHTMLにあり、かつ高速です。
  • ハイドレーション（アイソモーフィック/ユニバーサル）。 最初のペイントをSSRまたはSSGで行い、その後ブラウザでJavaScriptが「ハイドレーション」してインタラクティブ性を追加します。これはほとんどの最新フレームワークが行う方法で、コンテンツにとってリスクは低いです — コンテンツを空白にしたり置き換えたりするハイドレーションの不一致に注意してください。
  • インクリメンタル静的再生成（ISR）。 スケジュールまたはオンデマンドで再生成される静的ページ。SSGと同様ですが、コンテンツがより新しい — 大規模なカタログに適しています。
  • エッジレンダリング。 CDNエッジノードで実行されるSSR — SSRと同じ低リスクで、グローバルなオーディエンスに対してより高速な初回バイトまでの時間を実現します。
  • ストリーミングSSR。 HTMLは準備ができ次第、チャンク単位でブラウザにストリーミングされます。低リスクですが、インデックス可能なコンテンツが遅延または後回しにされたチャンクにのみ閉じ込められていないことを確認してください。

私のJavaScript SEOガイド からの結論：「あらゆる種類のSSR、静的レンダリング、プリレンダリングの設定は、検索エンジンにとって問題ありません。Gatsby、Next、Nuxtなどはすべて素晴らしいです。」 フレームワークよりも、提供するレンダリングモードの方が重要です — 同じNext.jsアプリでも、SSR/SSGを提供するか完全なCSRを提供するかによって、安全かリスクがあるかが決まります。

動的レンダリング — 回避策であり、戦略ではない

動的レンダリングとは、ボットを検出して、彼らにプリレンダリングされたJavaScriptなしのバージョンを提供し、ユーザーにはクライアントサイドバージョンを提供することを意味します。Googleは現在、それについて率直です：「動的レンダリングは回避策であり、検索エンジンにおけるJavaScript生成コンテンツの問題に対する長期的な解決策ではありません」、そして*「動的レンダリングは回避策であり、追加の複雑さとリソース要件を生み出すため、推奨される解決策ではありません。」* Evidence for this claim Google describes dynamic rendering as a workaround and does not recommend it as a long-term solution. Scope: Google Search guidance for JavaScript-generated content; server-side rendering, static rendering, or hydration are the recommended alternatives. Confidence: high · Verified: Google Search Central: Dynamic rendering as a workaround 私も同意します。そして、私は常にそうしてきました — 正直に言うと、私はそれを推奨したことはなく、Googleも今それを推奨しないことを嬉しく思います。それはボットとユーザーに異なるコンテンツを提供することであり、クローキングに非常に近いものです。代わりにSSR、静的、またはハイドレーションを利用してください。

ひとつ注意点があります。Bingは今でも動的レンダリングを推奨しています。 Microsoftは*“bingbot is generally able to render JavaScript”* (翻訳) 「bingbotは通常JavaScriptをレンダリングできる」と述べていますが、それを大規模に行うのは難しいため、“we recommend dynamic rendering as a great alternative for websites relying heavily on JavaScript.” (翻訳) 「JavaScriptに大きく依存するウェブサイトには、ダイナミックレンダリングを優れた代替手段として推奨します」としています。実際的な結論としては、SSR/SSGは両方のエンジンを満足させ、この議論全体を回避できます。

これがあなたのコンテンツに意味すること

レンダリングは、GoogleがあなたのJavaScriptコンテンツを見るかどうかを決定します。しかし、見ることは仕事の半分にすぎません。ページがレンダリングされると、実際的な懸念は、実際の<a href>リンク、生のHTMLとレンダリングされたHTMLのフィールドごとのパリティ、robotsディレクティブのステージ順序、遅延コンテンツ、無限スクロール、ソフトエラーページです。これらはすべてJavaScript SEOページにあり、テストワークフロー（URL InspectionのレンダリングされたHTML、スクリーンショット、コンソール）もそこにあります。

これは検索パイプラインのレンダリング段階です。周囲の段階については、クロール（ページがどのように取得されるか）とインデックス（レンダリングされたページが次にどうなるか）を参照するか、全体の流れについては検索の仕組みハブを参照してください。

ここで覚えておく価値のある監査ルールが1つあります。レンダリングは状態であり、普遍的な勝者ではありません。 本文コンテンツとクロール可能なリンクについては、レンダリングされたDOMは、成功したJavaScriptが追加または削除したものを示します。タイトルと説明については、追加の入力を示しますが、Googleは他のソースからタイトルリンクやスニペットを生成する場合があります。robotsディレクティブについては、生のnoindexがレンダリングを防ぐ可能性があるため、JavaScriptによる削除は非対称です。正規化については、Googleは既存の値を変更するのではなく、1つのソースまたは1つのJavaScript設定値を使用することを推奨しています。また、JavaScriptはすでに受信したHTTPレスポンスステータスを変更できません。証拠ではこれらの列を分けておき、フィールド固有の動作についてはGoogleの現在のJavaScript SEOガイダンス を使用してください。

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.