XMLサイトマップのpriorityとchangefreqはクロール頻度を変えますか？

Googleはpriorityとchangefreqを無視します。canonical URLを掲載し、重要な変更があったときだけ正確なlastmodを更新することが重要です。

クロールバジェットとは？SEOへの影響・確認方法・改善手順【2026年最新】

Q: 小規模サイトでもクロールバジェット対策は必要ですか？

多くの場合、専用施策は不要です。Googleは主に100万URL以上で週次更新するサイト、1万URL以上で日次更新するサイト、または『検出 - インデックス未登録』が大きな割合を占めるサイト向けの高度なガイドとしています。小規模サイトは内部リンク、サイトマップ、canonical、品質、Page Indexingの確認を優先します。

Q: クロール回数を増やせば検索順位は上がりますか？

保証されません。クロールは検索結果に出るための前工程ですが、順位を決めるランキングシグナルそのものではありません。クロール後にもレンダリング、重複統合、品質評価、インデックス判断があります。

Q: noindexを付けるとクロールバジェットを節約できますか？

直接のクロール停止策にはなりません。Googlebotはnoindexを読むためにページを取得します。インデックスから外す目的にはnoindexを使い、長期的にクロール不要なURLはURL生成、内部リンク、canonical、robots.txtを目的別に整理します。

Q: robots.txtでブロックすれば検索結果から消えますか？

保証されません。robots.txtはクロールを制御しますが、外部リンクなどからURLが知られている場合は内容を取得せずURLだけが検索結果に出る可能性があります。検索結果から除外するなら、クロール可能な状態でnoindexを認識させるか、認証で保護します。

Q: 404はすべて別ページへリダイレクトすべきですか？

いいえ。代替先がある移転は301または308などの恒久リダイレクトを使い、代替先のない永久削除は404または410を返します。関係のないトップページへ一律転送するとsoft 404と判断される可能性があります。

Q: サーバーを高速化すればクロールは必ず増えますか？

必ずではありません。速度改善はクロール能力の制約を緩める可能性がありますが、クロール需要が低ければ取得は増えません。Crawl StatsやURL Inspectionでhostloadや可用性の制約を確認してから判断します。

Google Crawling InfrastructureとGoogle Search Centralの一次資料を2026年7月29日に再確認しました。主要なクロールバジェット資料は2026年7月22日、canonical資料は7月10日、サイトマップ資料は7月8日に更新されています。

結論から言うと、一般的な小規模サイトでは「クロールバジェット対策」を独立施策にする必要はほとんどありません。重要URLが取得されない、不要なパラメータURLへ要求が集中する、ホスト可用性に警告がある、といった証拠がある大規模・高頻度更新サイトで初めて本格的に診断します。

30秒で分かる結論

まず「本当にクロールバジェット問題か」を判定する

Googleの高度なガイドが想定するのは、主に週次更新する100万URL以上、日次更新する1万URL以上、またはSearch Consoleで「検出 - インデックス未登録」が大きな割合を占めるサイトです。数値は厳密なしきい値ではありません。

対象になりやすい大規模EC、求人、不動産、ニュース、UGC、商品在庫が頻繁に変わるサイト

最初に見る証拠重要URLの取得遅延、5xx・429、Hostload exceeded、不要URLへの大量要求

成功指標総クロール数ではなく、重要URLの適時取得率と不要URL比率の改善

意味	Googleが、そのhostnameで「クロールでき、かつクロールしたい」と判断するURLの集合
構成要素	クロール能力の上限（crawl capacity limit）とクロール需要（crawl demand）
主な対象	100万URL以上で週次更新、1万URL以上で日次更新、または「検出 - インデックス未登録」が多いサイト
主な確認先	Crawl Stats、URL Inspection、Page Indexing、検証済みGooglebotのサーバーログ
主な改善	可用性、誤ブロック、重複・faceted URL、soft 404、リダイレクト、サイトマップ、HTTPキャッシュ
成功KPI	重要URLの取得遅延、未取得率、不要URL比率、5xx・429、応答時間をURL群ごとに比較
保証しないもの	インデックス登録、検索順位、流入、売上。クロール後にも別の評価工程があります

クロールバジェットとは「クロール能力」と「クロール需要」の交点

