【Google検索セントラル解説】JavaScriptで出す内容がGoogleに届かない原因の探し方と直し方｜ソフト404・URLの「#」・キャッシュ

2026年11月5日

自社サイトの一部が検索結果に出ない。表示は正常なのに、Googleには中身が見えていないかもしれない。

そんなときに最初に開くべき公式ページが「Fix Search-related JavaScript problems」（日本語版の題名は「検索関連の JavaScript の問題を解決する」）です。

この記事では、英語版の原文を読み、Googleが挙げている確認項目を順に整理します。英語版と日本語版の差、更新の経緯、中小企業のサイトでの確かめ方も加えました。

合同会社謙虚は、3つのドメインを並行して運用し、何を変えると数字が動くかを測り続けています。JavaScriptで中身を出しているサイトでは、「Googleに見えているか」を最初に確かめないと、その後の改善が空振りになるため、このページを読みます。

結論：3行で言うと

このページは原因の特定と修正のチェックリストです。入口は、Search Consoleの「URL検査」かリッチリザルトテストで、Googleが実際に見た姿を確かめることです
確認項目は9つあり、ソフト404、URLの「#」、保存データへの依存、キャッシュ、WebSocketなど、SPA（1枚のページ内で表示を切り替えるシングルページアプリ）で起きやすい落とし穴が中心です
公式の説明は「Googleに読ませる側の注意点」です。順位が上がると約束する内容ではありません

このページの基本情報

項目	内容
原題（英語）	Fix Search-related JavaScript problems
日本語版の題名	検索関連の JavaScript の問題を解決する
英語版の最終更新日	2025年12月18日
日本語版の最終更新日	2025年12月18日
位置（章）	クロールとインデックス登録の章の、JavaScript SEOの節
直近の主な更新	2025年8月28日に、JavaScriptで作るペイウォール（有料会員向けの表示制限）の節を追加

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

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

前提：Googlebotは「遠慮がちな訪問者」

Googlebotは、サイトを訪れる人の体験を損なわないよう、クロール（ページの巡回）を最優先に動くと書かれています。

Googlebotとその描画部分であるウェブレンダリングサービス（WRS）は、ページの中身に関係しないと判断した通信を取りに行かない場合があります。報告用やエラー用の通信がその例です。

そのため、サイトに入れた計測タグの記録だけでは、Googlebotの動きを完全には読めません。確認にはSearch Consoleの「クロールの統計情報」レポートを使うよう案内されています。

手順1：Googleが見た姿を確かめる

リッチリザルトテストまたはSearch ConsoleのURL検査で、Googleによるクロールと描画を確かめます。

読み込まれたリソース、JavaScriptコンソールの出力と例外、描画後のDOM（ページの部品構造）などが見られます。

あわせて、Googlebotを含む訪問者のJavaScriptエラーを集めて点検する方法も勧められています。ページには、エラーを記録するコード例が載っています。

解析エラー（構文の誤りで読み込み自体が失敗するもの）は、この方法では記録できないという注意書きつきです。

手順2：チェックリスト

原文の項目を、私の言葉で表にまとめました。

項目	Googleの説明の要点
ソフト404を防ぐ	SPAは存在しないページでも200を返しがちです。404を返すURLへ転送するか、noindexのrobotsメタタグを動的に足します
許可の要求を前提にしない	Googlebotはカメラなどの許可要求を拒否するものと考え、許可なしでも内容が読める作りにします
URLの「#」で内容を切り替えない	AJAXクロールの仕組みは2015年から廃止されています。内容の切り替えにはHistory APIを使うよう勧められています
保存データに頼らない	WRSはページごとに、ローカルストレージ、セッションストレージ、Cookieを消します
コンテンツのフィンガープリント	WRSはキャッシュの指示を無視することがあり、古いJS・CSSを使う恐れがあります。ファイル名に内容由来の文字列を入れて更新のたびに変えます
機能検出と代替手段	Googlebotが対応しない機能（例はWebGL）には、代替表示かサーバー側での事前描画を用意します
HTTPで取れる状態にする	GooglebotはHTTPでコンテンツを取得します。WebSocketsとWebRTCは未対応なので、HTTPの代替経路を用意します
ウェブコンポーネント	WRSはLight DOMとShadow DOMを平らにして扱います。想定どおりのHTMLが描画されるかを確かめます
JavaScriptのペイウォール	全文を送ってJavaScriptで隠す方式は、制限の方法として信頼できません。購読の確認後にだけ全文を渡すようにします

ソフト404の2つの直し方

原文には、存在しない商品などを開いたときの直し方が2つ載っています。1つは、404を返すURLへ移動させる方法です。

もう1つは、robotsメタタグのnoindexを動的に足す方法です。

SPAがエラー処理をクライアント側のJavaScriptで行うと、エラーページが200で返り、索引に入って検索結果に出る可能性がある、と説明されています。

最後の工程

