サーバーエラーとは？主な原因とSEOへの影響

サイトに5xxのサーバーエラーが表示されると、検索のクロールやインデックスにも影響が及びます。原因の見極めから、SEOで取るべき対処、復旧後の確認までを運営者向けに解説します。

サーバーエラーとは

サーバーエラーは、狭義にはHTTPステータスコードの5xxを指し、サーバーがリクエストに正常に応答できないときに返すエラーです。広義には、アプリやサービスが画面に出すサーバーエラーの通知も含みます。500や503などの5xxコードが表示されているなら、そのコードを生成しているのはサーバーであり、原因はサーバー側にあります。

サーバーエラーが表示される主な原因

前述のとおり、5xxの原因はサーバー側に限られます。HTTPステータスコードはサーバーが生成するため、利用者の端末やブラウザのキャッシュが原因で5xxが返ることは原則ありません。確認すべきはサーバー側であり、アクセス集中による過負荷、プログラムや設定の不具合、メンテナンス、DNSの問題が主な原因です。

エラーコード別のサーバーエラーの意味

500番台を中心に、それぞれのコードが何を表すかを早見表で押さえます。5xxと429はサーバー側、400番台はクライアント側のエラーです。

500 内部サーバーエラー

英語表記はInternal Server Errorです。サーバー内部で処理に失敗した状態を広く指す、原因を1つに特定しにくい汎用的なエラーです。

502 Bad Gateway

リバースプロキシやCDNなどの中継サーバーが、上流のサーバーから正常な応答を受け取れていない状態を示します。

503 Service Unavailable

アクセス集中やメンテナンスで一時的に利用できない状態を示します。計画的なメンテナンス時に運営側が意図的に返すコードでもあり、その扱いは後述します。

504 Gateway Timeout

中継サーバーが、上流のサーバーからの応答を時間内に受け取れなかった状態を示します。

混同しやすい400番台のエラー

400・403・404はクライアント側のエラーで、リクエストやURL側に原因があります。5xxはサーバー側の問題のため、対処の所在が異なる点に注意します。ただし429は過負荷を示すため、サーバーエラーとして扱われます。

サーバーエラーがクロールやインデックスに与える影響

サーバーエラーが続くと、検索での評価にも影響します。5xxと429のエラーは、Googleのクローラーにクロールのペースを一時的に落とすよう促すもので、エラーを返すURLが多いほど低下幅も大きくなります。インデックス済みのURLはしばらく保持されますが、解消されないままだと最終的には削除の対象です。

サーバーが2xxを返すようになれば、クロール頻度は徐々に元へ戻ります。さらに、サーバーエラーが多いとクロール能力の上限そのものが下がるため、ページ数の多い大規模サイトではクロールバジェットの面でも不利になります。

ステータスコードに応じてインデックスから削除される共通の仕組みは、検索結果やインデックスからページを削除する方法や410を使いインデックスから早く削除するでも扱っています。本記事は5xx特有の挙動に絞ります。

サーバーエラー発生時にSEOで押さえる対処

5xxはサーバー側で起こるため、SEOの観点では、検索評価を落とさない形で復旧まで進めることが要点になります。

計画的なメンテナンスでは503とRetry-Afterを返す

計画的にサイトを停止する場合は、404や200ではなく503を返します。これにより停止が一時的であるとGoogleに伝わり、あわせてRetry-Afterヘッダーで復帰の目安を示すと、再クロールのタイミングの判断にも使われます。503は1〜2日程度の短期にとどめ、長くても2〜3日を超える運用は避けてください。長期間続くと恒久的に利用できないと判断され、URLが検索から削除される可能性があるためです。

robots.txtが5xxを返さないようにする

robots.txtが5xxを返すと、Googleは最初の12時間サイト全体のクロールを停止し、その後もrobots.txtの取得を試み続けます。メンテナンス中でも、robots.txt自体は通常どおりクロールできる状態に保ち、5xxやアクセス制限で取得できない状態にしないことが必要です。robots.txtの基本的な役割はrobots.txtとはで解説しています。

原因の特定と修正はサーバー・開発側で行う