クロールバジェットは、サーバーが耐えられるアクセス数だけで決まりません。Googleは、サイトを過負荷にしないためのクロール能力の上限と、更新・人気・品質・固有性などから判断するクロール需要を組み合わせます。Googleのクロール基盤では、サイトは基本的に固有のhostname単位で扱われるため、www.example.comとshop.example.comは別々に観察します。

クロール能力の上限

Googlebotがサーバーを不安定にしない範囲です。並行接続数、接続時間、レイテンシ、TTFB、5xx、429、DNS・ネットワーク障害などで上下します。

並行接続数 × 接続時間 × ホストの健全性

クロール需要

GoogleがURLを取得・再取得したい度合いです。人気、全体的なユーザー価値、コンテンツの固有性、重要な更新、サイト移転などが関係します。

更新必要性 × 価値 × 固有性 × 発見信号

重要：サーバーが速くても、クロール需要が低ければ取得数は増えません。反対に、重要な高品質コンテンツが未取得で、サーバー能力が上限に達している証拠があれば、基盤増強が有効になる場合があります。

クロール、レンダリング、インデックス、ランキングは別工程

クロールされたページが必ずインデックスされるわけではありません。Googleは取得後にレンダリング、重複統合、品質・有用性の評価、canonical選択などを行います。検索順位はさらに後段です。したがって、クロール回数の増加をSEO成果そのものとして扱わないことが大切です。

クロールバジェット対策が必要なサイトを先に判定する

規模だけで判断せず、重要URLが必要な時期に取得されていない証拠まで確認します。公開当日のクロールを通常要件にするのではなく、商品在庫、ニュース、求人締切など、事業上の許容時間を先に決めてください。

本格診断を検討

規模と症状がそろっている

固有URLが100万以上あり、週1回程度内容が変わる
固有URLが1万以上あり、価格・在庫・ニュースが毎日変わる
「検出 - インデックス未登録」が全体の大きな割合を占める
重要URL群の取得が業務上の許容時間を超える
サーバーログでfilter・sort・calendar URLへの大量要求が見つかる
Crawl Statsに5xx、429、DNS、接続、hostloadの問題がある

通常SEOを優先

クロールバジェットより別原因が濃い

URL数が少なく、公開後に妥当な期間で取得されている
ログでは200取得済みだが、Page Indexingでは未登録
重複、薄い内容、誤canonical、レンダリング不良がある
内部リンクがなく、サイトマップにもURLがない
「毎日クロールされない」ことだけを問題にしている
クロール総数の増加だけをKPIにしている

1. 重要URLを定義商品、記事、求人、イベントなど、取得されるべきURL群と許容時間を決める。

2. 未取得を証明サーバーログでGooglebot取得日時を確認し、Page Indexingと混同しない。

3. 原因を分離能力不足、需要不足、発見不足、誤ブロック、品質・重複を切り分ける。

小規模サイトの目安：公開後に数日以上かかることは珍しくありません。重要な時限情報を扱うサイト以外で「公開当日に取得されない＝異常」と決めつけないでください。

Search Consoleとサーバーログで確認する方法

一つのレポートだけで原因を断定しないでください。Crawl Statsはサイト全体の傾向、URL Inspectionは特定URLのGoogle側情報とライブテスト、Page Indexingはインデックス状況、サーバーログは実際の要求履歴を示します。

Crawl Stats

要求総数、ダウンロード量、平均応答時間、レスポンスコード、ファイル種別、目的、Googlebot種別、ホスト状態、URL例を確認します。URL台帳ではありません。

LOG

サーバーログ

特定URL・ディレクトリの最終取得日時、取得間隔、状態コード、応答時間を集計します。User-Agent名だけでなく、正規のGooglebotか検証します。

URL

URL Inspection

Googleが最後に取得した状態、クロール可否、canonical、取得日時、レンダリング結果を確認します。ライブテストはGoogleインデックスの状態そのものではありません。

Page Indexing

「検出 - インデックス未登録」「クロール済み - インデックス未登録」「soft 404」「重複」など、後段の結果をURL群ごとに見ます。

