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

クロールバジェットとは、一定期間内にGooglebotがサイト上でクロールしようとするページ数のことです。小規模サイトでは事実上、上限はありません。数百万URLを抱えるサイトでは、戦略的な資源になります。フィルター、ページネーション、中身のないテンプレート、ステージング用ページにバジェットが消費され、優先したいコンテンツがクロールされなくなるためです。その結果、新商品のインデックス登録が遅れ、カタログのカバー率が下がり、検索順位も落ちます。

zoom_in

ステップ1：クローラーのログを収集して分析する

Googlebotが実際に何をクロールしているかを知る最も確かな情報源は、Webのサーバーログです。ログ分析で、実際のリクエスト頻度、ボットが無視している、または迷い込んでいるセクション、サーバーが返すHTTP応答が分かります。ログがなければ、最適化はすべて推測になります。

Nginx / ApacheからGooglebotのリクエストを抽出する

# Filter only Googlebot requests from the last 7 days
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $7}' \
  | sort | uniq -c | sort -rn \
  | head -50

# HTTP status codes seen by Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '{print $9}' \
  | sort | uniq -c | sort -rn

# Top URLs returning 404 to Googlebot
grep 'Googlebot' /var/log/nginx/access.log \
  | awk '$9 == "404" {print $7}' \
  | sort | uniq -c | sort -rn | head -30

大量のログを構造的に分析するなら、専用ツールを使います。Screaming Frog Log File Analyser、Semrush Log Analyser、ELKスタック（Elasticsearch + Kibana）などです。URLをパターンごとに自動でグループ化し、クロール頻度の推移をグラフにしてくれます。

ステップ2：Google Search Consoleとサーバー応答の分析

Google Search Consoleは、サーバーログにアクセスしなくても、集計済みのクロールデータを提供します。入り口になるのは「クロールの統計情報」レポートです。1日あたりの平均リクエスト数、ページの読み込み速度の目安、レスポンスコードの分布が分かります。

• GSC → 設定 → クロールの統計情報：クロールリクエストのグラフと、ファイル種別・レスポンスコード別の内訳。404や500の急増、デプロイ後の落ち込みを探します。
• GSC → インデックス作成 → ページ：インデックス登録されたURL数と、登録されない理由の比較。「検出 - インデックス未登録」は、クロールバジェット不足を直接示すシグナルです。
• GSC → URL検査：特定のページの状態を手動で確認します。最後にクロールされた日時と、Googlebotが見た内容が分かります。
• GSC → 設定 → クロールレート：ボットがサーバーに負荷をかけている場合は、クロールレートを抑えられます。通常は不要で、計測できるパフォーマンス問題があるときだけ制限します。

クロールバジェットを浪費する原因

大規模サイトでボットがバジェットを失う原因は、典型的には6つあります。ログで1つずつ特定して量を見積もると、最適化の優先順位が決まります。

zoom_in

URLパラメーターと重複：対処法

ECサイトで最大のバジェット浪費源は、パラメーター付きURLです。万能の解決策はなく、パラメーターの性質によって適切な対処が変わります。

# robots.txt — blocking parametric URLs
User-agent: *

