Googleクローラーがサイト全体に来ない原因はrobots.txtが最多

UPDATED

2026.09.05

読了

14 min

サイト全体でGoogleのクロールが止まる原因は、ひとつに絞れないことがほとんどです。robots.txtの誤設定、noindexタグの全ページ適用、サーバーやDNSのエラー、WAFによる誤ブロックなど、複数の技術的な要因が重なって「クローラーが来ない」という状態を作り出しています。個別ページの品質が悪いという話ではなく、サイト全体に影響する構造的な問題であるケースが大半です。この記事では、Google Search Consoleの各種レポートをもとに、原因の切り分け方と対処の順序を整理していきます。

サイト全体でクロールが止まる原因はrobots.txtの「Disallow: /」が最多

robots.txtは、サイトのルートディレクトリに置かれるテキストファイルで、検索エンジンのクローラーにどのページをクロールしてよいかを指示する役割を持っています。この中に「Disallow: /」という一行があると、サイト全体へのクロールを禁止する指示になってしまいます。

特定のディレクトリだけをブロックするつもりが、誤って全体を対象にする記述をしてしまい、Googlebotがどのページにもアクセスしなくなるというケースは珍しくありません。サイトのリニューアルや、開発環境から本番環境への移行のタイミングで起こりやすい事故です。開発中はクローラーに来てほしくないため意図的に「Disallow: /」を書いておき、本番公開時に消し忘れてしまうという流れが典型例といえます。

確認するには、ブラウザで「https://自分のサイトのドメイン/robots.txt」に直接アクセスし、内容を目視でチェックするのが一番早い方法です。「User-agent: *」の下に「Disallow: /」とだけ書かれていたら、サイト全体をブロックしている状態なので、必要な記述だけを残すよう修正します。Search Consoleの「robots.txtレポート」でも、Googleが検出したrobots.txtの内容や前回のクロール日、警告・エラーの有無を確認できます。

Search Consoleの「クロールの統計情報」レポートでは、クロール中のrobots.txtリクエストの失敗率も見られます。Googleがrobots.txtを頻繁にリクエストしているのに有効なレスポンスが返ってこない場合、サイトのクロールが遅くなったり停止したりすることがあります。robots.txt自体が正しく取得できないというサーバー側の不調も、クロール停止のきっかけになり得るということです。

noindexタグとX-Robots-Tagヘッダーの全ページ誤設定が原因になっているケース

robots.txtがクロール自体をブロックする仕組みなのに対し、noindexはクロールは許可しつつ「インデックスへの登録はしないでほしい」と伝える仕組みです。指定方法は大きく二つあり、HTMLの内に書くrobotsメタタグと、HTTPレスポンスヘッダーに書くX-Robots-Tagがあります。

この設定がサイト全体に誤って適用されてしまう事例は実務上少なくありません。多いのは、CMSやWordPressのテーマ・プラグインの設定変更によって、意図せずすべてのページにnoindexが適用されてしまうパターンです。本番運用前にテスト環境として「検索エンジンにインデックスされないようにする」設定を有効にしていて、公開後もその設定が残ってしまっているというケースがよく報告されています。

サーバーやCDNの設定でHTTPレスポンスヘッダーにX-Robots-Tag:noindexが付与されてしまっている場合は、HTMLソースを見ただけでは気づけません。レスポンスヘッダーを直接確認しないと発見が難しいという厄介さがあります。Google検索セントラルのコミュニティにも、意図せずnoindexヘッダーが付与されてインデックスから除外されてしまったという相談が寄せられています。

チェックにはSearch ConsoleのURL検査ツールを使い、対象URLが正常にクロールされてインデックス登録が可能かどうかをテストする方法が有効です。ページ数が多いサイトでは、サイト内を一括でクロールできる外部ツールで、noindexやnofollowが指定されているページを一括抽出する方法も使われています。原因を特定したら、CMS側の「検索エンジンによるインデックスを拒否する」設定がオンになっていないかをまず確認してください。

503エラーとDNS障害はGooglebotのアクセスそのものを止める

