クロールレポートの約47,000ページ目あたりで、本気でキャリアチェンジを考えた。このサイト――英国の大手eコマース企業で、インデックス可能なURLが約91,000個あった――6ヶ月間、ずっと約34,000ページのインデックス数で停滞していた。成長していない。クライアントは何かが「壊れている」と確信していた。私は何も壊れていないと言った。私は半分正しかった。
重要なポイント：91,000ページのサイトでは、Googlebotはあなたのアーキテクチャが指示する内容をクロールします。内部リンク、サイトマップの規律、そして無駄の排除によって、どのページがインデックスされるかが決まります。On a 91,000-page site Googlebot crawls what your architecture tells it to: internal linking, sitemap discipline, and killing waste decide which pages get indexed.
そのプロジェクトはクロールバジェットについての私の考え方を完全に変えた。理論ではなく――Googleのドキュメントは読んでたし、Search Centralの動画も見てたし、クロールバジェットが何かは知ってた。だが知ることと、実際にスケール規模で管理することは全く別の話だ。以下は、2022年3月のあの火曜日の朝、Google Search Consoleで初めてクロール統計を引き出して、胃が落ちる思いをした時の自分に伝えたいすべてだ。was. But knowing it and actually managing it at scale are two wildly different things. What follows is everything I'd tell myself if I could go back to that Tuesday morning in March 2022 when I first pulled the crawl stats in Google Search Console and felt my stomach drop.
クロールバジェットが実際に意味すること（そして意味しないこと）
人々が常に引っかかるポイントはこれだ：クロールバジェットは「Googleがお前のサイトに対して今後インデックスするページ数」を意味しない。つまりおよそ「与えられたクロールウィンドウ内でGooglebotがフェッチするURLの数」であり、それはGoogleが定義する「クロールレート制限とクロール需要の組み合わせ」だ。fetch within a given crawl window, which Google itself defines as a combination of crawl rate limit and crawl demand.
クロールレート制限は、サーバーに負荷をかけずにGooglebotがクロール可能な速度だ。クロール需要はGoogleがクロールしたい量――URLの人気度と変更頻度で決まる。この2つのレバーを掛け合わせれば、サイトがどの程度のクロール注目を受けるかのおおよその目安が得られる。wants to crawl -- driven by how popular your URLs are and how often they change. Multiply those two levers together and you have a rough sense of how much crawling attention your site gets.
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、同じコンテンツだ。/shop?colour=blue&size=medium&material=cotton&brand=brandx. Then someone flipped the order and got/shop?size=medium&colour=blue&brand=brandx&material=cotton. Different URL, identical content.
Screaming Frog（バージョン18、JavaScriptレンダリングが以前のバージョンより大幅に向上）でクロールを実行し、フィルタシステムだけで200,000以上のURLが生成されていることを発見しました。Googlebotはこれらを絶えず訪問していました。一方、数千の正当な商品ページはインデックスされないままでした。
実際に機能した修正
これを2段階で解決した。まず、Google Search ConsoleでURLパラメータ処理を設定して――フィルタパラメータを「ページコンテンツを変更しない」としてフラグを立てて、Googlebotに統合するよう指示した。次に、より重要なことに、開発チームが適切なcanonical戦略を実装して、すべてのフィルタ組み合わせをベースカテゴリページに指し示すようにした。また、実用的にcanonicalできない低価値フィルタページにはnoindexを追加した。noindex to low-value filtered pages that couldn't practically be canonicalised.
約8週間以内に、インデックスページ数が上昇し始めた。爆発的ではなく――着実に。これは実は望ましい状態だ。インデックスページ数の急激な増加は、時にGoogleの再評価を招くことがあり、きれいな勝利にはならない。
Search ConsoleのクロールStats：ほとんどの人が無視するデータ
過去3年間で、クロール問題を具体的に対象にしてほぼ80のサイトを監査した。そのサイトを渡してくれた人の15%程度しか、Search ConsoleのCrawl Statsレポートを見たことがなかった。この数字はもっと高いはずだ。Crawl Stats report in Search Console. That number should be much higher.
クロール統計レポートは、1日あたりの平均クロール要求数、平均応答時間、そして――重要なことに――Googlebotが実際にクロールしているもの（目的別に分類：発見対リフレッシュ）を示す。「リフレッシュ」クロールが支配的で、発見クロールが最小限なら、Googleは既に知っているページの再確認に時間を費やしている。新しいものを見つけていない。これは内部リンクが浅い、またはXMLサイトマップが何の役に立っていないことを示す信号だ。
91,000ページのプロジェクトでは、1日あたり約2,400クロール要求があった。このサイトサイズなら、Googleが1回ですべてをクロールするのに理論上約38日かかることを意味する――すべてのリクエストがユニークで有用なページに当たったと仮定して。そうではなかった。クロール要求の約40%はリダイレクトチェーンかパラメータで膨れ上がった重複に当たっていた。
平均応答時間はあなたが思うより重要です
キャリアの初期に過小評価していたことの1つ：Googlebotはサーバー速度に本当に敏感です。ランキングへの影響という意味ではありませんが（少なくとも直接的には）、クロール意欲という意味ではあります。遅いサーバーはGooglebotを引き下がらせます。Googleは苦戦しているサーバーへのストレスを避けるため、クロール率を低下させます。
そのカタログサイトのTime to First Byteは、ピークトラフィック時のカテゴリページで約1.8秒でした。クライアントが共有ホスティングから適切なキャッシング設定を備えた専用VPS（ページキャッシング用WP Rocket、オブジェクトキャッシング用Redis）に移行した後、TTFBは400ms以下に短縮されました。その後6週間で、1日あたりのクロールリクエスト数が明らかに増加しました。相関関係ですが、このパターンを何度も見ているので、却下することはできません。
XMLサイトマップ：形式的なものとして扱うのをやめてください
私が引き継ぐサイトマップのほとんどは間違っている。劇的に間違っているわけではなく――ただ静かに、無駄に間違っているだけだ。
よく見かける問題：
- サイトマップに含まれているページが404またはリダイレクト301を返している
- noindexされたページがサイトマップに含まれている（これはGooglebotを混乱させる――「クロールしろ」と「このページをインデックスするな」を同時に言っているようなものだ）
<lastmod>の日付が静的であるか、単に間違っているdates that are static or just wrong- 1つのファイルに70,000以上のURLが含まれているサイトマップ（制限は1ファイルあたり50,000で、大きなファイルは処理速度を低下させます）
- サイトマップインデックスファイルがなく、単一の大きなXMLファイルのみ
大規模カタログプロジェクトでは、サイトマップに単一ファイル内に91,000個のURLが含まれていた。また、かつて生成されたあらゆるフィルター済みURLも含まれていて、そのうち40,000個以上がnoindexされていた。Googlebotはこの巨大なファイルを処理して、結局ほとんどのURLはどうせクロールすべきではないと判明している。両端で無駄なシグナルが発生していた。
サイトマップアーキテクチャを適切なサイトマップインデックスに再構築し、それが分割された子サイトマップを指すようにしました。コアカテゴリーページ用、製品ページ用（ボリュームのため2ファイルに分割）、編集コンテンツ用です。各ファイルは40,000未満のURL。<lastmod>の値はデータベース内の実際の最終更新日から動的に生成。noindexされたページもリダイレクトもありません。<lastmod>values dynamically generated from the actual last-modified date in the database. No noindexed pages, no redirects.
Bing Webmaster Toolsのデータ（確認する価値はある――Bingはときどき、Googleも経験している構造的な問題を示唆するクロール行動パターンを表示する）では、サイトマップ処理時間が60%以上低下した。
内部リンク：実際にあなたがコントロールできるレバー
Seahawkが2020年にメディアクライアント向けに大規模コンテンツサイト――約65,000記事――を担当するまで、私は本当にこれを理解していなかった。そのサイトは、整形の良いサイトマップときれいなURL構造にもかかわらず、クロール予算の問題を抱えていた。問題は内部リンクの深さだった。数千の記事は事実上孤立していて、クロールされたページからそれらを指す内部リンクがどこにもなかった。
Googlebotはサイトマップだけに従うわけではない。リンクに従う。ページがサイトマップのエントリーのみを通じてのみ発見可能で、内部リンクがゼロの場合、優先度が下げられる。それは公式には明確な用語では記載されていないが、Googleの内部リンクに関する自身のガイダンスは、重要なページからのクロール可能なリンクがGooglebotの発見優先度の決め方であることを明確にしている。only follow sitemaps. It follows links. If a page is only discoverable through a sitemap entry and has zero internal links, it gets deprioritised. That's not officially documented in crisp terms, but Google's own guidance on internal linking makes clear that crawlable links from important pages are how Googlebot prioritises discovery.
そのメディアクライアント向けに、Ahrefsの Site Audit ツールを使って内部リンクを監査し、3件以下の内部リンクしか指してない記事が約12,000件あることを特定しました。CMS（WordPress、カスタム Gutenberg ブロック）に自動化された「関連記事」ブロックを構築し、文脈的に類似したコンテンツを引き出すようにしました。その四半期の間に、そのサイトのインデックス対象ページは41,000から58,000以上に増加しました。ドメインオーソリティは同じ。コンテンツ生産率も同じ。内部リンク構造がより良くなっただけです。WordPress, custom Gutenberg block) that pulled contextually similar content. Over the following quarter, indexed pages on that site climbed from 41,000 to over 58,000. Same domain authority. Same content production rate. Just better internal linking.
大規模なサイト監査で私が今使っている番号付きアプローチ：
- Screaming Frog のフルクロールを実行して内部リンクデータをエクスポート
- 3件未満の被リンク内部リンクを持つすべてのページを特定
- 適切にリンクされているページを照合する――トピックスター集を見つけるare well-linked -- find topical clusters
- 高トラフィックページから、リンク不足のページへ向けて文脈的な内部リンクを構築
- Search ConsoleのURL検査ツールで新たにリンクされたページが「発見済み――現在インデックス未登録」から「クロール済み」に移行することを確認する
Search Consoleの「発見済み――現在インデックス未登録」ステータスは警告信号だ。Googleはページが存在することを知っているが、フェッチを優先していない、という意味だ。内部リンクを改善することが、通常はこれを解決する最速の方法だ。
ログファイル分析：不快だが必要な作業
正直に言うと――ログファイル分析は何年も避けていた。クロールツールがほとんど必要な情報を提供してくれるなら、不要な深掘りに感じた。私は間違っていた。
ログファイルは、Googlebotが実際に何をしたかを告げる。サイトマップやクロールツールから推測したことではなく。あるプロジェクト――約8,000個のプロダクトドキュメンテーションページを持つSaaS企業――でのログ分析は、Googlebotがクロール時間の約30%を/wp-admin/隣接URLと、robots.txtでブロックされるべきだった管理側アセットに費やしていることを明らかにした。誰もそれを適切に設定していなかった。4ヶ月間クロールされていないドキュメンテーションページがある。actually did, not what you infer it did from your sitemap or crawl tool. On one project -- a SaaS company with about 8,000 product documentation pages -- log analysis revealed Googlebot was spending nearly 30% of its crawl time on/wp-admin/adjacent URLs and admin-side assets that should have been blocked in robots.txt. Nobody had set that up properly. Documentation pages that hadn't been crawled in four months.
Screaming FrogのLog File Analyserは、私が使うツールだ。派手ではないが信頼できる。サーバーログをインポートして、Googlebot user agentでフィルタリングして、URLヒット頻度でソートする。浮かび上がるパターンはほぼ常に啓発的だ――そしてほぼ常に、クロールされるべきではないものがクロールされている。 is the tool I use. It's not glamorous but it's reliable. Import your server logs, filter by Googlebot user agent, and sort by URL hit frequency. The patterns that emerge are almost always illuminating -- and almost always include something crawling that shouldn't be.
対応すべき時と放置すべき時
すべての大規模サイトが積極的なクローリングバジェット管理を必要とするわけではありません。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 の組み合わせが正解です。Disallow in robots.txt prevents Googlebot from fetching the page at all -- saving crawl budget but meaning Google can't read any signals on that page.Noindex allows Google to fetch the page but tells it not to include the page in search results. For crawl budget specifically,disallow is more effective on truly junk URLs (admin paths, internal search results). For filtered facet pages where you want Google to understand the content but not index it,noindex with a canonical is usually the right call.
クロール予算の問題を修正した後、改善が見られるまでの現実的な期間はどのくらいですか？
正直に言うと、クロール率によります。91,000 ページのプロジェクトでは、主な修正を展開してから、インデックス登録ページ数の有意な変動が見られるまでに約 6 ～ 8 週間かかりました。一夜にして変わることを期待しないでください。Googlebot は再クロール、再評価する必要があり、インデックス作成パイプライン自体も遅延があります。
---
91,000 ページのプロジェクトは上手くいきました。インデックス登録ページ数が 5 ヶ月間で 34,000 から 71,000 を超える数に増加しました。完璧ではありません。本来インデックスされるべきではない、実質的に薄い商品ページがありました。しかし、重要なコンテンツは発見されました。クライアントは何か壊れているのかを尋ねなくなりました。そして私は、クロールレポートの 47,000 ページ付近でキャリア転職を検討することもなくなりました。ほぼ。