クロールバジェット：大規模サイトの実践ガイド

800ページなら追加予算はほぼ不要です。フィルターで80,000 URLを作ると、登録不要な場所へGooglebotの時間を使わせます。GSCの症状が似ても対策は全く違います。

本ガイドは、検出済み・未登録が多い、サイトマップ発見が遅い、ログにパラメーター要求が多いEC、メディア、市場、プログラマティックSEO向けです。

クロールバジェットとは？

一定期間にGoogleが取得でき、したいURLの集合で、2要素があります。

• 容量上限： サーバーを過負荷にせず送れる要求数です。
• 需要： 新しさ、人気、品質、価値に基づく再訪意欲です。

高速化は容量を改善しますが、増加を保証しません。薄い、ほぼ同一、需要のない数千URLでは、需要は低いままです。

主に非常に大きなサイト、毎日変わる約10,000以上のURL、または検出済み・未登録の割合が多い場合に関係するとGoogleは説明します。小ブログならきれいなサイトマップと適切なリンクで十分です。

まず予算が本当の問題か確かめます

robots.txtから始めず、4問に答えます。

1. 重要URLは公開や重要更新後すぐ取得されますか？
2. 多数の有効URLが何週間も検出済み・未登録ですか？
3. Crawl Statsにパラメーター、検索、重複への要求が多いですか？
4. 増加時に5xx、タイムアウト、遅い応答が頻発しますか？

すべていいえなら、品質、リンク、登録可否が原因である可能性が高いです。

直感でなくログから始めます

GA4 はサーバーのアクセスログを提供しません。リクエストされた URL、ステータス、時刻は、閲覧権限のあるログで確認してください。公開タグの確認だけでは、これらの記録は取得できません。

有用な基準レポートには次を含めます。

User-Agentを盲信しないでください。悪質ボットが名乗るため、逆引きDNSや公式IPで検証してから報告へ入れます。

効率を改善する7つの方法

1. 発見可能なURL在庫を減らします

ファセットは典型的な原因です。10フィルター、各複数値、自由な組み合わせで数万URLを作れます。

3群に分けます。

• 独自価値と検索需要：登録、自己参照、内部リンクを用意します。
• 訪問者向けで検索不要：意図して取得と登録を制御します。
• 無価値：生成とリンクを止めます。

タグを読むため取得するのでcanonicalだけではなくなりません。不要URLを広めないのが最も有効です。

2. サイトマップを優先一覧にします

DBの全件出力ではなく、次だけを含めます。

• 正規URLです。
• 200を返します。
• 登録可能です。
• 十分に有用です。
• 真実の<lastmod>です。

フッター反映ごとに全部変えると価値が下がります。本文、商品データ、重要情報が変わるときに更新します。

Sitemap Checkerでインデックス、URL数、lastmodの範囲を確認します。

3. 転送チェーンと古いリンクを除きます

A → B → C → Dは到着を遅らせ保守を増やします。内部リンクとサイトマップはDへ直接向けます。

移行後、古い転送を早く消さず、1段へ縮めて要求をログで監視します。Redirect Chain Checkerで全段階をすぐ確認できます。

4. 意味のある状態コードを返します

永久削除は404か410にし、200の不在表示にしません。Soft 404は無価値URLの処理を続けさせます。

反復する5xxとタイムアウトは深刻です。追加負荷回避で容量が下がる場合があります。時刻とテンプレートで分類し、欠陥と急増を区別します。

5. 取得と描画を軽くします

速い応答、簡潔なHTML、安定資源で同条件でも多く処理できます。TTFB、キャッシュ、DB、画像、JSは体験だけでなく取得効率にも影響します。

重いJSはHTML取得後の描画も必要です。SSRや重要部分の事前描画で待ち行列依存を減らします。

6. 事業価値に沿ってリンクを作ります

サイトマップにしかない重要URLは弱く見えます。カテゴリー、ハブ、パンくず、関連内容で自然な経路を作ります。

編集者が訪問経路を説明できなければ、クローラーも困るかもしれません。

7. 大量公開と更新を計画します

一度に数十万件を変えると負荷が集中します。適切な分割、種別ごとのサイトマップ、正しいlastmodで更新へ集中させます。

逆効果な予算の「裏技」

全体にnoindexを付けます

noindexを読むため取得するので要求は減りません。robotsも気軽な調整つまみではなく、遮断URLが長く認識・待機され得ます。

CSSとJavaScriptを遮断します

描画と評価に必要です。遮断すると不完全、またはモバイルに不適切に見える場合があります。

サイトマップ交換で優先を強制します

発見は助けますが割当保証ではありません。整理は在庫を明確にしても薄い内容に価値を与えません。

何としても頻度を上げます

遅い・失敗中のサーバーには悪化を招きます。量より先に健全性を回復します。

大規模サイトの14日計画

1–3日目：基準を作ります

Crawl Stats、登録レポート、7–14日のアクセスログを出力し、テンプレート、状態、パラメーター、応答時間で分類します。

4–6日目：最大の浪費元を3つ選びます

通常はファセット、転送、Soft 404です。20問題を一度に直すと、効果を帰属できません。

7–10日目：生成元を直します

部品からパラメーターを除き、URL生成、サイトマップ、状態を直します。テスト環境で試しますが、評価されるのは公開側です。

11–14日目：リリースを監視します

優先URL要求、5xx頻度、応答時間、登録変化を比べます。一晩で変わりませんが、ログは総合報告より早く示します。

Search Consoleとログ

GSCは取得傾向、登録、全体エラーに最適です。ログは、どのボットがいつどのURLへ、何の状態・遅延で要求したかに答えます。

補完する情報源です。GSCが地図、ログが足跡です。

成功はどう見えるべきですか？

要求総数で判断しないでください。成功しても量は横ばいで、行き先だけが変わることがあります。

4から6週間、小さな指標表を追います。

• 正規の200ページへ届く割合です。
• パラメーター、転送、Soft 404、エラーへの浪費です。
• 最多取得テンプレートの応答中央値です。
• 重要URLの公開から初回取得までの時間です。
• 検出済み・未登録の価値あるURL数です。
• 取得ピーク時のサーバーエラーです。

最善は単なる取得増でなく、重要変更の早い発見、無用な別版への要求減、安定した性能です。

季節性も重要です。セール前の市場、速報時のメディア、移行後のカタログは一時変動します。同等期間で比べ、リリースへ注記し、忙しい1週だけで誤結論を出さないようにします。

最後に取得と登録を分けます。頻繁に取得しても、薄い、重複、有用性不足なら未登録のままです。確実な到達をログで確認したら、ルール調整をやめ、ページ自体を改善します。

出発点： 無料SEO監査でサイトマップ、robots、転送、登録可否を確認し、ログで実クロールを測ります。

まとめ

予算最適化は訪問回数を増やす裏技ではなく、価値あるURLへ現存の活動を向け、速く安定して返すことです。不要在庫、正確なサイトマップ、状態、短い転送、優先リンクを整えます。小規模なら内容品質への投資の方がよい場合が多いです。

参考：Google Search Centralの予算管理とGooglebot文書です。