JavaScriptサイトが検索に出ない原因｜描画の壁を越える

「画面には表示されているのに、検索結果には出てこない」「クロール済みなのに登録されていない、という表示が並んでいる」——制作を外に任せたサイトで起きやすい症状です。疑うべき先は記事の文章量やキーワードではありません。ページの本文が、あとから組み立てられる仕組みで差し込まれている可能性があります。この記事では、何が起きているのかと、自分で確かめる手順を整理します。

検索に出ないページの中で起きていること

Googleの処理は3つの段階に分かれています。まずクロールでURLを取得し、robots.txtの許可を確認してHTMLを読みます。次にレンダリングで、ヘッドレスのChromiumがJavaScriptを実行し、実行後のHTMLを作ります。最後にそのレンダリング済みHTMLをインデックスに登録します。

問題が起きるのは1段目と2段目のあいだです。クライアント側でページを組み立てる作り方では、最初に返されるHTMLが実質的に空で、本文も見出しも入っていません。1段目の時点でGoogleが受け取っているのは、器だけのHTMLです。この段階で拾えるのはhref属性に書かれたリンクくらいで、そこから先の中身は2段目を待つことになります。

Googleは、HTTP 200を返すページを原則すべてレンダリングのキューに入れます。つまりJavaScriptを使っているだけで対象外になるわけではありません。ただし、キューに入ってから実行が完了して初めて中身が読まれるため、実行が失敗すれば空のページとして評価されます。「サイトは動いているのに検索に出ない」という状態は、この失敗の結果として現れます。

もう一点、順序の性質として押さえておきたいのが、リンクの発見が1段目でも2段目でも起きることです。初期HTMLに書かれたリンクは早く発見され、JavaScript実行後に現れるリンクは遅れて発見されます。新しく公開したページへの導線が実行後にしか存在しないと、発見そのものが後ろにずれます。公開直後の記事が拾われにくいサイトでは、この時間差が効いていることがあります。

レンダリングは後回しで処理される

2段目がいつ処理されるのかは、長く不透明な部分でした。Googleは2019年のChrome Dev Summitで、クロールからレンダリング完了までの待ち時間は中央値で5秒、90パーセンタイルでも数分以内だと説明しています。数週間待たされるという以前の通説は、この時点で否定されました。

この数値から読み取るべきは「速いから安心」ではありません。速く処理されるからこそ、失敗した場合の原因が待ち時間ではなく実装側にあると切り分けられる、という意味です。公開から数週間経っても中身が認識されていないなら、それは順番待ちではなく、実行時のエラーやリソース取得の失敗を疑う段階です。

実務では、外部APIからのデータ取得に失敗したときに空の画面を返す作りが、そのまま検索側に伝わります。人が見るときは再読み込みすれば直りますが、クローラーは再訪までその空の状態を持ち続けます。読み込み失敗時に何を返すかの設計が、そのまま検索結果に反映されるという前提で作る必要があります。

Googleは読めてもAI検索は読めない

2026年に入って、この問題の性質が変わりました。判断する相手が増えたためです。Googleのクローラーはヘッドレスブラウザを使ってJavaScriptを実行しますが、AI検索側のクローラーは事情が違います。複数の調査で、GPTBotやClaudeBot、PerplexityBotといったクローラーはJavaScriptを実行せず、最初に返されたHTMLだけを読んで次に進むと報告されています。

ある調査では、GPTBotがJavaScriptファイル自体は一定割合で取得しているものの実行はしていないという観測結果が示されています。ファイルを取りに来ることと、それを動かして中身を組み立てることは別だという意味です。取得のログが残っているから読まれているはず、という推測は成立しません。

結果として起きるのが、Googleの検索結果には出るのにAIの回答には一切出てこない、という状態です。従来なら「Googleで順位が付いているなら実装は問題ない」と判断できましたが、その前提が崩れています。検索の入口が増えた分だけ、初期HTMLに中身があることの価値が上がったと考えるのが実務的です。

この観点は、社内で改修予算を通すときにも使えます。SEOの技術改修は成果が見えにくく後回しにされがちですが、AI検索での引用可否という説明を足せば、話が今の関心事につながります。「順位が上がるかもしれない」より「回答に載る条件を満たしていない」のほうが、判断する側に伝わります。

動的レンダリングは回避策に格下げされた

かつての定番だった対処が、動的レンダリングです。クローラーには事前に描画したHTMLを返し、人にはJavaScriptのページを返す仕組みで、数年前は推奨手段として紹介されていました。現在の公式ドキュメントでは、これは回避策（workaround）として説明されており、長期的な解決策としては位置づけられていません。

