大規模なEC・求人・不動産・メディアサイトでは、Googlebotが商品や記事ではなく、絞り込み条件、並べ替え、内部検索、重複URLばかり取得していることがあります。ただし、クロール数が多いだけでは問題とは判断できません。重要なのは、Googlebotの実リクエストをサーバーログで確認し、クロールさせたいURL集合と突き合わせることです。
クロールバジェット監査では、URL群ごとのリクエスト配分、HTTPステータス、応答時間、更新後の再クロールまでを比較します。本記事を読めば、無駄クロールの発生源を特定し、影響度と修正難易度から着手順を決め、変更後の効果まで検証できるようになります。
クロールバジェット監査が必要なサイトを最初に見極める
クロールバジェットは、すべてのサイトで優先すべき課題ではありません。Googleは、主な対象として「重複のないページが100万以上で週次更新」「1万ページ以上で毎日更新」「URLの大部分が『検出－インデックス未登録』」のいずれかに該当するサイトを挙げています。数値は厳密なしきい値ではなく、規模の目安です。
Googleが説明するクロールバジェットは、Googleがサーバーに負荷をかけずに取得できる量である「クロール能力の上限」と、Googleが取得する必要性を判断する「クロールの必要性」で決まります。サーバーを高速化して取得能力を上げても、重複や低価値ページが多く、クロール需要が低ければ重要ページの取得は増えません。
監査を始める前に、次の条件を確認します。
| 確認項目 | 監査の必要性が高い状態 | 主な確認データ |
|---|---|---|
| URL規模と更新量 | 1万URL以上で日次更新、または100万URL以上で週次更新 | CMS・データベース・XMLサイトマップ |
| 未登録URL | 「検出－インデックス未登録」が広いURL群で増えている | Search Console |
| URL増殖 | 絞り込み、並べ替え、検索、セッションIDなどでURLが大量生成される | URL一覧・クロールデータ |
| 発見速度 | 新規・更新ページのクロールが事業上の必要時期に間に合わない | 公開日時・ログの初回取得日時 |
| サーバー状態 | Googlebotへの5xx、429、タイムアウト、応答遅延がある | クロール統計・サーバーログ |
数百ページ程度で、新規ページが速やかにクロールされている場合は、クロールバジェットよりもコンテンツ品質、内部リンク、インデックス可否の確認を優先します。
監査ではSearch Console・サーバーログ・URL台帳を突き合わせる
クロールバジェット監査は、1つのツールだけでは完結しません。Search ConsoleはGoogle側の傾向を把握する入口、サーバーログはGooglebotが実際に取得したURLの記録、URL台帳は各URLを「クロールさせたいか」で判定する基準として使います。
Search Consoleで全体傾向を捉え、サーバーログの実リクエストをURL台帳とサイトマップの方針に照らすことで、改善対象となる差分を特定します。
| データ | 分かること | 分からないこと・注意点 |
|---|---|---|
| Search Consoleのクロール統計 | リクエスト総数、応答サイズ、応答時間、ステータス別・目的別の傾向 | 個別URLを完全に一覧化する用途には向かない |
| サーバー／CDNログ | 取得URL、時刻、ユーザーエージェント、IP、HTTPステータス、応答時間 | URLの事業価値や正規URLかどうかは別途付与が必要 |
| URL台帳 | 正規URL、テンプレート、公開状態、インデックス方針、更新頻度 | 実際にGooglebotが取得したかは分からない |
| XMLサイトマップ | クロールさせたい正規URLと最終更新日 | サイト内の不要URLや孤立URLは網羅しない |
| 外部クローラー | 内部リンクから到達できるURL、canonical、robots、ステータス | Googlebotの実行動作そのものではない |
最低限、ログには日時、リクエストURL、HTTPメソッド、ステータス、応答時間、ユーザーエージェント、接続元IPが必要です。CDNとオリジンサーバーの両方にログがある場合は、二重集計を避け、Googlebotへの最終レスポンスを確認できる側を基準にします。
ユーザーエージェント名だけでGooglebotと判定してはいけません。文字列は偽装できるため、Googleが公開するIP範囲との照合、または逆引きと正引きを組み合わせた確認を行います。逆引き先が `googlebot.com`、`google.com`、`googleusercontent.com` のいずれかで終わり、正引きで元のIPに戻ることを確認してから集計対象にします。
STEP1｜監査期間とクロールさせたいURL集合を固定する
クロールバジェット監査は、対象判定から始め、Googlebotの実ログを基に改善し、同じ条件で再測定する6段階で進めます。
最初に、比較できる期間とURL分類を決めます。通常は直近28日を起点にし、曜日差や更新サイクルが長い場合は56日または90日に広げます。サイト移転、障害、大量公開、robots.txt変更があった期間は、平常時と分けて記録します。
URL台帳には、少なくとも次の項目を持たせます。
- 正規化後URL
- URLテンプレートまたはディレクトリ
- ページ種別
- HTTPステータス
- canonical指定先
- robots.txtの許可・拒否
- meta robotsの状態
- XMLサイトマップ掲載有無
- インデックスさせたいか
- 更新頻度
- SEOまたは事業上の優先度
URLは「重要URL」「維持URL」「条件付きURL」「不要URL」「廃止URL」に分類すると、ログとの比較が容易です。重要URLは新商品、募集中求人、主要カテゴリなど、発見や更新反映を急ぐページです。条件付きURLは検索需要のある一部の絞り込みページ、不要URLは並べ替えやトラッキングパラメータ、廃止URLは削除済み商品などを想定します。
STEP2｜Googlebotの実ログをURL群別に集計する
確認済みGooglebotのログだけを抽出し、URLを正規化してテンプレート単位にまとめます。クエリパラメータを機械的に削除すると、問題のある組み合わせURLを見失うため、原URLと正規化URLの両方を保持してください。
監査の中心指標は次の5つです。
全体のクロール数だけでなく、5つの指標をURL群別に比較すると、重要URLへの配分と改善余地を判断できます。
| 指標 | 計算方法 | 判断できること |
|---|---|---|
| クロール配分率 | URL群のGooglebotリクエスト数 ÷ 全Googlebotリクエスト数 | どのURL群に取得が集中しているか |
| 無駄クロール率 | 不要・廃止URLへのリクエスト数 ÷ 全Googlebotリクエスト数 | 改善余地の大きさ |
| 重要URL到達率 | 期間中に1回以上取得された重要URL数 ÷ 重要URL総数 | 優先URLがカバーされているか |
| 更新反映遅延 | 更新日時から次回Googlebot取得日時までの時間 | 更新ページの再取得速度 |
| エラー比率 | 5xx・429等のリクエスト数 ÷ 全Googlebotリクエスト数 | クロール能力を下げる技術問題 |
たとえば、28日間に確認済みGooglebotのリクエストが120万件あり、不要URLへのリクエストが36万件なら、無駄クロール率は30%です。これは業界基準ではなく、そのサイト内で改善前後を比較するための値です。重要URL到達率や更新反映遅延と一緒に見て、不要URLへの集中が重要URLの遅れと同時に起きているかを確認します。
STEP3｜無駄クロールを原因別に分類する
無駄なURLを一括して処理すると、検索需要のあるページまで消す危険があります。発生原因、検索価値、現在のインデックス状態を分けて判定します。
パラメータ・ファセットURL
色、サイズ、地域、価格、並べ替えなどの組み合わせは、URL空間を急速に増やします。Googleは、ファセットナビゲーションが事実上無限のURLを作り、新しい有用なURLの発見を遅らせる可能性を説明しています。一方、地域×職種など検索需要を持つ組み合わせもあるため、すべてをブロックするのではなく、インデックス対象と非対象をルール化します。
重複URL・canonical不整合
HTTP／HTTPS、www有無、末尾スラッシュ、大小文字、トラッキングパラメータなどで同じ内容が複数URLに分かれていないか確認します。canonicalは統合のシグナルですが、不要URLを大量に生成し続けてよいという意味ではありません。内部リンク、サイトマップ、リダイレクト、canonicalの向きをそろえます。
削除URL・soft 404・リダイレクトチェーン
完全に削除したURLは404または410を返します。内容がないのに200を返すsoft 404は修正対象です。移転先がある場合は最終URLへ直接301を返し、AからB、BからCのような連鎖を解消します。404をゼロにするため、無関係なトップページへ一律転送する運用は避けてください。
サーバーエラー・レート制限・応答遅延
Googleの公式情報では、応答遅延、5xx、HTTP 429などが増えると、クロール能力の上限が下がる可能性があります。URL群別、時間帯別、ホスト別にエラーと応答時間を集計し、アプリケーション、CDN、データベース、WAFのどこで発生しているかを切り分けます。
STEP4｜影響度・確信度・工数で改善優先度を決める
改善順は、リクエスト件数だけでは決めません。「重要URLへの影響」「原因判定の確信度」「修正工数」「誤って必要URLを止めるリスク」を合わせて評価します。
実務では、次の式で優先度スコアを付けると判断を共有しやすくなります。
`優先度スコア ＝ 影響度（1～5）× 確信度（1～5）÷ 工数（1～5）`
影響度には、無駄リクエスト数だけでなく、重要URL到達率、更新反映遅延、エラー率への寄与を含めます。この式はGoogleの指標ではなく、社内の着手順を決めるための管理方法です。
影響度が大きく、原因判定の確信度が高く、修正工数が小さい施策から優先します。式はGoogleの指標ではなく、社内の意思決定用です。
| 問題 | 主な修正 | 優先度を上げる条件 | 変更時の注意 |
|---|---|---|---|
| 5xx・429・大幅な遅延 | 容量、キャッシュ、WAF、アプリケーションを修正 | 重要URLにも発生し、クロール量が低下 | 障害対応として最優先 |
| 無限に増える不要ファセット | URL生成制御、内部リンク整理、必要に応じrobots.txt | リクエスト比率が高く、検索価値がない | 既存インデックス削除は別手順が必要 |
| 重複URL | リダイレクト、canonical、内部リンク、サイトマップ統一 | 多数の重複へ継続的にクロール | canonicalだけに依存しない |
| 削除済みURL・soft 404 | 404/410、または適切な移転先へ301 | 200応答の空ページが大量にある | 関連性のない一律転送を避ける |
| 更新ページの発見遅延 | 内部リンク、サイトマップ、正確なlastmodを修正 | 事業上重要な更新が間に合わない | lastmodは実質変更時だけ更新 |
| 応答ボディの再取得 | HTTPキャッシュと304対応を確認 | 未変更ページの取得負荷が大きい | キャッシュ整合性を検証 |
`noindex`は、クロール停止の即効策ではありません。Googleは指定を読むためにURLへアクセスする必要があります。また、robots.txtはクロールを止める仕組みであり、すでに登録されたURLを確実に検索結果から消す仕組みではありません。目的に応じて、URL生成停止、404/410、301、canonical、noindex、robots.txtを使い分けます。
STEP5｜修正後はクロール量ではなく配分の変化を検証する
修正後の成功は、全体のクロール数が増えたかではなく、重要URLへ配分が移り、更新反映が速くなり、サーバーエラーが減ったかで判断します。robots.txtで不要URLを止めても、サイトがクロール能力の上限に達していなければ、空いた分が他URLへ自動的に再配分されるとは限りません。
変更日を記録し、変更前後で同じ長さの期間を比較します。大規模変更はディレクトリやテンプレート単位で段階的に実施すると、原因と効果を追いやすくなります。
- 不要URL群のクロール配分率が低下したか
- 重要URL到達率が上昇したか
- 新規・更新URLの取得遅延が短くなったか
- 5xx、429、タイムアウトが減ったか
- 正規URLとサイトマップ掲載URLへのクロールが増えたか
- 検索流入やインデックス対象URLに悪影響がないか
改善が見られない場合は、Googleが別経路から不要URLを発見していないか、URL分類が粗すぎないか、重要URL自体の品質・内部リンク・更新価値に問題がないかを再確認します。
クロールバジェット監査で避けたい5つの判断ミス
- 小規模サイトで監査を最優先する：対象外のサイトでは、インデックス阻害、内部リンク、コンテンツ品質を先に確認します。
- ユーザーエージェントだけでGooglebotを判定する：IPを確認しない集計は、偽装ボットによって歪む可能性があります。
- クロール数の増加を成功指標にする：順位や登録を直接保証しません。重要URLへの配分と反映速度を見ます。
- 不要URLをすべて同じ方法で処理する：削除、重複、インデックス不要、クロール不要では適切な制御が異なります。
- 修正後にログを再取得しない：設定変更だけで完了にせず、実リクエストの変化を確認します。
まとめ
クロールバジェット監査の目的は、クロール数をむやみに増やすことではなく、Googlebotの限られた取得を事業上重要なURLへ向けることです。まず対象サイトかを見極め、確認済みGooglebotのログとURL台帳を突き合わせます。そのうえで、無駄クロール率、重要URL到達率、更新反映遅延、エラー比率をURL群別に比較してください。
このテーマの全体像や前提を確認したい場合は、「テクニカルSEOとは？クロールからセキュリティまで、企業担当者が押さえるべき7領域の実務チェックリスト」もあわせて確認してください。
改善は、サーバー障害、無限URL、重複、soft 404、発見経路の順に、影響度と工数を見ながら進めます。変更後は同じ条件でログを再集計し、重要URLへの配分と取得速度が改善したことまで確認して、監査を完了します。
参考文献・データ元
- 「クロール バジェットを最適化する」Google Crawling Infrastructure、最終更新2026年8月4日。クロールバジェットの対象、定義、URL群管理、HTTPステータス、キャッシュに関する根拠として使用。https://developers.google.com/crawling/docs/crawl-budget?hl=ja
- 「ファセット ナビゲーション URL のクロールを管理する」Google Search Central。ファセットURLが過剰なURL空間を生む問題と管理方針の根拠として使用。https://developers.google.com/search/docs/crawling-indexing/crawling-managing-faceted-navigation
- 「Google クローラーとフェッチャーからのリクエストを確認する」Google Crawling Infrastructure。GooglebotのIP範囲およびDNSによる確認方法の根拠として使用。https://developers.google.com/crawling/docs/crawlers-fetchers/verify-google-requests
- 「クロールの統計情報レポート」Google Search Console ヘルプ。クロールリクエスト、応答、目的、ホスト状態の確認項目として使用。https://support.google.com/webmasters/answer/9679690?hl=ja
- 「サイトマップを作成して送信する」Google Search Central。正規URLとlastmodを含むサイトマップ運用の根拠として使用。https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap