JavaScriptとSEOの話は、たいてい両極端に振れます。「JSを使うとインデックスされない」と言う人がいる一方で、「今のGooglebotは何でもレンダリングできるから気にしなくていい」と言う人もいる。
Googleの説明を追っていくと、答えはどちらでもありません。JavaScript自体は問題にならないが、壊れ方には備えておく必要がある。 これがレンダリング関連の回を通して一貫している立場です。
この記事では、公式ポッドキャスト「Search Off the Record」でレンダリングを扱った回から、Googlebotがページをどう見ているのかと、実装で踏みやすい落とし穴をまとめました。CSSと遅延読み込みの話も含みます。
この記事は「Search Off the Record 全54回まとめ」のクラスタ記事です。他のテーマは元記事から辿れます。
Googlebotはどうやってページを見ているのか
第77回（2024-07-11）は、GoogleのレンダリングチームのZoe Clifford氏がゲストの回で、この記事の中心になります。
HTMLなら、基本的にすべてレンダリングしている
レンダリングとは、ヘッドレスブラウザでページを読み込み、JavaScript実行後のユーザーが見る状態をインデックスすることです。
そしてこの処理は非常にコストが高いにもかかわらず、HTMLページであれば基本的にすべてレンダリングしていると説明されています。<span lang=”en”>”we just render all of them as long as their HTML”</span>（第77回、2024-07-11）。PDFなど他のコンテンツタイプは対象外です。
「レンダリングされないかもしれない」という前提で設計を考えている場合、まずここが違います。
Chromiumは常に最新に追従している
2019年以前は事情が違いました。Blink Platform APIを使った手動統合だったためChromiumの更新が遅れ、ES6のサポートなどで実際に問題が起きていたそうです。
現在は安定版Chromiumに継続的に追従しています。いわゆるevergreen Googlebotです。新しいブラウザ機能やAPIは基本的に自動で使えるようになり、既存機能が壊れることはテストで保証されているとされています。ただし新しい属性などは自動的には認識されない場合がある、という但し書きが付きます。
レンダリング環境の3つの癖
実装で引っかかりやすい特性が3つ挙げられています。
- ステートレス — セッションは毎回リセットされます
- Cookieは有効だが、同意バナーはクリックしない — バナーの裏にコンテンツを隠している場合、そこは見えていません
- requestIdleCallback() が発火しない — Googlebotは常にビジーなためです。現在は定期的に「idleを装う」ことで対応しているとのことですが、これに依存した実装は危険です
実際、requestIdleCallback() が発火されないためにページコンテンツが読み込まれなかったビデオサイトの事例が紹介されています。
JavaScriptは、それだけでは不利にならない
第94回（2025-06-26）で、この点はかなりはっきり言われています。<span lang=”en”>”JavaScript is fine. It’s okay. Yes, it is okay. Calm down.”</span>（第94回、2025-06-26）。
同じ回で否定されているのは、両方向の思い込みです。JavaScriptを使うと自動的にSEOに悪いという考えも誤りですし、AngularのようなGoogle製フレームワークを使えば自動的に有利になるという考えも誤りだ、と。
JavaScriptによるリダイレクトについても、第77回で明言されています。クロール時ではなくレンダリング時に発生する点以外は通常のリダイレクトと同様に扱われ、特別扱いはしていない、と。JSリダイレクトが不利になるという通説は否定されています。
構造化データをJavaScriptで実装することも問題ないとされています。ただし条件があって、数百のリソースを読み込むような複雑なページでは、クロールレートやHTTPエラーで一部のリソースを取得できない場合がある。エラー時にページが崩壊しないよう注意が必要だ、という補足が付きます。
つまり、JSを使うこと自体ではなく、JSが失敗したときにどうなるかが論点だということです。
動的レンダリングは、もう推奨されない
Googlebotのユーザーエージェントを判定して特別なHTMLを返す実装は、かつて解決策として広く紹介されていました。第77回では、これを「ユーザーエージェント・シェナニガンズ」と呼んで扱っています。
現在の立場は非推奨です。理由はランキングへの影響ではなく、長期的にサイトが変更された際に問題を起こしやすいという保守性の観点でした。UA判定の分岐は、時間が経つほどメンテナンスされなくなり、いつの間にか片方だけが壊れます。
関連して、GooglebotのユーザーエージェントをブロックしていたためにChrome DevToolsでのデバッグが困難になった、という事例も紹介されています。UAで挙動を変える実装は、デバッグそのものを難しくします。
注意: 第77回は収録から2年以上が経過しており、Chromiumのバージョン追従状況やレンダリング挙動の詳細は変更されている可能性があります。
CSRの本当のリスクは、壊れたときの姿
第60回（2023-05-30）で、クライアントサイドレンダリング（CSR）の欠点が扱われています。
指摘されているのは単純です。レンダリングに失敗すると、空のHTMLしか残らない。 インデックスに何も入りません。<span lang=”en”>”the fallback is empty HTML, right? And personally, I would not risk that”</span>（第60回、2023-05-30）という言い方がされています。
そしてこれはCSRに限った話ではなく、サーバーサイドでもフォールバックがなければ同じ問題が起きる、とされています。
第77回では、脆弱な実装の具体例が挙がっています。APIが429エラーを返した場合にページ全体が空白になったり、google.comへリダイレクトされたりするケースです。エラーハンドリングを書いていない実装は、負荷が高いときに空のページをGooglebotに見せることになります。
もう一つ、見落とされがちな点があります。GooglebotはHTML本体だけでなく、ページが読み込むAPIやリソースについてもrobots.txtを遵守します。 APIエンドポイントをrobots.txtでブロックしていると、コンテンツの取得に失敗して不完全なインデックスになる可能性があります。
なお、レンダリング失敗時に次回クロールまで更新の反映が遅れる可能性はありますが、失敗をトリガーにクロール頻度を調整しているわけではないとも説明されています（第60回）。
遅延読み込みの落とし穴
第98回（2025-08-21）は遅延読み込みを1本まるごと扱った回です。実装している人が多いわりに、確認方法まで知られていない領域だと思います。
ネイティブ実装なら、インデックスへの影響は小さい
数年前からブラウザネイティブの loading="lazy" 属性が使えるようになり、JavaScriptライブラリなしで実装できるようになりました。WordPressもFelix Arntz氏の貢献でデフォルト対応済みです。
ネイティブ実装であれば、インデックスへの影響は小さいとされています。
カスタムライブラリのほうが危ない
問題は data-src のようなカスタム属性を使うライブラリのほうです。実装にミスがあると、Googlebotが画像を正しく認識できずインデックスに影響します。
<span lang=”en”>”If you use a custom library, that doesn’t mean that you have a problem.”</span>（第98回、2025-08-21）——カスタムライブラリを使っていること自体が問題なのではなく、問題が起きる余地があるということです。
画像がGoogle画像検索に大規模に表れない場合、遅延読み込みの実装不備が原因かもしれない、という指摘は覚えておく価値があります。画像検索からの流入が想定より少ないサイトは、まずここを疑えます。
確認方法
Search ConsoleのURL検査ツールでレンダリング後のHTMLを確認し、遅延読み込みの対象が src 属性に反映されているかをチェックする。これが第98回で挙げられている確認手順です。
ヒーロー画像に付けてはいけない
ファーストビューのヒーロー画像に loading="lazy" を付けると、ブラウザのリソーススキャナーによる早期読み込みが阻害され、表示が遅れたりレイアウトがずれたりします。Core Web Vitals、特にLCPが悪化します。
これはGoogle自身もやらかしていて、developers.google.com/search が全画像をデフォルトで遅延読み込みしてしまい、ヒーロー画像にも影響していた事例が語られています。CMSが一括で付ける設定になっていると起きがちなので、ファーストビューだけは除外できているか確認してください。
装飾画像とコンテンツ画像の区別
アイコンなどの装飾的な画像はCSSで読み込むのが一般的で、これは遅延読み込みとは呼ばず、意味的にコンテンツの一部ではないため画像検索インデックスの対象にもなりにくい、とされています。この区別は次のCSSの話につながります。
注意: 第98回は収録から1年以上が経過しており、ネイティブloading属性やView Transitions APIなどブラウザ標準機能の状況は変化している可能性があります。
CSSでできること、できないこと
第96回（2025-07-24）は「CSSはSEOに影響するのか」という問いを技術的に検証した回です。
まず前提として、<span lang=”en”>”Google’s guidelines say you should make your CSS files crawlable.”</span>（第96回、2025-07-24）——CSSファイルはクロールできる状態にしておく必要があります。ここをブロックすると、レンダリング結果が実際の見た目と変わります。
そのうえで、影響しないものと、実は影響するものが整理されています。
影響しないもの
- クラス名のキーワード — クラス名はスタイル指定のための識別子であり、テキストコンテンツではありません。キーワードを入れても意味がありません
!important— CSSの詳細度を上書きする仕組みで、SEOとは無関係です
実は影響するもの
::before/::afterの疑似要素 — ここで追加したコンテンツはDOMに含まれず、Googleのレンダリングでも認識されません。装飾目的なら問題ありませんが、意味のあるコンテンツ（例としてハッシュタグの#記号が挙げられています）を疑似要素で追加すると、インデックス側から見えなくなります- CSS背景画像 — ニュース記事の説明写真のようにコンテンツの一部である画像をCSS背景で実装すると、DOM上に画像要素として存在しないため画像検索などに認識されません。コンテンツに関わる画像は
imgやpictureを使うべきで、純粋な装飾のみCSS背景でよい、という切り分けです - CSSで作った表組み — CSSだけでテーブルレイアウトを作り、そこに表形式データを入れると、行と列の関係が認識されません。通常の
table要素が持つ構造上の利点が得られない、ということです
デバッグ時に混乱する癖
100vh を使ったヒーロー画像は、URL検査ツールのレンダリングプレビューで画像だけが巨大に表示され、本文が見えなくなることがあります。ビューポート拡張による表示上の癖で、DOM上にはテキストが存在するためSEO的には問題ありません。
ただしデバッグ時に「本文が認識されていない」と誤解しやすいので、max-height などで制限しておくのが望ましいとされています。この癖を知らないと、存在しない問題を追いかけることになります。
HTMLの書き方は、どこまで影響するか
第105回（2026-02-26）は、ブラウザのHTMLパースとSEOの関係を扱った回です。ここで技術者向けの通説がまとめて否定されています。
順位には影響しないもの
HTMLの標準準拠度（validity） がランキングに直接影響するという通説は、明確に否定されました。<span lang=”en”>”you cannot give a ranking boost to validate HTML for example”</span>（第105回、2026-02-26）。
セマンティックマークアップ ——H1/H2の階層構造やarticle、section、navといった要素の適切な使用——も同様です。アクセシビリティやブラウザには有用だが、検索エンジンのランキングにはほとんど影響しない、とされています。
resource hints（DNS prefetch、preload、preconnect）も、ブラウザのユーザー体験向上には非常に有効だが、Googleのクローラーは同期的な取得を行わずキャッシュも利用するため、検索エンジンにとってはほとんど意味がない、と説明されています。
裏付けとして、第94回では上位200サイトのうちホームページに有効なHTMLを持つのは0.5%という調査結果が紹介されています。それでも上位に表示されているわけです。同じ回で、HTMLが壊れていると必ず深刻な悪影響が出るという考えは過度な誇張であり、テキストとして読める部分は多くの場合問題なく扱われる、とも説明されています。
それでも実害が出るケース
ただし「HTMLは何でもいい」という話ではありません。第105回で挙げられている実害のあるパターンがこれです。
head内に本来置くべきでない要素が入ると、ブラウザがheadを暗黙的に閉じてbodyを開始します。 scriptがiframeを注入するようなケースが例に挙がっています。その結果、後続のhreflangやlink要素がbody内に移動してしまい、検索エンジン側では無視されます。
hreflangを正しく書いたのに効いていない、というケースはこれが原因かもしれません。
関連して、body内のcanonicalは信用されない設計になっていると考えられる、という説明もあります。コメント欄などへの悪意あるインジェクションでcanonicalをハイジャックされるリスクがあるためです。
もう一つ、canonicalタグを初回HTML取得時とJavaScriptによる変更後で異なる値にしないこと。意図が不明確になって検索エンジンが混乱するため、可能な限り最初のHTMLに明示的に記述すべきとされています。
表示速度の位置づけ
ページ表示速度の改善については、ユーザー体験や直接的なコンバージョン・リテンションに寄与するが、ランキングへの直接効果ではなく二次的な効果である、と位置づけられています。速度改善をSEO施策として説明していると、根拠が弱くなるということです。
注意: 第105回はAMP Cacheの現状など、収録後に状況が動いている項目を含みます。
Googleが否定した、レンダリング関連の8つの通説
| 通説 | Googleの説明 | 出典 | 鮮度 |
|---|---|---|---|
| 動的レンダリング（UA判定でHTMLを切り替える）は有効な解決策 | 現在は推奨しない。長期的な保守問題を引き起こす | 第77回 2024-07-11 | 要確認 |
| JavaScriptによるリダイレクトは不利になる | 通常のリダイレクトと特別扱いされない | 第77回 2024-07-11 | 要確認 |
| JavaScriptは自動的にSEOに悪い／Google製フレームワークなら有利 | どちらも誤り | 第94回 2025-06-26 | 新しめ |
| HTMLが壊れていると必ず深刻な悪影響が出る | 過度な誇張。テキストとして読める部分は問題なく扱われる | 第94回 2025-06-26 | 新しめ |
| CSSのクラス名にキーワードを入れると効果がある | 効果はない | 第96回 2025-07-24 | 新しめ |
| HTMLの標準準拠度（validity）が順位に直接影響する | 明確に否定 | 第105回 2026-02-26 | 要確認 |
| セマンティックマークアップが順位に大きく影響する | 否定。アクセシビリティには有用だがランキングにはほとんど影響しない | 第105回 2026-02-26 | 要確認 |
| resource hintsがクロール・ランキングに有用 | 無関係。Googlebotは同期的取得を行わずキャッシュを利用する | 第105回 2026-02-26 | 要確認 |
日本のサイト運営者にとって
ここまでの内容で、日本のサイト運営者に関わりやすいものを挙げます。ただし、これらの回で日本語検索や日本市場に特化した言及があるわけではありません。国内でよくある構成に当てはめた場合の話です。
WordPressを使っている場合
第98回のとおり、WordPressは画像の遅延読み込みにデフォルト対応しています。便利な一方で、ファーストビューのヒーロー画像にも一律で適用されるとLCPが悪化します。テーマやプラグインの設定でファーストビューを除外できているか、一度確認する価値があります。
Cookie同意バナーを実装している場合
第77回で、レンダリング時にCookieは有効だが同意バナーはクリックしない、と説明されています。バナーを閉じるまでコンテンツが表示されない実装になっていると、Googlebotから見えているのはバナーだけ、という状態になり得ます。国内サイトでも同意管理ツールの導入が進んでいるので、確認しておきたいところです。
SPAやヘッドレスCMSで構築している場合
第60回のCSRの話がそのまま当てはまります。レンダリングが失敗したときに何が残るか。APIエンドポイントをrobots.txtでブロックしていないか。この2点は構成を決める段階で確認しておくべき項目です。
hreflangが効いていない場合
第105回のhead暗黙クローズの話を疑ってください。タグマネージャーや広告スクリプトをhead内に入れているサイトでは、起きる余地があります。
まとめ
レンダリング関連の回を通して見えるのは、論点が「JavaScriptを使うかどうか」から「失敗したときにどうなるか」へ移っているということでした。
Googlebotは基本的にすべてのHTMLページをレンダリングしますし、Chromiumは常に最新に追従しています。JSリダイレクトも構造化データのJS実装も、それ自体は問題になりません。
その代わり、壊れたときに空のHTMLしか残らない構成や、APIエラーでページが白紙になる実装、UA判定で分岐していて片方が放置される仕組みは、時間が経つほどリスクになります。動的レンダリングが非推奨になった理由も、ランキングではなく保守性でした。
CSSとHTMLについても同じ構造です。クラス名やvalidityは順位に効きませんが、疑似要素に意味のあるコンテンツを入れる、CSS背景でコンテンツ画像を出す、headが暗黙的に閉じてhreflangが無視される——このあたりは実際に見えなくなります。
効かないものを気にするのをやめて、見えなくなるパターンを潰す。 レンダリング周りの実務は、だいたいこれに集約されるのだと思います。
なお、この記事で「要確認」と付けた項目は、収録から時間が経っており状況が変わっている可能性があります。実装を決める前には developers.google.com の最新ドキュメントで裏を取ってください。
関連記事
- Search Off the Record 全54回まとめ — この記事の元になったピラー記事
- クロールの仕組みと誤解 — レンダリングの前の工程
- Search Consoleレポートの読み方 — URL検査ツールでの確認方法
- ページエクスペリエンス・Core Web Vitals — LCPとINPの詳細
コメント