500 Internal Server Error（内部サーバーエラー）

TL;DR — 500 Internal Server Errorは、ページを組み立てようとしている途中でサーバーが壊れたことを意味します。URLやブラウザー、検索クローラーの問題ではありません。単発の500は通常Googleが再試行し、コストが発生するというルールもありません。文書化されている危険は、多数のページがしばらく500を返す場合です。そのときGoogleはクロールを遅くし、最終的にはページを検索から外す可能性があります。まずブラウザーではなく、サーバーのエラーログを確認して修正を始めてください。

500エラーとは何か

500 Internal Server Errorは、Webにおける「something went wrong and I can’t tell you exactly what.」 (翻訳)「何か問題が起きましたが、正確には伝えられません」という意味です。サーバーはリクエストを受け取り、ページの構築を始めましたが、問題に遭遇して諦め、ページの代わりに一般的なエラーを返しました。私が書いたAhrefsのHTTPステータスコードガイドでは、サーバーが「encounters some kind of issue and doesn’t have a better or more specific error code.」 (翻訳)「何らかの問題に遭遇し、より適切または具体的なエラーコードがない」と説明しています。 Evidence for this claim A 500 response means the server encountered an unexpected condition that prevented it from fulfilling the request. Scope: RFC 9110 defines the generic response semantics; it does not diagnose the underlying server fault. Confidence: high · Verified: 2026-07-14 IETF: RFC 9110 §15.6.1 — 500 Internal Server Error

理解すべき重要な点は、500がキャッチオールだということです。サーバー側で何かが壊れたことは伝えますが、何が壊れたかは伝えません。その「何が」を突き止めることが、作業のすべてです。

サーバーの問題であり、通常はあなたの問題ではない

500エラーはサーバーエラーである5xxファミリーに属します。これは、ページが見つからない404のように、リクエスト（不正または存在しないURL）に関する4xxエラーとは異なります。500ではURLが完全に正しくても、サーバーが処理を完了できなかっただけかもしれません。500には、502、503、504という仲間もあります。これらもサーバー側のエラーですが、不正なゲートウェイ、一時的に利用できないサーバー、タイムアウトなど、より具体的な状況を示します。

500サーバーエラーはSEOに悪影響を与えるか

1ページで単発かつ時々しか起きない500サーバーエラーならどうでしょうか。Googleは通常戻ってきて再試行します。再試行時にページが正常に読み込まれれば、通常はそれで終わりです。Googleは、孤立した障害が無害だという包括的な約束を公表していません。ただし、単発の一時的な障害を罰する仕組みも文書化していません。

文書化されている本当のリスクは、多数のページでサーバーエラーが継続することです。その場合は次のようになります。

1. Googleは再試行を続け、エラーが継続していることを確認すると、サイトをクロールする速度を落とします。
2. それでもエラーが解消しなければ、Googleは最終的にそのページをインデックスから外します。つまり検索に表示されなくなります。 Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers

良い知らせは、Google自身の文書が、根本的な問題を修正してクロールが再び成功すると段階的に回復すると説明していることです。ただし、期間や結果は保証していません。「Recovery is usually quick」 (翻訳)「回復は通常速い」は一般的なケースであり、約束ではありません。

修正を始める方法

• まずサーバーのエラーログを確認します。 本当の理由はブラウザーではなく、そこにあります。ブラウザーは「500」と表示するだけですが、ログにはなぜかが記録されています。
• 最近何が変わったかを確認します。 新しいプラグイン、テーマ、モジュールでしょうか。最近のコードデプロイでしょうか。.htaccessのような設定ファイルの編集でしょうか。最近の変更は、まず疑うべき対象です。
• Google Search Consoleを確認します。 Page Indexingレポートには「Server error (5xx)」セクションがあり、Googleがサーバーエラーを検出しているURLを示します。
• ホストに問い合わせます。 特に共有ホスティングでは、メモリやリソースの上限に達したことがサーバーエラーの原因になる場合が多く、ホスト側で確認できることがあります。

Googleがどのように段階的に対応するか、~1%の目安、500と503の違い、完全な診断順序まで知りたいなら、Advancedタブに切り替えてください。

