この記事のまとめ
サーチコンソールの「サーバーエラー(5xx)」は、記事の中身に対する判定ではありません。Googleがそのページを取りに行ったときにサーバーが500番台のエラーを返し、中身を一度も受け取れなかったという記録です。公式ドキュメントは「Google が 5xx ステータス コードを返す URL から受信したコンテンツはすべて無視されます」と明記しています。だから記事を書き直しても消えません。直す対象はサーバー側で、しかも公式は「Google はサイトのクロール頻度を落とします。クロール頻度の低下は、サーバーエラーを返す個別の URL の数に比例します」と書いているため、1ページの問題では終わりません。ただし1回出ただけで検索結果から消えるわけでもありません。
サーチコンソールの「ページ」を開いたら、「サーバーエラー(5xx)」という行にURLが並んでいた。クリックして出てきたURLをブラウザで開くと、何事もなく普通に表示される。
ここで話が噛み合わなくなります。見えているのだからサーバーは動いている。では、Googleは何を見て「エラー」と言っているのか。しかも一覧記事を読みに行くと「インデックスされない原因15選」が出てきて、自分の行がどれなのか決まりません。
結論を先に書きます。これはページの中身についての判定ではなく、そのとき応答が返らなかったという記録です。Googleは中身を一度も受け取っていません。公式ドキュメントは「Google が 5xx ステータス コードを返す URL から受信したコンテンツはすべて無視されます」と書いています(HTTP ステータス コードが Google のクローラーに及ぼす影響)。
つまり記事をリライトしても、タイトルを変えても、この行は消えません。見る場所はサーバーの側です。そして「今開いたら見られる」ことは、この行の否定になりません。理由はこのあと構造で説明します。
Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。
この行は、どこに出ている何なのか
「サーバーエラー(5xx)」は、ページ インデックス登録レポートで「登録されなかった理由」として並ぶ項目の1つです。公式ヘルプの説明はこれで全文です。
ページをリクエストしたときに、サーバーから 500 レベルのエラーを返されました。サーバーエラーの修正についてご確認ください。
— Google公式ヘルプ(ページ インデックス登録レポート)
一行しかありません。ここで手が止まる人が多いので、同じヘルプの別の場所にある説明も引きます。「サーバーエラー」という節に、もう少し具体的な言い換えがあります。
サーバーエラーは、Googlebot が URL にアクセスできなかったか、リクエストがタイムアウトになったか、サイトがビジー状態だったことを示します。そのため、Googlebot はリクエストを中止せざるを得ませんでした。
— Google公式ヘルプ(ページ インデックス登録レポート)
「アクセスできなかった」「タイムアウト」「ビジー状態」。どれもページの内容の話ではありません。返事が返ってこなかった、あるいは返事の代わりにエラー番号が返ってきた、という話です。
⚠️ 置かれている場所についても1つ補足します。2026年9月8日にこの日本語ヘルプの見出し構造を取得して数えたところ、「インデックス登録に関する問題の原因」の下は「未登録」「警告」「インデックスに登録済み」の3つに分かれており、「サーバーエラー(5xx)」は「未登録」の15項目のうち先頭にあります。そして「未登録」の前置きは「ページはインデックスに登録されていませんが、必ずしもエラーによるものではありません。具体的な説明を読んで、対処する必要があるエラーかどうかを確認してください」です。つまりこの欄には、直すべき行と直さなくてよい行が混ざっています。確認したのはこの1ページの本文と見出しだけで、Search Consoleの画面表示そのものは照合していません。
では、5xxの行はどちらなのか。直す側です。クロールの統計情報レポートの公式ヘルプは、レスポンスの一覧のうち「不正なレスポンス コード」という見出しの下に「サーバーエラー(5XX)」を置き、「このようなエラーは可用性に関する警告の原因となるため、できる限り修正する必要があります」と書いています。
同じ欄に並ぶ別の項目でも、判断はまったく違います。たとえば「noindexタグによって除外されました」は正常、直すのは意図と違うときだけで扱っている行は、公式が「正しく作動しています」と書いている側です。行ごとに意味が違うので、まとめて件数を減らす作業にはなりません。
なぜ「開けば見られる」のに、この行が出るのか
5xxは、そのURLの性質についての判定ではなく、そのリクエストのときのサーバーの状態を記録したものだからです。ここが分かると、これから挙げる3つの厄介さが全部同じ原因から出ていることが見えます。
① 記録なので、後から見に行っても再現しない
Googleが取りに行った瞬間のサーバーの状態と、あなたがブラウザで開いた瞬間の状態は別物です。この取り違えは非常に多いらしく、公式ヘルプが先回りして書いています。
URL 検査ツールを使用すると、ページのインデックス登録レポートで報告されたサーバーエラーの再現が可能かどうかを確認できます。サーバーエラーは一時的なものである可能性があるため、サーバーエラーが原因で Google のクロールが失敗したときでも、ライブテストは成功することがあります。
— Google公式ヘルプ(ページ インデックス登録レポート)
ライブテストが成功しても、レポートの行は否定されません。公式が「そういうことが起きる」と書いている以上、ここで「Googleの誤りだ」と結論して手を止めるのがいちばん損です。
同じヘルプのよくある質問にも、時間のずれについての項目があります。「URL 検査ツールには問題が表示されないのに、ページ インデックス登録レポートにエラーが表示されるのはなぜですか?」に対する答えは「Google が最後にクロールした後に、エラーが出た URL が修正された可能性があります」で、「URL のクロール日を確認し」「ページのクロール以降に修正が行われていないか確認してください」と続きます。見るべきは今の状態ではなく、クロールされた日時です。
② 状態はサーバー単位なので、1ページの話で終わらない
ここが、noindexやソフト404のようなページ単位の項目といちばん違うところです。公式ドキュメントは、5xxを受け取ったときのGoogle側の反応をこう書いています。
5xx および 429 のサーバーエラーは、Google のクローラに対して一時的にクロールのペースを落とすように促します。Google 検索の場合、すでにインデックスに登録されている URL はインデックスに保持されますが、最終的には削除されます。
— Google公式ドキュメント(HTTP ステータス コードが Google のクローラーに及ぼす影響)
落ちるのは「そのページのクロール頻度」ではなく「サイトのクロール頻度」です。同じページの表に、その度合いまで書かれています。
Google はサイトのクロール頻度を落とします。クロール頻度の低下は、サーバーエラーを返す個別の URL の数に比例します。Google 検索の場合、Google のインデックス登録パイプラインは、繰り返してサーバーエラーを返す URL をインデックスから削除します。
— Google公式ドキュメント(HTTP ステータス コードが Google のクローラーに及ぼす影響)
「比例します」と書かれているので、並んでいるURLの本数には意味があります。3本なのか300本なのかで、サイト全体が受ける影響が変わります。1本ずつ潰す作業ではなく、まとめて出ている原因を1つ探す作業だ、と考えたほうが早く終わります。
⚠️ 数える単位についても注意があります。クロールの統計情報レポートの公式ヘルプは、レスポンスの割合について「データは URL ごとではなく合計リクエスト数に基づいています」とし、「Google が URL を 2 回リクエストし、初回はサーバーエラー(500)を受け取り、2 回目は OK(200)だった場合、レスポンスはサーバーエラー 50%、OK 50% になります」と例まで書いています。URLの本数とリクエストの回数は別の数字です。 この画面そのものの読み方(個人ブログで見る価値があるのはどこか)は「クロールの統計情報」は何を見る画面?個人ブログが見る価値があるのはほぼ2つにまとめました。
③ 状態には「続いた長さ」があるので、時間で扱いが変わる
1回の5xxと、1か月続く5xxは、公式の扱いが違います。さきほど引いた2つの文を並べると、それがはっきり出ています。
| 状態 | 公式の記述 |
|---|---|
| 5xxが返り始めた | 「すでにインデックスに登録されている URL はインデックスに保持されます」 |
| 5xxが繰り返される | 「繰り返してサーバーエラーを返す URLをインデックスから削除します」/「最終的には削除されます」 |
| 200が返るようになった | 「サーバーが 2xx ステータス コードを返すようになると、Google はサイトのクロール頻度を徐々に引き上げます」 |
だから「1回出たからもう終わり」でもなければ、「放っておいても平気」でもありません。公式が条件にしているのは繰り返しているかどうかです。そして復旧も一瞬ではありません。「徐々に引き上げます」と書かれている以上、直した翌日にすべてが戻るとは書かれていません。
なお、この3つはどれも5xxが「中身の評価」ではなく「状態の記録」だから起きています。記録なので後から再現しない。状態はサーバー単位なのでサイト全体に及ぶ。状態には長さがあるので時間で扱いが変わる。ここを押さえておけば、残りは確認作業だけです。
Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。
公式が個別に挙げている番号は3つだけ
「5xx」とまとめて書かれていますが、公式ドキュメントの表に番号として載っているものは限られています。2026年9月8日にこのページのHTMLを取得して5xxの節の表の行を数えたところ、500・502・503の3行でした。3行は同じ説明を共有しています。
| 公式の表に載っている番号 | 公式の表記 |
|---|---|
| 500 | internal server error |
| 502 | bad gateway |
| 503 | service unavailable |
⚠️ これは「5xxはこの3つだけ」という意味ではありません。同じページの冒頭が「Google がウェブでよく検出する上位 20 のステータス コードを取り上げます」と範囲を宣言しており、珍しい番号は載せないと明記されています。たとえば504(gateway timeout)は、この表には出てきません。節の見出しは「5xx (server errors)」で、上に引いた説明は5xx全体にかかる書き方になっています。3つは例であって、一覧ではありません。
もう1つ、番号が5xxでないのに同じ扱いになるものがあります。429(too many requests)です。公式は「Google のクローラーは、429 ステータス コードをサーバーが過負荷状態であることを示すシグナルとして扱います。これはサーバーエラーとみなされます」と書いています。アクセス制限系のプラグインやWAFがGooglebotに429を返していると、5xxと同じ側に分類されます。
まず決めるのは「一時的か、続いているか」
これを自分で推測する必要はありません。専用の画面があります。ページ インデックス登録レポートの公式ヘルプ自身が、サーバーエラーの節の最初にこう書いています。
クロールの統計情報レポート内のホストのステータス判定で Google がサイトの可用性に関する問題を報告しているかどうか、そしてその問題を実際に確認して修正できるかを確認します。
— Google公式ヘルプ(ページ インデックス登録レポート)
ホストのステータスは3つの値しか取りません。そしてその3つが、「一時的か、続いているか」を絞り込む入口になります。クロールの統計情報レポートの公式ヘルプの原文で並べます。
| ホストのステータス | 次にやること |
|---|---|
| 「過去 90 日間にサイトでクロールの可用性に関する重大な問題は発生しませんでした」 | 公式いわく「必要な作業はありません」 |
| 「問題が 1 件以上発生しましたが、発生したのは 1 週間以上前です」 | 公式いわく「一時的な問題だったか、問題が解決された可能性があります」。レスポンスの表を見て対応が要るか判断する |
| 「過去 1 週間以内に、サイトでクロールの可用性に関する重大な問題が 1 件以上発生しました」 | 公式いわく「繰り返し発生している問題かどうか調べてみてください」 |
詳細はさらに3つのカテゴリに分かれます。公式ヘルプが挙げているのは「robots.txt の取得」「DNS の解決」「サーバー接続」です。5xxの行を追いかけているなら見るのは「サーバー接続」で、公式はこれを「グラフには、クロール中にサーバーが応答しなかったのはいつか、URL のレスポンス全体が提供されなかったのはいつかが表示されます」と説明しています。
⚠️ 同じ画面の「robots.txt の取得」が赤くなっている場合は、この記事の範囲ではありません。robots.txtそのものが取得できないと、ページ単位ではなくサイト全体のクロールが止まる側の話になり、公式も別のドキュメントに分けて説明しています。切り分けはサイトマップの「robots.txt にアクセスできません」はサーバー側の問題ですに書きました。
直す対象は、ページの外側にある
公式ヘルプの「サーバー接続エラーを解決する」には、確認先が太字の項目として並んでいます。原因の候補として挙がっているのは次の3つです。
- 「動的ページへのリクエストに伴う過剰なページ読み込みを減らす」。公式の説明は「動的ページは応答に時間がかかるため、タイムアウトの原因になることがあります。または、サーバーから過負荷のステータスが返され、Googlebot がクロール頻度を落とすよう求められることもあります」。並べ替えや絞り込みのパラメータでURLが増えている場合がこれにあたります
- 「ホスティング サーバーの停止、過負荷、構成ミスがないかどうかを確認する」。公式は「上記を行っても、接続、タイムアウト、または応答の問題が解決しない場合は、ウェブ ホスティング プロバイダに相談して、サイトのトラフィック処理能力の増強を検討します」としています
- 「Google のクローラーを誤ってブロックしていないかどうかを確認する」。公式が挙げているのは「DNS 構成の問題、ファイアウォールや DoS 対策保護システムの構成ミス、コンテンツ管理システムの構成といったシステムレベルの問題」です
3つ目には、個人ブログでいちばん心当たりのある説明が続いています。
しかし、Googlebot は人間のユーザーよりも多数のリクエストを発することが多いため、こうした保護システムが反応して、ウェブサイトに対する Googlebot のクロールがブロックされる場合があります。
— Google公式ヘルプ(ページ インデックス登録レポート)
人が開くと見える理由は、たいていこれです。あなたのアクセスは1回で、Googlebotのアクセスはまとまった回数です。回数で反応する仕組みが間に入っていると、人間だけが通れて、クローラーだけが弾かれます。サーバーを移した直後、セキュリティ系のプラグインを入れた直後、アクセス制限の設定を変えた直後にこの行が増えるのは、この構造です。
なお公式ヘルプは、このあとに「検索エンジンによるサイトのクロールとインデックス登録を適切に管理する」という項目も置いていますが、そこは意図的にGooglebotを止めている場合の話なので、原因の候補とは別に読んでください。逆に、クロールの回数そのものが多すぎて落ちているなら、対処は止めることではありません。クロールの統計情報レポートのヘルプは「Google がサイトをクロールする頻度が過大な場合は、クロール頻度の引き下げをリクエストできます」と案内しています。
インデックスされない原因は5xxだけではありません。全体の切り分けはインデックスされない原因は2系統に分かれる、確認できるものから潰すに、URL検査の表示ごとに次の一手がどう変わるかはサーチコンソールでインデックスを確認する方法、URL検査の表示ごとに次の一手が違うに整理しています。この記事は5xxの行だけを扱います。
直した後、いつ戻るのか
戻り方は2段階です。まずクロール頻度が戻り、そのあとにレポートの表示が変わります。公式ドキュメントが書いているのは前者で、「サーバーが 2xx ステータス コードを返すようになると、Google はサイトのクロール頻度を徐々に引き上げます」です。「徐々に」なので、直した瞬間に元通りではありません。
レポート側には「修正を検証」という機能があります。所要時間について公式ヘルプはこう書いています。
検証は通常 2 週間ほどで完了しますが、それより長くかかる場合もあります。
— Google公式ヘルプ(ページ インデックス登録レポート)
⚠️ 表示の見え方について1つ。公式ヘルプは「ただし、すべてのインスタンスが修正されても、問題の重大度レベルのラベル(「エラー」または「警告」)は変わらず」と書いています。ラベルの色が残っていること自体は、直っていない証拠になりません。
片付いた後にやること
5xxの行が消えると、サイトは「Googleが普通に取りに来られる状態」に戻っただけです。そこから先に残るのは、すでに検索結果に出ているページのほうをどうするかという問題です。
ここから先は、クロールの話ではなく順位とクリックの話になります。使う道具も変わります。選択肢としては、たとえば次のような分かれ方をします。
- サーチコンソールの検索パフォーマンスをそのまま見る。追加の道具は要りませんが、表示回数・クリック数・掲載順位を自分で見比べる手間がかかります
- Looker Studioなどにつないで表を作る。自由に加工できますが、作るまでの設定が要ります
- スプレッドシートにCSVを落として並べ替える。誰でもできますが、毎月同じ手順を踏むことになります
- リライト候補の抽出に特化したツールを使う。判断は速くなりますが、道具ごとに前提と得意分野が違います
検索パフォーマンスのどこを見るかはサーチコンソールでリライト記事をどう選ぶ?迷わない判定基準と手順にまとめています。
よくある質問
「サーバーエラー(5xx)」とはどういう意味ですか
Googleがそのページを取りに行ったときに、サーバーが500番台のエラーを返した、という意味です。公式ヘルプの説明は「ページをリクエストしたときに、サーバーから 500 レベルのエラーを返されました」の一行です。ページの内容についての評価ではありません。公式ドキュメントは「Google が 5xx ステータス コードを返す URL から受信したコンテンツはすべて無視されます」としており、中身は読まれていません。
そのURLをブラウザで開くと普通に見られます。Googleの誤りではないですか
誤りとは限りません。公式ヘルプが「サーバーエラーは一時的なものである可能性があるため、サーバーエラーが原因で Google のクロールが失敗したときでも、ライブテストは成功することがあります」と明記しています。見るべきは今の状態ではなく、クロールされた日時のほうです。同じヘルプは「URL のクロール日を確認し」「ページのクロール以降に修正が行われていないか確認してください」と案内しています。
記事の中身を直せば消えますか
消えません。5xxはページの中身に対する判定ではないからです。公式ドキュメントが書いているとおり、Googleは5xxを返したURLから受け取った内容をすべて無視します。リライトもタイトル変更も、この行には効きません。直す対象はサーバーの側で、公式ヘルプが挙げているのは動的ページの負荷、ホスティングの停止や過負荷や構成ミス、ファイアウォールやDoS対策によるクローラーの誤ブロックです。
放っておくとインデックスから消えますか
1回出ただけで消えるとは書かれていません。条件は繰り返しです。公式ドキュメントは「すでにインデックスに登録されている URL はインデックスに保持されますが、最終的には削除されます」とし、別の箇所で「繰り返してサーバーエラーを返す URL をインデックスから削除します」と書いています。続いているかどうかが分かれ目です。
他のページに影響しますか
します。クロール頻度が落ちるのはサイト単位です。公式ドキュメントは「Google はサイトのクロール頻度を落とします。クロール頻度の低下は、サーバーエラーを返す個別の URL の数に比例します」と書いています。本数が増えるほど影響が大きくなる、という書き方です。なお公式が書いているのはクロール頻度とインデックス登録までで、順位がどうなるかについては書かれていません。
504も同じ扱いですか
公式ドキュメントの5xxの表には504の行がありません。2026年9月8日に確認した時点で、表に番号として載っているのは500・502・503の3つです。ただし同じページは冒頭で「Google がウェブでよく検出する上位 20 のステータス コードを取り上げます」と範囲を宣言しており、載っていない番号があるのは前提です。節の見出しは「5xx (server errors)」で、説明も5xx全体にかかる書き方になっています。
429が返っている場合はどうなりますか
サーバーエラーと同じ側に分類されます。公式ドキュメントは「Google のクローラーは、429 ステータス コードをサーバーが過負荷状態であることを示すシグナルとして扱います。これはサーバーエラーとみなされます」と書いています。アクセス回数で制限をかける仕組みがGooglebotに反応している場合は、ここを疑ってください。
クロールの統計情報レポートは、どこから開きますか
サーチコンソールの設定から開きます。ページ インデックス登録レポートの公式ヘルプは、サーバーエラーの節で「クロールの統計情報レポート内のホストのステータス判定で Google がサイトの可用性に関する問題を報告しているかどうか」を確認するよう案内しています。見るカテゴリは「サーバー接続」です。「robots.txt の取得」が赤い場合は別の問題で、そちらはサイトマップの「robots.txt にアクセスできません」はサーバー側の問題ですに書きました。
同じレポートに出ている他の項目とは何が違いますか
5xxの行は、Googleが中身を一度も受け取れなかった側の項目です。同じ「未登録」の欄でも、たとえばソフト404は「200を返しているのに中身が無い」状態ですで扱っている行は、中身が届いたうえでGoogleが下した判断です。サーチコンソールのリダイレクトエラーとは、転送が重なって行き先が決まらない状態は、行き先が決まらなかった側です。届かなかったのか、届いたが判断されたのかで、直す場所がまったく違います。
まとめ
- これは中身への判定ではなく、サーバーが応答を返せなかった記録。公式は「Google が 5xx ステータス コードを返す URL から受信したコンテンツはすべて無視されます」と明記している。だから記事を直しても消えない
- 「開いたら見られる」は反証にならない。公式ヘルプ自身が「サーバーエラーが原因で Google のクロールが失敗したときでも、ライブテストは成功することがあります」と書いている。見るのは今の状態ではなくクロールされた日時
- 影響はページ単位で終わらない。公式は「Google はサイトのクロール頻度を落とします。クロール頻度の低下は、サーバーエラーを返す個別の URL の数に比例します」としている。1本ずつ潰すより、まとめて出ている原因を1つ探すほうが早い
- 消えるかどうかの条件は「繰り返し」。公式は「インデックスに保持されますが、最終的には削除されます」「繰り返してサーバーエラーを返す URL を…削除します」と書いている。1回で終わりでもないし、放置してよいわけでもない
- 一時的か続いているかは、クロールの統計情報レポートの「ホストのステータス」で決まる。3値は「重大な問題は発生しませんでした」「発生したのは 1 週間以上前です」「過去 1 週間以内に」。5xxを追うなら見るカテゴリは「サーバー接続」
- 直す先はページの外側。公式が挙げているのは動的ページの負荷・ホスティングの停止や過負荷や構成ミス・ファイアウォールやDoS対策によるクローラーの誤ブロックの3つ。人間だけ通れてクローラーが弾かれるのは、多くの場合3つ目
- 公式の表に番号として載っている5xxは500・502・503の3つだけだが、同じページが「上位 20 のステータス コード」に限ると宣言しているので、これは一覧ではなく例。429も公式に「サーバーエラーとみなされます」
- 復旧は「徐々に」。公式は「サーバーが 2xx ステータス コードを返すようになると…クロール頻度を徐々に引き上げます」とし、検証は「通常 2 週間ほど」としている
ここから先は、私が作ったツールの話です。
リライトレーダーは、この記事の「片付いた後にやること」で書いたすでに検索結果に出ているページの側を扱います。Search Console のエクスポートをZIPのまま落として貼るだけで、掲載順位4.0〜20.5位・表示回数100回以上のページだけを拾い、改善余地スコアの大きい順に並べます。判定と候補3記事の改善余地スコアの確認、そのうち1記事分の診断カードまでは無料で、残りの診断カードが2,980円(税込)の買い切りです。月額課金や自動更新はありません。ログインも不要です。CSVファイルそのものはブラウザの外に出ません(送るのは、診断カードを出すときは選んだ1ページのURL・数値・入力したキーワード、「ページタイトルを取得する」を押したときは判定に出たページのURL最大10件です)。
⚠️ ただし、向かない人がいます。サーバーエラーを追いに来た人には、この時点では向きません。サーバーの状態もクロールもインデックス登録も扱っていません。読むのは、すでに検索結果に出ているページの4つの数字だけです。また、表示回数が2桁で止まっているサイトにも向きません。判定の条件が表示回数100回以上なので、対象になるページが1つも出ないからです。
Search ConsoleのZIPを読み込むと、候補の判定と1記事分の診断カードを無料で確認できます。登録は不要です。ZIPが無い場合は、診断カードの見本を確認できます。

