「コンテンツのない状態でページがインデックスに登録されています」の原因と対処法
「コンテンツのない状態でページがインデックスに登録されています」とは、Googleがページ自体はインデックスしたものの、コンテンツを読み取れなかったことを示す警告ステータスです。
「インデックスされない」問題とは本質的に異なり、ページはインデックスに存在しているにもかかわらず、中身が空の状態で登録されているという特殊な問題になります。
2026年1月、GoogleのJohn Mueller氏はRedditでこのステータスについて回答し、「放置するとサイトのページがインデックスから落ち始める」と警告しました。原因の多くはサーバーやCDNがGooglebotへのコンテンツ配信をブロックしているケースであり、JavaScriptの問題ではないとも明言しています。
通常、これはサーバー/CDNがGoogleにコンテンツを配信するのをブロックしていることを意味します。JavaScriptとは関係ありません。通常はかなり低レベルのブロックで、GooglebotのIPアドレスに基づくこともあるため、Search Consoleのテストツール以外からテストするのはおそらく不可能です。
Strange Issue – Page Indexed without content
この記事では、以下の内容を解説します。
Google公式ヘルプの定義からJohn Mueller氏・Gary Illyes氏の公式発言まで、信頼できる情報源をもとに整理しました。 まずはステータスの正確な意味を把握するところから始めていきましょう。
インデックス状態の把握が大変という方は、SEOサイト管理自動化ツール「inSite（インサイト）」を試してみてください。
inSiteのインデックスチェック機能では、サイト内のページのクロール状態を毎日自動でチェックします。
どれだけのページがインデックスされてなくて原因は何なのか、クローラーは定期的に来ているのかといった情報を常に監視することができます。
1ページずつURL検査をしなければわからないインデックス状態。
inSiteを使えばこれを常に把握できるため、効率よくSEOにおける有効な打ち手を考えることができます。
ページのインデックス率向上や、ページの評価をアップさせるリライトの効率化にかなり使えると思うので、ぜひお試しください。
サーチコンソール「コンテンツのない状態でページがインデックスに登録されています」とは？
「コンテンツのない状態でページがインデックスに登録されています」とは、Googleがページをインデックスに登録したにもかかわらず、コンテンツを正常に読み取れなかった状態を示すステータスです。
Search Consoleの「ページのインデックス登録」レポートでは、「登録済み」かつ「警告あり」に分類されます。
Google Search Console ヘルプでは、次のように定義されています。
このページはGoogleのインデックスに登録されていますが、なんらかの理由でコンテンツを読み取れませんでした。ページがGoogleにクローキングされているか、Googleがインデックスに登録できない形式になっている可能性があります。この状態は、robots.txtによるブロックが原因ではありません。
Google Search Console ヘルプ
ポイントは「ページ自体はインデックスされている」という点です。エラーではなく警告に分類されているのも、インデックス登録そのものは完了しているためでしょう。
ここで注意したいのが、「コンテンツのない状態でインデックスに登録されている」問題と「インデックスされない」問題は、まったく別の現象だという点です。
| 比較項目 | コンテンツのない状態でインデックス登録 | インデックス未登録（クロール済み等） |
|---|---|---|
| インデックス状態 | 登録済み（警告あり） | 未登録 |
| 問題の本質 | コンテンツが空のまま登録されている | そもそもインデックスに登録されていない |
| 主な原因 | サーバー/CDNのブロック、リソースのブロック | コンテンツ品質、クロール予算など |
| 対処の方向性 | Googlebotへのコンテンツ配信を修正 | コンテンツ改善、内部リンク強化など |
「クロール済み – インデックス未登録」や「検出 – インデックス未登録」は、ページがインデックスに登録されなかった状態を指します。
一方、今回のステータスはインデックス登録自体は行われており、ただしコンテンツが空の状態で登録されてしまったという問題です。
原因も対処法もまるで異なるため、混同すると的外れな対応をしてしまいかねません。
「コンテンツのない状態でページがインデックスに登録されています」以外の各ステータスの全体像を把握したい場合は、インデックスカバレッジの全ステータスと対処法もあわせて確認してみてください。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
「コンテンツのない状態でページがインデックスに登録されています」が表示される3つの原因
「コンテンツのない状態でページがインデックスに登録されています」が表示される原因は大きく3つに分類されます。
それぞれ発生の仕組みと確認すべきポイントが異なるため、順に見ていきましょう。
サーバー・CDNによるGooglebotのブロック
「コンテンツのない状態でページがインデックスに登録されています」が発生する原因として最も多いのは、サーバーやCDNがGooglebotへのコンテンツ配信をブロックしているケースです。
2026年1月、John Mueller氏はRedditでこのステータスについて次のように回答しました。
通常、これはサーバー/CDNがGoogleにコンテンツを配信するのをブロックしていることを意味します。JavaScriptとは関係ありません。通常はかなり低レベルのブロックで、GooglebotのIPアドレスに基づくこともあるため、Search Consoleのテストツール以外からテストするのはおそらく不可能です。
Strange Issue – Page Indexed without content
CloudflareなどのCDNにはbot管理機能が搭載されており、この機能がGooglebotを不正なbotと誤判定してブロックしてしまうことがあります。IPアドレスベースの低レベルなブロックであるため、ブラウザで正常に表示されるかどうかを確認しただけでは問題を発見できません。
さらにMueller氏は、こう続けています。
これは本質的にサイトの配信側の問題であり、Google側でコントロールできるものではありません。
過剰なbot対策や、動作不良のCDN/ゲートウェイ/サーバーが原因の場合があります。
Strange Issue – Page Indexed without content
CDNのbot保護機能が進化するにつれて、意図せずGooglebotをブロックしてしまう事例は増加傾向にあります。
とりわけCloudflareを利用しているサイトでは、ファイアウォールルールやbot管理の設定を重点的にチェックすべきでしょう。
robots.txtによるリソースファイルのブロック
「コンテンツのない状態でページがインデックスに登録されています」が発生する2つ目の原因は、robots.txtによるリソースファイルのブロックです。
Google公式ヘルプには「robots.txtによるブロックが原因ではありません」と記載されていますが、Gary Illyes氏は2021年3月に次のように発言しています。
このエラーは本当にrobots.txtでブロックされているページのためのものです。
Search Engine Roundtable
一見矛盾しているように思えますが、実はこの2つの発言は矛盾していません。
公式ヘルプの「robots.txtによるブロックが原因ではない」とは、URL自体がrobots.txtでブロックされている状態を指しています。
一方、Gary Illyes氏の発言は、JavaScriptやCSSといったリソースファイルがrobots.txtでブロックされているケースを指しているのです。
具体的には、ページのURL自体はクロールを許可されているものの、そのページの表示に必要なJavaScriptファイルやCSSファイルがrobots.txtのDisallow指定でブロックされていると、Googlebotはページにアクセスできてもコンテンツを正しくレンダリングできません。
結果として、コンテンツが空の状態でインデックスされてしまうわけです。
この「URL単位のブロック」と「リソースファイル単位のブロック」の区別は、原因を正確に特定するうえで非常に大切なポイントとなります。
robots.txtを確認する際には、ページURLだけでなく、そのページが読み込むJS・CSSファイルのパスもDisallow対象に含まれていないかチェックしてください。
クローキングまたはGoogleが処理できない形式
「コンテンツのない状態でページがインデックスに登録されています」が発生する原因の3つ目は、クローキング（ユーザーと検索エンジンに異なるコンテンツを表示する行為）が意図せず発生しているケース、もしくはGooglebotが処理できないファイル形式を使用しているケースです。
Google公式ヘルプでも「ページがGoogleにクローキングされているか、Googleがインデックスに登録できない形式になっている可能性があります」と記載されています。
ページが Google にクローキングされているか、Google がインデックスに登録できない形式になっている可能性があります。
この状態は、robots.txt によるブロックが原因ではありません。
Google Search Console ヘルプ
意図的なクローキングはGoogleのスパムポリシーに明確に違反しますが、実務ではそうと気づかないまま発生しているケースが少なくありません。
例えば、ユーザーエージェントに応じてコンテンツの出し分けをしている場合に、Googlebotに対して空のレスポンスを返してしまっている可能性があります。
とはいえ、John Mueller氏の最新の発言を踏まえると、このステータスの原因としてはサーバー/CDNレベルのブロックが圧倒的に多く、クローキングや処理不能な形式が原因となるケースは相対的に少ないようです。
「JavaScriptの問題ではない」とMueller氏が明言している点からも、JSレンダリングの失敗を真っ先に疑う必要はないと言えるでしょう。
ただし、JSレンダリングの失敗の可能性がゼロとは断定できません。
Onely社が推奨する診断方法として、Chrome DevToolsのNetwork条件でUser Agentを「Googlebot Smartphone」に変更してページを表示し、通常のブラウザ表示と比較する方法があります。
表示内容に差異があれば、意図しないクローキングが発生している可能性が高いと判断できます。
出典：How To Fix “Page indexed without content” in Google Search Console
3つの原因パターンをまとめると、まずサーバー/CDNの設定を疑い、次にrobots.txtによるリソースブロックを確認し、最後にクローキングや特殊な形式の問題を検討するという優先順位で調査を進めるのが効率的です。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
対処が必要なケースと放置NGの判断基準
「コンテンツのない状態でページがインデックスに登録されています」が発生した場合は、すべてのケースで緊急対応が必要なわけではありません。
ただし、放置してよいケースは限られており、判断を誤ると検索パフォーマンスに深刻な影響が出る可能性があります。
対処が必要なケースは、以下の2パターンです。
▼対応が必要なケース
1つ目は、重要なページがこのステータスに該当している場合です。
トップページ、主要サービスページ、コンバージョン導線上のページなど、ビジネスに直結するページが影響を受けていれば、早急に原因を特定して修正する必要があります。 John Mueller氏が言及した事例では、ホームページの検索順位が1位から15位に下落したケースが報告されています。
2つ目は、このステータスに該当するページ数が急増している場合です。
短期間でページ数が増加しているなら、サーバーやCDNの設定変更、あるいはbot対策の強化がGooglebotに影響を与えている可能性が高いと言えます。
サイト全体に波及するリスクがあるため、すぐに調査に着手すべきでしょう。
ちなみに、John Mueller氏は次のように明言しています。
これはサイトのページがインデックスから落ち始めることを意味するので（もうすぐ、または既に）、これを緊急の問題として扱うのが良いでしょう。
一方、ひとまず様子を見てOKなケースもあります。
▼すぐに対応しなくてもいいケース
開発中のページやテストページなど、意図的にコンテンツが存在しないページが該当している場合は、ステータス自体が正常なため、すぐに対応する必要はありません。
ただし、そうした不要なページがインデックスに残り続けるのは望ましくないため、noindex設定やページの削除を検討してください。
noindexの設定方法については、noindexタグによる除外の方法と注意点で詳しく解説しています。
該当ページが少数で、かつ重要なページに影響が出ていない場合も、すぐに対処しなくて問題ありません。
ですが、定期的にSearch Consoleで状況を確認し、ページ数が増えていないかをモニタリングしておくことをおすすめします。
現在のインデックス状況を把握するには、インデックスに登録されていないページ数の確認方法も参考になるでしょう。
判断に迷った場合は、「そのページが検索結果に表示されなくなったらビジネスに影響があるか」を基準に考えると、優先度を決めやすくなります。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
原因の特定方法と対処手順
「コンテンツのない状態でページがインデックスに登録されています」を解消するには、以下の3つのステップを順に進めるのが最も効率的です。
前半で解説した3つの原因パターンそれぞれに対応する形で、具体的な確認方法と修正手順を紹介します。
①URL検査ツールで状態を確認する
対処の第一歩は、Search ConsoleのURL検査ツールで該当ページの現在の状態を正確に把握することです。
URL検査ツールを開き、該当ページのURLを入力して検査を実行してください。
結果画面では「URL は Google に登録されています」と表示されつつ、「コンテンツのない状態でページがインデックスに登録されています」という警告が出ているはずです。
確認すべきポイントは3つあります。
1. ページのインデックス登録の詳細
「ページのインデックス登録」の中にある「クロール」と「インデックス作成」の情報を開き、「前回のクロール」の日時と「ページの取得」のステータスを確認しましょう。
「ページの取得」が「成功」以外になっていれば、サーバー側でGooglebotがブロックされている可能性が高いと判断できます。
2. クロール済みページの表示
「クロール済みのページを表示」をクリックすると、Googlebotが取得したHTMLやスクリーンショットを確認できます。
ただし、このステータスが出ているページでは、HTML・スクリーンショットとも「情報が利用できません」と表示される場合があります。 そうした表示になること自体が、Googlebotがコンテンツを取得できていない証拠となるわけです。
3. 公開URLのテスト
「公開URLをテスト」を実行すると、現時点でGooglebotがページをどう認識しているかをリアルタイムで確認できます。
ここで問題なくコンテンツが表示されれば、過去の一時的な障害だった可能性があります。 逆に依然としてコンテンツが取得できなければ、問題は継続中です。
URL検査ツールの詳しい使い方はGoogle Search Console ヘルプ: URL検査ツールを参照してください。
なお、影響を受けているページが大量にある場合、1つずつURL検査ツールで確認するのは現実的ではありません。 そうしたケースでは、Inspection APIを活用したインデックス状態を自動チェックするツールを使い、一括で状態を把握するのが効率的でしょう。
②サーバー・CDN設定を確認する
John Mueller氏が2026年1月に明言しているとおり、このステータスの最も多い原因はサーバーやCDNがGooglebotへのコンテンツ配信をブロックしていることです。
「通常、これはサーバー/CDNがGoogleにコンテンツを配信するのをブロックしていることを意味します。JavaScriptとは関係ありません。通常はかなり低レベルのブロックで、GooglebotのIPアドレスに基づくこともあるため、Search Consoleのテストツール以外からテストするのはおそらく不可能です。」
── John Mueller（Google Search Advocate）
確認手順を見ていきましょう。
CDNのbot管理設定を確認する
CloudflareをはじめとするCDNのbot管理機能やファイアウォールルールで、GooglebotのIPアドレスやUser Agentがブロック対象に含まれていないか確認してください。
とりわけCloudflareの「Bot Fight Mode」や「Super Bot Fight Mode」は、設定によってはGooglebotまでブロックしてしまうケースが報告されています。
GooglebotのIPアドレスをホワイトリストに追加する
Googleは公式にクローラーのIPアドレスリストを公開しています。
Google Developers: Googlebotの概要からIPリストを取得し、CDNやファイアウォールのホワイトリストに追加してください。
サーバーのアクセスログを確認する
サーバーのアクセスログでGooglebotからのリクエストを抽出し、レスポンスコードが200になっているかを確認してください。
403（Forbidden）や429（Too Many Requests）、503（Service Unavailable）が返されていれば、それがブロックの原因です。
修正後に再クロールをリクエストする
設定を修正したら、URL検査ツールの「インデックス登録をリクエスト」を実行して再クロールを促しましょう。
John Mueller氏が述べたとおり、この問題はSearch Consoleのテストツール以外からは再現が難しいため、修正後の確認もURL検査ツールの「公開URLをテスト」で行うのが確実です。
③robots.txtとリソースのブロック状況を確認する
robots.txtによるリソースファイルのブロックが原因の場合、URL自体はクロール可能でも、ページのレンダリングに必要なJavaScriptやCSSが取得できず、結果として「コンテンツなし」と判定されます。
確認と対処の流れは次のとおりです。
robots.txtの内容を確認する
サイトの /robots.txt を直接開いて、JavaScriptファイルやCSSファイルのパスがDisallowされていないかチェックしましょう。
例えば以下のような記述があると、レンダリングに必要なリソースがブロックされてしまいます。
# NG例
User-agent: *
Disallow: /wp-content/themes/
Disallow: /wp-includes/# OK例
User-agent: *
Disallow: /admin/
Allow: /wp-content/themes/
Allow: /wp-includes/Googlebot視点でページを表示確認する
Onely: Page indexed without contentの修正方法が推奨する診断方法として、Chrome DevToolsのNetwork条件でUser Agentを「Googlebot Smartphone」に変更してページを表示する方法があります。
通常のブラウザ表示と比較して、CSSが崩れていたりコンテンツが表示されなかったりすれば、リソースのブロックやクローキングの問題が発生している証拠です。
ブロックを解除してrobots.txtを更新する
レンダリングに必要なリソースのブロックが見つかったら、robots.txtのDisallowルールを修正してください。
修正後はrobots.txtの反映に時間がかかる場合があるため、Search Consoleの「設定」＞「robots.txt」からrobots.txtの再クロールをリクエストしておきましょう。
レンダリング結果を確認して再クロールを促す
URL検査ツールの「公開URLをテスト」で、修正後のレンダリング結果にコンテンツが正しく表示されることを確認しましょう。
問題が解消されていれば「インデックス登録をリクエスト」を実行してください。
影響を受けるページが多数ある場合は、Search Consoleの「修正を検証」機能を活用してください。 検証プロセスは通常2週間ほどで完了し、対象ページが順次再クロールされます。
以上の3ステップを順に進めれば、原因の特定から修正完了までを体系的に進められるはずです。
どのステップで問題が見つかるかによって原因パターンが切り分けられるため、闇雲に設定を変更するよりも効率よく解決に至れるでしょう。
関連するインデックスカバレッジステータスとの違い
Search Consoleの「ページのインデックス登録」レポートには、似たような名前のステータスが複数存在し、混同されがちです。
「コンテンツのない状態でページがインデックスに登録されています」と、よく混同される3つのステータスの違いを比較表で整理します。
| ステータス | 問題の本質 | 主要原因 | 対処の方向性 |
|---|---|---|---|
| コンテンツのない状態でページがインデックスに登録されています | インデックス済みだがコンテンツが空の状態で登録された | サーバー/CDNによるGooglebotブロック、robots.txtによるリソースブロック、クローキング | サーバー・CDN設定の修正、robots.txtの見直し |
| クロール済み – インデックス未登録 | クロールされたがインデックスに登録されなかった | コンテンツ品質の問題、重複コンテンツ、クロールバジェットの配分 | コンテンツの改善、内部リンク構造の最適化 |
| 検出 – インデックス未登録 | URLは検出されたがクロール自体が行われなかった | クロールバジェットの不足、サイト規模に対するクロール需要の超過 | サイト構造の整理、不要ページの削除、サイトマップの最適化 |
| ソフト404 | ページは存在するが実質的にコンテンツがないと判定された | 空のページ、検索結果0件ページ、エラーページに200を返す設定 | 該当ページの削除または適切なステータスコード（404/410）の返却 |
この表で押さえておくべき最大のポイントは、「コンテンツのない状態でインデックス」だけがインデックス登録済みのステータスだという点です。
他の3つはいずれもインデックスに登録されていない状態であり、問題の性質も対処法もまったく異なります。
なお、Onely社の分析によると、「コンテンツのない状態でページがインデックスに登録されています」が解消された後、そのページが「クロール済み – インデックス未登録」に移行するケースが確認されています。
これは、Googlebotがコンテンツを正常に取得できるようになった結果、今度はコンテンツの品質評価が行われ、インデックスに値しないと判断される場合があるためです。
ステータスが変わったからといって安心せず、移行先のステータスに応じた追加対応が必要になる点には注意してください。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
その他のインデックスステータス一覧
その他のインデックスステータスの一覧を以下の表にまとめました。他のエラーや除外が発生している方は参考にしてください。
▼インデックスステータス一覧表
| 大分類 | カテゴリ | ステータス名 | 対処の必要性 |
|---|---|---|---|
| 登録済み | – | ページはインデックスに登録済みです | 不要 |
| 警告あり | robots.txtによりブロックされましたが、インデックスに登録しました | 確認推奨 | |
| コンテンツのない状態でページがインデックスに登録されています | 確認推奨 | ||
| 未登録 | エラー | サーバーエラー（5xx） | 高い |
| リダイレクトエラー | 高い | ||
| 未承認のリクエスト（401）が原因でブロックされました | 高い | ||
| アクセス禁止（403）が原因でブロックされました | 高い | ||
| 見つかりませんでした（404） | 状況による | ||
| 他の 4xx の問題が原因で、URL がブロックされました | 高い | ||
| ソフト404 | 高い | ||
| ブロック | robots.txt によりブロックされています。 | 意図的なら不要 | |
| URL に noindex が指定されています | 意図的なら不要 | ||
| クロール・Google判断 | 検出 – インデックス未登録 | 中程度 | |
| クロール済み – インデックス未登録 | 高い | ||
| 重複・正規化 | 代替ページ（適切なcanonicalタグあり） | 不要 | |
| 重複しています。ユーザーにより、正規ページとして選択されていません | 確認推奨 | ||
| 重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました | 確認推奨 | ||
| ページにリダイレクトがあります | 不要 |
なお、全ステータスについて詳しく解説している「インデックスカバレッジとは？全ステータスの意味と対処法を解説」も参考にしてください。
また、インデックスに登録されないページ数を確認する方法は、「「インデックスに登録されていないページ数」の確認方法と対処法【放置OKなケースも解説】」を参考にしてください。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
まとめ
本記事の要点を整理します。
- 「コンテンツのない状態でページがインデックスに登録されています」は、ページ自体はインデックス済みだがGoogleがコンテンツを読み取れなかった状態を示す警告ステータス
- 「インデックスされない」問題とは本質的に異なる
- 最も多い原因はサーバーやCDNによるGooglebotのブロック
- John Mueller氏によればJavaScriptの問題ではなく、IPアドレスベースの低レベルなブロックであることが多い
- robots.txtによるリソースファイル（JavaScript・CSS）のブロックも主要な原因の一つ
- URL自体のブロックとリソースファイルのブロックは区別して考える必要がある
- 重要なページが該当している場合や、ステータスの対象ページ数が急増している場合は緊急対応が必要
- 放置するとサイトのページがインデックスから落ち始めるリスクがある
- 対処はURL検査ツールでの状態確認から始め、サーバー・CDN設定の見直し、robots.txtの修正と順を追って進めるのが効率的
まず取り組むべきアクションとしては、Search ConsoleのURL検査ツールで該当ページの状態を確認するところから始めてください。
公開URLのテストで問題が継続しているかどうかを判断し、継続していればサーバー・CDN設定とrobots.txtを順に確認していく流れが最短の解決ルートです。
このステータスを発見したら、後回しにせず速やかに原因を特定し、対処に動くことが大切です。
インデックス状態の把握が大変という方は、SEOサイト管理自動化ツール「inSite（インサイト）」を試してみてください。
inSiteのインデックスチェック機能では、サイト内のページのクロール状態を毎日自動でチェックします。
どれだけのページがインデックスされてなくて原因は何なのか、クローラーは定期的に来ているのかといった情報を常に監視することができます。
1ページずつURL検査をしなければわからないインデックス状態。
inSiteを使えばこれを常に把握できるため、効率よくSEOにおける有効な打ち手を考えることができます。
ページのインデックス率向上や、ページの評価をアップさせるリライトの効率化にかなり使えると思うので、ぜひお試しください。
この記事が気に入ったら
フォローしてね！