TL;DR — RFC 9110は、500をサーバーがリクエストを満たせなくなった予期しない状態と定義しています。これはステータスコード自体が示す範囲のすべてです。原因、期間、再試行の価値があるかどうかは意味論ではなく診断の問題です。Googleの文書化された反応は段階的です。単発の500は通常再試行され、サイト全体で500が続くとクロールが遅くなり、解消しなければ最終的にインデックスから削除されます。Muellerは、エラー率が約1%を超えると何かが壊れている可能性が高いという、個人的な大まかな目安を示しています。ただし、これはGoogleの文書化された閾値ではありません。また、再試行 → クロール低下 → インデックスからの削除という流れは、文書化された挙動を示すもので、固定された一連のタイマーではありません。まずサーバーログで診断し、次にGSCのServer error (5xx)レポートと、Crawl Statsの「by response」を確認してください。500と503の違いも重要です。503は「後で戻ってきて」という公認のコードで、約2日間の猶予があります。制御されていない500にはそのような猶予はありません。

500の実際の意味

実務家の略式表現ではなく、まず仕様から始めましょう。HTTP意味論の標準であるRFC 9110は、500 Internal Server Errorを、サーバーがリクエストを満たせなくなった予期しない状態と定義しています。これは、ステータスコード自体が伝える内容の全範囲です。根本原因、失敗したコンポーネント、問題が続く期間、同じリクエストが再試行で成功するか、回復の見込みがあるかは特定しません。「サーバーが処理できない何かに遭遇した」ことを超える部分はすべて診断であり、ステータスコードの意味論ではありません。そして診断は、仕様やブラウザーではなく、サーバーのエラーログにあります。

AhrefsのHTTPステータスコードガイドでは、実務向けの定義を意図的に率直にしています。サーバーが「encounters some kind of issue and doesn’t have a better or more specific error code.」 (翻訳)「何らかの問題に遭遇し、より適切または具体的なエラーコードがない」というものです。これは同じRFCの境界を平易な言葉にしたもので、依然としてキャッチオールであり、診断ではなく症状です。

500は502（不正なゲートウェイ）、503（サービス利用不可）、504（ゲートウェイタイムアウト）と並ぶ5xxファミリーに属します。いずれもサーバー側ですが、500は「より適切なコードがない」という意味のコードです。ステータスコード自体には診断の詳細がないため、ブラウザーを再読み込みしてもなぜ起きたかは分かりません。真実を示すのはサーバーのエラーログです。

Googlebotは500をどう扱うか

Googleのクローラーは、設計上、サーバーの健全性に合わせて速度を落とすようになっており、5xxレスポンスを「slow down」 (翻訳)「速度を落とす」ための信号の1つとして読み取ります。Googleの現在の文書は、この反応の形を確認しています。5xxと429のレスポンスは、一時的なクロールレート低下を引き起こし（影響を受けるURL数に応じて調整されます）、失敗し続けるURLは最終的にインデックスから削除される可能性があります。一方、すでにインデックスにあるコンテンツは、正常な更新が行われるまで当面維持されます。 Evidence for this claim Google reduces crawling in response to 5xx errors and eventually removes persistently failing URLs from its index. Scope: Google documents the general 5xx progression; it does not provide a guaranteed retry or recovery timeline for an individual URL. Confidence: high · Verified: 2026-07-14 Google: How HTTP status codes affect Google's crawlers John Muellerは、Search Engine Journal経由で伝えられたGoogle SEO Office Hoursのセッションで、同じ段階を自分の言葉で説明しています。

“We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (翻訳)「その点について厳格な閾値はありません。ただ、基本的に500エラーが起きると、再試行します。それでも500エラーが続けば、クロールを遅くします。そして500エラーが続くようなら、そのURLをインデックスから外します。」

これは、固定された3段階のタイマーや、移行やタイミングが保証された流れではなく、文書化された挙動（再試行、クロール低下、削除の可能性）の説明として読んでください。Googleは、ある段階が次の段階に移る正確な閾値を公表していません。1つのURLで起きた単発の500は通常再試行され、次の取得が成功すれば通常は終わりです。ただしこれは一般的なケースの説明であり、単発の障害にコストがまったくないことの保証ではありません。文書化された本当のリスクは、エラーが解消しない場合にあります。

サイト全体のサーバーエラーが単発より悪い理由

サイトの大部分が一度にサーバーエラーを返すと、さらに厄介な動きが起きます。Googleの現在の文書は、クロールレートの低下が影響を受けるURL数に応じて大きくなることを確認しています。サイトの失敗範囲が広いほど、クロールは遅くなります。Muellerは、Google自身のクロールが過負荷の一因かもしれないとGoogleが疑う、という形で、その理由をより具体的に説明しています。

“But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (翻訳)「しかし、サイトの大部分で500エラーが継続し、もしかすると私たちが問題を引き起こしているのだと仮定すると、サイト全体のクロールを遅くします。そしてある時点で、これらのページは本当に消えたようだと言い、削除することになります。」

