5xxエラーがSEOやインデックスに与える影響を解説します。500・502・503・504の違い、Search Consoleでの確認方法、原因別の修正手順、再発防止策まで分かりやすく紹介します。
Google Search Consoleに「サーバーエラー（5xx）」と表示されると、検索順位が下がるのか、ページが検索結果から消えるのかと不安になりがちです。
特に、ブラウザでは問題なくページを開ける場合、どこに異常があるのか判断しにくいでしょう。
5xxエラーは、Webサーバーがリクエストを正常に処理できなかったときに返すステータスコードです。
短時間で復旧する一時的なエラーであれば、すぐに検索順位が大きく下がるとは限りません。
ただし、同じエラーが頻発したり長期間続いたりすると、Googlebotのクロール頻度が低下し、最終的にはインデックスにも影響する可能性があります。
対応するときは、エラーコードだけを見て原因を決めつけるのではなく、対象URL、発生範囲、継続時間、サーバーログを順番に確認することが重要です。
そこで今回は、5xxエラーがSEOに与える影響と、確認・修正・再発防止の手順を実務の流れに沿ってまとめました！
自社で確認できる範囲と、エンジニアやサーバー会社へ相談すべき範囲を切り分け、重要なページから落ち着いて対応しましょう。
まず確認！5xxエラーがSEOに与える影響を正しく理解しよう
5xxエラーへの対応では、エラーが1件表示されたという事実だけで、すぐにサイト全体のSEO評価が下がったと判断しないことが大切です。
Googlebotは5xxエラーを受け取ると、一時的なサーバー障害の可能性を考慮して、同じURLへのアクセスを後で再試行します。
一方で、エラーが繰り返されるサイトに対しては、サーバーへの負荷を抑えるためにクロールを一時的に減らします。
すでにインデックスされているURLは、5xxエラーが発生した直後に削除されるわけではありませんが、正常な内容を長期間取得できなければ、最終的にインデックスから外れる可能性があります。
そのため、SEOへの影響はエラーの件数だけでなく、発生範囲、継続時間、対象ページの重要度を組み合わせて判断する必要があります。
トップページや主要なサービスページで発生している場合と、検索流入のない不要なURLで発生している場合では、対応の緊急度が異なります。
まずは5xxエラーの意味と4xxエラーとの違いを理解し、優先的に調査すべきURLを選びましょう。
5xxエラーとは？サーバー側で起きる問題を分かりやすく整理！
Webページへアクセスすると、ブラウザやGooglebotからサーバーへ「このURLの内容を表示してほしい」というリクエストが送られます。
サーバーはリクエストの処理結果を、3桁のHTTPステータスコードで返します。
正常にページを返せた場合は200番台、転送が行われた場合は300番台、リクエストやURLに問題がある場合は400番台が使われます。
500番台のステータスコードは、サーバー側で問題が起き、リクエストを正常に処理できなかった状態を表します。
たとえば、存在しないページへアクセスした際に返される404は、URLに対応するページがないことを示す4xxエラーです。
これに対して500や503は、URLが存在していても、プログラムの不具合やサーバーの混雑などによって内容を返せない場合に発生します。
画面に同じようなエラーメッセージが表示されていても、実際に返されているコードによって意味と対応方法は異なります。
そのため、表示画面だけで判断せず、開発者ツールやHTTP確認ツールで実際のレスポンスコードを確認することが欠かせません。
原因によってはCMSの設定変更で直せる場合もありますが、サーバーやプログラムの調査が必要になるケースもあります。
放置は危険？短時間の発生と長期化した場合の違い！
5xxエラーが一度発生しただけで、ページの検索順位やサイト全体の評価が即座に失われるわけではありません。
サーバーの一時的な再起動や短時間のアクセス集中などが原因で、すぐに正常な200レスポンスへ戻れば、SEOへの影響は限定的であると考えられます。
ただし、Googlebotがアクセスするたびに5xxエラーを受け取る状態では、ページ内容を取得したり、更新内容を確認したりできません。
Googleのクローラーは5xxエラーや429エラーが続くと、サーバーへ過度な負荷をかけないよう、サイトに対するクロールを一時的に減らします。
正常なレスポンスが戻ればクロール頻度は段階的に回復しますが、障害が長期化すると、既存ページがインデックスから外れる可能性もあります。
また、SEOだけでなく、ユーザーが商品ページや問い合わせページを開けないことによる売上機会の損失も無視できません。
何度アクセスしてもエラーが出るサイトは、ブランドやサービスへの信頼を損なう原因にもなります。
したがって、短時間で復旧したエラーは経過を確認しつつ、数時間以上続くエラーや繰り返し発生するエラーは、早めに原因調査へ移る必要があります。
SEOへの影響が大きいページから優先して対応しよう！
Search Consoleに多数の5xxエラーが表示されても、すべてのURLを同じ優先度で調査する必要はありません。
最初に確認したいのは、トップページ、商品・サービスページ、問い合わせページ、検索流入の多い記事など、集客や売上に直結するURLです。
次に、外部サイトから多くの被リンクを獲得しているページや、広告・メール・SNSから利用者を誘導しているページを確認します。
主要なURLでエラーが続いている場合は、検索エンジンだけでなく、実際のユーザーにも影響が出ている可能性が高いため、緊急度は高くなります。
一方で、削除済みの管理用URLや検索結果に掲載する必要のない動的URLであれば、重要ページと同じ速さで対応する必要はないケースもあります。
ただし、不要なURLであっても、存在しないページに5xxを返す設定は適切とは限りません。
完全に削除したURLは404または410、移転したURLは適切な転送など、URLの状態に合ったレスポンスへ整理する必要があります。
画像、CSS、JavaScriptなどのファイルで5xxエラーが発生している場合も、ページの表示やGoogleによる内容理解に影響していないか確認しましょう。
事業への影響、検索流入、コンバージョン、発生範囲の順に整理すると、限られた時間でも優先順位を付けやすくなります。
原因を素早く特定！代表的な5xxエラーとチェックポイント
5xxエラーには複数の種類があり、コードによって問題が起きている場所の目安が異なります。
ただし、500なら必ずプログラム、502なら必ず外部サービスというように、コードだけで原因を断定することはできません。
同じ503エラーでも、アクセス集中、計画的なメンテナンス、サーバーのリソース不足など、発生原因はさまざまです。
効率よく調査するには、最初にエラーコードを確認したうえで、発生時刻、対象URL、直前に行った更新、サーバーや外部サービスの稼働状況を照合します。
さらに、自社のブラウザでは表示できるのにGooglebotだけが5xxを受け取っている場合、セキュリティ機能やアクセス制限も調査対象になります。
原因を「サーバー」「サイトやCMS」「外部サービス」「アクセス制御」に分けて考えると、確認漏れを防ぎやすくなります。
調査した内容は口頭だけで共有せず、URL、時刻、コード、再現条件を記録し、エンジニアやサーバー会社が確認できる形に整えましょう。
500・502・503・504の違いを押さえて調査を早めよう！
500 Internal Server Errorは、サーバー内部で予期しない問題が発生し、処理を完了できなかった場合に返される代表的なコードです。
プログラムのエラー、CMSやプラグインの不具合、設定ファイルの記述ミス、ファイル権限の問題など、幅広い原因が考えられます。
502 Bad Gatewayは、利用者からのリクエストを受けたサーバーが、さらに接続している上流サーバーから正常な応答を受け取れなかった状態です。
CDN、リバースプロキシ、ロードバランサー、アプリケーションサーバー間の通信異常などが主な確認対象になります。
503 Service Unavailableは、サーバーが一時的にリクエストを処理できない状態を示します。
アクセス集中、メンテナンス、CPUやメモリの不足など、一時的な停止を伝える際にも使用されます。
504 Gateway Timeoutは、上流サーバーから制限時間内に応答が返らなかった状態です。
データベース処理の遅延、外部APIの停止、重いプログラム処理などを確認する必要があります。
エラーコードは調査の入口として有効ですが、最終的な原因はサーバーログと発生状況を組み合わせて判断することが重要です。
よくある原因を「サーバー・サイト・外部サービス」に分けて確認！
サーバー側では、急激なアクセス増加、CPUやメモリの不足、ディスク容量の枯渇、プロセス停止、ネットワーク障害などを確認します。
特定の時間帯だけエラーが増える場合は、アクセス集中のほか、バックアップやデータ更新などの定期処理が影響している可能性もあります。
サイトやCMS側では、PHPなどのプログラムエラー、テーマやプラグインの競合、データベース接続の失敗、設定ファイルの誤記を調べます。
サイト更新やプラグイン追加、CMSのバージョンアップ直後に発生した場合は、直前の変更が重要な手がかりになります。
外部サービス側では、CDN、リバースプロキシ、ロードバランサー、決済機能、外部APIなどの障害やタイムアウトを確認します。
Webサーバー自体が正常でも、接続先が応答しなければ502や504が返ることがあります。
また、ファイアウォールやWAF、ボット対策機能がGooglebotを不審なアクセスと判断し、遮断しているケースにも注意が必要です。
まず発生時刻と変更履歴を照合し、その後にサーバー、CMS、外部接続、セキュリティ設定の順で確認すると、調査範囲を絞りやすくなります。
ユーザーには見えるのにGoogleだけ5xxになる原因にも注意！
担当者のブラウザでページを正常に開けても、Googlebotがアクセスした時点では5xxエラーが発生していた可能性があります。
Search Consoleの情報は、現在の表示状態ではなく、Googlebotが最後にクロールした時点の結果を含んでいるためです。
また、CDNやブラウザのキャッシュによって利用者には保存済みのページが表示される一方、Googlebotが接続する元のサーバーではエラーが起きている場合もあります。
アクセス元のIPアドレス、ユーザーエージェント、国や地域、短時間のアクセス回数によって異なるレスポンスを返す設定も確認が必要です。
特に、WAFやボット対策機能の制限が厳しいと、正規のGooglebotまで遮断し、Googleだけが5xxや403を受け取ることがあります。
ただし、ユーザーエージェントに「Googlebot」と書かれているだけでは、Googleからのアクセスであるとは判断できません。
Googlebotを確認する際は、アクセス元IPに対する逆引きと正引きを行うか、公開されているGooglebotのIP範囲と照合します。
確認せずに特定のユーザーエージェントを全面的に許可すると、偽装したクローラーまで通すおそれがあります。
Googlebotの正当性を確認したうえで、必要なアクセスだけを許可する設定に調整しましょう。
この順番なら迷わない！5xxエラーの調査・修正手順
5xxエラーを効率よく解決するには、思いついた設定を次々に変更するのではなく、確認する順番を決めることが大切です。
最初にSearch Consoleで対象URLと発生範囲を把握し、現在もエラーが再現するか確認します。
次に、実際のHTTPステータスコードとサーバーログを調べ、どの処理で問題が発生しているかを絞り込みます。
原因を修正した後は、ブラウザでページが表示されるかだけでなく、サーバーが正常な2xxコードを返しているかまで確かめます。
最後にGoogleへ再確認を促し、クロール、インデックス、検索流入が回復しているかを継続的に追います。
この流れで進めれば、過去に一度だけ発生したエラーに過剰反応したり、原因を確認しないままプラグインや設定を変更したりするリスクを減らせます。
技術担当者へ依頼する場合も、対象URLや発生時刻を整理しておくことで、調査をスムーズに進められます。
手順1：Search Consoleで対象URLと発生状況を把握！
Search Consoleの「ページのインデックス登録」を開き、「サーバーエラー（5xx）」に分類されているURLと件数を確認します。
この表示は、サーバーがGooglebotに対して500番台のレスポンスを返し、ページを正常に取得できなかったことを示します。
対象URLを開き、トップページやサービスページなどの重要URLが含まれているか、特定のディレクトリに集中しているかを確認しましょう。
最終クロール日時も確認し、現在発生している障害なのか、すでに復旧した過去のエラーなのかを切り分けます。
重要なURLはURL検査に入力し、「公開URLをテスト」で現時点の取得状況を確認します。
公開URLテストが成功する場合は、一時的なエラーが解消している可能性があります。
ただし、時間帯によって発生する障害やアクセス回数に応じた制限は、1回のテストだけでは確認できないことがあります。
クロール統計情報も確認し、ホストの接続状況や5xxエラーの割合が急増していないかを調べましょう。
エラーURLを重要度、ページ種類、ディレクトリ、最終クロール日時で分類すると、共通原因を見つけやすくなります。
手順2：ステータスコードとサーバーログから原因を絞り込む！
Search Consoleで対象URLを確認したら、ブラウザの開発者ツールやHTTP確認ツールを使い、現在返されているステータスコードを調べます。
画面にページが表示されていても、内部ではリダイレクトが繰り返されていたり、一部のファイルだけが5xxを返していたりする場合があります。
通常のパソコンだけでなく、スマートフォン環境や異なるネットワークからも確認すると、端末や接続元による違いを見つけやすくなります。
次に、サーバーのアクセスログとエラーログを確認します。
アクセスログでは、対象URLへいつ、どのIPアドレスやユーザーエージェントからアクセスがあり、どのコードを返したかを確認できます。
エラーログでは、プログラムの停止、データベース接続の失敗、メモリ不足、タイムアウトなど、内部で発生した問題を把握できます。
すべてのアクセスで発生するのか、Googlebotだけなのか、一定時間帯だけなのかを比較することも重要です。
調査内容は、URL、発生日時、エラーコード、再現条件、直前の変更内容をセットで記録しましょう。
この情報があれば、サーバー会社や開発担当者へ依頼する場合も、原因調査を始めやすくなります。
手順3：原因別に修正し、必ず正常な応答を確認！
プログラムやCMSが原因の場合は、エラーログに記録された箇所を確認し、不具合のあるコード、テーマ、プラグインを修正します。
更新直後に発生した場合は、変更前の状態へ戻してエラーが解消するかを確認する方法も有効です。
ただし、利用中のプラグインを理由なくすべて停止すると、別の機能や表示に影響するため、バックアップを取得したうえで一つずつ切り分けます。
サーバー負荷が原因であれば、画像や処理の軽量化、キャッシュの活用、データベースの改善、不要な処理の停止、サーバープランの見直しを検討します。
設定ミスが原因の場合は、リダイレクト、アクセス権限、設定ファイル、PHPやWebサーバーの設定を確認します。
CDNや外部APIが原因の場合は、接続先の障害情報、DNS、タイムアウト時間、通信設定を調べます。
修正後は、ページをブラウザで表示できるかだけでなく、200などの正常な2xxレスポンスが返っているかを確認することが重要です。
原因を特定できない場合は、推測で設定を変え続けず、ログと再現条件を添えてサーバー会社、CMS提供会社、制作会社へ相談しましょう。
手順4：Googleに再確認を促し、復旧状況を追跡！
修正後はURL検査の「公開URLをテスト」を実行し、Googleが現在のページへアクセスできる状態か確認します。
テストで問題がなければ、検索流入や売上への影響が大きいURLを中心に、インデックス登録をリクエストします。
多数のURLに共通する問題を修正した場合は、ページのインデックス登録レポートから「修正を検証」を開始します。
重要なURLがXMLサイトマップに正しく記載されているかも確認し、更新されたページをGoogleが見つけやすい状態に整えましょう。
ただし、インデックス登録をリクエストしても、検索結果が即座に元へ戻るとは限りません。
Googleのクローラーは、サーバーが正常な2xxレスポンスを返すようになると、サイトへのクロールを段階的に増やします。
復旧確認では、Search Console上のエラー件数だけでなく、クロールされたページ数、インデックス状況、表示回数、クリック数も追います。
一時的に正常になった後で再発するケースもあるため、数日から数週間はサーバーログや監視結果を確認しましょう。
エラー表示の消失ではなく、正常な取得と検索パフォーマンスの回復まで確認することが対応完了の基準です。
再発を防いでSEOを守ろう！運用ルール
5xxエラーは、どれほど注意して運営していても、アクセス集中や外部サービスの障害などによって発生する可能性があります。
重要なのは、エラーを完全にゼロにすることだけではなく、発生を早く検知し、SEOや売上への影響が広がる前に復旧できる体制を整えることです。
特に、サイト更新やサーバー移行、CMSのバージョンアップ、キャンペーン開始時は、通常よりもエラーが起きやすくなります。
変更前後の確認項目、問題が起きた場合の戻し方、担当者への連絡手順を決めておくと、障害発生時に迷いにくくなります。
また、計画的なメンテナンスでは、ページを停止するだけでなく、Googlebotへ「一時的な停止」であることを正しく伝える必要があります。
誤ったステータスコードを返すと、メンテナンス画面が通常の内容として扱われたり、重要ページが存在しないと判断されたりするおそれがあります。
適切なレスポンス、継続的な監視、担当者間の連携を組み合わせ、エラーの長期化を防ぎましょう。
メンテナンス時にやってはいけない対応を避けよう！
計画的なメンテナンスでサイトを一時停止するときは、メンテナンス画面を表示するだけでなく、適切なHTTPステータスコードを返す必要があります。
一時的にページを提供できない場合は、503 Service Unavailableを返す方法が適しています。
503は、ページが削除されたのではなく、現在は一時的に利用できないことをクローラーへ伝えるコードです。
メンテナンス画面に200を返し続けると、Googleが通常ページの内容をメンテナンス文へ置き換えて認識する可能性があります。
再開予定が明確な場合は、Retry-Afterヘッダーを利用して、再度アクセスしてほしい時期を伝える方法もあります。
ただし、503を返していれば無期限に停止してよいわけではありません。
Googleは503を受け取ったページを再試行しますが、長期間停止すると検索結果から外れる可能性があります。
一時停止のために重要ページを404や410へ変更したり、サイト全体をrobots.txtで遮断したりする対応も避けましょう。
メンテナンスはできるだけ短時間で終え、復旧後は503が残っていないか、主要ページと関連ファイルを必ず確認します。
定期監視と社内連携でエラーの長期化を防ごう！
5xxエラーの影響を小さくするには、Search Consoleから通知が届くまで待つのではなく、サーバーや主要URLを継続的に監視することが効果的です。
外部の監視サービスを利用すれば、ページが応答しない場合や5xxを返した場合に、メールやチャットへ通知できます。
トップページ、サービスページ、購入ページ、問い合わせページなど、事業への影響が大きいURLは高い頻度で確認しましょう。
Search Console、アクセスログ、エラーログ、サーバー監視を組み合わせると、Googlebotだけの問題や一時的な負荷も把握しやすくなります。
サイト更新やサーバー変更を行う際は、作業前のバックアップ、公開後の表示確認、ステータスコード確認を手順に含めます。
問題が発生した場合に元の状態へ戻せるよう、変更した内容と担当者も記録しておくことが重要です。
SEO担当者、制作担当者、エンジニア、サーバー管理者の間で、誰が一次確認を行い、誰へ連絡するかを決めておきましょう。
過去の障害について、発生日時、原因、影響範囲、修正内容、再発防止策を残すと、同じ問題が起きた際の対応時間を短縮できます。
まとめ
5xxエラーは、サーバーがリクエストを正常に処理できなかったときに返すステータスコードです。
短時間で復旧する一時的なエラーであれば、検索順位へ直ちに大きな影響が出るとは限りません。
一方で、5xxエラーが頻発または長期化すると、Googlebotのクロールが減り、最終的にはインデックスから外れる可能性があります。
対応時は、Search Consoleで対象URLと最終クロール日時を確認し、実際のステータスコードとサーバーログから原因を切り分けます。
修正後はページが表示されることだけで判断せず、正常な2xxレスポンスが返っているか確認しましょう。
その後、必要に応じてインデックス登録のリクエストや修正の検証を行い、クロール状況と検索流入の回復を追います。
すべてのエラーを同時に調査するのではなく、発生範囲、継続時間、ページの重要度を基準に優先順位を付けることがポイントです。
トップページや主要な集客ページから対応し、不要なURLは本来の状態に合ったステータスコードへ整理します。
定期監視と社内の連絡ルールも整え、5xxエラーが発生してもSEOと事業への影響を最小限に抑えられる運用を目指しましょう。
Webマーケにお悩みなら、「AI×経験×アイディア」のぎあはーとへ！
合同会社ぎあはーとは「AI×プロの経験×アイディア」で強いマーケ戦略を着実にお届けする会社です。
| ・月間売上を前年比277.4%に （3,479,415円→9,653,169円） （上場アパレルメーカーM社：2021年 運用1年） ・新規サイトで月間コンバージョン数を31件へ （ メディア系SaaSツールC社：2025年 施策10ヶ月） ・Webイベントで1,330名の参加者集客 （メディア系SaaSツールC社：2026年 イベント期間30日） |
こんな実績を持つマーケティングのプロが、他にできない強い施策を素早く回転させます。
戦略からコンテンツ運用、結果分析までをワンストップで受けつけております。また、10本で8,8000円という格安にてSEO記事制作もお受けしております。
料金表
| 内容 | 基本料金 |
| マーケティング顧問業務 LLMO戦略立案・コンテンツ制作・レポート | 月額・要お見積もり |
| SEO記事の制作1本（スポット依頼） 5,000字以上、追加料金なし キーワード選定等ワンストップ | 9,900円（税込） |
| SEO記事の制作10本（スポット依頼） 合計50,000字以上、追加料金なし キーワード選定等ワンストップ | 88,000円（税込） |
まずはオンライン面談によるお見積もりや無料のサイト診断ができますので、ぜひお気軽にご相談ください！