理由は運用の重さです。クローラーの判別、描画したHTMLの保存と更新、両者の内容が一致しているかの監視が常に必要になります。ずれが生じたとき、人が見る内容と検索が見る内容が違う状態になり、意図せずクローキングに近づくおそれがあります。

これから作るなら、サーバー側で描画してからHTMLを返す方式（SSR）か、あらかじめHTMLを生成しておく方式（SSG）が本線です。すでに動的レンダリングで動いているサイトを今日止める必要はありませんが、リニューアルや基盤の更新のタイミングで移行の計画に入れておくのが妥当な判断です。

30分でできる自己診断

改修を依頼する前に、自分の手元で状況を確認できます。専用ツールは不要で、ブラウザとSearch Consoleだけで足ります。次の3つを順に見てください。

• ブラウザでページのソースを表示し、本文の一節をそのまま検索する（見つからなければ初期HTMLに本文がない）
• Search ConsoleのURL検査でライブテストを実行し、レンダリング済みHTMLとスクリーンショットを確認する
• URL検査の「その他の情報」でページリソースの取得エラーを確認する（読み込めなかったファイルが並ぶ）
• ブラウザの設定でJavaScriptを無効にして同じページを開く（何も出なければクライアント側で組み立てている）
• 同じ手順を、記事ページ・サービスページ・一覧ページの3種類で試す（一部だけ問題があるケースが多い）

この確認で分かるのは、問題が全ページに及ぶのか一部なのかという範囲です。範囲が分かると、改修の規模と優先順位が決まります。一覧ページだけ空なら回遊とクロールの経路の問題、サービスページだけ空なら売上に直結する箇所の問題です。

以前は、Googleのキャッシュ表示を使って「Googleが見ている状態」を手軽に確認できました。この機能は2024年に廃止されており、現在の確認手段はSearch ConsoleのURL検査に集約されています。古い手順書にキャッシュ確認が残っている場合は、URL検査に置き換えてください。ライブテストなら、公開前や改修直後の状態もその場で確認できます。

なお、ソース表示で本文が見つからないこと自体は、即座に致命的とは限りません。Googleは2段目で読み取る可能性があります。ただし前述のとおりAI検索側では読まれないため、見つからない箇所は改修候補として記録しておく扱いにします。

描画方式の違いを一覧で押さえる

社内で議論するときに混乱しやすいのが、方式の呼び名です。技術側と話す前に、それぞれが何をどこで組み立てているのかを整理しておくと話が早くなります。

方式	初期HTMLの中身	Googleの見え方	AI検索クローラー	向くページ
クライアント側描画（CSR）	ほぼ空	2段目で読まれる（失敗リスクあり）	読まれない	ログイン後の管理画面
サーバー側描画（SSR）	本文入り	1段目で読まれる	読まれる	更新が頻繁なサービスページ
静的生成（SSG）	本文入り	1段目で読まれる	読まれる	記事・事例・料金など
動的レンダリング	相手により変わる	読まれるが監視が必要	設定次第	移行期の一時策

BtoBサイトの多くは、記事や事例、料金ページのように内容が頻繁に変わらないページが中心です。この構成なら静的生成でほぼ足り、複雑なSSRを入れる必要はありません。方式の選択は流行ではなく、更新頻度と内容の性質で決めます。

逆に、在庫や価格がリアルタイムで変わる部分だけをJavaScriptで差し替える構成は理にかなっています。全部を同じ方式で作る必要はなく、ページの役割ごとに分けるのが現実的な設計です。

リンクはaタグとhrefで書く

レンダリングが成功していても、リンクの書き方で経路が途切れることがあります。Googleがリンクとして辿るのは、href属性を持つaタグです。クリックでJavaScriptが動いて画面が切り替わる作りは、人には使えてもクローラーには次のURLが見えません。

よく起きるのは、一覧ページの「次のページへ」や絞り込みの結果です。ボタン要素やdivにクリック処理を付けただけの実装では、2ページ目以降が発見されません。100件の事例があるのに最初の10件しか検索に出ていないサイトは、まずここを確認します。

対処は単純で、遷移先のURLを持つaタグとして書き、その上でJavaScriptの挙動を足すことです。両立できる作りなので、hrefを省略している箇所を洗い出して直すだけで発見される範囲が変わります。

URLに#を使うと別ページとして扱われない