この「we assume we’re causing it」 (翻訳)「私たちが原因だと仮定する」という因果関係の説明は、Googleの現在の公式文書からの逐語的な表現ではなく、Mueller自身の特徴づけとして扱ってください。根底にある仕組み（失敗するURLが増えるほどクロールレートが下がる）は文書化されていますが、正確な因果関係は文書そのものより本人の発言で確認しやすいものです。いずれにしても、実務上のフィードバックループは理解しておく価値があります。リソース枯渇時の積極的なクロールが500を増やす → Googleがサイト全体のクロールを控える → それでもエラーが続けばページが削除される、という流れです。つまり500の問題は、常にコードのバグとは限りません。クローラーやトラフィックの急増時にだけ発生する同時負荷で、サーバーが耐えられなくなっている場合もあります。

どの程度が「多すぎる」のか

明確な線引きはありません。Google自身のトラブルシューティング文書は、エラー率の閾値をまったく公表していません。MuellerはSEO Office Hoursで、（公式のGoogle出版物ではなく、Search Engine Journal経由で伝えられたものですが）個人的な大まかな目安を示しています。

“My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (翻訳)「私の感覚では、1%を超える何かが見えているなら、何かが壊れているように思えます。」

~1%はMuellerに帰属する非公式の異常検知の目安であり、Googleが文書化または強制している上限ではありません。これ未満ならおそらく問題ありませんが、超えているなら調査する価値があります。ただし1%を超えたことを自動的なトリガーと見なさず、1%未満であることも保証と見なさないでください。Googleが公に約束している唯一の数字は、数字がないことです。「we don’t have any strong thresholds.」 (翻訳)「厳格な閾値はありません。」

500と503：重要な違い

ここは多くの人が間違えるところです。503 Service Unavailableは、クローラーに「一時的に停止しています。後で戻ってきて」と伝える公認の方法です。Googleは意図的な状態として扱い、猶予期間を設けます。Google自身のクロールに関するトラブルシューティング文書は明確です。

“Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (翻訳)「サーバーが過負荷のときは、Googlebotのリクエストに対して503または429のHTTPレスポンスステータスコードを一時的に返してください。GooglebotはこれらのURLを約2日間再試行します。なお、「利用不可」のコードを数日以上返すと、Googleはサイト上のURLのクロールを恒久的に遅くするか、停止します。」

対照的に、503は意図的で約2日間の再試行猶予があり、制御されていない500は意図的ではなく、そのような猶予がありません。Googleが諦めるまで再試行されるだけです。実務上の要点は、計画したメンテナンスや意図的な過負荷防御には、500や200のエラーページではなく、503（できればRetry-Afterヘッダー付き）を返すことです。本当の障害を200に見せてはいけません。

500を診断する方法

これを層ごとに進めます。アプリケーション／コード、プラットフォーム／CMS、インフラとリソース、設定の順に、費用が低く成功しやすいものから確認します。**（WordPress固有）**と記した手順は一般的なWordPressの実務であり、普遍的な修正ではありません。実際のスタックに合わせて調整してください。

1. サーバーのエラーログ。 error.log／access.log（またはプラットフォームのログビューアー）を確認します。失敗したリクエストと時刻を照合してください。実際のスタックトレース、PHPの致命的エラー、DB接続失敗はここに現れます。これを読むまでは、その後のすべてが推測です。
2. GSC — Server error (5xx)レポート。 Google Search ConsoleのPage Indexingレポートは、Google自身が500を確認しているURLに印を付けます。次にCrawl Statsを開き、時間の経過に沿った**「by response」**の内訳を読みます。これで一時的な障害と、継続的な可用性問題を区別できます。
3. Bing Webmaster Tools。 クロールエラーのアラートはServer Errors (5xx)をまとめ、具体的なURLとCrawl Informationツールを示します。
4. ブラウザーだけでなく、ボットとして再現します。 クロールによる負荷、ボット検出／ファイアウォールの設定ミス、同時ボットトラフィック時だけ問題になる容量制限などにより、あなたには正常に読み込めてもGooglebotにはサーバーエラーを返すページがあります。URL Inspection（GSC）、Fetch as Bingbot、またはボットのユーザーエージェントを付けたcurlで、ボットだけの失敗を見つけます。「ブラウザーでは動く」は問題がない証拠ではありません。
5. プラグイン／テーマ／モジュールの競合（WordPress固有のパターン。ほかでは適応）。 まずバックアップを取ります。無効化を始める前に、必ず戻せる手段を用意してください。その後、拡張機能を無効にし、1つずつ再有効化して原因を切り分けます。触れたもののファイル権限と所有者も確認してください。ホスティング事業者のWordPress向けトラブルシューティングガイドではこのパターンが頻繁に報告されていますが、どの環境でも最大の原因だという証拠ではありません。別のCMSやカスタムアプリでは、第三者モジュール、パッケージ、ミドルウェアの競合に相当します。
6. リソース枯渇。 PHPのメモリ上限、データベース接続数の上限、共有ホスティングの容量、トラフィックまたはクロールの急増です。ホスト側で確認できることがあります。
7. 設定と最近の変更。 壊れた.htaccess、誤ったサーバー設定の編集、最近のデプロイ、間違ったデータベース認証情報などです。まず調べる価値が高いのは最近の変更です。

