Search Consoleのサーバーエラー5xxを切り分けて直す手順

Search Console のページインデックス登録レポートに「サーバーエラー（5xx）」が並んでいる。ところが、そのURLをブラウザで開くと普通に表示される。ここで手が止まります。ただ、今ブラウザで開けることと、Googlebot（Googleの巡回ロボット）がアクセスしたときに開けていたことは、別の話です。

先に結論です。5xx は一時的でも放置できません。Google はサーバーエラーを返す個別のURLの数に比例してサイトのクロール頻度を落とし、繰り返しサーバーエラーを返すURLは、インデックス登録パイプラインがインデックスから削除します。すでにインデックスに登録済みのURLも、いったんは保持されますが最終的には削除されます。

つまり調べるべきは「今アクセスできるか」ではありません。いつ・どのくらいの頻度で落ちていたかです。

5xx を返したとき、Google 側で何が起きるか

Search Console は 4xx〜5xx の範囲のステータスコードと、リダイレクトの失敗（3xx）についてエラーメッセージを生成します。ここでいうステータスコードとは、サーバーが応答するときに返す3桁の数字のことです。数字ごとに Google の扱いは変わります。

表のいちばん下が、今まさに困っている行です。5xx と 429 は、Google のクローラーに対して一時的にクロールのペースを落とすよう促します。そして、5xx ステータスコードを返すURLから受信したコンテンツはすべて無視されます。エラー画面に「ただいま混み合っています」と丁寧な案内を書いても、その文字列が評価に使われることはありません。

一段上の視点でも同じことが起きています。サイトの応答が遅くなった場合、サーバーエラー（5xx）やレート制限のシグナル（429 など）が返された場合には、クロール頻度の上限が下がり、Google によるクロールが減少します。逆に、一貫して応答し、応答時間が安定しているか改善していれば、上限は上がります。可用性は、記事単位ではなくサイト単位で効いてくる土台です。

ライブテストの成功を、復旧の証拠にしない

Search Console のヘルプは、サーバーエラーを「Googlebot がURLにアクセスできなかったか、リクエストがタイムアウトになったか、サイトがビジー状態だったこと」を示すもの、と説明しています。そのため Googlebot はリクエストを中止せざるを得ませんでした、と続きます。アクセスの集中や処理の重さで起きるものは、時間帯によって出たり出なかったりします。

夜間の数十分だけ落ちるサーバーなら、昼にテストして成功しても不思議はありません。エラーが起きたときの条件が、テストのときにそろっているとは限らないからです。だからライブテストの成功だけを根拠に「直った」と判断するのは避けたほうが安全です。復旧の証拠として使うには弱い。

代わりに見る場所は決まっています。ページインデックス登録レポートのヘルプ自身が、クロールの統計情報レポート内の「ホストのステータス判定」で Google がサイトの可用性に関する問題を報告しているかどうかを確認するよう案内しています。ホストのステータスは緑色になっているのが理想です。赤色なら、クリックして可用性の詳細を開き、robots.txt の可用性・DNS の解決・ホスト接続の3カテゴリを確認します。

切り分けの手順

上から順にやると、原因が「サーバー全体」「特定の時間帯」「特定のURLの作り」のどれなのかが絞れます。

1. エラーの実物を取る。ページインデックス登録レポートで「サーバーエラー（5xx）」をクリックし、ページ例のURLを書き出します。ここで見るのは件数の多さより、URLの傾向です。1種類のテンプレートに偏っていれば、サーバー全体の問題ではない可能性が上がります。
2. ホストのステータスを見る。クロールの統計情報レポートを開き、可用性のステータスの色を確認します。赤色なら、robots.txt の可用性・DNS の解決・ホスト接続のどこで落ちているかまで降ります。DNS のグラフには、サーバーでホスト名が認識されなかった時点やクロール中に応答しなかった時点が表示されます。
3. 落ちた時刻を特定する。サーバー接続のグラフには、クロール中にサーバーが応答しなかった時点、URLのレスポンス全体が提供されなかった時点が表示されます。ここで得た時刻が、次のログ照合の検索キーになります。
4. 同じ時刻のサーバーログを突き合わせる。アクセスログとエラーログを、手順3の時刻の前後で抜き出します。バックアップ、バッチ処理、再起動、他社クローラーの集中など、負荷の山と重なっていないかを見ます。ここが一致すれば、原因は「ページの作り」ではなく「その時間帯に起きていた何か」です。
5. URLの作りを疑う。同じ内容をパラメータの順番違いで配信しているサイトは、コンテンツを動的に配信しているとみなされます。動的ページは応答に時間がかかるため、タイムアウトの原因になることがあります。または、サーバーから過負荷のステータスが返され、Googlebot がクロール頻度を落とすよう求められることもあります。パラメータリストは短くし、使用する数を少なくすることが推奨されています。
6. サーバー側の基本を確認する。接続・タイムアウト・応答の問題が残るなら、ホスティングサーバーの停止、過負荷、構成ミスがないかどうかを確認します。共有サーバーなら、同居している他サイトの負荷も候補に入ります。
7. 直してから検証をリクエストする。エラーが関係するすべての箇所を修正し、各理由の詳細ページで「修正を検証」をクリックします。