画面を切り替えるときにURLの#以降だけを変える作りがあります。この形式では、Googleは#以降を別のページとして扱いません。結果として、複数の画面が同じ1つのURLとして認識され、それぞれの内容が検索対象になりません。

公式に推奨されているのは、History APIを使って本来のパスを書き換える方法です。絞り込みや並べ替えの結果を共有・ブックマークできるかどうかが、そのまま検索側の見え方に対応します。人がURLをコピーして送れない画面は、検索にも載りません。

BtoBサイトで影響が大きいのは、製品の型番や業種で絞り込む一覧です。「製造業向け」「従業員100名以上」といった切り口ごとに独立したURLがあれば、それぞれが検索の入口になります。絞り込みの軸は、そのまま検索の入口の数になるという見方をすると、設計の優先度が変わります。

タイトルは差し込んでよいがcanonicalは触らない

JavaScriptでtitle要素やメタディスクリプションを設定するのは問題ありません。公式にも、ページごとに固有のタイトルと説明文を設定する方法として案内されています。画面ごとに内容が変わる作りでは、この処理が必須になります。

一方で、canonicalについては明確な制限があります。公式ドキュメントは、JavaScriptを使ってcanonicalのURLを指定したURLとは別のものに変更するべきではないと述べています。初期HTMLに書いたcanonicalを実行後に書き換える処理は、意図しない正規化を招きます。

実務では、複数のプラグインやタグマネージャが同じ要素を書き換えていて、最終的にどのURLが残るのか誰も把握していないケースがあります。URL検査のレンダリング済みHTMLで、canonicalの最終状態を確認するのが確実です。特にタグマネージャ経由で挿入している場合、管理画面のどこに設定があるか分からなくなりがちなので、設定場所も記録に残してください。

存在しないページがソフト404になる

クライアント側で組み立てるサイトでよく起きるのが、ソフト404です。存在しない商品IDにアクセスしても、サーバーはHTTP 200で器のHTMLを返し、画面上だけ「見つかりません」と表示する。この状態はGoogleから見ると、中身の薄いページが200で存在していることになります。

公式が示している対処は2つです。サーバー側の404ページへリダイレクトするか、JavaScriptでエラーページにnoindexのメタタグを追加することです。どちらも「エラー時は検索対象から外す」という意思をHTMLで示す処理です。

放置すると、廃止した商品ページや期限切れのイベントページが大量に残り、クロールの手間だけを消費します。削除や終了の処理は、画面表示だけでなくステータスコードまで含めて決めておく必要があります。終了したウェビナーの申込ページを毎回そのまま残しているサイトは、この状態になっている可能性が高い箇所です。

タブ・アコーディオン・無限スクロールの扱い

見えていないコンテンツがどう扱われるかは、実装によって変わります。判断の基準は「HTMLに入っているか」です。タブやアコーディオンの中身が、閉じた状態でもレンダリング済みHTMLに含まれているなら読まれます。CSSで隠れているだけなら問題ありません。

読まれないのは、クリックされて初めてサーバーに問い合わせて中身を取ってくる作りです。クローラーはタブをクリックしないため、その中身は存在しないものとして扱われます。FAQをアコーディオンで作るときは、この違いが露出の有無に直結します。

無限スクロールも同じ構図です。スクロールしないと次が読み込まれない一覧は、続きが発見されません。対処は、ページ番号付きのURLを併設し、そこから各ページに辿れる経路を残すことです。人にはスクロール、クローラーにはページ分割という二重の入口を用意します。

Web Componentsを使っている場合、Googleはshadow DOMとlight DOMをまとめて評価すると説明しています。ただし前提は、レンダリング済みHTMLに内容が現れていることです。ここでも確認手段はURL検査です。

robots.txtでJSとCSSを止めると詰む

見落としがちな失敗が、レンダリングに必要なファイルの遮断です。robots.txtでJavaScriptやCSSのディレクトリを拒否していると、2段目の実行に必要な部品が揃わず、描画が不完全なまま評価されます。

• JavaScript・CSS・API応答のパスをrobots.txtで拒否していないか確認する
• 画像やスクリプトを別ドメインやCDNに置いている場合、そちら側のrobots.txtも対象になる
• 検証環境のrobots.txtを本番へそのまま持ち込む事故が最も多い（Disallow: / が残る）
• URL検査のページリソース一覧で、取得できなかったファイルを確認する
• アクセス制限（IP制限・Basic認証）を掛けたままのディレクトリも同じ結果になる