修正方法（原因に合わせて修正する）

診断が示した層に合わせて修正します。次は実務家の解説で報告されている一般的なパターンであり、あなたのスタックで最も起こりやすいものを順位付けした普遍的な一覧ではありません。

• 設定／デプロイが原因 → 変更をロールバックし、.htaccess、設定、認証情報を修正します。
• リソース枯渇 → 上限（PHPメモリ、DB接続数）を引き上げるか、ホスティング層をアップグレードします。クロールが過負荷を引き起こしているなら、クロールレートの問題でもあります。
• プラグイン／モジュールの競合 → 原因の拡張機能を削除または置き換えます。
• コードのバグ → コードを修正し、不足しているエラーハンドリングを追加します。
• 原因が分からない → 正確な時刻とログ行を添えてホストにエスカレーションします。本番環境で推測しないでください。

再発を防ぐ

5xx率の監視とアラート、本番投入前のステージング、既知のトラフィック急増前の負荷テスト、そしてGooglebotのクロール自体がトリガーならクロール負荷の管理を行います。実際の過負荷時には、サーバーに制御不能なエラーを出させるのではなく、意図的に503／429を返します。

FAQ

500サーバーエラーはSEOに悪影響を与えますか？ 文書化されたリスクは、主に規模を伴う継続です。単発のエラーは通常再試行され、1回の一時的な障害に対する文書化されたペナルティはありません。サイト全体でエラーが続くとクロールが遅くなり、インデックス削除につながる可能性があります。

500のページがGoogleによってインデックスから外れるまでどのくらいかかりますか？ 固定された期間はありません。Googleはまず再試行してクロールを遅くします。インデックスから外れるのは、エラーが続いた場合だけです。修正すれば、クロールが再び成功した後、ページは通常戻ります。

サイトがGooglebotには500を返すのに、ブラウザーでは正常に読み込まれるのはなぜですか？ ボットだけに起きるエラーは通常、容量またはボット処理の問題を意味します。クロールによる負荷、ファイアウォール／ボットルール、同時ボットトラフィック時だけ問題になる上限などです。手動のブラウザーチェックではなく、ログを信頼してください。

サイトの大部分でエラーが起きると、影響を受けたページだけでなくサイト全体のクロールを遅くしますか？ はい。Googleの文書は、クロールレートの低下が失敗しているURL数に応じて大きくなることを確認しています。そのためサイトの大部分がエラーを返すと、サイト全体のクロールが遅くなります。Muellerはさらに、Google自身のクロールが過負荷の一因かもしれないとGoogleが疑う、という理由づけをしています。これは本人の特徴づけであり、現在の公式文書からの逐語的な表現ではありません。

WordPressで500が起きる原因は何ですか？ WordPressに限ると、ホスティング事業者とWordPressコミュニティは、プラグイン／テーマの競合、壊れた.htaccess、PHPメモリ上限への到達を最も頻繁に報告しています。これはそのプラットフォームで報告されている内容であり、あらゆるエラーの普遍的な主原因だという主張ではありません。上の診断順序（まずログ、次に変更点）はCMSに関係なく同じです。

500の後にリクエストを自動再試行しても安全ですか？ まずメソッドとリクエストの冪等性を確認した場合に限ります。ステータス自体は再試行ポリシーを許可しません。GET、HEAD、PUT、DELETEは冪等であるため、一般に再試行しても安全です（繰り返しても追加の副作用が起きないためです）。一方、APIが冪等性を明示的に保証していない限り、単独のPOSTは通常安全ではありません。冪等性キーなどがないまま盲目的に再試行すると、注文やメールの重複、決済の二重請求につながるおそれがあります。再試行する場合は、ジッター付き指数バックオフを使い、試行回数に上限を設け、苦戦中のサーバーに失敗の上に再試行の嵐を浴びせないよう再試行予算を設定します。

AI summary

Advanced版の要約です。

