HTTPステータスコードをGooglebotはどのように処理するのか? Googleが詳細に解説

[レベル: 上級]

HTTP ステータスコードとネットワーク/DNS エラーに関する技術ドキュメントを Google は検索セントラルサイトに新規に公開しました。

この記事では、概要と、特に重要な部分を紹介します。

Google 検索での HTTP ステータスコードの扱い

HTTP ステータスコードの定義は RFC 7231 などで定められています。
しかしながら、Google 検索は独自の扱いをすることもあります。

Googlebot がウェブをクロールしてきたなかで最も多く返された 20 種類のステータスコードの扱いをドキュメントは説明しています。

2xx/3xx/4xx/5xx の最終的な扱いは基本的に同じ

ステータスコードは次の 4 つのカテゴリに大別できます。

  • 200 番台 (2xx)
  • 300 番台 (3xx)
  • 400 番台 (4xx)
  • 500 番台 (5xx)

基本的に、それぞれの番台のステータスコードの最終的な処理は同じになります。
たとえば、同じリダイレクトでも、301 と 302 では技術的に表す意味合いは異なります。

  • 301: URLが恒久的に変わった
  • 302: URL が一時的に変わった

それでも、Google 検索においては 301 と 302 の扱いは結局のところ同じです。

Googlebot が遭遇する各番台の具体的なステータスコードは次のとおりです。

2xx

  • 200 (success)
  • 201 (created)
  • 202 (accepted)
  • 204 (no content)

200 番台はどれも「成功」で、URL はインデックスの対象になります(必ずしもインデックスされるとは限らない)。

ただし、次のいずれかの場合はソフト 404 として処理される場合があります。

  • 200 を返してもコンテンツがない
  • 204 を返す

3xx

  • 301 (moved permanently)
  • 302 (found)
  • 303 (see other)
  • 304 (not modified)
  • 307 (temporary redirect)
  • 308 (moved permanently)

300 番台は転送を意味します。
言い換えると URL の変更です。
どれも転送先の URL がインデックスの対象になります。

ただし若干の違いがあります。
301 は転送先の URL が正規 URL だという強いシグナルを送ります。
一方で、302 が送るシグナルは弱いものです。

最終的には、301 も 302 も転送先の URL がインデックスされる(PageRank などの評価も引き継がれる)のですが、処理にかかる時間の観点では 301 の方がずっと早いでしょう。
本来の定義上、301 は URL の恒久的な変更を意味するからです。

302 は一時的な移動を意味するものの、長期にわたってリダイレクトが継続すると、完全に移動したものだと Google は判断するのです。
そして 301 のように処理します。
ほかの検索エンジンは、RFC の定義に忠実に処理するかもしれません。

なお、307 は 302 相当で、308 は 301 相当とのことです。

また、リダイレクトが連続した場合は 10 回まで Googlebot はたどります。
11 回以上リダイレクトが続くと、リダイレクトエラーになります。

なお robots.txt に関しては、リダイレクトは 5 回までです。
6 回以上のリダイレクトは 404 として処理されます。

4xx

  • 400 (bad request)
  • 401 (unauthorized)
  • 403 (forbidden)
  • 404 (not found)
  • 410 (gone)
  • 411 (length required)
  • 429 (too many requests)

400 番台はクライアント側(ブラウザや Googlebot)のエラーです。

400 番台のステータスコードを返す URL はインデックス処理が行われません(例外 は 429、後述)。
すでにインデックスされている URL が再クロール時に 400 番台を返すとインデックスから削除されます。

404 も 410 は表す意味が技術的には異なっても Google 検索での処理は同じです。
差異がないわけではなさそうですが、極めて小さなものです。

なお 429 は、サーバーに過多なリクエストが発生していることを意味し、次に示す 5xx のサーバーエラーと同等に扱われます。
Googlebot のクロールを抑える目的で 429 を利用できます。
429 以外の 4xx にはクロールを抑える効果はありません。

5xx

  • 500 (internal server error)
  • 502 (bad gateway)
  • 503 (service unavailable)

500 番台はサーバー側のエラーを意味します。

5xx のステータスコードを Googlebot が受け取ったときは、クロール頻度を下げます。
すでにインデックスされている URL はそのままの状態を保ちます。
とはいえ、長期にわたって 5xx を返し続けるといずれインデックスからは削除されます。

サーバーのメンテナンスでサイトを一時停止するときは 503 を返すようにサーバーを構成するのが原則です。
ですが、Google 的には、500 でも 502 でも(429 でも)たいして違わないということですね(それでも 503 を絶対的に推奨しますが)。

なお、robots.txt が 5xx を返すと Googlebot はそのサイト全体をクロールしません。
robots.txt が 30 日以上 5xx を返すと、robots.txt の最後のキャッシュ コピーに従ってクロールします。
キャッシュの robots.txt がない場合は制限なしにクロールします。

僕のように、こういった技術的な解説が好きな人はドキュメントをご自身で読んでください。
面白いです。

ネットワーク エラーと DNS エラーに関してはこの記事では触れなかったのでドキュメントで確認してください。

この記事を書いた時点では、ドキュメントは英語だけです。
日本語訳ページはまだ出ていません。
ゲイリーをせっつくといいかもしれません(笑)。

【UPDATE (2021/07/12)】
日本語ページも公開されています。