項目を直したら、もう一度リッチリザルトテストかURL検査で試します。直っていれば、エラーの代わりに緑のチェックマークが出ます。

残るときは、検索セントラルのヘルプコミュニティで質問するよう案内されています。

英語版と日本語版の違い

確認した日付（2026年11月5日）時点で、両版の最終更新日はどちらも2025年12月18日でした。節の構成、チェックリストの項目、コード例に、内容の差は見つかりませんでした。

見た点	結果
項目数と順序	同じ
2025年8月追加のペイウォールの節	日本語版にもある
Googlebot、WRSの前置き	両版にある
言い回しの差	英語版の「リッチリザルトテストまたはURL検査ツール」の並びが、日本語版では「Search Consoleの」を頭につけた書き方になっています。実質は同じです

更新の経緯

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

2020年3月：JavaScriptのトラブルシューティング文書に関する更新が記載されています
2020年4月：キャッシュへのリンクはデバッグに信頼できないという注記が、JavaScriptのデバッグガイドにも加えられたと記載されています。現在のページには、この注記は見当たりませんでした
2020年8月21日：HTTP以外のネットワーク接続への対処の節が追加されたと記載されています
2024年2月6日：JavaScript関連のガイダンスを見直し、古い情報や不要な情報を削除したと記載されています
2025年8月28日：JavaScriptを使うペイウォールの考慮事項が追加されました

ここに挙げた以外の細かい改訂は、変更履歴からは確かめられませんでした。

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

言えること	言えないこと
GoogleはJavaScriptを実行する。ただし、クローラー向けに考慮する点と制限がある	「GoogleはJavaScriptを読めないので、JavaScriptは使わないほうがよい」
URL検査とリッチリザルトテストで、描画後の姿を確かめられる	「テストに通れば、検索結果に必ず出る」（このページはテストの合格と掲載を結びつけていません）
計測タグの記録は、Googlebotの動きの全体像を示さないことがある	「アクセス解析にGooglebotが映らないので、来ていない」
SPAの存在しないページは、200を返さないよう対策が要る	「ソフト404を直すと順位が上がる」（索引にエラーページが入る問題への対策です）
WebSocketとWebRTCは、Googlebotでは使えない	「サイトでWebSocketを使うと、検索から外れる」（HTTPの代替経路があればよい、という説明です）

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

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

1. まず、自社のサイトがJavaScript頼みかを知る

従業員数人から数十人の会社のサイトは、WordPressの通常のテーマなら、本文がサーバーから最初のHTMLで届く作りが多いはずです。その場合、このページの項目の大半は関係しません。

確かめるには、ブラウザでページを開き、右クリックの「ページのソースを表示」で本文の一部の文字を検索します。見つかれば、本文は最初のHTMLにあります。

AIクローラーを含めた同じ観点は、AIクローラーとJavaScriptの解説記事にまとめています。

この記事は公式ページの読み解き、そちらは確認の実務です。

2. 対象のURLでURL検査を実行する

Search ConsoleのURL検査で、確認したいURLを調べます。原文が挙げている、読み込まれたリソースや描画後のDOMの情報を見て、本文が含まれているかを確かめます。

見た目はそろっているのに、本文や料金表がHTMLに無ければ、JavaScript起因の疑いがあります。ここで確認することは、リッチリザルトテストの使い方とも共通します。

詳しい手順はリッチリザルトテストの使い方で解説しています。

3. 存在しないURLが404を返すか確かめる

ブラウザで、わざと存在しないURLを開きます。画面が「見つかりません」でも、本当のステータスは別の話です。

確かめる方法は、ブラウザの開発者ツールの「ネットワーク」で、最初のリクエストのステータスを見ることです。外部の制作会社が作ったSPAのサイトなら、ここを制作側に確認してください。

4. 制作会社に渡す質問を決めておく

JavaScriptで作ったサイトの場合は、次の4点を制作側に聞くと話が早く進みます。

URLの切り替えは「#」を使っていないか。History APIを使っているか
ログイン状態やCookieがなくても、公開ページの全文が表示されるか
JavaScriptとCSSのファイル名は、更新のたびに変わる仕組みか
存在しないURLで、404かnoindexの対応をしているか

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

2026年11月5日に、kenkyo.aiに対して次の確認をしました。ここで確かめたのは、公式ページの項目のうち、外から測れる範囲だけです。

確認	結果
存在しないURLのステータス（curlで取得）	404を返し、HTMLのrobotsメタタグはnoindexでした。ソフト404にはなっていません
robots.txtを取得	禁止は管理画面（wp-admin）だけで、JavaScriptやCSSのフォルダは禁止されていません
トップページの最初のHTMLを取得	script要素とstyle要素を除いても、1万字を超える本文が最初のHTMLに入っていました。JavaScriptを実行しなくても読めます
トップページ内のリンクを確認	内部リンク55件のうち、「#/」で始まる、URLの「#」で表示を切り替えるものは0件でした