クロールレポートの約47,000ページ目あたりで、本気でキャリアチェンジを考えた。イギリスの大手ECカタログサイトで、インデックス可能なURLが約91,000ページあるのに、6ヶ月間、インデックス済みページが約34,000ページで停滞していた。成長していない。クライアントは何か「壊れている」と確信していた。私は何も壊れていないと言った。半分は正しかった。
重要なポイント：91,000ページのサイトでは、Googlebotはあなたのアーキテクチャが指示する内容をクロールします。内部リンク、サイトマップの規律、そして無駄の排除によって、どのページがインデックスされるかが決まります。
あのプロジェクトは、クロールバジェットに対する私の考え方を一変させた。理論ではなく——Googleのドキュメントは読んでいたし、Search Centralのビデオも見ていたし、クロールバジェットが何かは知っていた。だが知ることと、実際に大規模で管理することは、まったく別物だ。以下は、2022年3月のあの火曜日の朝、Google Search Consoleでクロール統計を初めて引き出して、胃が落ちるのを感じた時間に戻れたなら、自分に言いたいすべてのことだ。
クロールバジェットが実際に意味すること（そして意味しないこと）
人々が常に引っかかるポイントはこれだ：クロールバジェットは「Googleがお前のサイトに対して今後インデックスするページ数」を意味しない。つまりおよそ「与えられたクロールウィンドウ内でGooglebotがフェッチするURLの数」であり、それはGoogleが定義する「クロールレート制限とクロール需要の組み合わせ」だ。
クロールレート制限とは、Googlebot がサーバーに負荷をかけずにクロールできる速度のこと。クロール需要とは、Google がクロールしたい量のこと。これはURLがどれほど人気で、どのくらい頻繁に変わるかで決まる。この2つのレバーを掛け合わせれば、サイトがどのくらいのクロール注力を受けるか、ざっくりした感覚が得られる。
ページが1,000ページ未満のサイトのほとんどにとって、これは関係ない。Googleはすべてをクロールする。だが数万ページになり、特に6桁に達すると、Googlebot は選択を始める。優先順位をつける。無視する。そして正しいものを優先するように設定していなければ、セッションIDパラメータのURLやフィルタ済みファセットページをのんきにクロールしている間、新しい商品がリリースされても数週間気づかないままになる。
これは仮定の話ではありません。91,000ページのプロジェクトで実際に起こったことです。
誰も教えてくれなかったファセットナビゲーション問題
ファセットナビゲーションは、大規模サイトで私が遭遇した最大のクロールバジェット消費犯です。常に。毎回。
そのカタログサイトはファセット絞り込みシステム（色、サイズ、素材、ブランド）を備えていたが、URLパラメータハンドリングはどこにも設定されていなかった。フィルタの組み合わせごとに一意のURLが生成された。「青」「中」「綿」「BrandX」を選ぶと/shop?colour=blue&size=medium&material=cotton&brand=brandxが得られた。次に誰かが順序を入れ替えて/shop?size=medium&colour=blue&brand=brandx&material=cottonが得られた。異なるURL、同じコンテンツ。
Screaming Frog（バージョン18、JavaScriptレンダリングが以前のバージョンより大幅に向上）でクロールを実行し、フィルタシステムだけで200,000以上のURLが生成されていることを発見しました。Googlebotはこれらを絶えず訪問していました。一方、数千の正当な商品ページはインデックスされないままでした。
実際に機能した修正
これを2段階で対処した。まず、Google Search Console でURLパラメータハンドリングを設定し、絞り込みパラメータを「ページコンテンツを変更しない」とフラグを立てて、Googlebot が統合するよう通知した。次に、そしてより重要なことに、dev チームが適切なカノニカル戦略を実装し、すべてのフィルタ組み合わせをベースカテゴリーページにポイントした。また、実際にはカノニカル化できない低価値フィルタページに noindex を追加した。
約8週間で、インデックス済みページ数が上昇し始めた。爆発的ではなく、着実に。実際、これは望ましいことだ。インデックス済みページの急激なスパイクは、クリーンな勝利ではなく、Google からの再評価を引き起こすことがある。
Search ConsoleのクロールStats：ほとんどの人が無視するデータ
過去3年間で、クロール問題を具体的に対象にしてほぼ80のサイトを監査した。そのサイトを渡してくれた人の15%程度しか、Search ConsoleのCrawl Statsレポートを見たことがなかった。この数字はもっと高いはずだ。
クロール統計レポートは、1日あたりの平均クロールリクエスト、平均応答時間、そして最も重要なことに、Googlebot が実際にクロールしているもの（目的別：discovery vs. refresh）を表示する。「refresh」クロールが支配的で、discovery クロールが最小限の場合、Google は既に知っているページを再確認するのに時間を費やしている。新しいものを見つけていない。これは内部リンクが浅い、または XML サイトマップが何の役に立っていないというシグナルだ。
91,000ページのプロジェクトでは、1日あたり約2,400クロールリクエストで推移していた。その規模のサイトでは、すべてのリクエストが一意で有用なページにヒットすると仮定した場合、Google は理論上、すべてを一度クロールするのに約38日かかることになる。そうではなかった。クロールリクエストの約40%がリダイレクトチェーンまたはパラメータが膨れたダプリケートにヒットしていた。
平均応答時間はあなたが思うより重要です
キャリアの初期に過小評価していたことの1つ：Googlebotはサーバー速度に本当に敏感です。ランキングへの影響という意味ではありませんが（少なくとも直接的には）、クロール意欲という意味ではあります。遅いサーバーはGooglebotを引き下がらせます。Googleは苦戦しているサーバーへのストレスを避けるため、クロール率を低下させます。
そのカタログサイトのTime to First Byteは、ピークトラフィック時のカテゴリページで約1.8秒でした。クライアントが共有ホスティングから適切なキャッシング設定を備えた専用VPS（ページキャッシング用WP Rocket、オブジェクトキャッシング用Redis）に移行した後、TTFBは400ms以下に短縮されました。その後6週間で、1日あたりのクロールリクエスト数が明らかに増加しました。相関関係ですが、このパターンを何度も見ているので、却下することはできません。
XMLサイトマップ：形式的なものとして扱うのをやめてください
私が引き継ぐサイトマップのほとんどは間違っている。劇的に間違っているわけではなく、ただ静かに、役に立たないように間違っている。
よく見かける問題：
- サイトマップに含まれているページが404またはリダイレクト301を返している
- sitemapに含まれるnoindexページ（Googlebotを混乱させます。同時に「このページをクロールせよ」と「このページをインデックスするな」と言っていることになります）
- <lastmod>の日付が静的であるか、単に間違っている
- 1つのファイルに70,000以上のURLが含まれているサイトマップ（制限は1ファイルあたり50,000で、大きなファイルは処理速度を低下させます）
- サイトマップインデックスファイルがなく、単一の大きなXMLファイルのみ
大規模なカタログプロジェクトでは、sitemapに91,000個のURLが1つのファイルに含まれていました。生成されたすべてのフィルタ済みURLも含まれており、そのうち40,000個以上がnoindexされていました。Googlebotがこの巨大なファイルを処理してから、ほとんどのURLをそもそもクロールすべきではないことを発見していました。両方の側で無駄なシグナルです。
サイトマップアーキテクチャを適切なサイトマップインデックスに再構築し、それが分割された子サイトマップを指すようにしました。コアカテゴリーページ用、製品ページ用（ボリュームのため2ファイルに分割）、編集コンテンツ用です。各ファイルは40,000未満のURL。<lastmod>の値はデータベース内の実際の最終更新日から動的に生成。noindexされたページもリダイレクトもありません。
Bing Webmaster Toolsのデータ（はい、確認する価値があります。BingはGoogleも経験している構造的な問題のヒントになるクロール動作パターンを示すことがあります）では、sitemap処理時間が60%以上低下しました。
内部リンク：実際にあなたがコントロールできるレバー
Seahawk Mediaが2020年にメディアクライアント向けの大規模なコンテンツサイト（約65,000記事）を担当するまで、本当に認識していなかったことがあります。サイトはwell-formedなsitemapとクリーンなURL構造があるにもかかわらず、クロール予算の問題を抱えていました。問題は内部リンクの深さでした。何千もの記事が実質的に孤立していて、クロールされたページから指す内部リンクがありませんでした。
Googlebotはサイトマップだけに従うわけではない。リンクに従う。ページがサイトマップのエントリーのみを通じてのみ発見可能で、内部リンクがゼロの場合、優先度が下げられる。それは公式には明確な用語では記載されていないが、Googleの内部リンクに関する自身のガイダンスは、重要なページからのクロール可能なリンクがGooglebotの発見優先度の決め方であることを明確にしている。
そのメディアクライアント向けに、Ahrefsの Site Audit ツールを使って内部リンクを監査し、3件以下の内部リンクしか指してない記事が約12,000件あることを特定しました。CMS（WordPress、カスタム Gutenberg ブロック）に自動化された「関連記事」ブロックを構築し、文脈的に類似したコンテンツを引き出すようにしました。その四半期の間に、そのサイトのインデックス対象ページは41,000から58,000以上に増加しました。ドメインオーソリティは同じ。コンテンツ生産率も同じ。内部リンク構造がより良くなっただけです。
大規模なサイト監査で私が今使っている番号付きアプローチ：
- Screaming Frog のフルクロールを実行して内部リンクデータをエクスポート
- 3件未満の被リンク内部リンクを持つすべてのページを特定
- よくリンクされているページと相互参照し、トピッククラスタを見つけます
- 高トラフィックページから、リンク不足のページへ向けて文脈的な内部リンクを構築
- Search ConsoleのURL検査ツールで、新しくリンクされたページが「発見済み、現在インデックス未登録」から「クロール済み」に移行したことを検証します
Search Consoleの「発見済み、現在インデックス未登録」ステータスはあなたのカナリアです。Googleがページの存在を知っているが、フェッチを優先していないということです。内部リンクを改善することが、通常はこれを解決する最速の方法です。
ログファイル分析：不快だが必要な作業
正直に言うと、ログファイル分析は何年も避けてきたものです。クロールツールがほとんどすべてを提供してくれるなら、不必要な深掘りに感じました。私が間違っていました。
ログファイルはGooglebotが実際に何をしたかを教えてくれます。sitemapまたはクロールツールから推測したことではありません。あるプロジェクト（約8,000ページのプロダクトドキュメンテーションを持つSaaS企業）で、ログ分析によってGooglebotがそのクロール時間の30%近くを/wp-admin/隣接URLと、robots.txtでブロックされるべき管理者側のアセットに費やしていることが明らかになりました。誰もそれを適切にセットアップしていませんでした。4ヶ月間クロールされていないドキュメンテーションページがありました。
私が使用しているツールはScreaming FrogのLog File Analyserです。派手ではありませんが信頼性があります。サーバーログをインポートし、Googlebotユーザーエージェントでフィルタリングし、URLヒット頻度でソートします。出現するパターンはほぼ常に啓発的であり、ほぼ常にクロールされるべきではない何かを含んでいます。
対応すべき時と放置すべき時
すべての大規模サイトが積極的なクローリングバジェット管理を必要とするわけではありません。10,000ページあって9,800ページがインデックスされているなら、レバーを引き始めないでください。存在しない問題を作り出すことになります。
クローリングバジェット管理が本当に価値のある時間になるのは以下の場合です:
- インデックス可能ページが約15,000ページを超えている
- 新しいコンテンツが追加されているにもかかわらず、インデックス数が停滞している
- クローリング統計でページボリュームに対して予想されるよりもはるかに低い平均クローリングリクエストが表示されている
- 「発見済み、現在インデックス未登録」または「クロール済み、現在インデックス未登録」ステータスの数千のURLが表示されている
2番目のステータスである「クロール済み、現在インデックス未登録」は異なるもので、分離する価値がある。これはGoogleがページをフェッチして、通常はコンテンツが薄いか重複に近い問題によってインデックスしないことを決めたことを意味する。クロールバジェットの最適化によっては、品質の問題は解決できない。
---
よくある質問
クロールバジェットは小規模サイトに影響しますか？
意味のある形ではめったにない。サイトのページ数が1,000未満で読み込みが速い場合、Googleはほぼ確実にすべてをクロールする。クロールバジェットが本当の懸念になるのはスケール時、通常は10,000〜15,000ページ以上のサイト、または大部分のURLが動的に生成されるサイトである。
サイトマップを直接送信すればクロールバジェットの問題は解決しますか？
いいえ。サイトマップは発見に役立つ、GoogleにこれらのURLが存在することを知らせる。しかし、サイトに構造的な問題がある場合（ファセットナビゲーション スパム、遅いサーバーレスポンス、浅い内部リンク）、サイトマップはそれらのシグナルを無視できない。サイトマップを提案として考えてほしい、命令ではなく。
GooglebotがゴミURLにクロールバジェットを無駄にしていないかどうかを確認するにはどうしたらいいですか？
Google Search Consoleのクロール統計レポートから始めて、どのURLタイプがリクエストを最も多く受けているか確認します。その後Screaming Frogのクロール結果と相互参照して、重複、noindex、または低品質な高ボリュームURLパターンを特定します。ログファイル分析はサーバーログにアクセスできれば最も正確な状況を提供します。
クロールバジェットを節約するために`noindex`または`robots.txt disallow`を使用すべきですか？
用途に応じた異なるツール。robots.txtのDisallowはGooglebotがページを完全にフェッチするのを防ぎ、クロールバジェットを節約するが、Googleはそのページのシグナルを読むことができない。NoindexはGoogleがページをフェッチすることを許可するが、検索結果にそのページを含めないよう指示する。クロールバジェット特に関しては、disallowが真のジャンクURL（管理パス、内部検索結果）に対してより効果的である。フィルター済みファセットページでGoogleにコンテンツを理解させたいが、インデックスしたくない場合、通常はnoindexとcanonicalが正しい方法である。
クロール予算の問題を修正した後、改善が見られるまでの現実的な期間はどのくらいですか？
正直に言うと、クロールレートによる。91,000ページのプロジェクトでは、主要な修正がデプロイされた後、インデックス済みページ数に意味のある動きが見られるまでに約6〜8週間かかった。一夜にして変化することは期待しないでほしい。Googlebotが再クロール、再評価する必要があり、その上にインデックスパイプラインは独自のレイテンシーを持っている。
---
91,000ページのプロジェクトは上手くいった。インデックス済みページは5ヶ月間で34,000から71,000を超えるまで増加した。完璧ではなく、本当にインデックスされるべきではない薄い商品ページがあったが、重要なコンテンツが見つかった。クライアントは何か壊れているのかと質問するのを止めた。そして私はクロールレポートの47,000ページ目あたりでキャリア変更を視野に入れるのをやめた。ほぼ。
関連記事：2026年のAI検索キーワード調査：それが何か、従来のものがなぜ、301対302リダイレクト：SEOにとって実際に重要なのはどちらか、2026年のLSIキーワード：それが何か、それが何でないか、何。