• 500 = RFC 9110の予期しない状態の境界。 これはステータスコード自体の範囲全体です。根本原因、期間、再試行の価値は示しません。診断ではなく症状なので、ブラウザーではなくサーバーログから根本原因を調べます。4xx（クライアント／リクエスト）エラーや、5xxの仲間である502／503／504とは区別されます。
• Googleの文書化された反応は段階的です。 一時的なクロールレート低下（影響を受けるURL数に応じて調整）と、失敗し続けるURLの最終的なインデックス削除の可能性があり、取得が再び成功すれば回復します。Muellerはこれを再試行 → クロール低下 → インデックスからの削除と説明しています。これは文書化された挙動の説明であり、固定された一連のタイマーではありません。単発の500は通常再試行されますが、コストがないとは約束されていません。本当の文書化されたリスクは規模を伴う継続です。
• サイト全体の500はより悪い状態です。 クロールレートの低下は失敗するURL数に応じて大きくなります。Muellerは、Google自身のクロールが過負荷の一因かもしれないとGoogleが疑うという理由づけをしています。これは公式文書の逐語的表現ではなく本人の特徴づけです。いずれにせよ、クロール負荷がさらに500を引き起こすフィードバックループになります。
• 閾値ではなく目安です。 Muellerは、~1%を超えるエラー率は「probably broken」 (翻訳)「おそらく壊れている」と述べていますが、これはSEO Office Hoursでの個人的な表現であり、Googleが文書化した上限ではありません。Googleは厳格な閾値はないとしています。
• 500と503。 503（または429）はGoogleの文書によると、約2日間の再試行猶予がある公認の「後で戻ってきて」という信号です。制御されていない500には猶予がありません。計画的な停止には（Retry-After付きの）503を使います。
• 層ごとの診断順序。 サーバーログ → GSCのサーバーエラー（5xx）＋クロール統計「応答別」 → Bingウェブマスターツール → ボットとして再現（URL検査／curl） → プラグイン／モジュールの競合（WordPress固有のパターン。他では適応し、最初にバックアップ） → リソース枯渇 → 設定／デプロイの変更。
• 再試行の安全性はステータスコードではなくリクエストに依存します。 冪等メソッド（GET／HEAD／PUT／DELETE）は一般に安全に再試行できます。冪等性キーのない単独のPOSTは通常安全ではありません。バックオフ、再試行上限、再試行予算を使います。
• 回復。 修正後は通常速く、クロールが再び成功すれば削除されたページも戻る傾向があります。ただしGoogleは期間も結果も保証していません。

公式ドキュメント

検索エンジンとHTTP仕様による一次資料のドキュメントです。

Google

• Google検索のクロールエラーをトラブルシュート — Googleがサーバーエラーをどう扱うか、また一時的な過負荷で503／429を公認の方法として使うことを説明しています。
• Google検索の仕組み：詳細ガイド — クロールスケジューラーと、5xxレスポンスが「slow down」 (翻訳)「速度を落とす」と解釈されることを説明しています。
• クロール統計レポート — 一時的な障害と継続的な問題を見分けるための「by response」内訳（Server error (5xx) を含む）です。
• Googlebotのクロールレートを下げる — サーバーに制御不能なエラーを出させるのではなく、意図的にクロールを遅くする正しい方法です。

Bing／Microsoft

• Bingウェブマスターツール — クロールエラーアラート一覧 — BingがServer Errors (5xx) をどうまとめ、影響を受けたURLをどこで確認するかを説明しています。

HTTP仕様／リファレンス

• MDN — 内部サーバーエラー — ステータスコード自体の定義です。
• RFC 9110 §15.6.1 — 500 Internal Server Error — 権威あるHTTP意味論です。

原文からの引用

記録に残る発言です。出典ページがJavaScriptでレンダリングされる場合や、二次報道を経由して伝えられた場合は、<small>の注意書きで示しています。

Google — 段階的な対応