Googlebotがサイトにアクセスしようとしてエラーが発生する場合、原因としてDNSエラーやタイムアウト、サーバーのダウンやビジー状態が挙げられます。具体的には、DNSがダウンしている、DNSの構成にミスがある、ファイアウォールでウェブサーバーへのアクセスがブロックされている、Googlebotからの接続をサーバー側が拒否している、サーバーに過負荷がかかっているといったケースです。

特に注意したいのが503エラーです。503は「サービス利用不可」を意味するステータスコードで、Googleはこれを一時的な障害として扱います。短期間なら大きな問題にはなりませんが、この状態が長く続くとGoogleはそのサイトへのクロールを控えるようになり、最終的にはインデックスから除外されてしまう可能性があります。メンテナンス中に503を返す設定にしている場合、メンテナンスが長引くとクロール自体が止まるリスクがあるので気をつける必要があります。

DNSエラーについては、DNSキャッシュに古い情報が残っていることが原因で、正しいサイトにアクセスできずエラーになるケースがあります。この状態が続くとインデックスから消えてしまう可能性があります。

対処としては、Search Consoleの「クロールの統計情報」レポートで、ホスティングの状態やエラー率、レスポンス時間の推移を確認することが基本になります。エラー率が急上昇している時期があれば、その時期にサーバー障害やメンテナンスがなかったかを社内やサーバー管理会社に確認します。サーバーログを直接見て、Googlebotがアクセスしたときにどのステータスコードを返しているかを調べる方法も有効です。DNS設定については、レジストラやDNSサービス側の構成ミスがないかを確認し、必要ならサポート窓口に問い合わせます。

CloudflareなどのWAF設定がGooglebotを誤ってブロックすることがある

AIクローラーによる無断学習やコンテンツ収集への対策として、CloudflareなどのCDN・WAFサービスでボットへのアクセスを制限するサイトが増えています。この設定の際に、意図せずGooglebotまで一緒にブロックしてしまう事故が起こり得ます。

WAFやボット対策機能は、特定のUser-Agentやアクセスパターンを持つ通信を不正なボットとして遮断するルールを設定できますが、設計を誤ると、正規の検索エンジンクローラーであるGooglebotやBingbotの通信までブロック対象に含まれてしまいます。検索エンジンクローラーとAI学習ボットをまとめて拒否すると、サイトが検索結果から除外され、オーガニック検索からの流入がゼロになるリスクがあるため、運用には慎重さが求められます。

Googleが検索用にインデックスすることだけを許可し、それ以外の検索エンジンやAIボットをブロックしたい場合は、robots.txtで「Allow: /」をGooglebotに明示的に設定し、それ以外のUser-Agentには「Disallow: /」を設定する方法があります。ただしrobots.txtはクローラー側の自主的な遵守に依存する仕組みで、悪意のあるボットの中にはこの指示を無視するものも存在するため、CloudflareのWAF機能による強制的なブロックと組み合わせて運用するのが望ましいとされています。

複数の対策を組み合わせると、設定の相互作用によって想定外の挙動が起きやすくなります。CDNの管理画面でボットマネジメントやファイアウォールルールを変更したあとは、Search Consoleのクロール統計情報でクロールリクエスト数や成功率に異常な変化がないかを確認する習慣をつけておくと安心です。

手動による対策とセキュリティの問題はSearch Consoleで真っ先に確認する

Googleのアルゴリズムは自動化されたウェブスパムの検出を得意としており、ガイドライン違反の多くは自動的に検出されて検索結果への表示が抑制されます。自動検出で見逃されたケースや悪質性の高いケースについては、Google社内の担当者が個別に審査を行い、「手動による対策」としてペナルティを課すことがあります。

手動による対策を受けているサイトは、検索結果での掲載順位が下がったり、サイト全体や一部のページが検索結果から完全に除外されたりします。これはSearch Consoleの「セキュリティと手動による対策」内にある「手動による対策」レポートで確認できます。ここに項目が表示されていれば、ウェブマスターガイドラインへの違反があったと判断されたということです。

あわせて確認したいのが「セキュリティの問題」レポートです。サイトがハッキングされている、マルウェアが埋め込まれている、フィッシングコンテンツが含まれているといった警告を示すもので、第三者に不正アクセスされてスパムコンテンツや不正なリダイレクトが埋め込まれた場合、Googleはユーザー保護のためにそのサイトへのアクセスや検索結果への表示を制限することがあります。表面上は正常なコンテンツに見えても、サーバー内部に不正なファイルが仕込まれているケースもあるため、注意深い調査が必要です。

