記事執筆者：認定SEOコンサルタント 三田健司
「新しく公開したページが、いつまで経っても検索結果に出てきません」というご相談が、ここ数か月で目に見えて増えています。ブログを更新しても、サービスページを追加しても、Google検索でヒットしない。
そんなとき、SEOの解説記事でよく出てくるのが「クロールバジェット」という言葉です。クロールの予算、つまりGoogleが自社サイトを見に来てくれる回数の上限を指す用語で、これが足りていないのではないかと不安になる方は少なくありません。
そのクロールバジェットについて、Googleが2026年7月22日に公式ドキュメントを大きく書き直しました。用語の整理が中心ではあるものの、これまで明示されていなかった重要な一文がいくつか追加されています。
この記事では、Googleの公式ドキュメントに書かれている内容をもとに、クロールバジェットの仕組み、今回の更新で新しく分かったこと、そして中小企業のサイトが実際に何をすればよいのかを整理します。読み終えるころには、「自社は気にすべきなのか、気にしなくてよいのか」がはっきり判断できるはずです。
Googleが「クロールバジェット」の解説を更新｜2026年7月22日
更新の狙いは「分かりやすさ」と「用語の統一」
Googleは2026年7月22日、クロールに関する開発者向けドキュメント「Optimize your crawl budget（クロールバジェットの最適化）」を更新しました。Google自身は更新の目的を「明確さ、用語の一貫性、文章の流れを改善するため」と説明しています。
つまり、クロールの仕組みそのものが変わったわけではありません。これまで曖昧に書かれていた部分を整理し、専門用語の使い方をドキュメント全体で揃えたというのが、今回の更新の性格です。
なお、このドキュメントは以前は検索セントラル内に置かれていましたが、現在は「Google Crawling Infrastructure」という独立したドキュメント群へ移されています。古いブックマークからアクセスしている方は、リダイレクトされる先が変わっている点にご注意ください。
ただし、書き直しの過程でこれまで公式には明言されていなかった内容がいくつか追加されており、そこがSEO業界で話題になりました。仕組みが変わっていなくても、「Googleがこう説明した」という事実そのものに価値があるからです。
新しく加わった重要な一文
今回の更新で追加された文章のうち、中小企業のサイト運営に関係するものは主に3つです。ひとつ目は「すべてのサイトは、同じ既定の控えめなクロール容量の上限から始まります」という一文です。
ふたつ目は「クロールの需要はクローラーごとに異なりますが、クロール容量の上限はすべてのクローラーで共有されます」という説明です。これは、あるクローラーの需要が高まると、他のクローラーが使える容量が減るという意味になります。
3つ目は、サーバー側の対策として「読み込み速度の改善」と「HTTPキャッシュの活用」が明記されたことです。特に、変更のないページに対して304（Not Modified）を返すことで、サーバーの帯域とリソースを節約できるという具体的な記述が加わりました。
なぜ今このドキュメントが注目されるのか
背景には、Web上を巡回するボットの種類が急速に増えている事情があります。従来の検索エンジン向けのクローラーに加えて、生成AIの学習や回答生成のためにサイトを訪れるクローラーが次々と登場しました。
サーバーへのアクセスが増えれば、当然その負荷も増えます。「クロール容量は全クローラーで共有される」という一文が注目されたのは、この状況と直結しているからです。
筆者がSEOコンサルティングの現場で見ていても、共用サーバーで運用している中小企業のサイトほど、この影響を受けやすい傾向があります。まずは仕組みを正しく理解しておくことが、無駄な対策を避ける近道になります。
クロールバジェットとは？2つの要素で決まる仕組み
クロールバジェットの定義
Googleの公式ドキュメントは、Webを「ほぼ無限の空間」と表現しています。公開されているすべてのURLを見に行くことはGoogleにも不可能なので、1つのサイトに割ける時間とリソースには限りがあります。
この、あるサイトに割り当てられるリソースの配分を「クロールバジェット」と呼びます。日本語では「クロール予算」と訳されることもありますが、意味は同じです。
そしてクロールバジェットは、「クロール容量の上限」と「クロールの需要」という2つの要素で決まります。片方だけを改善しても、思ったような効果は出ません。
要素①クロール容量の上限（クロール キャパシティ リミット）
1つ目の要素は「クロール容量の上限」です。Googleは、サイトのサーバーに負荷をかけすぎないようにクロールしたいと考えており、そのために接続の本数と接続を開いておく時間の合計を制限しています。
この上限は、Search Consoleのヘルプなどでは「ホストロード」という名前でも登場します。サーバーが安定して速く応答していれば上限は上がり、遅くなったりエラーを返したりすれば下がる仕組みです。
具体的には、レイテンシ（応答までの遅れ）やTTFB（最初の1バイトが返るまでの時間）が安定または改善していれば、Googleはより多くの接続を使ってクロールできるようになります。逆に、500番台のサーバーエラーや429（リクエスト過多）を返すと、Googleはクロールを減らします。
要素②クロールの需要（クロール デマンド）
2つ目の要素は「クロールの需要」、つまりGoogleがそのサイトをどれだけ見に来たいと思っているかです。Googlebotの場合、サイトの規模、更新頻度、ページの品質、そして他サイトと比べたときの関連性によって需要が変わるとされています。
公式ドキュメントは、このうちサイト運営者が自分で動かせる要素として3つを挙げています。「認識されている在庫」「人気度」「鮮度」の3つです。
「認識されている在庫」とは、Googleが把握しているURLの総量のことです。重複URLや、そもそもクロールさせる必要のないURLが大量にあると、そこにクロールの時間が浪費されてしまいます。
Googleはこの「在庫の管理」こそがサイト運営者が最も大きく改善できる要素だと明記しています。後半で具体的な手順を解説します。
「サイト」はホスト名単位で数えられる
意外と見落とされがちなのが、Googleのクロール基盤における「サイト」の定義です。公式ドキュメントでは、サイトとは「一意のホスト名」を指すと説明されています。
たとえば「https://www.example.com/」と「https://code.example.com/」は別のサイトとして扱われ、それぞれ別のクロールバジェットを持ちます。サブドメインでキャンペーンサイトや採用サイトを運用している場合、本体サイトとはクロールの扱いが分かれるということです。
逆に言えば、サブディレクトリで運用しているコンテンツは同じサイトの一部として扱われます。サイト構成を決める段階で意識しておきたいポイントです。
「すべてのサイトが控えめな上限から始まる」の本当の意味
新規サイトも老舗サイトも出発点は同じ
今回追加された「すべてのサイトは、同じ既定の控えめなクロール容量の上限から始まります」という一文は、誤解されやすい表現でもあります。これは「新しいサイトは不利で、古いサイトは有利」という意味ではありません。
むしろ逆で、Googleはすべてのサイトを同じスタートラインに置いていると読むのが自然です。大企業のサイトだから最初から大量にクロールされる、という前提ではないわけです。
公開したばかりのサイトでクロールが少ないと感じても、それは「あなたのサイトが低く評価されている」という証拠にはなりません。単に、まだ上限を引き上げる材料がGoogle側に揃っていないだけです。
上限が上がる条件は「需要」と「健全性」
公式ドキュメントは続けて、「より多くクロールする需要があり、サイトが健全な状態を保っていれば、Googleのシステムがこの上限を時間とともに自動的に調整します」と説明しています。条件は2つです。
ひとつは「もっとクロールしたい」とGoogleに思わせるだけの需要があること。更新頻度が高く、内容に価値があり、他サイトから参照されているサイトほど需要は高まります。
もうひとつは、サーバーが健全であることです。Googleがアクセスしたときに安定して速く応答できていれば、上限は少しずつ引き上げられていきます。
なお、この調整に「何日で上がる」といった目安はGoogleから示されていません。期間を確約することはできませんので、短期的な変化に一喜一憂しないことをおすすめします。
上限が下がるのはどんなときか
クロール容量の上限は、下がることもあります。公式ドキュメントが挙げているのは、サイトの応答が遅くなったとき、サーバーエラー（5xx）を返したとき、そしてレート制限のシグナル（HTTP 429）を返したときです。
中小企業のサイトでよくあるのは、格安の共用サーバーでアクセスが集中し、一時的に応答が極端に遅くなるケースです。この状態が続くと、Googleは「このサーバーに負担をかけるべきではない」と判断してクロールを控えます。
また、セキュリティプラグインやWAFの設定が厳しすぎて、Googlebotのアクセスまでブロックしてしまっている例も見かけます。心当たりがある場合は、サーバーのアクセスログを確認してみてください。
Googleが示す「クロールバジェットを増やす2つの方法」
公式ドキュメントは、クロールバジェットを増やす方法として2つだけを挙げています。ひとつは「サーバーのリソースを増やすこと」です。
URL検査ツールで「ホストの負荷を超えました（Hostload exceeded）」が出るような状態であれば、サーバーのプランを上げる判断が有効な場合があります。ただし、事業として妥当な範囲で、という但し書きが付いています。
もうひとつは「対象とするGoogleのサービスに向けてコンテンツの品質を最適化すること」です。Google検索の場合、人気度、全体としてのユーザー価値、コンテンツの独自性などが判断材料になると明記されています。
クロール容量はすべてのクローラーで共有される
需要はクローラーごと、容量はサイトで1つ
今回の更新で追加されたもうひとつの重要な説明が、クロール容量の共有についてです。Googleは「各クローラーはそれぞれ異なるクロールの需要を持つが、クロール容量の上限はすべてのクローラーで共有される」と明記しました。
Googleのクローラーは、検索用のGooglebotだけではありません。広告向けのAdsBot、ショッピング向けのクローラー、画像や動画を扱うクローラーなど、目的別に多数存在します。
これらが別々の「需要」を持ちながら、アクセスできる容量という一本の水道管を共有しているというイメージです。誰かが大量に使えば、他の誰かに回る分は減ります。
広告やショッピングを使っている場合の注意点
公式ドキュメントは、AdsBotは動的な広告ターゲットを運用しているサイトで需要が高くなり、Googleショッピングは商品フィードに登録した商品が多いほど需要が高くなると説明しています。つまり、広告やECを積極的に運用しているサイトほど、クローラーの種類も回数も増えます。
それ自体は事業として正しい選択ですが、サーバーの余力が乏しい状態でそれをやると、検索用のGooglebotに回る容量が圧迫される可能性があります。広告を始めてから新規ページのインデックスが遅くなった、という相談を受けることもあります。
もっとも、これはあくまで容量に余裕がない場合の話です。適切なサーバーで運用できていれば、通常の中小企業サイトの規模で問題になることはほとんどありません。
AIクローラーが増えている今の意味
2026年に入り、AI検索や生成AIのためにWebを巡回するボットが一段と増えました。Google自身も、NotebookLM向けのユーザーエージェント名を「Google-GeminiNotebook」に変更するなど、AI関連のクローラーを整理しています。
Google以外のAI事業者のクローラーは、Googleのクロール容量とは別枠で動きます。ただし、サーバーの物理的な処理能力は共通なので、AIボットのアクセスが多すぎてサーバーが重くなれば、結果的にGooglebotのクロールにも悪影響が及びます。
アクセスログを見て、明らかに不要なボットが大量に来ている場合は、robots.txtで制御することを検討してもよいでしょう。ただし、AI検索に自社の情報を出したいのであれば、無差別にブロックするのは得策ではありません。
自社サイトは気にすべき？Googleが示す3つの目安
そもそも「上級者向けのガイド」だと明記されている
ここが、この記事でいちばんお伝えしたい部分です。Googleはこのドキュメントの冒頭で、「サイトのページ数が多くなく、公開したその日にクロールされているようであれば、このガイドを読む必要はありません」とはっきり書いています。
そのうえで、大規模で更新の速いサイト向けの上級ガイドであると位置づけを明示しています。クロールバジェットは、すべてのサイトが気にすべきテーマではないのです。
目安①100万ページ以上で、週1回程度更新される大規模サイト
1つ目の目安は、ユニークなページが100万ページ以上あり、内容がそこそこの頻度（週1回程度）で変わるサイトです。大手の情報サイトや、商品点数の非常に多いECサイトが該当します。
中小企業のコーポレートサイトでこの規模になることは、まずありません。仮に数千ページあったとしても、桁が2つ違います。
目安②1万ページ以上で、毎日内容が変わるサイト
2つ目は、ユニークなページが1万ページ以上あり、内容が非常に速く（毎日）変わるサイトです。求人サイト、不動産ポータル、価格が日々変動するECサイトなどが典型例です。
中小企業でも、在庫連動型のECや、店舗数の多いチェーンの店舗ページを持っている場合は、この条件に近づくことがあります。自社が当てはまるかどうかは、サイトマップに登録されているURL数を確認すると分かります。
目安③「検出 – インデックス未登録」が大量にあるサイト
3つ目は、Search Consoleで「検出 – インデックス未登録（Discovered – currently not indexed）」に分類されているURLが、全URLのうち大きな割合を占めているサイトです。この状態は、Googleがそのページの存在を知ってはいるものの、まだ見に行けていないことを示します。
ページ数がそれほど多くないのにこの分類が積み上がっているなら、クロールバジェット以外の要因を疑うほうが現実的です。この点は次の章で詳しく取り上げます。
目安に当てはまらないサイトがやるべきこと
3つの目安のどれにも当てはまらない場合、Googleが求めているのはたった2つです。「サイトマップを最新の状態に保つこと」と「ページのインデックス登録レポートを定期的に確認すること」だけで十分だと書かれています。
クロール上限を上げようと難しい設定をいじるより、この2つを確実に続けるほうが結果につながります。サイトマップはプラグインで自動生成できますし、レポートは月に一度眺めるだけでも変化に気づけます。
それでもインデックスされないときに疑うこと
「検出」と「クロール済み」の違い
Search Consoleのページインデックス登録レポートには、よく似た2つのステータスが並びます。「検出 – インデックス未登録」と「クロール済み – インデックス未登録」です。
前者は、GoogleがURLの存在は知っているものの、まだ実際にアクセスしていない状態を指します。後者は、アクセスはしたけれどもインデックスには入れなかった状態です。
公式ドキュメントも「クロールされたすべてのページが必ずインデックスされるわけではない」と明記しています。クロールされた後に、そのページがインデックスにふさわしいかどうかの評価が行われるためです。
Google担当者が語った「品質との関係」
2026年7月に公開されたGoogleのポッドキャスト「Search Off the Record」で、ジョン・ミューラー氏がこのテーマに触れています。「クロール済み – インデックス未登録」は品質の問題のサインなのか、という質問への回答です。
ミューラー氏は「ときどきはそうだ」と答えたうえで、「システムがサイトの品質に強い懸念を持っている場合、インデックスするページ数を減らすことは確かにある」と説明しました。品質への懸念が強ければ、クロールも減り、インデックスも減るという流れです。
そのうえで、「これを技術的な問題として直そうとする必要はない」とも述べています。技術的な原因がないのに多くのページがインデックスされないなら、一歩下がってサイト全体の品質を考え直すべきだ、という趣旨です。
AIで量産した記事が抱えやすい弱点
同じ回答のなかで、ミューラー氏はAI生成コンテンツにも言及しています。「サイトの大部分がAIで生成されていて、しばらくはうまくいっていたとしても、読んだ人が『AIで書かれたと分かる。自分にとって独自の価値がない』と感じることがある」という指摘です。
ただし氏は「AI生成コンテンツがすべて悪いという意味ではない」と明確に断っています。問題は生成手段ではなく、「誰でも書ける内容で、何も新しいことを教えてくれない」ページになっているかどうかです。
筆者も生成AIを執筆の補助として使いますが、必ず自社の実務で確認した数字や、現場で実際に起きた事例を足すようにしています。そこが読者にとっての独自価値になるからです。
技術を直す前に見直すこと
ミューラー氏は、自分のサイトを客観的に見ることの難しさにも触れています。「自分のサイトは自分の子どものようなもので、もちろん世界一よい子に見える」という表現で、第三者の目で見直すことの大切さを説明しました。
実務としておすすめなのは、社内の別部署の人や、業界外の知人に読んでもらうことです。「このページを読んで、何が分かった？」と聞いてみると、価値が伝わっているかどうかがすぐに分かります。
今日から見直せるクロール効率の改善ポイント
①重複したURLを1本にまとめる
最初に取り組むべきは、同じ内容が複数のURLで見られる状態を解消することです。Googleは「ユニークなURLではなくユニークなコンテンツにクロールを集中させるため、重複コンテンツを排除する」ことを最初の対策として挙げています。
よくあるのは、wwwの有無、httpとhttpsの混在、末尾のスラッシュの有無、index.htmlの付いたURLなどです。これらはすべてリダイレクトで1本に統一し、canonicalタグで正規URLを示しておきます。
なお、Googleはcanonicalの修正が反映されるまで最大2週間程度かかる場合があるとしています。直したのに変わらないと焦らず、しばらく様子を見てください。
②クロール不要なURLはrobots.txtでブロックする
ユーザーには必要でも、Googleに見せる必要のないページはあります。無限スクロールのページや、同じ内容を並べ替えただけのページなどが該当します。
公式ドキュメントは、こうしたページをnoindexではなくrobots.txtでブロックするよう推奨しています。noindexの場合、Googleはページをいったんリクエストしてからタグを見て捨てるため、クロール時間が無駄になるからです。
ただし、robots.txtを「一時的にクロール予算を他へ回すため」に使うのは推奨されていません。すでに容量の上限に達していない限り、空いた分が他のページに回るわけではないためです。
③削除したページは404か410を返す
完全に削除したページには、404または410のステータスコードを返します。Googleは一度知ったURLを忘れることはありませんが、404は「このURLを再クロールしなくてよい」という強いシグナルになります。
一方、robots.txtでブロックしただけのURLは、クロール待ちの列に長く残り続け、ブロックを外した瞬間に再びクロールされます。削除と非公開は別物なので、目的に応じて使い分けてください。
④ソフト404をなくす
ソフト404とは、内容としては「ページが見つかりません」なのに、サーバーが200（正常）を返してしまっている状態です。Googleから見ると正常なページに見えるため、クロールされ続けて容量を消費します。
Search Consoleのページインデックス登録レポートで「ソフト404」の項目を確認すれば、該当URLを一覧で確認できます。中身のない検索結果ページや、商品が0件のカテゴリーページで発生しやすい現象です。
⑤サイトマップと最終更新日を正しく保つ
Googleはサイトマップを定期的に読んでいるため、クロールしてほしいコンテンツはすべて含めておく必要があります。更新のあるサイトでは、lastmodタグを付けることが推奨されています。
ただし、lastmodの日付が実態と合っていない場合は注意が必要です。誤った日付を入れるくらいなら、lastmod自体を付けないほうがよいという見解もGoogleから示されています。
WordPressの場合、サイトマッププラグインが自動で日付を入れてくれます。全記事を一括で軽微に編集すると全ページのlastmodが更新されてしまうので、その点だけ気をつけてください。
⑥リダイレクトの連鎖を短くする
公式ドキュメントは「長いリダイレクトチェーンはクロールに悪影響を及ぼす」と明記しています。AからB、BからC、CからDと転送が連なると、そのたびにリクエストが発生するためです。
サイトリニューアルを何度か経験しているサイトほど、古いリダイレクト設定が積み重なっています。一度整理して、可能な限り1回の転送で最終URLへ届くようにしておくと効率が上がります。
⑦表示速度と304レスポンスを整える
今回の更新で追記されたのが、この項目です。サーバーの応答時間とリソースを最適化してページを速く読み込ませること、そして304（Not Modified）を返せるようにすることが挙げられています。
304は「前回のクロール時から変わっていません」という返答で、Googleにキャッシュの再利用を促します。これによりサーバーの帯域とリソースが節約でき、結果的にクロール容量に余裕が生まれます。
実装はサーバーやCDNの設定に依存するため、自社で判断が難しい場合は制作会社やサーバー会社に相談するのが確実です。無理に設定を触ってサイトが表示されなくなるリスクは避けましょう。
WordPressサイトでありがちな「クロールの無駄づかい」
添付ファイルページが大量に生成されている
WordPressは、画像をアップロードするたびに「添付ファイルページ」という専用URLを作ることがあります。画像1枚につき1ページなので、記事数が増えるほどURLが膨らみます。
これらのページには、画像1枚以外にほとんど中身がありません。多くのSEOプラグインには添付ファイルページを親記事へリダイレクトする設定があるので、有効になっているか確認してみてください。
日付アーカイブ・著者アーカイブが放置されている
年別・月別のアーカイブページや、投稿者別のアーカイブページも、初期設定のままだと生成され続けます。1人で運営しているブログの著者アーカイブは、記事一覧と内容がほぼ重複します。
使っていないアーカイブは、SEOプラグインの設定で無効化するのが手軽です。ユーザーにとっても価値があるかどうかを基準に判断してください。
タグが乱立して1記事1タグ状態になっている
タグはつい増えがちですが、そのタグが付いた記事が1本しかないなら、タグページは記事の劣化コピーにしかなりません。タグの数だけ薄いページが増えることになります。
目安として、記事が3本以上ぶら下がらないタグは作らないというルールを決めておくと管理しやすくなります。すでに乱立している場合は、統合か削除を検討しましょう。
サイト内検索の結果ページがクロールされている
サイト内検索の結果ページは、検索語の組み合わせだけ無限にURLが生まれます。かつてのウェブマスター向けガイドラインには「検索結果ページをブロックする」という指示がありましたが、ガイドラインが検索セントラルの「検索の基本事項」に整理された際に、その記述はなくなりました。
2026年7月末に公開されたGoogleのポッドキャストでも、ジョン・ミューラー氏がこの経緯に触れています。氏は「今のポリシーには載っていないが、純粋に技術的な理由から今もブロックする意味はある」と述べ、スパム扱いされなくなっただけで、推奨されなくなったわけではないという立場を示しました。
理由は2つあります。ひとつは無限に増えるURLがクロールとサーバーを消耗させること、もうひとつは無関係な語で検索させられたページが自社ドメイン配下でインデックスされ、スパムの温床になりうることです。
絞り込み・並べ替えのパラメータURL
ECサイトや求人サイトでよく使われる、色・サイズ・価格帯などの絞り込み機能も要注意です。組み合わせの数だけURLが生成され、内容の大半は重複します。
Googleはこうした「ファセットナビゲーション」専用の解説ページも用意しています。該当する機能を持っているサイトは、そちらも合わせて確認しておくとよいでしょう。
実務での進め方
いきなり全部に手を付ける必要はありません。まずSearch Consoleのページインデックス登録レポートを開き、「インデックスに登録されていないページ」の内訳を上から順に見ていきます。
件数の多い項目から1つずつ潰していけば、無駄なクロールは着実に減ります。設定変更は本番サイトに影響するため、バックアップを取ってから作業することをおすすめします。
よくある質問（FAQ）
クロールバジェットは数値で確認できますか？
「あなたのサイトのクロールバジェットは○○です」という形で確認できる数値は公開されていません。Search Consoleの「設定」内にあるクロールの統計情報で、1日あたりのクロールリクエスト数や平均応答時間の推移は確認できます。
絶対値を追うより、傾向を見ることをおすすめします。応答時間が急に伸びていないか、クロール数が不自然に落ちていないかをチェックすれば、サーバー側の問題に早く気づけます。
新しく作ったサイトは、クロールされるまで時間がかかりますか？
すべてのサイトは同じ控えめな上限から始まるとGoogleは説明しているので、公開直後のクロールが多くないのは自然な状態です。上限は需要とサイトの健全性に応じて自動的に調整されていきます。
ただし、Googleから何日で上がるといった期間は示されていません。サイトマップを送信し、更新を続けながら待つのが現実的な進め方です。
robots.txtでブロックすれば、その分のクロールが他のページに回りますか？
公式ドキュメントは、それを目的にrobots.txtを使わないよう明記しています。すでにサイトがクロール容量の上限に達している場合を除き、空いた分が他のページに振り替えられるわけではないためです。
robots.txtは「まったくクロールさせたくないページやリソース」を指定するために使うものだと理解しておいてください。予算の付け替えツールではありません。
ページ数が少ないのにインデックスされません。どうすればいいですか？
ページ数が少ない場合、クロールバジェットが原因である可能性は低いと考えられます。まずnoindexの誤設定、robots.txtの誤ったブロック、canonicalが別URLを指していないかといった技術面を確認してください。
技術的な問題が見当たらないのに登録されないなら、内容の独自性を見直す段階です。Googleの担当者も、技術的に直そうとするより一歩下がって品質全体を考えるべきだと述べています。
サーバーのプランを上げればクロールは増えますか？
サーバーの処理能力が不足していてクロールできない状態であれば、リソースを増やすことは有効な手段のひとつです。URL検査ツールで「ホストの負荷を超えました」が出ている場合が該当します。
ただし、需要そのものが低い場合は、サーバーを強化してもクロールは増えません。Googleも「クロール容量の上限に達していなくても、需要が低ければクロールは少なくなる」と説明しています。
サブドメインで運用しているサイトは別扱いになりますか？
Googleのクロール基盤は「サイト」を一意のホスト名として定義しているため、サブドメインは別サイトとして扱われ、クロールバジェットも別になります。採用サイトやキャンペーンサイトをサブドメインで運用している場合が該当します。
サブディレクトリで運用すれば同じサイトの一部として扱われます。どちらが有利かは目的次第なので、制作段階で方針を決めておくのがおすすめです。
まとめ｜クロールバジェットより先に見るべきもの
2026年7月22日に更新されたGoogleのクロールバジェット解説から、押さえておきたい点を整理します。まず、クロールバジェットは「クロール容量の上限」と「クロールの需要」という2つの要素で決まります。
今回新しく明記されたのは、すべてのサイトが同じ控えめな上限から始まること、そしてクロール容量の上限はすべてのクローラーで共有されることの2点です。加えて、読み込み速度の改善と304レスポンスの活用が対策として追記されました。
そのうえで最も大切なのは、このガイドが大規模サイト向けの上級者向け資料だとGoogle自身が明言しているという事実です。ページ数がそれほど多くなく、公開した日にクロールされているサイトなら、読む必要はないとまで書かれています。
中小企業のサイトでインデックスされない場合、原因はクロールバジェットではなく、技術的な設定ミスかコンテンツの独自性であることがほとんどです。Googleの担当者も、技術的に直そうとする前にサイト全体の品質を見直すよう促しています。
今日できることをひとつだけ挙げるなら、Search Consoleの「ページのインデックス登録」レポートを開き、登録されていないページの理由を件数の多い順に確認することです。そこに書かれている理由が、次にやるべきことをそのまま教えてくれます。
クロール・インデックス対策のご相談はアクセス・リンクへ
株式会社アクセス・リンクは、栃木県下野市を拠点に、SEOコンサルティングとホームページ制作を行っている会社です。代表の三田健司は全日本SEO協会の認定SEOコンサルタントとして、Webサイトの制作・運用に10年以上、延べ1,000件以上の案件に携わってきました。
「新しいページがインデックスされない」「Search Consoleに見慣れないエラーが並んでいる」といったご相談も多くいただきます。技術的な原因なのか、コンテンツの見直しが必要なのかを切り分けたうえで、優先順位をつけてご提案します。
自社サイトの状況を一度整理したいという方は、お問い合わせフォームからお気軽にご相談ください。現状のヒアリングから丁寧に対応いたします。
記事執筆・株式会社アクセス・リンク 代表取締役
Webサイト制作歴10年以上の経験を元にSEOコンサルティングを行い、延べ1,000件以上のサポート実績を誇ります。個人事業主や中小企業向けのホームページ制作やSEOコンサルティングを得意としています。
（社）全日本SEO協会 認定SEOコンサルタント
コメント