• “We don’t have any strong thresholds on that. But essentially what happens with 500 errors is we’ll try to retry them. And if we continue to see …the 500 errors then we will …slow down crawling. And if we continue to see that there are 500 errors then we will drop those URLs from the index.” (翻訳)「その点について厳格な閾値はありません。ただ、基本的に500エラーが起きると、再試行します。それでも500エラーが続けば、クロールを遅くします。そして500エラーが続くようなら、そのURLをインデックスから外します。」 — John Mueller、Google。 報道記事を読む Google SEO Office Hours動画のSearch Engine Journalによる書き起こし経由で伝えられたものです。最終的な引用として扱う前に、元の動画で正確な文言を確認してください。
• “But if a large part of a site consistently has 500 errors and we might assume that maybe we’re causing the problem and we’ll slow down crawling of the whole site and at some point we’ll say well, it looks like these pages are really gone, we’re going to drop them.” (翻訳)「しかし、サイトの大部分で500エラーが継続し、もしかすると私たちが問題を引き起こしているのだと仮定すると、サイト全体のクロールを遅くします。そしてある時点で、これらのページは本当に消えたようだと言い、削除することになります。」 — John Mueller、Google。 報道記事を読む Search Engine Journal経由で伝えられたものです。元の動画と逐語的に照合してください。
• “My feeling is if you’re seeing something more than one percent then that sounds like something is kind of broken.” (翻訳)「私の感覚では、1%を超える何かが見えているなら、何かが壊れているように思えます。」 — John Mueller、Google。大まかなエラー率の目安についての発言です。 報道記事を読む Search Engine Journal経由で伝えられたものです。元の動画と逐語的に照合してください。

Google — 公認の「速度を落とす」信号（文書で確認済み）

• “Return 503 or 429 HTTP response status codes temporarily for Googlebot requests when your server is overloaded. Googlebot will retry these URLs for about 2 days. Note that returning ‘no availability’ codes for more than a few days will cause Google to permanently slow or stop crawling URLs on your site.” (翻訳)「サーバーが過負荷のときは、Googlebotのリクエストに対して503または429のHTTPレスポンスステータスコードを一時的に返してください。GooglebotはこれらのURLを約2日間再試行します。なお、「利用不可」のコードを数日以上返すと、Googleはサイト上のURLのクロールを恒久的に遅くするか、停止します。」 — Google Search Centralのドキュメント。 Jump to quote

Patrick Stox — 定義（Ahrefs、確認済み）

• “500 Internal Server Error – The server encounters some kind of issue and doesn’t have a better or more specific error code.” (翻訳)「500 Internal Server Error — サーバーは何らかの問題に遭遇し、より適切または具体的なエラーコードを持っていません。」 — Ahrefsブログの私のHTTPステータスコードガイド。 Jump to quote

500エラーのトリアージチェックリスト

サーバーエラーが現れたら、すぐに上から順に実行します。

• サーバーのエラーログを取得し、ブラウザーの「500」だけでなく、実際のエラー（スタックトレース／PHPの致命的エラー／DB障害）を見つけた。
• 最近何が変わったかを確認した。新しいプラグイン／テーマ／モジュール、最近のデプロイ、.htaccessまたはサーバー設定の編集、変更されたDB認証情報。
• **GSC → ページのインデックス登録 → サーバーエラー（5xx）**を開き、Googleが500を検出しているURLを確認した。
• 時間の経過に沿った**GSCクロール統計「応答別」**を読み、一時的か継続的かを判断した。
• 同じURLについてBingウェブマスターツールのクロールエラーアラートを確認した。
• ブラウザーだけでなく、ボットとして再現した（URL Inspection／Fetch as Bingbot／ボットのユーザーエージェント付きのcurl）。
• ホストとともにリソース枯渇（PHPメモリ、DB接続、ホスティング容量）を除外した。
• 1つずつ無効化と再有効化を行い、プラグイン／モジュールの競合を切り分けた。
• 計画的な停止中に制御不能なサーバーエラーを返していないことを確認した。その代わりに503（Retry-After付き）を使う。
• 修正後、エラー率が非公式の~1%の異常検知の目安（Muellerの目安であり、Googleの文書化された閾値ではありません）を下回り、GSCでクロールが再び成功していることを確認した。

ランブック：「サイトがサーバーエラーを返しています — 最初に何を確認すべきですか？」

慌てずに進める作業順です。原因を見つけて修正するまで、順番に実行します。

0. 範囲を確認する（2分）。 1つのURL、1つのテンプレート／セクション、それともサイト全体でしょうか。1つのURLなら影響は小さい（Googleが再試行します）ですが、サイト全体なら緊急事態です。Googleがサイト全体のクロールを遅くするのはこのパターンです。

1. サーバーのエラーログを読む。 まずerror.logを確認します。時刻を失敗と照合してください。探すのは本当の原因、つまりPHPの致命的エラー、DB接続失敗、セグメンテーション違反、メモリ不足による強制終了です。これを行うまでは、以下のすべてが推測です。

2.「何が変わったか」と照合する。 最近の変更で並べ替えます。最後のデプロイ、追加または更新したプラグイン／テーマ／モジュール、.htaccessの編集、DB認証情報のローテーション、設定の反映などです。サーバーエラーの多くは、数時間から数日前の変更にさかのぼれます。可能ならまずロールバックし、次に診断してください。サービスを戻せば時間を稼げます。

