大規模なサイト所有者向けのクロール バジェット管理ガイド
このガイドでは、大規模かつ頻繁に更新されるサイトの Google のクロールを最適化する方法について説明します。
サイト内で頻繁に更新されるページがそれほど多くない場合や、ページが公開日と同じ日にクロールされると考えられる場合は、このガイドを読む必要はありません。サイトマップを最新の状態に保ち、定期的にインデックス カバレッジを確認するだけで十分です。
しかし、提供後しばらく経ったにもかかわらずインデックスに登録されていないコンテンツがある場合は、別の問題がある可能性があります。その場合は、URL 検査ツールを使用して、ページがインデックスに登録されていない理由を確認してください。
このガイドの対象読者
これは上級者向けのガイドであり、以下のサイトを対象としています。
- 大規模（重複のないページが 100 万以上）で、コンテンツが中程度に（1 週間に 1 回）更新されるサイト
- 中規模以上（重複のないページが 1 万以上）で、コンテンツがかなり頻繁に（毎日）更新されるサイト
- Search Console で URL の大部分が検出- インデックス未登録に分類されるサイト
クロールの一般理論
ウェブはほぼ無限に近い空間であるため、利用可能な URL をすべて調査してインデックスに登録するとなれば、Google の能力を超えることになります。そのため、Googlebot が 1 つのサイトをクロールできる時間には限界があります。Google がサイトのクロールに費やす時間とリソースは、通常、サイトのクロール バジェットと呼ばれます。サイト上でクロールされたすべてのページが必ずしもインデックスに登録されるわけではありません。各ページを評価、統合、査定して、クロール後にインデックスに登録するかどうかを判断する必要があります。
クロール バジェットは、クロール能力の上限とクロールの必要性の 2 つの要素によって決まります。
クロール能力の上限
Google では、Googlebot によってご利用のサーバーに負担をかけることなく、サイトをクロールしたいと考えています。Googlebot では、負担をかけないためのクロール能力の上限を計算します。計算では、Googlebot でサイトのクロール時に使用可能な同時並行接続の最大数と、次回の取得までに必要な待ち時間が考慮されます。また、サーバーに過負荷をかけずに重要なコンテンツ全体をカバーするように配慮されます。
クロール能力の上限は、以下のようないくつかの要因に基づいて上下することがあります。
- クロールの状態: しばらくの間サイトが迅速に応答している場合はクロール頻度の上限が上がるので、クロール時に使用可能な接続の数が増えます。サイトの応答が遅くなった場合やサーバーエラーが返された場合はクロール頻度の上限が下がり、Googlebot によるクロールが減ります。
- Google のクロール上限: Google には多数のマシンがありますが、どのマシンでもクロール頻度に上限があります。これまでどおり、現在のリソースに従って選択する必要があります。
クロールの必要性
Google では通常、他のサイトと比較して、クロールする時間、更新頻度、ページの品質、関連性を考慮して、サイトのクロールに必要なだけの時間を費やしています。
クロールの必要性を決定する重要な要素は次のとおりです。
- 検出された URL 群: Googlebot は、ユーザーの指示がなければ、サイト上の認識している URL のすべてまたはほとんどをクロールしようとします。多くの URL が重複している場合や、他の理由（削除されている、または重要でない URL など）でクロールされたくない場合、サイトのクロールに費やす時間の多くが無駄になってしまいます。これはサイト所有者が最も確実に管理できる要素です。
- 人気度: インターネット上で人気の高い URL ほど、Google のインデックスで情報の新しさが保たれるよう頻繁にクロールされる傾向があります。
- 古さ: Google のシステム側からは、変更の反映に十分な頻度でドキュメントを再クロールしたいと考えています。
また、サイトの移転といったサイト全体のイベントでは、新しい URL のコンテンツをインデックスに再登録するために、クロールの必要性が高まることがあります。
まとめ
こうしたクロール能力とクロールの必要性を併せて考えると、サイトに対するクロール バジェットとは、Googlebot によるクロールが可能であり、かつクロールが必要な URL セットであると定義できます。クロール能力の上限に達していない場合でも、クロールの必要性が少なければ、Googlebot によるサイトのクロールは少なくなります。
おすすめの方法
以下のおすすめの方法に沿って、クロールの効率を最大化します。
- URL 群を管理する: 適切なツールを使用して、クロールしてほしいページとクロールしてほしくないページを Google に伝えます。Google がインデックス登録に適さない URL に時間をかけすぎている場合、Googlebot は、サイトの残りの URL を確認しなくても問題ないと判断することがあります（確認する必要があると判断した場合は、バジェットを増やします）。
- 重複コンテンツを 1 つにまとめる: 重複コンテンツを除外して、一意の URL ではなく一意のコンテンツのみをクロールするようにします。
- robots.txt を使用して URL のクロールをブロックする: ユーザーにとって重要であっても、必ずしも検索結果に表示させたくないページがあります。たとえば、リンクされているページで情報が重複している無限スクロール ページや、内容は同じで並べ方が違うだけのページなどです。このリストの最初の項目にあるように重複ページを 1 つにまとめることができない場合は、robots.txt を使用して、（検索にとっては）重要でないページをブロックします。robots.txt を使用して URL をブロックすると、URL がインデックスに登録される可能性が大幅に低下します。
-
完全に削除されたページについては
404または410ステータス コードを返す: Google は認識している URL を無視することはありませんが、404ステータス コードは、対象の URL を再度クロールしないことを強く求めるシグナルです。ただし、ブロックされた URL はその後もしばらくクロールキューに残り、ブロックが解除されると再クロールされます。 soft 404エラーを削除する:soft 404ページは引き続きクロールされるため、バジェットが無駄になります。soft 404エラーについては、インデックス カバレッジ レポートをチェックしてください。- サイトマップを最新の状態に保つ: Google は定期的にサイトマップを読み取っているので、Google にクロールさせたいコンテンツはすべてサイトマップに含めてください。更新したコンテンツがサイトにある場合は、
<lastmod>タグを含めることをおすすめします。 - 長いリダイレクト チェーンを避ける: クロールに悪影響を及ぼす長いリダイレクト チェーンは避けます。
- ページの読み込みを効率化する: Google がより高速にページを読み込んでレンダリングできるようになると、サイトからより多くのコンテンツを読み取れる可能性があります。
- サイトのクロールをモニタリングする: クロール時にサイトの可用性に関する問題が発生していないかをモニタリングし、クロールを効率化する方法を探します。
サイトのクロールとインデックス登録のモニタリング
サイトのクロール プロファイルをモニタリングする手順は次のとおりです。
- Googlebot において、サイトの可用性に関する問題が発生していないかを確認します。
- クロールされていないが、クロール対象とすべきページがあるかどうかを確認します。
- 今より速やかにクロールされるべきコンテンツがサイトにないかを確認します。
- サイトのクロール効率を向上させます。
- サイトの過剰クロールに対応します。
Googlebot に対してサイトの可用性に関する問題が発生していないかを確認する
サイトの可用性を改善しても、クロール バジェットが増えるとは限りません。前述のとおり、Google はクロールの必要性に基づいて最適なクロール頻度を決定します。しかし、可用性の問題は、Google がサイトをクロールしようとしたときにそれを妨げる原因になります。
診断:
クロールの統計情報レポートを使用して、サイトに関する Googlebot のクロール履歴を確認します。このレポートには、Google がサイトで可用性の問題を検出した日時が表示されます。サイトに関する可用性のエラーや警告が報告されている場合、ホストの可用性グラフで、Googlebot のリクエスト件数が赤色の上限を超えているインスタンスを探してグラフをクリックし、失敗した URL を確認して、サイトの問題と結び付けてみてください。
また、URL 検査ツールを使用して、サイト上の URL をいくつかテストすることもできます。このツールから「ホスト負荷が制限を超えています」という警告が返された場合、サイトで検出された URL が多すぎて Googlebot がクロールしきれないことを意味します。
対応:
- 可用性の問題を検出して対処する方法については、クロールの統計情報レポートに関するドキュメントをご覧ください。
- クロールされたくないページのクロールをブロックします（URL 群の管理をご覧ください）。
- ページの読み込み速度とレンダリング速度を上げます（サイトのクロール効率を向上させるをご覧ください）。
- サーバー能力を増強します。Google が常にサービス能力の上限でサイトをクロールしているように見えても、必要にもかかわらずクロールまたは更新されていない重要な URL がある場合は、より多くのリソースを提供することで、Google がサイトのページをより多くリクエストできるようになります。クロールの統計情報レポートでホストの可用性の履歴を調べ、Google のクロール頻度が頻繁に上限に達していないかを確認します。頻繁に上限に達している場合は、1 か月間サービス リソースを増やし、その期間にクロール リクエストが増えたかどうかを確認します。
クロールされていないがクロールされるべきページがないかを確認する
Google は、高品質でユーザー価値の高いコンテンツをすべてインデックスに登録するために、サイトに必要なだけの時間を費やしています。Googlebot が重要なコンテンツをクロールできていないとお考えの場合、それは Googlebot がコンテンツを把握していないか、コンテンツが Google からブロックされているか、サイトの可用性によって Google のアクセスが調整されている（あるいは Google がサイトに負荷をかけないようにしている）かのいずれかです。
診断:
Search Console では、サイトのクロール履歴を URL またはパスでフィルタして確認することはできません。しかし、サイトログを調べると、特定の URL が Googlebot によってクロールされているかどうかを確認できます。このクロールされた URL がインデックスに登録されているかどうかは別問題です。
ほとんどのサイトでは、新しいページが認識されるまでに数日かかります。ニュースサイトなど、時間的制約のあるサイトを除き、ほとんどのサイトでは URL がすべて同じ日にクロールされるとは限りません。
対応:
サイトにページを追加してから十分に時間が経過してもクロールされない場合、その原因は、Google がページを認識していない、コンテンツがブロックされている、サイトが処理能力の限界に達している、クロール バジェットの対象外である、のいずれかです。
- 新しいページについて Google に指示する: 新しい URL を反映するようにサイトマップを更新します。
- robots.txt ルールを調べて、ページが誤ってブロックされていないことを確認します。
- クロールの優先順位を確認します（クロール バジェットを上手に使用します）。URL 群を管理し、サイトのクロール効率を向上させます。
- 処理能力が不足していないことを確認します。 Googlebot は、サーバーがクロール リクエストに応答できないことを検出すると、クロールを縮小します。
ページがクロールされたとしても、十分な価値やユーザーの需要がなければ、検索結果に表示されないことがあるので、注意が必要です。
更新内容がすぐにクロールされるかどうかを確認する
Google がサイトの新しいページや更新ページをクロールできていない場合、おそらく検知していないか、更新されていることを認識していないことが考えられます。Google がページの更新を認識できるようにするための方法をご紹介します。
Google では、ページを適切なタイミングでチェックしてインデックスに登録するよう努めていますが、ほとんどのサイトでは 3 日以上かかります。ニュースサイトなど、価値が高く時間的制約があるコンテンツがない限り、公開したその日に Google がページをインデックスに登録することはないと考えてください。
診断:
サイトログを調べて、特定の URL がいつ Googlebot によってクロールされたかを確認します。
インデックス登録日を確認するには、URL 検査ツールを使用するか、更新した URL を Google 検索します。
対応:
すべきこと:
- サイトにニュース コンテンツがある場合は、ニュース サイトマップを使用する。
- サイトマップ内で
<lastmod>タグを使用し、インデックス登録済みの URL が更新されたことを示す。 - シンプルな URL 構造を使用して、Google がページを検出できるようにする。
- Google が容易にページを見つけられるように、標準のクロール可能な
<a>リンクを提供する。
避けるべきこと:
- 変更されていない同じサイトマップを 1 日に複数回送信する。
- Googlebot がサイトマップ内のすべてをクロールするか、すぐにクロールすると考える。 サイトマップは Googlebot にとって有用なヒントになりますが、絶対的な要件ではありません。
- Google 検索の検索結果に表示したくないページの URL をサイトマップに含める。 これを行うと、インデックスに登録されたくないページがクロールされ、クロール バジェットが無駄になる可能性があります。
サイトのクロール効率を向上させる
ページの読み込み速度を上げる
Google のクロールは、帯域幅、時間、Googlebot インスタンスの可用性によって制限されます。 サーバーがリクエストに迅速に応答する場合は、Google がサイトのページをより多くクロールできる可能性があります。ただし、Google がクロールしたいと望んでいるのは高品質のコンテンツだけなので、低品質のページを高速化しただけでは、Googlebot によるクロールは増加しません。逆に、Google がサイトに含まれる高品質のコンテンツを見落していると判断した場合は、コンテンツをクロールするバジェットを増やす可能性があります。
クロールのためにページとリソースを最適化する方法は次のとおりです。
- robots.txt を使用して、サイズは大きいが重要でないリソースが Googlebot によって読み込まれることを防ぎます。重要でないリソース、つまりページの意味を理解するうえで重要でないリソース（装飾画像など）のみをブロックしてください。
- ページの読み込みが速いことを確認します。
- 長いリダイレクト チェーンはクロールに悪影響を及ぼすため、ご注意ください。
- サーバー リクエストに応答する時間と、ページのレンダリングに必要な時間の両方が重要です。これには、画像やスクリプトなどの埋め込みリソースの読み込み時間と実行時間も含まれます。インデックスへの登録が必要な大きいリソース、つまり読み込みが低速なリソースにご注意ください。
HTTP ステータス コードでコンテンツの変更を示す
Google は通常、クロールに関して If-Modified-Since および If-None-Match HTTP リクエスト ヘッダーをサポートしています。Google のクローラは、すべてのクロールの試みでヘッダーを送信するわけではなく、送信するかどうかはリクエストのユースケースによって異なります（たとえば、AdsBot は If-Modified-Since および If-None-Match HTTP リクエスト ヘッダーを設定する可能性が高くなります）。Google のクローラが If-Modified-Since ヘッダーを送信する場合、ヘッダーの値は、コンテンツが最後にクロールされた日時になります。その値に基づいて、サーバーはレスポンス本文なしで 304 (Not Modified) HTTP ステータス コードを返すことを選択する場合があります。この場合、Google は最後にクロールしたコンテンツ バージョンを再利用します。クローラが If-Modified-Since ヘッダーで指定した日付よりコンテンツの方が新しい場合、サーバーはレスポンス本文付きで 200 (OK) HTTP ステータス コードを返せます。
リクエスト ヘッダーとは無関係に、Googlebot が最後に URL にアクセスしてからコンテンツが変更されていない場合は、Googlebot のリクエストに対してレスポンス本文なしで 304 (Not Modified) HTTP ステータス コードを送信できます。これにより、サーバーの処理時間とリソースが節約され、間接的にクロールの効率が向上する可能性があります。
検索結果に表示させたくない URL を非表示にする
重要でないページでサーバー リソースが浪費されると、重要なページのクロールの妨げとなるため、サイト上の重要な新規または更新済みのコンテンツの検出に大幅な遅れが生じることがあります。
クロールされたくない多数の URL が検索結果に表示されると、サイトのクロールとインデックス登録に悪影響を及ぼす可能性があります。一般的に、こうした URL は以下のカテゴリに分類されます。
- ファセット ナビゲーションとセッション ID: ファセット ナビゲーションは、通常はサイトの重複コンテンツです。単にページの並べ替えまたはフィルタリングを行うセッション ID などの URL パラメータは、新しいコンテンツを提供しません。ファセット ナビゲーション ページは、robots.txt を使用してブロックします。
- 重複コンテンツ: 不要なクロールを避けるため、Google が重複コンテンツを特定できるようにします。
soft 404ページ: ページがすでに存在しない場合は、404コードを返します。- ハッキングされたページ: [セキュリティの問題] レポートを確認し、ハッキングされたページが見つかった場合は、そのページを修正または削除します。
- 無限のスペースとプロキシ: robots.txt を使用して、これらに対するクロールをブロックします。
- 低品質のコンテンツとスパム コンテンツ: これらは当然避けるべきです。
- ショッピング カート ページ、無限スクロール ページ、アクションを行うページ（「登録」ページ、「今すぐ購入」ページなど）。
すべきこと:
- リソースやページのクロールを望まない場合は、robots.txt を使用します。
- 共有リソースを複数のページ（共有画像や JavaScript ファイルなど）で再利用している場合、各ページで同じ URL からリソースを参照するようにすると、Google が同じリソースを何度もリクエストしなくてもキャッシュして再利用できるようになります。
避けるべきこと:
- サイトのクロール バジェットを再配分する方法として、robots.txt にページまたはディレクトリを定期的に追加または削除しないでください。robots.txt は、長時間にわたって Google に表示させたくないページやリソースにのみ使用します。
- バジェットを再配分する目的で、サイトマップをローテーションしたり、他の一時的な非表示メカニズムを使用したりしないでください。
サイトの過剰クロールに対応する（緊急時）
Googlebot には、クロール リクエストによってサイトが過負荷にならないようにするアルゴリズムがあります。 ただし、Googlebot によるサイトの過負荷が判明した場合、次の方法をお試しください。
診断:
サイト対して Googlebot の過剰なリクエストがないかサーバーを監視します。
対応:
緊急時に、Googlebot による過剰なクロールを緩和するには、以下の手順をおすすめします。
- サーバーが過負荷になっているときは、Googlebot のリクエストに対して、一時的に、
503または429HTTP レスポンス ステータス コードを返します。Googlebot はこのような URL に対して約 2 日間リクエストを再試行します。「利用不可」を示すコードが数日にわたって返されると、サイトの URL に対する Google のクロールが恒常的に減少または停止します。したがって、次の追加手順を実施する必要があります。 -
クロール頻度が低下したら、クロール リクエストに対して
503または429HTTP レスポンス ステータス コードを返すのをやめます。2 日間を超えて503または429を返すと、Google はそれらの URL をインデックスから削除します。 - ある程度の期間にわたってクロールおよびホスト能力をモニタリングします。
- 問題のあるクローラーが AdsBot クローラーである場合、Google がクロールしようとしているサイト用に動的検索広告ターゲットを作成したことが問題の原因になっている可能性があります。このクロールは 3 週間ごとに再実行されます。これらのクロールを処理できるだけのサーバー容量がない場合は、広告ターゲットを制限するか、配信容量を増やしてください。
クロールに関する誤解と事実
Google がウェブサイトをクロールしてインデックス登録する方法について、知識をテストしましょう。
5xx HTTP レスポンス ステータス コード（サーバーエラー）や接続タイムアウトが著しく多いと、サーバーの状態が健全でないと見なされ、クロール頻度が低下します。このため、Search Console のクロールの統計情報レポートに注意を払い、サーバーエラーを少なく抑えることをおすすめします。
nofollow ルールはクロール バジェットに影響する。nofollow とマークされていても、サイトの別のページやウェブ上の任意のページがリンクを nofollow としてラベル付けしていない場合は、クロールの対象となります。noindex を使用してクロール バジェットを制御できる。noindex ルールを見つけるには、ページをクロールする必要があります。ただし、
noindex はページをインデックス登録から除外するのに役立ちます。ページが最終的に Google のインデックスに登録されないようにしたい場合は、クロール バジェットを気にせずに、引き続き noindex を使用してください。また、noindex などの方法を使用して Google のインデックスから URL を削除すると、Googlebot はサイト上の他の URL に集中できるという点も重要です。つまり、noindex を使用すると、長期的にはサイトのクロール バジェットを間接的に解放できます。
4xx HTTP ステータス コードを配信するページは、クロール バジェットを浪費している。4xx HTTP ステータス コード（429 以外）を配信するページがクロール バジェットを浪費することはありません。Google がそのページをクロールしようとした場合、ステータス コード以外のコンテンツは受け取りません。