5xxの根本原因の特定や修正は、サーバーや開発の領域です。エラーログや設定の確認といった技術的な復旧はサーバー担当と連携して進め、SEOの観点では復旧を最優先しつつ検索評価を守る対応に専念します。

復旧後にSEOへの影響を確認する

復旧後は、エラーがクロールやインデックスにどう影響したかを確認します。Search Consoleの各レポートに加え、自社ツールも確認の手段として使えます。

クロールの統計情報でクロール状況を確認する

Search Consoleのクロールの統計情報で、サーバーエラーの発生件数とクロール頻度の推移を確認します。平時から定期的に見ておくと、5xxの増加を早期に把握でき、検索への影響を抑える監視と予防につながります。

ページのインデックス登録レポートでインデックス状況を確認する

ページのインデックス登録レポートで、サーバーエラーによる未登録や除外が出ていないかを確認します。Search Consoleで5xxとして報告されたページは、復旧後に再登録されるかを継続して確認します。

検索パフォーマンスで表示やクリックの変化を確認する

検索パフォーマンスレポートで、障害の前後の表示回数やクリック数の変化を確認し、検索流入への影響範囲を把握します。

kunugi SEO Checkerで復旧後のステータスコードを確認する

kunugi SEO Checkerを使うと、対象ページが返すHTTPステータスコードをブラウザのサイドパネルで確認できます。復旧後に200など正常なコードへ戻ったかを、その場で確認できます。機能の詳細はkunugi SEO Checkerの機能と使い方で解説しています。

kunugi GSC Controllerで検索パフォーマンスの変化を確認する

kunugi GSC Controllerを使うと、Search Consoleの検索パフォーマンス画面を期間比較の設定ですぐに開けます。障害の前後でクリック数や表示回数の変化を確認する用途に使えます。機能の詳細はkunugi GSC Controllerの機能と使い方で解説しています。

サーバーエラー対応でやってはいけないこと

復旧を急ぐあまり、検索評価を損なう対応は避けます。

• robots.txtを5xxにしたり、クロールをブロックしたままにしないでください。クロールが止まり、URLが検索から削除される可能性があります。
• 一時的な5xxではインデックスが保持されるため、復旧前に焦ってnoindexやURL削除ツールでページを外そうとしないでください。
• 503を長期間続けないでください。1〜2日程度にとどめ、2〜3日を超える停止は避けます。

利用者側でできる確認と対処

5xxの復旧はサイト運営者側の対応によります。利用者にできるのは限られた確認と対処で、自分の環境に原因がないかを切り分ける位置づけになります。ネットワークの瞬断やブラウザの不具合で、エラー表示が一時的に残ることもあるためです。

時間をおいて再度アクセスする

サーバー側の一時的な負荷や障害が原因のこともあるため、時間をおいて再度アクセスします。5xxは利用者側では直せないため、まず待つことが基本です。

自分だけの問題か全体の問題かを確認する

別の端末や回線、別のブラウザで同じページが表示されるかを確認し、自分だけの問題かサイト全体の問題かを切り分けます。

今サービス側で障害が起きていないか確認する

障害情報サイトや公式のステータスページ、SNSで、対象のサービスに障害が現在起きていないかをリアルタイムに確認します。同じ不具合が多発しているなら、サービス側の障害である可能性が高いです。

ブラウザのキャッシュ削除や再起動で自分の環境を切り分ける

ブラウザのキャッシュやアプリの不具合で古い表示が残ることもあります。キャッシュの削除、別のブラウザ、端末やルーターの再起動を試し、自分の環境が原因でないかを切り分けます。

接続できない場合は5xxとは別のエラーを見分ける

回線やセキュリティソフトが原因でサイトに接続できない場合は、5xxではなく、タイムアウトや接続拒否といったブラウザ独自のエラー画面になります。表示されているのが5xxコードなのか接続エラーなのかで原因の所在が変わるため、まず種類を見分けます。

スマホやアプリでサーバーエラーが出た場合の対処

スマホやアプリで表示されるサーバーエラーも、多くはサービス側に原因があります。利用者側でできるのは切り分けが中心です。アプリの再起動や再ログイン、アプリとOSの更新、通信回線の確認、アプリ側の障害情報の確認を行います。パソコンとスマホの両方で再現するかを見ると、原因の切り分けに役立ちます。