3. 検索エンジンから見た状態を確認する。 影響を受けたURLについてGSC → ページのインデックス登録 → サーバーエラー（5xx）を確認し、次にクロール統計 → 応答別で一時的な障害か継続的な障害かを見ます。Bingウェブマスターツールのクロールエラーアラートとも照合してください。これでSEO上の時間制限がどれほど切迫しているかが分かります。

4. ボットが見る方法で再現する。 人間には正常に表示されてもGooglebotがサーバーエラーを返すなら、ボットとしてテストします。URL Inspection、Fetch as Bingbot、またはcurl -A "Googlebot" <url>を使います。ボットだけのエラーは、容量、ファイアウォール／ボットルール、クロールによる負荷を示します。コードのバグとは別の修正が必要です。

5. よくある原因を二分探索する。

• プラグイン／モジュール: すべて無効にし、再び壊れるまで1つずつ有効化します。
• リソース: ホストとともにPHPメモリ上限、DB接続数の上限、ホスティング容量を確認します。特にトラフィックまたはクロールの急増時にサーバーエラーが集中する場合です。
• 設定: .htaccess／サーバー設定を、正常であることが分かっているバージョンに戻します。

6. クロールがトリガーなら、ただ受け入れない。 Googlebot自身のクロール量が過負荷を起こしている場合、正しい一時的な手段は**503／429**（Retry-After付き）を返すことです。サーバーに制御不能な500を出させてはいけません。Googleは503を「come back later」 (翻訳)「後で戻ってきて」という信号として約2日間尊重しますが、500にはそのような猶予がありません。

7. 回復を確認する。 エラー率が非公式の~1%の異常検知の目安を下回り、ログが正常で、GSC Crawl Statsに再び取得成功が表示されていることを確認します。削除されたページはクロールが成功すれば通常戻ります。期間は保証されませんが、通常は速やかです。

覚えておくべき段階的な対応: 単発の500 → 通常は再試行され、文書化されたリスクは小さい → 継続する500 → クロールが遅くなる → それでも継続 → URLがインデックスから外れる。Googleはこれらの移行の正確な時期を公表していません。そこまで進む前に連鎖を断つのが仕事です。

どのサーバーコードを返すべきか

何を返すかを決めるとき、または表示されている状態を解釈するときに使ってください。

障害は意図的ですか（メンテナンス／意図的な過負荷防御）？

• はい →Retry-Afterヘッダー付きで**503 Service Unavailable**を返します。Googleは一時的な状態として扱い、約2日間再試行します。200のエラーページを返してはならず、500にフォールスルーさせてもいけません。
• **いいえ（実際の予期しない障害です）→**続行します。

全員がエラーになりますか、それともクローラーだけですか？

• **全員 →**コード／設定／DBの問題です。サーバーのエラーログと「何が変わったか」の一覧を確認します。最近の変更をロールバックしてください。
• **Googlebot／Bingbotだけ →**容量、ボット検出／ファイアウォールルール、クロールによる負荷を疑います。ボットとして再現し、サーバーリソースとボットルールを確認します。

1つのURLですか、それともサイトの大部分ですか？

• **1つのURL／単発 →**緊急性は低いです。Googleは再試行するため、時間をかけて修正できますが、本当に孤立した事象であることを確認してください。
• **サイト全体／継続 →**緊急事態です。Googleがサイト全体のクロールを遅くし、最終的にインデックスから外すのはこのパターンです。まずサービスを復旧（ロールバック）し、次に根本原因を調べます。

エラー率は~1%を超えていますか？

• **はい →**実際の問題である可能性が高いので調査する価値があります。これはMueller自身の非公式な目安であり、Googleが文書化した閾値ではありません。
• **いいえ →**おそらく問題ありません。ただし、その時点の値だけでなく傾向を監視し続けてください。

プロンプト：500をログとデプロイに関連付ける

Diagnose this HTTP 500 incident from the sanitized evidence I provide. Build a
timeline across deployment events, request IDs, access logs, application errors,
resource signals, and affected URL patterns. Rank likely causes by evidence, separate
the fastest service-restoration action from the root-cause fix, and give exact
validation and rollback checks. Do not invent missing stack traces or thresholds.

[PASTE TIMELINE, HEADERS, LOGS, AND RECENT CHANGES]

プロンプト：スタックトレースを安全なテスト計画に変換する

Explain this stack trace in plain language, identify the failing component and its
inputs, and propose the smallest reversible test that distinguishes code, dependency,
configuration, and resource-exhaustion causes. Include what evidence would falsify
each hypothesis and how to confirm the URL returns a stable non-5xx response afterward.
Redact secrets and do not suggest exposing debug output publicly.

