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 ステータス コード | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Google はコンテンツのインデックス登録を検討します。コンテンツにエラーがあることが示唆される場合（空白のページやエラー メッセージなど）、Search Console は
|
|||||||||||
|
Googlebot は最大 10 回のリダイレクト ホップを追跡します。クローラーが 10 回以内のホップでコンテンツを受信しなかった場合、Search Console はサイトのページのインデックス登録レポートにリダイレクト エラーを表示します。Googlebot が追跡するホップ回数はユーザー エージェントによって異なります。たとえば、スマートフォン用 Googlebot と画像用 Googlebot では値が異なる場合があります。
robots.txt の場合、Googlebot は RFC 1945 の規定に従い、最低 5 回のリダイレクト ホップを追跡した後で追跡を停止し、robots.txt ファイルの Googlebot がリダイレクト URL から受信したコンテンツはすべて無視され、最終的なターゲット URL のコンテンツのインデックス登録が検討されます。
|
|||||||||||
|
Google のインデックス登録パイプラインは、インデックス登録において、
Googlebot が
|
|||||||||||
|
robots.txt ファイルが 30 日以上サーバーエラーのステータス コードを返す場合、Google は robots.txt の最後のキャッシュ コピーを使用します。使用できない場合、Google はクロールに対する制限はないと見なします。
Googlebot が
|
|||||||||||
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 アドレスがファイアウォール ルールによってブロックされていないことを確認してください。
- ネットワーク トラフィックを確認します。tcpdump や Wireshark などのツールを使用して、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 +answerexample.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 +answerexample.com. 86400 IN A 93.184.216.34dig +nocmd @b.iana-servers.net example.com +noall +answer... - 過去 72 時間以内に DNS 構成に変更を加えた場合は、グローバル DNS ネットワーク全体に変更が伝播されるまで待つ必要があります。 伝播を速めるには、Google のパブリック DNS キャッシュをフラッシュする方法があります。
- 自前の DNS サーバーを運用している場合は、サーバーが正常で過負荷状態になっていないことを確認します。