サーバーエラー（5xx）とは？サーチコンソールでの確認方法・原因・対処法を徹底解説
サーバーエラー（5xx）とは、Webサイトのサーバー側で問題が発生し、ユーザーやクローラーのリクエストに正常な応答を返せない状態を指します。
Google Search Console（サーチコンソール）でこのエラーが報告されると、Googlebotがページを正しく取得できず、インデックス登録に支障をきたす可能性があります。
放置すれば検索順位の低下やインデックスからの除外につながるため、早期の発見と対処が欠かせないでしょう。
正しい知識と手順さえ押さえれば、5xxエラーは十分に対処可能な問題です。
インデックス状態の把握が大変という方は、SEOサイト管理自動化ツール「inSite（インサイト）」を試してみてください。
inSiteのインデックスチェック機能では、サイト内のページのクロール状態を毎日自動でチェックします。
どれだけのページがインデックスされてなくて原因は何なのか、クローラーは定期的に来ているのかといった情報を常に監視することができます。
1ページずつURL検査をしなければわからないインデックス状態。
inSiteを使えばこれを常に把握できるため、効率よくSEOにおける有効な打ち手を考えることができます。
ページのインデックス率向上や、ページの評価をアップさせるリライトの効率化にかなり使えると思うので、ぜひお試しください。
サーバーエラー（5xx）とは
サーバーエラー（5xx）とは、Google Search Console（サーチコンソール）の「ページのインデックス登録」レポートに表示されるステータスの1つです。 Googlebotがサイトをクロールした際に、サーバー側でエラーが返されたことを意味します。
インデックスカバレッジレポートで確認できる全ステータスの一覧を見ると、このステータスは「エラー」カテゴリに分類されており、インデックス登録が正常に行われていない状態として扱われます。
HTTP仕様の国際標準であるRFC 9110 Section 15.6では、5xxエラーについて次のように定義しています。
「5xx（サーバーエラー）クラスのステータスコードは、サーバーがエラーを認識しているか、要求されたメソッドを実行できないことを示す」。
RFC 9110 Section 15.6
つまり、問題の原因はサイト訪問者やGooglebotの側ではなく、あくまでサーバー側にあるということです。
サーチコンソール上では、500・502・503・504といった個別のエラーコードは区別されません。
すべて一括で「サーバーエラー（5xx）」と表示される仕組みになっています。そのため、具体的にどのコードが返されているかを把握するには、サーバーログの確認が必要です。
なお、5xxエラーはサーバー側に原因がある「サーバーエラー」ですが、これとは別に4xxエラーと呼ばれる「クライアントエラー」も存在します。
例えば、クライアント側エラーである「見つかりませんでした（404）」は、リクエストされたページ自体が存在しない場合に返されるものです。
また、「アクセス禁止（403）が原因でブロックされました」は、アクセス権限の問題でページを表示できないケースに該当します。
5xxがサーバーの不具合を示すのに対し、4xxはURL自体やアクセス権限に問題があることを示す点が根本的な違いです。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
5xxエラーコードの種類と違い（500・502・503・504）
サーチコンソールでは一括りにされている5xxエラーですが、実際には複数のエラーコードが存在し、それぞれ発生原因が異なります。原因の特定と適切な対処を行うために、主要な4つのコードの違いを理解しておきましょう。
以下の表は、RFC 9110に基づく各コードの定義と、よくある発生原因をまとめたものです。
| エラーコード | 名称 | 意味 | よくある原因 |
|---|---|---|---|
| 500 | Internal Server Error | サーバーが予期しない状態に遭遇した | PHP構文エラー、.htaccess設定ミス、メモリ不足 |
| 502 | Bad Gateway | 上流サーバーから無効な応答を受信した | リバースプロキシの設定不備、CDN障害 |
| 503 | Service Unavailable | 一時的な過負荷またはメンテナンス中 | アクセス集中、計画メンテナンス |
| 504 | Gateway Timeout | 上流サーバーからの応答を時間内に受信できなかった | バックエンド処理のタイムアウト、DB応答遅延 |
500（Internal Server Error）
500（Internal Server Error） は最も一般的な5xxエラーです。
サーバー内部で何らかの予期しない問題が発生したことを示しますが、具体的な原因までは示してくれません。
PHPの構文エラーや.htaccessの記述ミスなど、さまざまな原因で発生し得るため、サーバーログを見て原因を絞り込む必要があります。
502（Bad Gateway）
502（Bad Gateway） は、サーバーが中継役（ゲートウェイやプロキシ）として動作している場合に発生するエラーです。上流のサーバーから正常な応答が得られなかったことを意味します。
NginxとApacheを組み合わせた構成や、CDNを利用している環境で見かけることが多いでしょう。
503（Service Unavailable）
503（Service Unavailable） は、サーバーが一時的にリクエストを処理できない状態であることを示します。アクセスが急増した場合や、計画的なメンテナンス中に返されるケースが代表的です。
一時的な問題であることが多く、時間をおけば自然に解消する場合もあります。
504（Gateway Timeout）
504（Gateway Timeout） は、中継サーバーが上流サーバーからの応答を待ち続けた結果、タイムアウトしたことを示します。
データベースのクエリが極端に遅い場合や、バックエンドの処理に時間がかかりすぎている場合に発生しやすいエラーです。
なお、サーチコンソールではこれらのコードが区別されず、すべて「サーバーエラー（5xx）」としてまとめて表示されます。
個別のエラーコードを特定するには、サーバーのアクセスログやエラーログを確認する必要があるため、次の章以降で具体的な手順を解説していきます。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
サーチコンソールでサーバーエラー（5xx）を確認する方法
5xxエラーが発生しているかどうかは、サーチコンソールの3つの機能を使って確認・分析できます。
まずはエラーの全体像を把握し、次に個別URLの状態を調べ、最後に発生頻度の傾向を読み取るという流れで進めるのが効率的です。
「ページのインデックス登録」レポートでの確認手順
5xxエラーの有無を最初に確認すべき場所は、「ページのインデックス登録」レポートです。
サーチコンソールにログインしたら、左側メニューの「インデックス作成」から「ページ」をクリックしてください。
以前は「インデックスカバレッジ」という名称でしたが、現在は「ページのインデックス登録」に変更されています。 古い記事やマニュアルでは旧名称が使われている場合があるので、同じレポートを指していると理解しておきましょう。
レポートが表示されたら、「ページがインデックスに登録されなかった理由」の一覧を確認します。 ここに「サーバーエラー（5xx）」という項目があれば、Googlebotのクロール時にサーバーエラーが返されたURLが存在するということです。
この項目をクリックすると、影響を受けているURLの一覧が表示されます。
URLごとに「最終クロール日」も確認できるため、エラーがいつ発生したのかの目安がわかります。
URLリストはエクスポートも可能なので、エンジニアへの共有や社内報告に活用すると便利でしょう。
URL検査ツールでのライブテスト方法
個別のURLについて「今もエラーが続いているのか」を確認するには、URL検査ツールが役立ちます。
サーチコンソール画面上部の検索バーに、確認したいURLを入力してください。
インデックス登録情報が表示されたら、右上の「公開URLをテスト」ボタンをクリックします。
これにより、Googlebotが現時点でそのURLにアクセスした場合の応答をリアルタイムで確認できます。
テスト結果が「URLはGoogleに登録できます」と表示されれば、現在はエラーが解消されている状態です。
逆に、「ページの取得に失敗しました」「サーバーエラー（5xx）」といった結果が出た場合は、まだ問題が継続しています。
ここでの判断ポイントは、エラーが一時的なものか恒常的なものかという点です。
レポート上でエラーが報告されていても、ライブテストで正常に取得できるなら、一時的なエラーだった可能性が高いと考えられます。
一方、ライブテストでもエラーが再現される場合は、サーバー側に継続的な問題が存在するため、早急な調査が求められるでしょう。
クロールの統計情報レポートで発生頻度を把握する
エラーの発生頻度やパターンを把握するには、クロールの統計情報レポートが最適です。
サーチコンソールの左側メニューで「設定」を開きましょう。
「クロールの統計情報」から「レポートを開く」をクリックしましょう。
このレポートでは、Googlebotのクロール状況がグラフで可視化されており、ホスト単位でのステータスコード分布を確認できます。
レスポンス別というボックスからサーバーエラー（5XX）をクリックしてください。
これでサーバーエラー（5XX）がいつ発生していたのかを確認することができます。
Google Search Console ヘルプ – Crawl Stats Reportでも、
Google Search Console ヘルプ – Crawl Stats Reportでも、5xxエラーはサイトの閲覧に支障をきたすため「可能な限り修正すべき」とされています。
グラフの形にも注目してみてください。 特定の日に一時的なスパイク（急増）が見られるだけなら、サーバーの一時的な不調やメンテナンスが原因だった可能性があります。
しかし、継続的にエラーが発生している場合は、構造的な問題が潜んでいる可能性が高く、根本的な対策が必要になるでしょう。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
サーバーエラー（5xx）が発生する主な原因
5xxエラーの原因は多岐にわたりますが、大きく4つのカテゴリに分類できます。
「過負荷」「設定ミス」「アプリケーションの不具合」「中継サーバーの問題」の4つです。
自社サイトのエラーがどのパターンに該当するかを見極めることが、効率的な対処への第一歩になります。
サーバーの過負荷・リソース不足
5xxエラーの原因として最も多いのが、サーバーのリソース不足による過負荷です。
主に500・503エラーとして発生します。
- アクセスの急増（503）
セールやSNSバズ、ボットの大量アクセスが集中し、サーバーが処理しきれなくなる - PHPのリソース制限超過（500）
memory_limitやmax_execution_timeに到達する。画像処理や大量データ出力のページで起きやすい - データベース接続数の上限（500）
ECサイトなどで同時アクセスが集中し、DBの接続プールが枯渇する - 共有サーバーのリソース制限
エックスサーバーやConoHa WINGなどでは、同一サーバー上の他サイトの影響でリソース制限がかかることもある
「昨日までは問題なかったのに急にエラーが増えた」という場合は、まずアクセスの急増を疑ってみてください。
サーバー設定の誤り（.htaccess・PHP・CGI）
5xxエラーの原因として次に多いのが、サーバーの設定ファイルの誤りです。
主に500エラーが返されます。
- .htaccessの記述ミス
RewriteRuleの構文エラーや、存在しないモジュールを前提とした記述が原因になる。小さなタイプミスでもサイト全体に影響が及ぶため注意が必要 - php.iniのパラメータ不備
PHPバージョンのアップグレード後に、廃止された関数や設定が残っているケースが多い - パーミッション設定の誤り
CGIスクリプトに実行権限がない、ログファイルへの書き込み権限が不足しているなど、見落とされがちな原因 - サーバー移行後の設定差異
旧サーバーからの引き継ぎがうまくいかず、移行直後に5xxエラーが急増するパターン
プラグインやアプリケーションの不具合
WordPressなどのCMSを利用している場合、プラグインやテーマが5xxエラー（主に500）の原因になることがあります。
- プラグイン同士の競合
キャッシュ系とセキュリティ系の組み合わせで特に起きやすい - アップデート直後の不具合
更新後に500エラーが出始めた場合、更新前のバージョンに戻して解消するか確認するのが最も効率的な切り分け方法 - アプリケーションコードのバグ
未処理の例外や無限ループなどが原因になる。サーバーのエラーログに詳細が記録されるため、ログ確認が原因特定の近道
リバースプロキシ・CDN起因のエラー（502・504）
502や504エラーが発生している場合は、リバースプロキシやCDNの構成に原因がある可能性があります。
- 502 Bad Gateway
Nginx＋Apache構成でバックエンドが応答を返せなくなった場合に発生する。プロセスの停止やソケット接続の問題が原因になりやすい - CDN障害による502・504
Cloudflareなど、CDN自体の障害で自社サーバーに問題がなくてもエラーが出る。2025年11月のCloudflare大規模障害では多くのサイトで502エラーが報告された。CDNプロバイダーのステータスページで障害情報を確認するのが先決 - 504 Gateway Timeout
重いDBクエリや外部API呼び出しの遅延で、中継サーバーがバックエンドの応答を待ちきれずタイムアウトする
なお、リバースプロキシの設定ミスは、5xxエラーだけでなくサーチコンソールの「リダイレクトエラー」を同時に引き起こすこともあります。
リダイレクトチェーンが原因でサーバー負荷が増加するケースもあるため、リダイレクト設定の見直しも併せて行うとよいでしょう。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
サーバーエラー（5xx）の対処法【原因別の具体的手順】
5xxエラーへの対処は、「特定」「調査」「修正」の3ステップで進めるのが効果的です。
闇雲に設定を変更するのではなく、まずエラーの全体像を把握し、次にサーバーログで根本原因を突き止め、最後に原因に応じた修正を行います。
5xxエラーの対処で最初にやるべきことは、どのURLでエラーが発生しているかを正確に把握することです。
以下の手順で影響範囲を特定してください。
- サーチコンソールの「ページのインデックス登録」レポートで「サーバーエラー（5xx）」のURLリストを確認し、CSVエクスポートする
- URL検査ツールのライブテストで、主要URLについて現在もエラーが継続しているか確認する
- エラーが特定のディレクトリやページタイプに集中していないか確認する（例：「/blog/」配下のみなら、ブログ機能に関連する問題の可能性が高い）
- Crawl Statsレポートで5xxエラーの発生頻度と推移を確認し、一時的な問題か継続的な問題かを見極める
- 影響URLがサイトマップに含まれているか確認する（サイトマップ内のURLはGoogleにとって重要なページなので対処の優先度が上がる）
併せて、ソフト404エラー（200を返しているが実質エラー）や、インデックスに登録されていないページ数の確認方法も確認しておくと、サイト全体のインデックス状況をより正確に把握できます。
Search Consoleで内部リンクを確認する方法も参考にしながら、エラーページへの内部リンクが存在しないかチェックしてみてください。
5xxエラーの全体像をサーチコンソールで把握したら、次はサーバーのエラーログで具体的な原因を確認します。
サーチコンソールでは5xxの個別コードが区別されませんが、サーバーログには個別のステータスコードと詳細なエラーメッセージが記録されています。
ここが原因特定の最も重要なポイントです。
主なエラーログの場所は以下のとおりです。
- Apache（Debian/Ubuntu系） –
/var/log/apache2/error.log - Apache（CentOS/RHEL系） –
/var/log/httpd/error_log - Nginx –
/var/log/nginx/error.log - レンタルサーバー（エックスサーバー・ConoHaなど） – コントロールパネルの「エラーログ」メニューから閲覧・ダウンロード可能
ログの読み方について、基本的な構造を押さえておきましょう。
エラーログの各行には、日時、エラーレベル（error、warn、noticeなど）、エラーメッセージが記録されています。
「サーバーログの見方がわからない」という方も心配いりません。
次のステップで紹介するエンジニアへの依頼テンプレートを使えば、SEO担当者でもエンジニアに必要な情報をもれなく共有できます。
5xxエラーの原因が特定できたら、それぞれのケースに応じた修正を行いましょう。
過負荷が原因の場合
- サーバーのプラン変更やリソース増強を検討する
- キャッシュ設定を最適化してサーバー負荷を軽減する
- 不要なボットからの大量アクセスはrobots.txtやサーバー設定でブロックする
設定ミスが原因の場合
- .htaccessの記述を見直し、構文エラーがないか確認する
- PHPバージョンや設定値（memory_limit、max_execution_timeなど）が適切かチェックする
- パーミッション設定を確認する（ファイルは644、ディレクトリは755が目安）
プラグインの不具合が原因の場合
- プラグインを1つずつ無効化して原因を特定する
- 原因のプラグインが見つかったら、互換性のあるバージョンに更新するか代替プラグインへ切り替えを検討する
CDNやプロキシが原因の場合
- CDNプロバイダーのステータスページで障害情報を確認する
- タイムアウト値の調整やバックエンドの応答速度改善を検討する
修正を行ったら、必ずURL検査ツールのライブテストで正常にページが取得できることを確認してください。
Google公式のHTTPステータスコードに関するドキュメントも参考にしながら、Googlebotの挙動への影響を把握しておくと安心です。
技術的な修正が必要な場合は、以下のテンプレートを使ってエンジニアに依頼すると、スムーズに対応が進みます。
エンジニアへの依頼テンプレート
【件名】
サーチコンソールで報告されたサーバーエラー（5xx）の調査・対処依頼
【発生日時】
yyyy年mm月dd日頃から（サーチコンソールのレポート上の日付）
【影響URL（例）】
- https://example.com/page-a/
- https://example.com/page-b/
- （その他○件。添付のCSVファイルを参照）
【サーチコンソールでの表示内容】
「ページのインデックス登録」レポートで「サーバーエラー（5xx）」として○件のURLが報告されています
【URL検査の結果】
ライブテストを実施したところ、○件中○件で現在もエラーが再現されました
【確認済みのこと】
- エラーは特定のディレクトリ（/xxx/）に集中している／サイト全体で発生している
- エラーの発生時期はyyyy年mm月dd日頃から
- 直近でサーバー設定の変更やプラグインの更新は行っていない／行った（内容を記載）
【依頼したい調査・対処内容】
- サーバーのエラーログから、該当URLへのアクセス時に返されているステータスコードと原因の特定
- 原因に応じた修正の実施
- 修正後の動作確認
このテンプレートを活用すれば、エンジニアが調査に必要な情報を最初から把握でき、やり取りの往復を最小限に抑えられます。
修正完了後はサーチコンソールの「修正を検証」ボタンを押して、Googleに再クロールをリクエストしておきましょう。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
5xxエラーがSEOに与える影響【Google公式見解】
5xxエラーがSEOに及ぼすダメージは、「エラーを返しているURLの数」と「エラーが続いている期間」の2つで決まります。
少数のURLで短期間だけ発生した5xxエラーなら、SEOへの悪影響は限定的です。
Google公式見解をもとに、具体的な影響を見ていきましょう。
クロール頻度の減少とクロールバジェットへの影響
5xxエラーが発生すると、Googleのクローラーはそのサイトへのアクセス頻度を自動的に下げます。
Googleは公式に「5xxおよび429サーバーエラーは、Googleのクローラーにクロールを一時的に減速させる」と明言しています。（出典：Google公式 – HTTPステータスコードがGoogleのクローラーに与える影響）
Googleの公式ドキュメントでは「クロール頻度の減少は、サーバーエラーを返している個別URLの数に比例する」と説明されています。
1つのURLだけが5xxを返している状態なら、サイト全体への影響はごくわずかでしょう。
一方、数百・数千のURLが同時に5xxを返すような状況では、サイト全体のクロールが大幅に低下するリスクがあります。
さらに、クロールバジェット（Googleがそのサイトに割り当てるクロールの上限）にも影響が及びます。
Googleのクロールバジェット管理ガイドでは「サイトが遅くなったりサーバーエラーを返したりすると、リミットは下がりGoogleのクロールは減少する」と記載されています。（出典：Google Search Central – 大規模サイトのクロールバジェット管理）
見落としがちですが、5xxエラーが恒常化するとそのページへの内部リンクが実質的にリンク切れと同じ状態になります。
リンク切れはPageRankの受け渡しを遮断し、サイト全体のSEO評価にじわじわと悪影響を与えかねません。
内部リンク切れの影響については、リンク切れがSEOに与える影響で詳しく解説しています。
インデックスからの削除までのタイムライン
5xxエラーが続くと、最終的にはインデックスから削除されます。
ただし、削除は即座に起きるわけではありません。
GoogleのJohn Mueller氏の発言を統合すると、以下のようなタイムラインが見えてきます。
| 経過時間 | Googleの挙動 | 対応の目安 |
|---|---|---|
| 数時間〜1日 | クロール減速のみ。インデックスは保持される | 一時的な障害であれば経過観察で問題なし |
| 複数日 | インデックスからの脱落が始まる可能性がある | 原因調査と修正に着手すべきタイミング |
| 約1週間 | 404と同様の扱いになり、インデックスから削除される（ただし定期的な再確認は継続） | 修正を最優先で進める |
| 約1か月後に復旧した場合 | 以前のランキングシグナルが保持された状態で復帰できる | 復旧後のモニタリングを継続する |
John Mueller氏は2025年11月のCloudflare障害時、Blueskyで「5xxが複数日続くと、ページが脱落し始める可能性があるが、それでもかなり早く元に戻る」とコメントしています。（出典：Search Engine Journal – Cloudflare Outage Triggers 5xx Spikes）
さらに同氏は「サーバーエラーが1週間も表示され続けると、Googleは404エラーと同様に扱い、クロールを減らしインデックスから削除するが、コンテンツが再び利用可能かどうか確認するために時折アクセスを続ける」とも説明しています。
Google公式ドキュメントでも「既にインデックスされたURLはインデックスに保持されるが、最終的には削除される」と記載されています。
5xxエラーのSEO影響をまとめると、短期間・少数URLなら影響は軽微であり、長期間・多数URLになるほどダメージは大きくなります。
重要なのは、エラーの発生そのものよりも「どれだけ早く気づいて対処できるか」です。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
一時的な5xxエラーと恒常的な5xxエラーの見極め方
すべての5xxエラーに同じ緊急度で対応する必要はありません。一時的なエラーか恒常的なエラーかを見極めることで、対応の優先度が大きく変わります。
「サーチコンソールに5xxエラーが表示されるたびに慌ててしまう」という方もいるかもしれません。
しかし、3つの基準を押さえれば、冷静に判断できるようになります。
対処の緊急度を判断する3つの基準
5xxエラーの緊急度は「エラーの継続期間」「影響URLの数と傾向」「外的要因の有無」の3つの基準で判断できます。
基準1. エラーの継続期間
もっとも重要な判断材料は、エラーがどのくらい続いているかです。
数時間以内に自然に解消されたなら、一時的なエラーと判断して経過観察で問題ありません。
一方、複数日以上続いている場合は恒常的な問題の可能性が高く、即座に対処が必要です。
基準2. 影響URLの数と傾向
特定の数URLだけでエラーが発生しているなら、個別ページ固有の問題でしょう。
サイト全体に広がっている場合は、サーバーそのものに問題を抱えている可能性があります。
サーチコンソールの「ページのインデックス登録」レポートで、影響URLが増加傾向にないかも確認してください。
基準3. 外的要因の有無
エラーの発生タイミングが、CDN障害やホスティング障害と一致していないか確認しましょう。
2025年11月に発生したCloudflareの障害では、多くのサイトで短時間の5xxスパイクが観測されました。
しかし、この障害は「短時間の5xxスパイクは主にクロール挙動に影響し、長期的なランキング低下にはつながらなかった」と報告されています。（出典：Search Engine Journal – Cloudflare障害とSEO影響）
John Mueller氏もこの障害について「5xx = Googleのクロールは減速するが、また元に戻る」とコメントしています。（出典：Business Tech Weekly – Cloudflare障害の影響）
外部サービスの障害が原因であれば、自社で対処すべき問題ではない場合がほとんどです。
放置してよいケースと即対処すべきケース
数時間以内に自然回復した一時的な5xxエラーは放置してよく、同じURLで繰り返し発生するエラーや影響URLが増加傾向にある場合は即対処が必要です。
▼放置してよいケース
CDNやホスティング側の一時的な障害が原因で、数時間以内に自然回復した場合は、基本的に対応不要です。
サーチコンソールのCrawl Statsレポートを確認し、一時的なスパイクだけで常態化していなければ心配ありません。
「本当に放置して大丈夫なのか」と気になるかもしれませんが、数日後にもう一度レポートを確認して異常がなければ安心してよいでしょう。
▼即対処すべきケース
以下のいずれかに該当する場合は、速やかな対応が求められます。
- 同じURLで5xxエラーが繰り返し発生している
- 影響を受けているURLの数が増加傾向にある
- 収益に直結する重要なページ（ECサイトの商品ページやLPなど）が含まれている
放置してよいケースを見極められれば、限られたリソースを重要な問題に集中できます。
5xxエラーの通知が来るたびに全力対応するのではなく、冷静に優先度を判断する習慣をつけましょう。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
エラー修正後のサーチコンソールでの検証と回復確認
5xxエラーを修正しただけでは、対応は完了していません。
サーチコンソールで検証を実行し、インデックスやランキングが正常に回復したことまで確認して、はじめて対処完了と言えます。
「修正を検証」の実行手順と検証期間の目安
5xxエラーの修正後、Googleに再確認してもらうために「修正を検証」機能を実行しましょう。
手順は以下のとおりです。
- サーチコンソールの「ページのインデックス登録」レポートを開く
- 「サーバーエラー（5xx）」のステータスをクリックして詳細画面に移動する
- 画面上部の「修正を検証」ボタンをクリックする
- Googleが該当URLを再クロールし、ステータスの改善を確認する
検証結果が出るまでには、通常約2週間かかります。
サイトの規模や対象URLの数によっては、それ以上の時間が必要になるケースもあるでしょう。
検証ステータスには、いくつかの種類があります。
- 検証中：Googleが対象URLを再クロールしている最中の状態
- 合格：すべての対象URLでエラーが解消されたことが確認された状態
- 不合格：一部またはすべてのURLでまだエラーが残っている状態。原因を再調査して修正後、再度「修正を検証」を実行する
- その他：検証の対象期間中に新たな問題が発生した場合など
不合格になっても焦る必要はありません。
残っている5xxエラーのURLを確認し、原因を特定して修正すれば、何度でも検証をやり直せます。
インデックス回復状況のモニタリング方法
5xxエラーが修正されると、Googleはクロール頻度を徐々に回復させます。
Google公式ドキュメントでは「サーバーが2xxステータスコードで応答し始めると、Googleはサイトのクロール頻度を徐々に増加させる」と述べられています。
回復状況を追跡するために、以下の3つのレポートを定期的にチェックしましょう。
- クロールの統計情報レポート
正常レスポンス（2xx）の割合が回復傾向にあるか確認する。5xxの割合が減少し2xxが増加していれば、問題は解消に向かっている - ページのインデックス登録レポート
エラー数が減少し、有効ページ数が増加する推移を追跡する。「サーバーエラー（5xx）」のカウントがゼロに近づいていれば回復が順調 - 検索パフォーマンスレポート
オーガニックトラフィック（クリック数や表示回数）が元の水準に戻っているか確認する。インデックス回復後も、検索パフォーマンスの回復にはさらに数日〜数週間かかる場合がある
モニタリングの推奨頻度は、修正後1〜2週間は毎日確認し、その後は週1回のペースで十分です。
エラー修正後のインデックス回復状況を定期的にモニタリングするなら、inSiteのインデックスチェック機能が便利です。
手動でレポートを毎日確認する手間を省き、回復の進捗を効率的に追跡できます。
5xxエラーに適切に対処すれば、ランキングは回復します。
焦って過剰な施策を打つよりも、正しい手順で修正し、サーチコンソールで回復を確認することが最善の方法です。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
5xxエラーを未然に防ぐための予防策
5xxエラーは、発生してから対処するだけでなく、そもそも発生させない仕組みづくりが鍵となります。
事後対応はどうしても後手に回りがちで、その間にクロール減速やインデックス削除が進んでしまう恐れがあります。
サーバー監視とアラート設定
5xxエラーの被害を最小化するには、発生後すぐに気づける体制を作ることが第一歩です。
外部監視ツールの導入
サーバーの稼働状況を常時監視するツールを導入しましょう。
UptimeRobotやPingdomなどのサービスでは、サーバーがダウンした際にメールやSlackで即座に通知を受け取れます。
UptimeRobotは無料プランでも5分間隔の監視が可能なので、まだ導入していない方はぜひ検討してみてください。
サーチコンソールのメールアラート
サーチコンソールには、重大な問題が検出された際にメールで通知する機能があります。
メール通知はデフォルトで有効になっていますが、過去に無効化していないか「ユーザー設定」>「メール設定」から確認しておきましょう。
ただし、サーチコンソールの通知はリアルタイムではないため、UptimeRobotなどの外部監視ツールとの併用が理想的です。
クロールの統計情報レポートの定点チェック
週1回の頻度で、クロールの統計情報レポートを確認する習慣をつけましょう。
5xxレスポンスの割合が突然増えていないか、クロール頻度が急激に下がっていないかを定期的にチェックすることで、問題の早期発見につながります。
なお、robots.txtファイル自体が5xxを返した場合、連鎖的な影響が発生します。 Google Search Console ヘルプ（robots.txtレポート）によれば、以下の3段階で影響が進行します。
- 最初の12時間
サイトのクロールが完全に停止する（robots.txtの取得は継続して試みる） - 12時間〜30日
最後に正常取得できたrobots.txtのキャッシュ版を使用してクロールを継続する - 30日経過後
サイト自体がアクセス可能であれば、robots.txtがないものとして制限なしでクロールされる。サイト全体にアクセス問題がある場合は、クロールが停止する
つまり、robots.txtのサーバーエラーは、サイト全体のクロールを止めてしまう可能性があるのです。（出典：Google Search Console ヘルプ-robots.txt レポート）
サーバーエラーの影響範囲を自動で検出し、内部リンク構造への悪影響を可視化するなら、inSiteの内部リンクチェックツールをお試しください。
内部リンクの最適化の記事も参考にしながら、サイト全体のリンク構造を健全に保ちましょう。
計画的メンテナンス時の503＋Retry-Afterヘッダー活用
計画的なメンテナンス時に5xxエラーのSEO影響を防ぐには、503ステータスコードとRetry-Afterヘッダーの組み合わせが有効です。
Googleは公式ブログで「ページが要求された際に404やエラーページを200で返すのではなく、503を返すのが良い。
検索エンジンクローラーにダウンタイムが一時的であることを伝えられる」と推奨しています。（出典：Google Search Central Blog – 計画的ダウンタイムの対処法）
John Mueller氏も2022年1月のOffice Hoursで、サイト障害時にページがインデックスから落ちてしまう問題について「問題が発生したときに503を返せるよう、事前にルールを用意しておくべき」と述べています。
503を返すことでGoogleに一時的な不具合だと伝えられ、1〜2日程度であればページが削除されることはないとのことです。（出典：Google Office Hours – 2022年1月21日）
Retry-Afterヘッダーの実装
503レスポンスを返す際には、Retry-Afterヘッダーを併せて設定しましょう。
Retry-Afterヘッダーは、クローラーに「この時間が経過したら再度アクセスしてください」と伝えるためのHTTPヘッダーです。
MDN Web Docsでも「Googlebotのような一部のクローラーはRetry-Afterヘッダーを尊重する」と記載されています。（出典：MDN Web Docs – Retry-Afterヘッダー）
Apacheの場合は.htaccessに、Nginxの場合はサーバー設定ファイルに、メンテナンス時だけ503とRetry-Afterを返すルールを事前に用意しておくと安心です。
ただし、503の長期使用には注意が必要です。
Googleは公式ブログで「持続的な503は、サーバーが恒久的に利用不能であるサインとみなされ、インデックスからURLが削除される可能性がある」と警告しています。（出典：Google Search Central Blog – 計画的ダウンタイムの対処法）
503はあくまで一時的なメンテナンス用です。恒久的な対策として使い続けることは避けてください。
メンテナンスが完了したら、速やかに通常のレスポンス（200）を返す状態に戻しましょう。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
その他のインデックスステータス一覧
その他のインデックスステータスの一覧を以下の表にまとめました。他のエラーや除外が発生している方は参考にしてください。
▼インデックスステータス一覧表
| 大分類 | カテゴリ | ステータス名 | 対処の必要性 |
|---|---|---|---|
| 登録済み | – | ページはインデックスに登録済みです | 不要 |
| 警告あり | robots.txtによりブロックされましたが、インデックスに登録しました | 確認推奨 | |
| コンテンツのない状態でページがインデックスに登録されています | 確認推奨 | ||
| 未登録 | エラー | サーバーエラー（5xx） | 高い |
| リダイレクトエラー | 高い | ||
| 未承認のリクエスト（401）が原因でブロックされました | 高い | ||
| アクセス禁止（403）が原因でブロックされました | 高い | ||
| 見つかりませんでした（404） | 状況による | ||
| 他の 4xx の問題が原因で、URL がブロックされました | 高い | ||
| ソフト404 | 高い | ||
| ブロック | robots.txt によりブロックされています。 | 意図的なら不要 | |
| URL に noindex が指定されています | 意図的なら不要 | ||
| クロール・Google判断 | 検出 – インデックス未登録 | 中程度 | |
| クロール済み – インデックス未登録 | 高い | ||
| 重複・正規化 | 代替ページ（適切なcanonicalタグあり） | 不要 | |
| 重複しています。ユーザーにより、正規ページとして選択されていません | 確認推奨 | ||
| 重複しています。Google により、ユーザーがマークしたページとは異なるページが正規ページとして選択されました | 確認推奨 | ||
| ページにリダイレクトがあります | 不要 |
なお、全ステータスについて詳しく解説している「インデックスカバレッジとは？全ステータスの意味と対処法を解説」も参考にしてください。
また、インデックスに登録されないページ数を確認する方法は、「「インデックスに登録されていないページ数」の確認方法と対処法【放置OKなケースも解説】」を参考にしてください。
≫inSiteでサイトのインデックス状況をチェックしてみる（無料）
まとめ｜サーバーエラー（5xx）対処のポイント
サーバーエラー（5xx）への対処で押さえるべきポイントは、次の5つです。
- サーバーエラー（5xx）は、サーバー側の問題でGooglebotがページにアクセスできなかった状態を示す
- 一時的なエラーは自然回復するが、複数日以上続くとインデックスから削除される可能性がある
エラーの継続期間と影響URLの数で緊急度を判断する - ランキングシグナルは保持されるため、適切に対処すれば以前の状態に回復できる
- サーチコンソールでの確認 → サーバーログでの原因特定 → 修正 → 検証依頼の流れで対処する
修正後はインデックス回復のモニタリングまで行う - 計画的メンテナンス時は503＋Retry-Afterヘッダーで予防できる
ただし長期間の503使用は逆効果になるため注意する
5xxエラーは、正しい知識と手順があれば必ず対処できる問題です。焦らず、一つひとつステップを踏んで対応していきましょう。
SEO対策とは？基礎知識と対策方法をわかりやすく解説も参考にしながら、サイト全体のSEO品質を高めていってください。
インデックス状態の把握が大変という方は、SEOサイト管理自動化ツール「inSite（インサイト）」を試してみてください。
inSiteのインデックスチェック機能では、サイト内のページのクロール状態を毎日自動でチェックします。
どれだけのページがインデックスされてなくて原因は何なのか、クローラーは定期的に来ているのかといった情報を常に監視することができます。
1ページずつURL検査をしなければわからないインデックス状態。
inSiteを使えばこれを常に把握できるため、効率よくSEOにおける有効な打ち手を考えることができます。
ページのインデックス率向上や、ページの評価をアップさせるリライトの効率化にかなり使えると思うので、ぜひお試しください。
この記事が気に入ったら
フォローしてね！