[PASTE SANITIZED STACK TRACE]

Shell：URLリストを5xxレスポンスのサンプルとして確認する

urls.txtに1行1件の絶対URLを入れて実行します。

while IFS= read -r url; do
  curl -sS -o /dev/null -w '%{http_code},%{time_total},%{url_effective}\n' "$url"
done < urls.txt

出力は、広範な障害から孤立したルートを分け、レスポンス本文をダウンロードせずにレイテンシーを記録します。

PowerShell：同じステータスサンプルを書き出す

Get-Content .\urls.txt | ForEach-Object {
  $r = Invoke-WebRequest -Uri $_ -SkipHttpErrorCheck
  [PSCustomObject]@{ Status = $r.StatusCode; Url = $_ }
} | Export-Csv .\status-sample.csv -NoTypeInformation

Shell：アクセスログの5xxステータスを数える

結果を信頼する前に、ステータスフィールドの位置を文書化したログ形式に合わせて調整してください。

awk '$9 ~ /^5[0-9][0-9]$/ { count[$9]++ } END { for (code in count) print code, count[code] }' access.log

サーバーエラーを見つけて診断するツール

• サーバーのエラーログ — error.log／access.log、またはホスト／プラットフォームのログビューアー。最も重要な単一のツールであり、本当の原因はここにあります。
• Google Search Console — ページのインデックス登録 —「サーバーエラー（5xx）」セクションに、Googleが500を確認しているURLが一覧表示されます。
• GSC — クロール統計レポート — 時間経過に沿った「応答別」の内訳で、一時的な障害と継続的な可用性問題を分けられます。
• GSC — URL検査 — Googleとして1つのURLを取得し、ボットだけに起きる500を再現します。
• Bingウェブマスターツール — クロールエラーアラートがサーバーエラー（5xx）をまとめ、クロール情報ツールを示します。
• curl — 任意のユーザーエージェントで再現します。curl -I -A "Googlebot" <url>を使うと、ボットが見た場合のステータスコードを確認できます。
• クローラー／サイト監査 — Ahrefs監査とScreaming Frog SEO Spiderがサイト全体の5xxレスポンスを示し、パターン（テンプレートまたはセクション全体の失敗）を見つけられます。
• 稼働時間／ステータス監視 — 5xx率をアラートし、Googleが気付く前に急増を知るためのものです。

時間をかける価値のあるリソース

私の関連する記事

• HTTP Status Codes: A Guide to How They Impact SEO & UX — 500の定義と、5xxクロールに関する広い枠組みを含む、私のステータスコード完全リファレンスです。
• テクニカルSEO入門ガイド — サーバーエラーがより大きな技術的全体像のどこに位置するかを説明します。

私の講演

• How Search Works （SlideShare）— クロールと、サーバーの健全性がどのようにクロールへフィードバックされるかについての私の解説です。（定型の免責事項が適用されます。「This is my understanding of systems… not going to be 100% complete or accurate.」 (翻訳)「これはシステムについての私の理解であり、100%完全または正確とは限りません。」）

業界からの情報

• 500エラーコードがインデックスに悪影響を与える理由 （検索エンジン・ジャーナル）— Matt G. Southernによる記事で、John Muellerの再試行 → クロール低下 → インデックスからの削除という引用と、~1%の目安を扱っています。
• Google Search Consoleの「サーバーエラー（5xx）」を修正する方法 （検索エンジン・ランド）— GSCレポートを段階的に確認する手順です。
• Google Search Consoleの「サーバーエラー（5xx）」を直す方法 （Onely）— 5xxエラーとは何か、GSCのどこで見つけるか、修正の道筋を説明します。
• サイトの500内部サーバーエラーを直す方法 （Kinsta）— サーバーログ、プラグイン／テーマ、PHPメモリ、.htaccess、権限を扱う、WordPressホスティング中心の詳細な修正リストです。
• 5xxサーバーエラー：問題を見つけて直すガイド （Lumar）— ログファイルとクロールバジェットに強い、エンタープライズ／技術監査の観点です。
• Google Search Consoleの5xxサーバーエラーを直す方法 （Sitechecker）— GSCレポートを扱う別の解説です。

動画

• Google Search Central（YouTube）— SEO Office Hoursのアーカイブです。John Muellerのサーバーエラーとクロールに関する指針（上で引用した再試行 → クロール低下 → インデックスからの削除という枠組み）の出典です。 Channel

自分で確認する：500 Internal Server Error

500とは何か、SEOにどう影響するかについての簡単な5問です。それぞれ回答を選んでから、答えを確認してください。

変更履歴