代表的な症状、確認する証拠、最初の対応
症状	確認する証拠	最初の対応
ホスト障害	5xx、429、DNS、接続、timeout、Hostload exceeded	Crawl Statsのホスト状態、監視、URL Inspection、ログを同じ時間帯で照合する。
重要URLが未取得	公開日時はあるが、Googlebotログがない	内部リンク、robots.txt、canonical、サイトマップ、HTTP状態、モバイル版リンクを確認する。
不要URLへ集中	filter、sort、session、calendar、重複、soft 404	URL生成規則と内部リンク元を特定し、canonical、robots.txt、404/410を目的別に選ぶ。
取得済み・未登録	ログに200があるが、Page Indexingでは未登録	品質、重複、Google選択canonical、レンダリング、index可否へ診断を移す。
再取得が遅い	重要更新後も古い取得日時のまま	正確なlastmod、内部リンク、HTTPキャッシュ、クロール需要、URLの価値を確認する。

ログはURL群ごとに集計する

全体平均だけでは、重要商品が未取得なのに不要な検索結果URLが大量取得されている状態を見逃します。最低でも、canonical・重要URL、filter・sort、サイト内検索、削除URL、soft 404、静的資源、リダイレクトに分類してください。

ログ集計の注意：Googlebotを名乗るUser-Agentは偽装できます。公式IP範囲やDNS検証など、正規のGoogleクローラを確認する手順を運用に組み込んでください。また、Crawl Statsとログの集計単位・タイムゾーン・CDN経由の記録差もそろえます。

改善は「取得不能」から直し、URL在庫を次に整理する

不要URLを一括で遮断する前に、重要URLの取得を妨げる可用性問題と誤設定を直します。広範囲のrobots.txt変更やURL生成規則の変更は、代表ディレクトリで試し、ロールバック方法を用意してください。

5xx・429・DNS・タイムアウトを直す
Googlebotがホストの不調を検知するとクロール能力の上限が下がります。障害時間帯、CDN・WAF・レート制限、オリジン負荷を照合します。
重要URLの誤ブロックを解除する
robots.txt、noindex、canonical、認証、WAF、モバイル版リンク、レンダリング資源の誤設定を確認します。
重複・無限URLの生成と内部リンクを減らす
filter、sort、calendar、session、サイト内検索、組み合わせパラメータをURL在庫として分類し、不要な発見経路を止めます。
削除・移転・重複に正しいHTTPとcanonicalを使う
代替先がある移転は直接の301/308、永久削除は404/410、重複は一貫したcanonicalと内部リンクで統合します。
canonical URLと正確なlastmodをサイトマップへ載せる
検索結果に出したいURLだけを掲載し、本文・構造化データ・主要リンクなどの重要更新時にlastmodを正確に更新します。
ページ効率とHTTPキャッシュを改善する
TTFB、レンダリング資源、画像、JavaScriptを軽くし、変更がないページでは304 Not Modifiedを正しく返せるようにします。

robots.txt・noindex・canonical・404/410の役割を混同しない

URL制御の目的別使い分け
手段	主な目的	重要な注意点
robots.txt	クロール要求を止める	検索結果からの除外は保証しない。noindexを読ませたいURLはブロックしない。秘密情報の保護には使わない。
noindex	検索インデックスから除外する	Googlebotがルールを読むためクロール可能である必要がある。直接のクロール停止策ではない。
rel=canonical	重複・類似URLの代表を示す	リダイレクトとcanonicalは強い信号、サイトマップ掲載は弱い信号。内部リンクもcanonicalへ統一する。
404 / 410	代替先のない永久削除を伝える	関係のないトップへ転送しない。soft 404にせず、正しいHTTP状態を返す。
301 / 308	恒久移転を伝える	最終URLへ直接転送し、長いチェーンやループを避ける。
認証	非公開情報を保護する	robots.txtは公開ファイルであり、アクセス制御ではない。

絞り込み・並べ替えURLは「検索対象にするか」を先に決める

EC、求人、不動産、イベントサイトのfaceted navigationは、色・サイズ・価格・地域・並べ替えの組み合わせで非常に大きなURL空間を作ります。クローラは取得前に価値を完全には判断できないため、不要なURLの過剰クロールと、新規URLの発見遅延につながる可能性があります。

検索対象にしない

クロール自体を抑える設計

不要なパラメータURLを内部リンクとして大量生成しない
robots.txtで明確なパターンをブロックする
必要に応じてフィルタ状態をURLフラグメントで表現する
代表一覧と個別詳細ページへの通常リンクを残す

検索対象にする

有限で一貫したURL空間にする