手順を1本通すと、こう進みます

たとえば、商品一覧のURLだけに 500 が出ているサイトを想定します。手順1でページ例を並べると、5件すべてが並び替えパラメータ付きのURLでした。ここで「サーバーが落ちている」説はいったん後退します。

手順2でホストのステータスは緑色。DNS もホスト接続も問題なし。となると、サーバー全体が落ちていたわけではないと読めます。手順3のサーバー接続グラフでは、応答しなかった時点が特定の時間帯に集まっていました。手順4でその時刻のログを見ると、同じ時間帯に一覧ページへのリクエストが集中しています。手順5と照らすと、パラメータ違いの一覧URLが大量に生成され、動的な生成処理が重なってタイムアウトしていた、という筋が通ります。

この場合に手を入れるのは、Googlebot の設定ではありません。パラメータの整理と、一覧生成のキャッシュです。原因の所在がURLの作りにあるなら、クロール側をいじっても再発します。

混雑・メンテナンスのときの正しい返し方

サイトを一時的に止めるとき、あるいは負荷が急に増えたとき。ここでの返し方には、Google 側の想定があります。

• 過負荷になっているエージェント（Googlebot、AdsBot など）に対しては、robots.txt でクロールをブロックできます。ただし有効になるまで最大1日程度かかることがあり、クロールに長期的な影響を及ぼす可能性があるため、あまり長くはブロックしないよう案内されています。
• 負荷の増大を動的に検出して対応できる場合は、配信制限に近づいた時点で HTTP 503 / 429 を返します。
• 503 や 429 を返すのは2〜3日程度までにすべきです。それを超えると、Google がサイトをクロールする頻度がいずれ少なくなってきます。
• 2〜3日後に Google のクロール頻度が適応したら、robots.txt のブロックを削除するか、503 または 429 を返すことを中止します。

数字が具体的に書かれているのは、この2〜3日という線です。長期メンテナンスを 503 のまま何週間も続ける運用は、この線を大きく越えます。逆に、数時間のメンテナンスで 503 を返すことは、この案内の範囲に収まります。

よくある誤解：クロールバジェットを心配する前に、可用性

5xx を見つけると「クロールバジェット（クロールの割り当て）が食われている」と考えたくなります。ただ、Google のクロールバジェットのガイドは上級者向けと明記されており、対象として挙げられているのは、重複のないページが100万以上で1週間に1回程度更新されるサイト、1万以上で毎日更新されるサイト、そして Search Console でURLの大部分が「検出 - インデックス未登録」に分類されるサイトです。これらの数値はサイトを分類する際の大まかな目安であって、正確なしきい値ではないとも書かれています。

数千ページ規模のサイトなら、割り当ての最適化より先に、応答が安定しているかどうかを見るほうが素直です。クロール能力の上限（ホスト負荷とも呼ばれます）は、サーバーに負担をかけないために計算されるもの。応答が安定していれば上がり、5xx や 429 が返れば下がります。規模の小さいサイトでのクロールの考え方は、小規模サイトのクロールバジェットで扱っています。

自己点検の表

今の状況をこの表に当てはめると、次の一手が決まります。

4行目が、いちばん取り違えやすいところです。「開けたから直った」で閉じると、同じエラーが翌週また積み上がります。

直したあと、どこで復旧を確認するか

修正後は「修正を検証」をクリックします。すると、直ちに Search Console によりサンプルとして数ページがチェックされます。サンプルのページに現在も問題が存在する場合、検証は終了し、検証ステータスは変更されません。サンプルにエラーが見つからなければ検証は続行され、ステータスは「開始」になります。この処理には数日以上かかることがあり、進行状況はメールで通知されます。

待つあいだの判断材料は、ボタンの結果だけではありません。クロールの統計情報のホストのステータスが緑色を保っているか。サーバー接続のグラフに新しい落ち込みが出ていないか。この2つが安定していれば、応答は戻っていると読めます。

ステータスコードと実際の中身がズレるという意味では、ソフト404の直し方も同じ系統の問題です。あわせて点検すると、サーバーの応答まわりの穴が一度に埋まります。