手動による対策やセキュリティの問題が見つかった場合は、該当する違反内容やハッキングされた箇所を特定し、修正したうえでSearch Consoleから再審査リクエストを送ります。再審査には数日から数週間かかることがあるため、余裕を持ったスケジュールで対応してください。

クロールバジェットの低下は低品質コンテンツと表示速度の遅さが引き金になる

Googlebotはすべてのサイトを無尽蔵にクロールしているわけではなく、サイトごとに「クロールバジェット」と呼ばれる予算のようなものが割り当てられています。サイト全体の評価が低いとGoogleに判断されると、クロールの優先順位が下がり、頻度そのものが低下する可能性があります。

低品質なコンテンツが大量にある、重複コンテンツが多い、更新頻度が極端に低い、過去に何らかの問題があったサイトなどは、クロール優先度が下がりやすい傾向にあります。頻度が下がると、新しく公開したページがなかなかクロールされない、更新内容が反映されにくいといった状態になり、体感的には「クローラーが来なくなった」と感じられます。

ページ表示速度が著しく遅い場合も、クローラーの巡回効率に影響します。表示速度が遅いサイトはサーバー応答にも時間がかかっている可能性が高く、限られたクロールバジェットの中で効率的にクロールできるページ数が少なくなるためです。

低品質・重複コンテンツの整理統合、不要なページの削除やnoindex化、サーバーやCMSの高速化によるページ表示速度の改善が対処の基本になります。クロールバジェットは即座に改善するものではなく、継続的なサイト品質の向上によって徐々に回復していく性質のものなので、中長期的な視点で取り組む必要があります。

内部リンク構造の不備は孤立ページを生みクロールを妨げる

サイト全体でクロールが来ないと感じる場合、根本的な原因としてリンク構造の問題があるケースも多く見られます。Googlebotは基本的に、既知のページに張られたリンクをたどって新しいページを発見します。サイト内外からのリンクのつながりが少ない、あるいは全くないページは、Googlebotに発見してもらえず、クロールされない孤立ページになってしまいます。

孤立ページが大量に発生している場合、サイト内のナビゲーション設計そのものに問題がある可能性があります。深い階層のページへのリンクがトップページやカテゴリページから一切張られていない、パンくずリストが機能していない、サイトマップページが存在しない、JavaScriptで動的に生成されたリンクがクローラーに正しく認識されていないといった状況が考えられます。

XMLサイトマップを作成してSearch Consoleに送信すれば、サイト内の重要なページの一覧をGoogleに明示的に伝えられます。関連ページ同士を内部リンクでつなぎ、どのページからでも数クリックで主要なコンテンツにたどり着けるようサイト構造を整理することも重要です。サイト規模が大きくなるほど、内部リンクの設計はクロール効率に直結するため、定期的な見直しが欠かせません。

サイト移行後は301リダイレクトの設定漏れでクロールが遅延する

サイトのURL構造の変更、HTTPからHTTPSへの移行、ドメインの変更、サーバーの引っ越しといった大規模な変更を行った直後は、一時的にクロールが来にくくなったり不安定になったりすることがあります。Googleが新しいURL構造やサーバー環境を再認識し、インデックスを更新するまでに一定の時間がかかるためです。

移行作業では、301リダイレクトを適切に設定し、旧URLから新URLへの評価の引き継ぎを正しく行うことが重要です。リダイレクトの設定漏れや、何重にもリダイレクトが連鎖するリダイレクトチェーン、リダイレクトループが発生していると、Googlebotが正しく新しいページにたどり着けず、クロールが滞る原因になります。

Search Consoleには「サイトの移転」に関する専用の機能やプロパティの再設定が必要になる場合もあるため、大規模な移行作業を行う際は事前に公式のヘルプドキュメントを確認し、手順に沿って進めるようにしてください。

「検出-インデックス未登録」と「クロール済み-インデックス未登録」は原因も対処法も違う