# Sort and filter parameters
Disallow: /*?sort=
Disallow: /*?order=
Disallow: /*?filter=
Disallow: /*?color=
Disallow: /*?size=

# Pagination deeper than page 3 (Allow/Disallow approach)
Disallow: /*?page=
Allow: /*?page=1
Allow: /*?page=2
Allow: /*?page=3

# Session and tracking parameters
Disallow: /*?sessionid=
Disallow: /*?token=
Disallow: /*?ref=
Disallow: /*?utm_

# Preview and drafts
Disallow: /*?preview=
Disallow: /*?draft=

フィルター、ファセット、ページネーション

ファセットナビゲーションは最も厄介なケースです。URLの組み合わせが爆発的に増えます。値が5つあるフィルター10個なら、組み合わせは100万を超える可能性があります。目標は、価値のあるファセット（ブランド＋カテゴリ）を残し、無駄な組み合わせをブロックすることです。

1. 価値のあるファセットを特定する：オーガニックトラフィックが多いページや、独自のSEOコンテンツがあるページ（ブランド専用の文章がある /catalog/nike/ など）は、自己参照のcanonicalタグを付けてインデックスに残します。
2. 価値の低い組み合わせにはnoindex + followを付ける：ページは表示され（リンクはたどられます）、インデックスには入りません。複数のファセットが有効なとき、テンプレートで<meta name="robots" content="noindex, follow">を出力します。
3. 純粋に技術的なパラメーターはDisallowする：並べ替え、色、サイズにSEOの価値がなければ、robots.txtでブロックします。
4. AJAXで読み込むファセット：ファセットをJavaScriptで読み込み、URLに反映しなければ、ボットは追加のURLを見つけません。アーキテクチャのレベルで問題を解決できます。

ページネーション：canonicalタグかDisallowか

最適なページネーション戦略は規模で変わります。10ページまでなら、クロールを許可し、2ページ目以降に1ページ目を指すcanonicalタグを付けます。数百ページに及ぶ場合は、3〜5ページ目より先をDisallowします。URLパラメーターを使わない無限スクロールは、ボットから1ページとして扱われるため、バジェットの面では有利です。

一時的なページ：ウェビナー、モックアップ、デモ

マーケティングチームが活発なサイトでは、一時的なページがバジェットをひそかに消耗させます。ウェビナーのランディングページ、デモ用モックアップ、クライアント向けプレビュー、A/Bテストのバリアント。すぐに作られ、そのまま残り続けることが多く、気づかないうちにクロールバジェットを消費します。

• meta robotsのnoindex：一時的なページすべてのテンプレートに<meta name="robots" content="noindex, nofollow">を追加します。ボットは訪問してディレクティブを読み、そのURLをインデックスから外します。テンプレートを触れるなら、最も簡単な方法です。
• X-Robots-Tag HTTPヘッダー：一時的なページに専用のHTMLテンプレートがない場合（生成したPDFやファイルなど）は、HTTPレスポンスヘッダーX-Robots-Tag: noindex, nofollowを使います。
• パスのプレフィックスでDisallow：一時的なページが予測しやすいパスの下にあるなら、robots.txtでブロックします。インデックス済みのURLが消える保証はありませんが、新しいURLはクロールされなくなります。
• HTTP認証：ステージングやプレビューのページを完全に隔離できる、唯一の確実な方法です。Googlebotは認証情報を持たないので、ページをクロールしません。

# robots.txt — patterns for temporary pages
User-agent: *

# Webinars and events
Disallow: /webinars/
Disallow: /events/draft-
Disallow: /landing/test-

# Mockups and previews
Disallow: /_preview/
Disallow: /mockups/
Disallow: /demo/

# A/B tests and experiments
Disallow: /*?variant=
Disallow: /*?experiment=
Disallow: /*?ab_test=

# Template preview parameters
Disallow: /*?preview=
Disallow: /*?draft=
Disallow: /*?revision=

大規模サイトのサイトマップインデックス

URLが数百万ある場合、1つのXMLサイトマップでは対応できません。上限は50,000 URLまたは50MBです。サイトマップインデックスは、子のサイトマップを指す目次ファイルです。これで優先度を構造化し、バジェットを最も必要な場所へ向けられます。

<?xml version="1.0" encoding="UTF-8"?>
<sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <!-- Priority sections — crawled first -->
  <sitemap>
    <loc>https://example.com/sitemap-products.xml</loc>
    <lastmod>2026-05-15</lastmod>
  </sitemap>
  <sitemap>
    <loc>https://example.com/sitemap-categories.xml</loc>
    <lastmod>2026-05-15</lastmod>
  </sitemap>
  <!-- Lower-priority sections -->
  <sitemap>
    <loc>https://example.com/sitemap-blog.xml</loc>
    <lastmod>2026-05-10</lastmod>
  </sitemap>
  <!-- Do NOT include noindex pages or duplicates! -->
</sitemapindex>

• コンテンツの種類ごとにサイトマップを分ける：商品、カテゴリ、ブログ、静的ページをそれぞれ別ファイルにします。GSCでセクション別のインデックス登録状況を確認できます。
• lastmodは正直に書く：lastmodはボットに更新の新しさを伝えます。今日の日付ではなく、実際に最後に変更した日付を設定します。そうしないと、ボットはこのシグナルを信用しなくなります。
• ブロックしたURLは含めない：noindexやDisallowのページをサイトマップに入れると、ボットに矛盾したシグナルを送ります。
• 子サイトマップの上限：各ファイルは最大50,000 URLまたは50MB（圧縮後）です。超えたら分割します（sitemap-products-1.xml、sitemap-products-2.xml）。

サーバー設定とレート制限

サーバー側は、クロールバジェットに両方向で影響します。応答が遅いとGoogleはクロールの強度を下げます。5xxエラーが出るとボットは待機して再試行に時間を費やします。サーバーの最適化は、クロール効率を直接改善します。

# Nginx: return 429 when any crawler sends too many requests
limit_req_zone $http_user_agent zone=crawlers:10m rate=10r/s;

location / {
    limit_req zone=crawlers burst=20 nodelay;
    limit_req_status 429;
    # ... other settings
}

KPIとモニタリング

クロールバジェットは継続的な監視が必要です。デプロイのたびに、パラメーター付きの新しいURLが何千も誤って公開される可能性があります。次の指標を、週次のダッシュボードと月次のレビューで確認します。

• 毎週：GSCのクロールリクエスト数を、今週と前週で比較します。急増は、直近のデプロイで新しい重複が生まれたサインです。
• 毎月：GSC → ページ → 「検出 - インデックス未登録」を確認します。サイトの規模が変わらないのに増えているなら、クロールバジェットの問題です。
• 大きなデプロイのたび：サイトに対してScreaming Frogを実行し、ユニークURLの数を確認します。前回のスナップショットと比較します。
• 四半期ごと：30日分のログを完全に分析します。更新したコードで生まれた、パラメーター付きURLの新しいパターンを探します。
• アラート：5xxの応答が1日のGooglebotの全リクエストの1%を超えたら通知されるように設定します。

すぐできる改善とロードマップ

クロールバジェットの最適化は、一度きりの作業ではなく継続的なプロセスです。作業は、すぐできる改善（1〜2週間で効果が出る）と、体系的な変更（1〜3か月）に分けます。

すぐできる改善のチェックリスト

• 一時的なページ（ウェビナー、モックアップ、デモ）のテンプレートすべてにnoindexを追加した
• robots.txtで ?preview=、?draft=、?sessionid=、?utm_ をDisallowした
• パラメーター付きのページすべて（並べ替え、2ページ目以降）で、クリーンなURLを指すcanonicalタグを設定した
• noindexとDisallowのページをサイトマップから外した
• サイトマップインデックスをセクション別に分割し、lastmodを正確にした
• リダイレクトチェーンを1ホップに減らした
• Googlebotのログで404が5%未満になり、リンク切れをなくした
• GSCに週次のモニタリングダッシュボードを設定した

FAQ