【Google検索セントラル解説】ダイナミックレンダリングは「回避策」｜Googleが勧める3つの方法とクローキングの線引き

2026年11月5日

中野輝規

「ボット向けに別のHTMLを出す」という仕組みを、ダイナミックレンダリングと呼びます。JavaScriptで画面を組み立てるサイトで、一時期よく使われた方法です。

では、いまのGoogleはこれをどう位置づけているのでしょうか。

この記事では、Google検索セントラルの「Dynamic rendering as a workaround」を英語版の原文から読みます。Googleが何を勧め、何を勧めていないのか、クローキングとの線引きはどこかを整理しました。

合同会社謙虚は、3つのドメインを並行して運用し、何を変えると数字が動くかを測り続けています。このページは「最初のHTMLに本文が入っているか」を確かめる大切さを裏側から示しているため、読む価値があります。

結論：3行で言うと

Googleは、ダイナミックレンダリングを回避策と位置づけ、長期的な解決策から外しています。勧めているのは、サーバー側のレンダリング、静的なレンダリング、ハイドレーションです
ボットと利用者に同じ内容を出している限り、Googlebotはクローキングと見なさないと書かれています。まったく違う内容を出せば、クローキングと見なされる場合があります
多くの中小企業のサイトは、最初のHTMLに本文が入っているため、この仕組みを入れる場面がそもそも少ないはずです（この点だけは原文にない、私の読み取りです）。まずは自社の状況の確認から始めます

このページの基本情報

項目	内容
原題（英語）	Dynamic rendering as a workaround
日本語版の題名	回避策としてのダイナミックレンダリング
英語版の最終更新日	2025年12月10日
日本語版の最終更新日	2025年12月18日
位置（章）	クロールとインデックス登録の章の、JavaScript SEOの節
直近の主な更新	変更履歴では2024年2月6日（「非推奨の回避策」であることを明確にした）と2022年8月10日（推奨しない方法だと説明を改めた）

原文はこちらです。英語版と日本語版があります。

Googleがこのページで言っていること

冒頭：「回避策」であって「長期的な解決策」ではない

ページは、ダイナミックレンダリングを、JavaScriptで作られた内容が検索エンジンに届かない問題への回避策と位置づけています。長期的な解決策の席には、別の方法が座ります。

代わりに勧められているのは、サーバー側のレンダリング、静的なレンダリング、ハイドレーションの3つです。いずれも、ページの中身を先に組み立てて渡す考え方です。

ブラウザ上でJavaScriptが内容を足す方式は、クライアント側のレンダリングと呼ばれます。Google検索はその内容もHTMLの内容と合わせて見ています。

ただし、Google検索のJavaScript対応には制限があり、描画後のHTMLに内容が出ないページもあると書かれています。ほかの検索エンジンはJavaScriptを無視することがあり、その場合、JavaScriptで作った内容は欠けた状態になります。

仕組み：ボットだけに別のHTMLを渡す

ダイナミックレンダリングでは、サーバーが利用者のリクエストとボットのリクエストを見分けます。たとえば、ユーザーエージェント（アクセス元を名乗る文字列）で判別します。

JavaScriptに対応しないボットだと判断すると、リクエストはレンダリング用のサーバーへ回されます。そこで、JavaScriptなしで読める版、たとえば静的なHTMLを返します。

利用者や、問題のないボットには、ふだんどおりの表示を返します。全ページに入れることも、ページごとに入れることも選べます。

ページはこの方法を、推奨される解決策ではないとも書いています。仕組みが複雑になり、必要な資源も増えるためです。

対象になりうるサイト

回避策が想定したのは、変化が速く、検索に載せてよい公開コンテンツで、JavaScriptで作られているものです。もう1つは、見てほしいボットが対応していないJavaScriptの機能を使っているコンテンツです。

どのサイトも使う必要はなく、ダイナミックレンダリングより良い方法がある、とも書かれています。比較は、ページがリンクしている外部の解説「Rendering on the web」にあります。

クローキングとの線引き

Googlebotは通常、ダイナミックレンダリングをクローキングの扱いにしません。条件は、ボットに出す内容が利用者に出す内容と似ていることです。

設定の途中でエラーページが出ても、クローキングとは見なされず、ほかのエラーページと同じように扱われます。

一方で、利用者に猫のページ、ボットに犬のページを出すようなやり方は、クローキングと見なされる場合があります。

Googleのスパムに関する方針では、クローキングが、検索順位を操作して利用者を欺く意図で、利用者と検索エンジンに別の内容を見せる行為と説明されています。JavaScriptや画像のように検索エンジンが読み取りにくい技術を使うときは、クローキングにならない形で内容を届ける方法が案内されています。

英語版と日本語版の違い

確認した日付（2026年11月5日）時点の最終更新日は、英語版が2025年12月10日、日本語版が2025年12月18日でした。日本語版のほうが8日新しい並びでした。

節の構成と、書かれている内容は一致していました。差があったのは、冒頭の時制です。