この種の問題は、原因が分かれば数分で直ります。難しいのは、症状が「順位が上がらない」という曖昧な形で現れるため、原因として疑われないことです。技術的な調査の最初に確認する項目として固定しておくのが確実です。

切り分けの手順

実際に問題を追うときの順番を整理します。範囲の特定から始めて、最後に実装の話に入ると、無駄な改修を避けられます。

この順で進めると、実装に手を入れる前に7割の原因が特定できます。先に方式の議論を始めると、原因が別のところにあった場合に無駄な工数が発生します。

やってはいけない対処

焦って手を打つと、状況が悪化することがあります。避けるべき対処を挙げておきます。

• クローラー向けだけにテキストを別途HTMLへ埋め込む（人が見る内容と乖離すればクローキングの疑いを招く）
• 新規のサイトで動的レンダリングを採用する（公式が回避策と位置づけた方式をこれから増やす理由がない）
• 原因を特定しないままサイトマップの再送信を繰り返す（発見の問題ではなく描画の問題なら効果がない）
• canonicalをJavaScriptで書き換えて正規化を調整しようとする（公式に非推奨。意図しないURLに寄る）
• 「Googleは賢いから読める」で判断を止める（AI検索のクローラーは読まないという前提が抜ける）
• 表示速度の対策としてHTMLを削り、本文までJavaScript側へ移す（速度は上がっても中身が消える）

最後の項目は、善意の改善が裏目に出る典型です。速度指標を上げるためにHTMLを軽くする作業と、初期HTMLに本文を含める要件は、しばしば衝突します。速度と初期HTMLの中身は、どちらかを犠牲にする関係ではなく両立させる設計課題として扱ってください。

制作会社への依頼に書く項目

この領域は、発注側が技術用語で細かく指定するとかみ合わなくなります。方式名ではなく、満たしてほしい状態を書くほうが確実です。以下をそのまま要件に入れられます。

• 主要ページ（サービス・料金・事例・記事）の本文と見出しが、JavaScript実行前のHTMLに含まれていること
• 一覧ページのページ送りと絞り込みが、href付きのリンクとして辿れること
• 画面の切り替えでURLのパスが変わり、その状態を共有できること
• 存在しないURLはサーバー側で404を返すこと（画面表示だけの「見つかりません」にしない）
• レンダリングに必要なファイルをrobots.txtで拒否しないこと
• 納品前にSearch ConsoleのURL検査でレンダリング済みHTMLを確認し、結果を共有すること

最後の項目が重要です。確認の実施と共有まで要件に含めておくと、リニューアル後に検索流入が落ちる事故の多くを防げます。過去に大きく落ちたサイトは、公開前にこの1回の確認をしていないケースがほとんどです。

よくある質問

WordPressで作っていれば問題ないですか

基本的には問題になりにくい構成です。サーバー側でHTMLを生成して返すため、初期HTMLに本文が含まれます。ただし、一部のテーマやプラグインが記事一覧や関連記事をJavaScriptで後から差し込む場合があり、その部分だけ読まれないことがあります。確認手順は同じです。

ReactやVueで作ったサイトは避けるべきですか

避ける必要はありません。同じ技術のまま、サーバー側で描画する構成やあらかじめHTMLを生成する構成を選べます。問題になるのは技術の選択ではなく、初期HTMLを空にしたまま公開する運用です。

プリレンダリングのサービスを使えば解決しますか

短期的には効果があります。ただし、クローラーに返すHTMLと人が見る内容を一致させ続ける運用が必要です。移行期の一時策として使い、恒久的な構成としてはサーバー側描画か静的生成を目指すのが公式の方向性に沿います。

直したらどのくらいで検索結果に反映されますか

再クロールと再評価を待つ必要があるため、即日ではありません。重要なページはURL検査からインデックス登録をリクエストできますが、全ページには使えません。数週間の単位で、インデックス作成レポートの推移を見て判断します。

まとめ

ブラウザで見えていることと、検索やAIに読まれていることは別です。Googleはクロール・レンダリング・インデックスの3段階で処理し、JavaScriptの実行は2段目に置かれます。実行が失敗すれば、そのページは空のまま評価されます。加えて2026年時点では、AI検索側のクローラーがJavaScriptを実行しないため、初期HTMLに中身があるかどうかの重みが以前より増しています。まずはソース表示とURL検査で、自社の主要ページがどちらの状態にあるかを確かめてください。範囲が分かれば、改修は要件を書いて依頼するだけの作業になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。