HTTP ステータス コード、ネットワーク エラーおよび DNS エラーが Google 検索に及ぼす影響

このページでは、各種の HTTP ステータス コード、ネットワーク エラーおよび DNS エラーが Google 検索に及ぼす影響について説明します。Googlebot がウェブでよく検出する上位 20 のステータス コードと、最も顕著なネットワーク エラーおよび DNS エラーを取り上げます。418 (I'm a teapot) などのまれにしか発生しないステータス コードは取り上げません。このページで言及しているすべての問題で生成されるエラーまたは警告は、Search Console のページのインデックス登録レポートに表示されるエラーまたは警告に対応しています。

HTTP ステータス コード

HTTP ステータス コードは、サイトをホストしているサーバーがブラウザやクローラなどのクライアントからのリクエストに応答したときに、それらのサーバーによって生成されます。HTTP ステータス コードにはそれぞれ異なる意味がありますが、多くの場合、リクエストの結果は同じです。たとえば、リダイレクトを示すステータス コードは複数ありますが、その結果はいずれも同じです。

Search Console は、4xx–5xx の範囲のステータス コードと、リダイレクトの失敗(3xx)について、エラー メッセージを生成します。サーバーがレスポンスで 2xx ステータス コードを返した場合、レスポンスで受信したコンテンツのインデックス登録が検討される可能性があります。

次の表では、Googlebot がよく検出する HTTP ステータス コードと、Google での各ステータス コードの処理方法を示しています。

HTTP ステータス コード

2xx (success)

Google はコンテンツのインデックス登録を検討します。コンテンツにエラーがあることが示唆される場合(空白のページやエラー メッセージなど)、Search Console はsoft 404 エラーを表示します。

200 (success)

Google は、コンテンツをインデックス登録パイプラインに渡します。コンテンツはインデックス登録システムによってインデックスに登録される可能性がありますが、登録される保証はありません。

201 (created)
202 (accepted)

Googlebot は、コンテンツの受信を一定期間待機してから、受信したすべての情報をインデックス登録パイプラインに渡します。タイムアウト期間はユーザー エージェントによって異なります。たとえば、スマートフォン用 Googlebot と画像用 Googlebot ではタイムアウト期間が異なる場合があります。

204 (no content)

Googlebot は、コンテンツを受信しなかったことをインデックス登録パイプラインに知らせます。Search Console は、サイトのページのインデックス登録レポートsoft 404 エラーを表示する場合があります。

3xx (redirection)

Googlebot は最大 10 回のリダイレクト ホップを追跡します。クローラーが 10 回以内のホップでコンテンツを受信しなかった場合、Search Console はサイトのページのインデックス登録レポートにリダイレクト エラーを表示します。Googlebot が追跡するホップ回数はユーザー エージェントによって異なります。たとえば、スマートフォン用 Googlebot と画像用 Googlebot では値が異なる場合があります。

robots.txt の場合、Googlebot は RFC 1945 の規定に従い、最低 5 回のリダイレクト ホップを追跡した後で追跡を停止し、robots.txt ファイルの 404 エラーとして扱います。

Googlebot がリダイレクト URL から受信したコンテンツはすべて無視され、最終的なターゲット URL のコンテンツのインデックス登録が検討されます。

301 (moved permanently)

Googlebot はリダイレクトを追跡します。リダイレクトはインデックス登録パイプラインによって、リダイレクトの宛先が正規版であることを示す強いシグナルとして使用されます。

302 (found)

Googlebot はリダイレクトを追跡します。リダイレクトはインデックス登録パイプラインによって、リダイレクトの宛先が正規版であることを示す弱いシグナルとして使用されます。

303 (see other)
304 (not modified)

Googlebot は、コンテンツが前回のクロール時と同じであることをインデックス登録パイプラインに知らせます。インデックス登録パイプラインは URL のシグナルを再計算する場合がありますが、再計算しない場合、ステータス コードはインデックス登録に影響しません。

307 (temporary redirect) 302 と同じです。
308 (moved permanently) 301 と同じです。

4xx (client errors)

Google のインデックス登録パイプラインは、インデックス登録において、4xx ステータス コードを返す URL を考慮しません。また、すでにインデックスに登録されている URL が 4xx ステータス コードを返すと、その URL はインデックスから削除されます。

Googlebot が 4xx ステータス コードを返す URL から受信したコンテンツはすべて無視されます。

400 (bad request)

429 を除くすべての 4xx エラーは同じように扱われます。Googlebot は、コンテンツが存在しないことをインデックス登録パイプラインに知らせます。

URL が以前インデックスに登録されていた場合は、インデックス登録パイプラインによってインデックスから削除されます。 新たに検出された 404 ページは処理されません。クロール頻度は徐々に低下します。

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

Googlebot は、429 ステータス コードをサーバーが過負荷状態であることを示すシグナルとして扱います。これはサーバーエラーと見なされます。

5xx (server errors)

5xx および 429 サーバーエラーは、Google のクローラに対して一時的にクロールのペースを落とすように促します。すでにインデックスに登録されている URL はインデックスに保持されますが、最終的には削除されます。

robots.txt ファイルが 30 日以上サーバーエラーのステータス コードを返す場合、Google は robots.txt の最後のキャッシュ コピーを使用します。使用できない場合、Google はクロールに対する制限はないと見なします。

Googlebot が 5xx ステータス コードを返す URL から受信したコンテンツはすべて無視されます。

500 (internal server error)

Googlebot はサイトのクロール頻度を落とします。クロール頻度の低下は、サーバーエラーを返す個別の URL の数に比例します。 Google のインデックス登録パイプラインは、繰り返してサーバーエラーを返す URL をインデックスから削除します。

502 (bad gateway)
503 (service unavailable)

soft 404 エラー

soft 404 とは、URL にアクセスしたときに、ページが存在しないことと 200 (success) のステータス コードをユーザーに伝えるページを返す URL のことを指します。場合によっては、メイン コンテンツのないページや空白のページなどもこれに該当します。

こうしたページは、ウェブサイトのウェブサーバーやコンテンツ管理システム、ユーザーのブラウザによってさまざまな理由で生成される場合があります。次に例を示します。

  • サーバーサイド インクルード ファイルがない。
  • データベースへの接続が切断されている。
  • 内部検索結果ページが空である。
  • JavaScript ファイルがアンロードされている、または欠落している。

200 (success) ステータス コードを返したのに、ページにエラー メッセージやなんらかのエラーを表示または示唆することは、ユーザーの利便性を損ねます。ユーザーは、そのページが公開中の有効なページであると認識する可能性がありますが、なんらかのエラーが表示されることがあります。このようなページは検索から除外されます。

Google のアルゴリズムが、コンテンツに基づいてそのページが実際にエラーページであることを検出すると、Search Console はサイトのページのインデックス登録レポートsoft 404 エラーを表示します。

soft 404 エラーを修正する

ページの状態と求める結果に応じて、さまざまな方法で soft 404 エラーを解決できます。

ユーザーにとって最適な解決方法を選択してください。

該当ページおよびコンテンツが利用できなくなっている

該当ページが削除されており、同様のコンテンツを含む代替ページがサイトに存在しない場合は、404 (not found) または 410 (gone) のレスポンス(ステータス)コードを返します。これらのステータス コードは、該当ページが存在せず、コンテンツをインデックスに登録するべきではないことを検索エンジンに指定します。

サーバーの設定ファイルにアクセスできる場合は、これらのエラーページをカスタマイズしてユーザーの利便性を向上させることができます。404 ページをわかりやすくカスタマイズすることにより、探している情報の場所をユーザーに知らせることができます。また、役に立つ他のコンテンツを提供して、サイト内をさらに探すよう促すこともできます。有用なカスタム 404 ページを設計するためのヒントは次のとおりです。

  • ユーザーに対して、探しているページが見つからないことを明確に伝えます。親しみやすく平易な言葉を使用します。
  • 404 ページを、サイトのその他の部分と同じデザイン(ナビゲーションを含む)にします。
  • 最も人気のある記事や投稿へのリンクのほか、ホームページへのリンクを追加します。
  • 無効なリンクを報告する方法をユーザーに提供することを検討します。

カスタム 404 ページは、ユーザーのためにカスタマイズして作成されるページです。こうしたページは検索エンジンの観点からは無用なため、ページがインデックスに登録されないように、サーバーが 404 HTTP ステータス コードを返すようにしてください。

該当ページまたはコンテンツが移動されている

該当ページが移動されている場合、または明確な代替ページが存在する場合は、301 (permanent redirect) を返してユーザーを適宜リダイレクトします。リダイレクトを使用することで、ユーザーのページの閲覧が妨げられることがなくなり、ページの新しい場所を検索エンジンに伝えることもできます。URL 検査ツールを使用して、URL が実際に正しいコードを返しているかどうかを確認してください。

該当のページおよびコンテンツが引き続き存在している

正常なページが soft 404 エラーと認識されている場合は、Googlebot に正しく読み込まれなかった、重要なリソースが欠落している、またはレンダリング中に重大なエラー メッセージが表示された可能性があります。URL 検査ツールを使用して、レンダリングされたコンテンツと返された HTTP コードを調べます。レンダリングされたページが空白になるか、ほとんど空白になるか、コンテンツにエラー メッセージがある場合、読み込むことができないリソース(画像、スクリプト、テキスト以外のその他の要素)を多く参照している可能性があります。このような状態は、soft 404 と解釈されます。リソースを読み込めない理由としては、リソースが(robots.txt によって)ブロックされている、ページ上のリソースが多すぎる、さまざまなサーバーエラー、読み込みが遅い、リソースが大きすぎるなどが考えられます。

ネットワーク エラーおよび DNS エラー

ネットワーク エラーおよび DNS エラーは、Google 検索における URL のプレゼンスに直ちに悪影響を及ぼします。Googlebot は、ネットワーク タイムアウト、接続リセット、DNS エラーを 5xx サーバーエラーと同様に扱います。ネットワーク エラーの場合は、サーバーが配信負荷を処理できない可能性があることを示しているため、直ちにクロール頻度の低下が始まります。Googlebot がサイトをホストしているサーバーにアクセスできなかったということは、Google がサーバーからのコンテンツを受信していないことを意味します。コンテンツがないと、Google はクロールされた URL をインデックスに登録できません。また、すでにインデックスに登録されている URL がアクセス不能な場合は、数日以内に Google のインデックスから削除されます。Search Console は、個々のエラーごとにエラーを生成する場合があります。

ネットワーク エラーをデバッグする

この種のエラーは、Google が URL のクロールを開始する前、または Google が URL をクロールしている最中に発生します。サーバーが応答する前にエラーが発生するために、問題を特定するヒントになるステータス コードが返されず、エラーの診断が難しくなる場合があります。タイムアウト エラーと接続リセットエラーをデバッグするには、次の手順を実施します。

  • ファイアウォールの設定とログを確認します。ブロックルール セットの範囲が広すぎる場合があります。Googlebot の IP アドレスがファイアウォール ルールによってブロックされていないことを確認してください。
  • ネットワーク トラフィックを確認しますtcpdumpWireshark などのツールを使用して、TCP パケットをキャプチャして分析し、特定のネットワーク コンポーネントまたはサーバー モジュールを指し示す異常を探します。
  • 疑わしい要因が見つからない場合は、ホスティング会社にお問い合わせください

ネットワーク トラフィックを処理するサーバー コンポーネントにエラーが潜んでいる可能性があります。たとえば、過負荷状態のネットワーク インターフェースによって一部のパケットがドロップされると、タイムアウト(接続を確立できない)や接続リセット(ポートが誤って閉じられたために RST パケットが送信される)が生じることがあります。

DNS エラーをデバッグする

一般的に、DNS エラーは構成ミスが原因で発生しますが、Googlebot の DNS クエリをブロックしているファイアウォール ルールが原因で発生することもあります。DNS エラーをデバッグするには、次の手順を実施します。

  • ファイアウォール ルールを調べます。ファイアウォール ルールによって Google のどの IP もブロックされていないことと、UDP リクエストと TCP リクエストの両方が許可されていることを確認してください。
  • DNS レコードを確認しますA レコードと CNAME レコードが、それぞれ正しい IP アドレスとホスト名を指していることを確認します。次に例を示します。
    dig +nocmd example.com a +noall +answer
    dig +nocmd www.example.com cname +noall +answer
  • すべてのネームサーバーがサイトの正しい IP アドレスを指していることを確認します。次に例を示します。
    dig +nocmd example.com ns +noall +answer
    example.com.    86400  IN  NS  a.iana-servers.net.
    example.com.    86400  IN  NS  b.iana-servers.net.
    dig +nocmd @a.iana-servers.net example.com +noall +answer
    example.com.    86400  IN  A  93.184.216.34
    dig +nocmd @b.iana-servers.net example.com +noall +answer
    ...
  • 過去 72 時間以内に DNS 構成に変更を加えた場合は、グローバル DNS ネットワーク全体に変更が伝播されるまで待つ必要があります。 伝播を速めるには、Google のパブリック DNS キャッシュをフラッシュする方法があります。
  • 自前の DNS サーバーを運用している場合は、サーバーが正常で過負荷状態になっていないことを確認します。