箇所	英語版	日本語版
冒頭の文	「was a workaround」と過去形で、過去の回避策だったと読める	「回避策であり」と現在形で、いまの回避策と読める
対象サイトの節	「was a workaround for」と過去形	「回避策です」と現在形
推奨についての文	「is a workaround and not a recommended solution」	「推奨される解決策ではありません」

推奨しない、という立場は両版で同じです。違うのは「だった」と言うか「である」と言うかの調子だけです。

ここは時制の差で、意味の差と断定する根拠は弱い段階です。英語版も、仕組みの説明と推奨についての文では「is」と現在形を使っており、過去形と現在形が混ざっています。

Internet Archiveの2024年7月27日の保存版にも同じ混在があり、2022年9月21日の保存版では冒頭が「is a workaround」でした。

「推奨しない回避策」という立場は、どの版でも変わっていません。

更新の経緯

Googleの変更履歴（英語版）で、このページに関わる記載を確かめました。

2022年8月10日：推奨される解決策ではなく、ほかに手段がない場合の回避策だと説明を改めた（変更履歴の記載）。代わりにサーバー側のレンダリング、静的なレンダリング、ハイドレーションを勧めた
2024年2月6日：JavaScript関連の文書を見直し、ダイナミックレンダリングが非推奨の回避策であることを明確にした（「非推奨」は変更履歴の語で、ページ本文にこの語はありません）

Internet Archiveの保存版も開きました。2022年5月30日の保存版（ページの最終更新日は2022年4月21日）の見出しは「Implement dynamic rendering」（ダイナミックレンダリングを実装する）で、ボット向けの描画サーバーの設定例、確認手順、困ったときの対処が載っていました。

ダイナミックレンダリングを、回避策として勧める書き方でした。

2024年7月27日と2025年4月7日の保存版では、現在と同じ題と内容でした。節は3つだけで、実装手順は消えています。

2022年9月21日の保存版では、冒頭がすでに「長期的な解決策ではない回避策」となっていましたが、実装の節はまだ残っていました。それ以外の途中の変化は、変更履歴の記載以上のことは書けません。

このページから、言えること・言えないこと

言えること	言えないこと
Googleは、サーバー側のレンダリング、静的なレンダリング、ハイドレーションを勧めている	ダイナミックレンダリングを入れれば、検索順位が上がる（ページは順位に触れておらず、内容を届ける方法の話に限られています）
利用者とボットに似た内容を出している限り、Googlebotはクローキングと見なさない	ボットだけに別の内容を出しても構わない、という意味ではありません。まったく違う内容は、クローキングと見なされる場合があります
Google検索はクライアント側で作られた内容も見る。ただし制限があり、描画後のHTMLに出ないこともある	Google検索がJavaScriptを一切読めない、という説明ではありません
ほかの検索エンジンは、JavaScriptを無視することがある	どの検索エンジンがどうなのかは、このページには書かれていません

中小企業の視点で、どう受け取るか

ここからはGoogleの説明とは別の、私の読み取りです。

1. 自社が対象かどうかを、まず確かめる

WordPressで作ったサイトは、ふつうは本文が最初のHTMLに入っています。この場合、ダイナミックレンダリングを検討する場面はほとんどありません。

確かめ方は簡単です。ページを開き、右クリックから「ページのソースを表示」を選びます。

ページの本文にある語を検索して、見つかれば最初のHTMLに入っています。

2. 見つからないときは、描画後の姿を確かめる

ソースに本文の語が見つからず、画面には表示されるときは、JavaScriptで内容を作っている可能性があります。この場合は、Search ConsoleのURL検査で、Googleが見た描画後のHTMLを確かめます。

手順の詳細は、JavaScriptの表示漏れを調べる方法を解説した記事にまとめました。この記事は公式ページの解説、そちらは実務の手順という役割です。

3. すでにボット向けの仕組みが入っていないかを聞く

制作会社に作ってもらったサイトや、ホームページ作成サービスで作ったサイトでは、ボット向けに別のHTMLを返す機能が、気づかないうちに有効になっていることがあります。契約や設定の資料に「プリレンダリング」「ボット向け配信」といった語がないかを確かめます。

入っている場合は、利用者に見える内容とGoogleが見た内容が似ているかを、URL検査と見比べて点検します。

4. 作り直すときは、最初のHTMLに本文を入れる方式を選ぶ

サイトを作り直す、あるいはJavaScript中心の作りに変えるときは、依頼先に「サーバー側で組み立てるか、事前に生成するか」を尋ねます。ページの勧めに沿った選び方です。

JavaScriptの処理の流れや注意点は、JavaScript SEOの基本を解説した記事で整理しています。

弊社のサイトで確かめたこと

2026年11月5日に、kenkyo.aiの公開記事1本に対して、次の確認をしました。ボットに別の内容を出していないか、という観点です。

確認	結果
通常のブラウザを名乗って、curlで取得	200で返り、最初のHTMLにh2見出しと本文が入っていました
Googlebotのユーザーエージェント文字列を名乗って、curlで取得	200で返り、本文のテキストは上と一致しました