パラメータ順序と表記を固定する
同じ結果を返す組み合わせを統合する
空結果や無効値に正しい状態を返す
価値のある組み合わせだけ内部リンク・サイトマップで発見させる

User-agent: Googlebot
Disallow: /*?*color=
Disallow: /*?*size=
Disallow: /*?*sort=

# 実際のURL規則に合わせ、重要ページを巻き込まないよう必ずテストする

canonicalだけに頼らない：Googleは、faceted URLへのcanonicalやnofollowが長期的にクロール量を下げる助けになる場合はあるものの、クロール不要なURLではrobots.txtやURL設計の方が一般に有効と説明しています。サイト固有の検索需要がある組み合わせまで一律遮断しないでください。

クロールバジェットを7段階で診断・改善する

変更前後で同じURL群・期間・集計条件を使い、仮説を一つずつ検証します。クロール要求には曜日・季節・サイト更新による変動があるため、変更直前の1日だけを比較対象にしないでください。

重要URLと許容クロール時間を定義する

商品、記事、求人、イベントなどをURL群に分け、「公開・重要更新から何時間／何日以内にGooglebot取得が必要か」を事業要件で決めます。

優先URL群許容時間公開・更新日時責任部署

URL在庫を分類する

canonical・index対象、重複、filter、sort、ページネーション、サイト内検索、削除、soft 404、リダイレクト、静的資源を分類します。hostnameも分けます。

URL生成規則内部リンク元HTTP状態canonical先

基準データを保存する

Crawl Statsの要求数、応答コード、ファイル種別、目的、Googlebot種別、ホスト状態を保存し、ログからURL群別の最終取得・取得間隔・応答時間を集計します。

同じタイムゾーン同じ期間中央値・95パーセンタイルURL群別件数

可用性と誤設定を先に直す

5xx、429、DNS、timeout、WAF、誤robots.txt、誤noindex、誤canonical、壊れた内部リンク、レンダリング資源の遮断を修正します。

URL Inspection実HTTP応答監視ログCDN・オリジン照合

不要URLの生成・発見・再取得を減らす

重複はcanonicalへ統合し、新規生成と内部リンクを止めます。クロール不要URLはrobots.txt、永久削除は404/410、代替先がある移転は直接リダイレクトを使います。

faceted URLsoft 404リダイレクトチェーンセッションURL

発見と再取得の信号を整える

canonical URLだけをサイトマップへ載せ、重要変更に正確なlastmodを付けます。重要ページへクロール可能な通常のリンクを設置し、モバイル版にも同等の発見経路を保ちます。

canonical URL正確なlastmod内部リンクモバイル版リンク

URL群ごとに再測定し、必要なら戻す

変更後も同じ条件で、重要URLの取得遅延、未取得率、不要URL比率、5xx・429、応答時間、Page Indexingを比較します。

成功条件中止条件ロールバック手順次の仮説

効果測定はクロール総数ではなく「重要URLの適時取得」で行う

総クロール数が減っても、重要URLの取得が遅くなれば失敗です。反対に総数が増えても、更新URLが適時に取得され、不要URLと障害が減っていれば改善の可能性があります。

中央値・P95公開・更新から最初のGooglebot取得までの時間

重要URL取得率許容時間内に取得されたURLの割合

不要URL比率Googlebot要求に占めるfilter・重複・soft 404の割合

5xx・429ホスト障害とレート制限の件数・時間帯

応答時間平均だけでなく分布と遅い時間帯を確認

後段成果Page Indexing・検索表示・流入は別指標として追跡

施策前後で比較する指標
層	主な指標	判断
取得	最初の取得まで、最終取得日、取得間隔、未取得率	重要URL群の中央値と遅い上位群が改善したか
応答	5xx、429、DNS、timeout、TTFB、304比率	障害とサーバー負荷が減り、重要URLを安定配信できたか
URL在庫	canonical、filter、sort、soft 404、削除URLの要求比率	不要URLが減り、重要URLの構成比が上がったか
インデックス	Page Indexing、Google選択canonical、未登録理由	取得済みなら品質・重複・レンダリングへ診断を移したか
検索成果	表示回数、クリック、流入、業務成果	クロール施策だけに成果を帰属せず、他要因も分けたか

ロールバック条件：重要URLがrobots.txtで遮断された、レンダリング資源が取得不能になった、取得遅延が悪化した、誤404・誤410・誤canonicalが増えた、サイトマップからindex対象が消えた場合は変更を戻します。

クロールバジェットで誤解されやすいこと

誤解

クロール回数が増えるほど順位が上がる

クロールは必要な前工程ですがランキングシグナルではありません。取得済み・未登録なら、回数より品質・重複・canonicalを確認します。

誤解

crawl-delayでGooglebotを制御できる

Googleのクローラは非標準のcrawl-delayルールを処理しません。緊急の過剰クロールは429や503、恒常的なURL問題は設計で対処します。

誤解

サイトマップを何度も送れば早く取得される

同じ未変更サイトマップを一日に何度も送る必要はありません。サイトマップはヒントであり、掲載URLすべての即時取得を保証しません。

誤解

4xxはすべてクロールバジェットを浪費する

Googleの説明では429を除く4xx自体は無駄なクロールとは扱われません。代替先のない削除URLには正しい404/410を返すのが適切です。

クロールバジェットのよくある質問

小規模サイトでもクロールバジェット対策は必要ですか？

多くの場合、専用施策は不要です。公開後に妥当な期間で取得されているなら、内部リンク、最新サイトマップ、canonical、robots.txtの誤設定、Page Indexing、コンテンツ品質を通常運用で確認します。

クロール回数を増やせば検索順位は上がりますか？

保証されません。クロールはランキングシグナルそのものではなく、その後にレンダリング、評価、重複統合、インデックス判断があります。重要URLの未取得問題と順位改善を同じ約束にしないでください。

noindexを付けるとクロールバジェットを節約できますか？

直接の停止策ではありません。Googlebotはnoindexを読むためにページを取得します。検索結果から除外する目的にはnoindexを使い、クロール不要なURLは生成・内部リンク・canonical・robots.txtを整理します。

robots.txtでブロックすれば検索結果から消えますか？

保証されません。robots.txtはクロール制御です。他ページからURLが知られている場合、内容を取得せずURLだけが表示される可能性があります。検索結果から除外するなら、クロール可能な状態でnoindexを認識させます。

404はすべて別ページへリダイレクトすべきですか？

いいえ。代替先がある移転は301または308、代替先のない永久削除は404または410を返します。無関係なトップページへの一律転送はsoft 404と判断される可能性があります。

サーバーを高速化すればクロールは必ず増えますか？

必ずではありません。速度改善はクロール能力の制約を緩める可能性がありますが、需要が低ければ取得は増えません。hostloadや可用性の制約がある証拠を確認してから増強します。

Search Consoleだけで特定URLのクロール履歴を確認できますか？

完全には確認できません。Crawl Statsはサイト全体の傾向とURL例を示します。特定URLやディレクトリの取得日時・頻度は、正規のGooglebotを識別したサーバーログを使います。

サイトマップのpriorityとchangefreqは有効ですか？

Googleはpriorityとchangefreqを無視します。検索結果に出したいcanonical URLだけを掲載し、本文や構造化データ、主要リンクなどの重要変更があったときに正確なlastmodを更新します。

Google公式資料と確認日

仕様・判断基準は2026年7月29日に次の一次資料で確認しました。ページ公開後もGoogleの仕様は更新されるため、実装変更前に最新内容を確認してください。

まとめ：重要URLの取得を妨げる原因を、証拠に基づいて直す

クロールバジェットは、すべてのサイトが増やすべき数値ではありません。まず規模、更新頻度、「検出 - インデックス未登録」の割合、重要URLの取得遅延から適用対象を判定します。

対象なら、クロール能力と需要を分け、Crawl Stats、検証済みGooglebotログ、URL Inspection、Page Indexingを照合してください。可用性と誤設定を先に直し、重複・faceted URL・soft 404・リダイレクトチェーンを整理し、canonical URLと正確なlastmodをサイトマップへ反映します。

クロール総数ではなく、重要URLが必要な時期に取得されたかを成功条件にすることが、もっとも実務的なクロールバジェット管理です。

執筆・検証：Finite Field 編集部Googleのクロール基盤、Search Console、サイトマップ、canonical、robots.txt、noindex、faceted navigationの公式資料を確認し、対象判定・診断・改善・測定を分けて構成しました。順位やインデックス結果を保証する表現は採用していません。