Search Consoleの「インデックス作成」内にある「ページ」レポートでは、「検出-インデックス未登録」と「クロール済み-インデックス未登録」という、似ているようで意味の異なる二つのステータスが表示されます。この二つを混同すると、原因の切り分けを誤ってしまいます。

「検出-インデックス未登録」は、GoogleがそのURLの存在自体は把握しているものの、まだクロールすら行っていない状態です。サイトマップやリンクを通じて存在は認識されているが、クロールの優先順位が低い、あるいはサーバー側の負荷を考慮してクロールを見送っている状態と説明されます。大量のページでこの状態が起きている場合、前述したクロールバジェットの不足や、サーバーの応答速度の遅さが原因になっている可能性が高いといえます。

「クロール済み-インデックス未登録」は、Googlebotが実際にそのページをクロールし、コンテンツを確認したうえでインデックスに登録する価値がないと判断された状態です。クロール自体は行われているため、サイト全体がクロールされていないという問題とは性質が異なり、ページ単体のコンテンツ品質や重複コンテンツ、内容の薄さが原因になっていることが多いとされています。

サイト全体でクロールが来ないと感じている場合でも、実際にはページごとにこの二つのステータスが混在していることが多いため、該当ページがどちらの状態にあるのかを一つずつ確認し、原因に応じた対処法を選ぶことが重要です。

Search Consoleでの原因切り分けは手動対策からクロール統計、robots.txtの順で進める

ここまで紹介した原因の多くは、Search Consoleの各種レポートを組み合わせて確認することで切り分けられます。効率的な確認の順序は次のとおりです。

まず「セキュリティと手動による対策」内の「手動による対策」レポートと「セキュリティの問題」レポートを確認し、Googleから明示的なペナルティや警告を受けていないかを見ます。ここに問題があれば、他の原因を調べるよりもこの対応を最優先で進めるべきです。

次に「設定」内の「クロールの統計情報」レポートを確認します。Googleが実際にどれくらいの頻度でサイトをクロールしているか、レスポンスのステータスコードの内訳、ホスティングに関するエラーの有無、robots.txtリクエストの成功率を時系列で確認できます。特定の時期からクロール数が急減している場合、その時期に技術的な変更やトラブルがなかったかを照らし合わせて調べます。

続いて「robots.txtレポート」で意図しないDisallow設定がないかを確認し、URL検査ツールで代表的なページを検査して、クロールとインデックスのどちらの段階で問題が起きているのかを絞り込みます。実際のページのHTMLソースやHTTPレスポンスヘッダーも確認し、noindexタグやX-Robots-Tagヘッダーが意図せず付与されていないかをチェックしてください。あわせてサーバーログでGooglebotのアクセス自体が来ているか、来ている場合はどのステータスコードが返されているかを確認すれば、サーバー側とサイト設定側のどちらに問題があるのかを特定できます。

Googleクローラーが来ない原因についてよくある疑問

クロールが止まってからどれくらいの期間で検索順位に影響が出るのか、気になる方は多いはずです。robots.txtの誤設定や503エラーが数日程度で解消されれば大きな影響は出にくいものの、数週間単位で続くとインデックスからの除外が進み、検索順位や表示回数の低下につながります。原因が判明したらできるだけ早く修正し、Search ConsoleのURL検査ツールで再クロールをリクエストすることが回復への近道です。

新規サイトでクローラーがなかなか来ないという相談もよくありますが、これは前述の誤設定とは性質が異なります。開設したばかりのサイトは被リンクや内部リンクの蓄積が少なく、Googleにとって発見の手がかりが乏しい状態です。この場合はXMLサイトマップの送信と、SNSなど外部からのリンク獲得を地道に進めることが有効な対応になります。

複数の原因が同時に起きている場合はどう対応すべきかという疑問もあります。robots.txtの誤設定とサーバーエラーが重なっているようなケースでは、まずSearch Consoleのレポートで問題の全体像を洗い出し、影響範囲が大きいものから順に修正していくのが基本の進め方です。一つを直したらすぐに次に着手するのではなく、修正後にクロール統計情報の推移を数日から一週間程度観察し、改善が反映されているかを確認してから次の対応に移ると、原因の切り分けを誤りにくくなります。