「500 Internal Server Error」の完全ガイド｜原因の特定と最短復旧フロー

Webサイトを運用している最中、あるいは特に何も変更していないのに突然「500 Internal Server Error（内部サーバーエラー / HTTP status 500）」が発生して画面が表示されなくなってしまった――そんな緊急トラブルに直面していませんか？

500 Internal Server Errorは、Webサーバー内部で致命的なエラーが発生し、正常にページを生成・表示できなかったことを通知するHTTPステータスコードです。主な原因には、.htaccessの文法エラー、PHPプログラムの文法ミスやFatal Error、メモリ上限（memory_limit）の超過、プラグインやテーマの競合、パーミッション設定の誤りなどが挙げられます。

サイトが落ちている状態を放置すると、ユーザーの離脱やコンバージョン機会の損失はもちろん、Googleのインデックス削除や検索順位の大幅な下落といった深刻なSEOリスクを招きます。そのため、パニックにならず最短ルートで原因を切り分け、迅速に復旧させることが不可欠です。

本記事では、いま画面の前で焦っている読者が最短でサイトを復旧できるよう、3分で原因を特定できるクイック診断テーブルから、主要な5大原因別の解決手順、主要レンタルサーバー別のログ確認方法、そしてサイト閲覧者向けの対処法までを分かりやすく解説します。

【3分でわかる】500エラー原因特定クイック診断テーブル

500エラー発生時に最も重要なのは「直前にどのような操作を行ったか」です。以下の診断テーブルから、ご自身の現在の状況に最も当てはまる項目を確認し、記載のアクションを優先的に実行してください。

500 Internal Server Error（内部サーバーエラー）とは？意味とSEOへの影響

トラブルシューティングに入る前に、HTTP 500エラーの技術的な本質と、なぜ一刻も早い復旧が求められるのか、そのSEOリスクについて整理しておきましょう。

1. HTTP 500ステータスコードの基本定義とサーバー側エラーの本質

500 Internal Server Error（内部サーバーエラー）とは、クライアント（Webブラウザや検索エンジンのクローラー）からのリクエストに対して、Webサーバー内部で予期せぬ障害が発生し、正常なレスポンス（HTML等）を返せなかったことを示すHTTPステータスコードです。

HTTPステータスコードは100番台から500番台まで分類されており、400番台（404 Not Found、403 Forbiddenなど）が「クライアント側のリクエストミス」を示すのに対し、500番台は「完全にサーバー側のプログラムや設定に問題がある」ことを意味します。

500エラーの最大の特徴は、サーバー側が「何らかの致命的なトラブルが起きたが、具体的な詳細をブラウザに返せない」状態であることです。セキュリティ上の理由から外部の訪問者にはエラーの詳細が表示されない設計になっているため、運営者側でサーバー内部のログや設定ファイルを確認して原因を突き止める必要があります。

2. 放置するとGoogleのインデックス削除・検索順位暴落を招くSEOリスク

500エラーを軽視して放置することは、サイト運営において最も危険な行為の1つです。訪問者がコンテンツを閲覧できないという機会損失に留まらず、検索エンジンからの評価に壊滅的なダメージを与えるリスクがあります。

短時間（数分から数時間程度）の一時的な障害であれば、Googlebotも再試行を行うため深刻なペナルティには至りません。しかし、時間が経つほど検索エンジンからの信用失墜につながるため、発生を確認した時点で迅速な原因特定と復旧作業を行うことが求められます。

【今すぐ試す】500エラー発生時の最短原因切り分けフローチャート

500エラーに直面した際、やみくもにファイルを編集したりサーバー設定を変更したりすると、問題が複雑化して復旧が困難になります。以下の2段階の切り分けを行い、障害の範囲とトリガーを正確に特定しましょう。

1. サイト全体が落ちているか特定ページのみかを確認

まず最初に行うべきは、エラーが発生している「範囲（スコープ）」の確認です。

• トップページのみ落ちている場合：トップページ専用のテンプレートファイル（front-page.php や home.php）の構文エラーや、メインクエリのループ処理に不備がある可能性が高いです。
• 特定記事・固定ページのみ落ちている場合：その記事内で呼び出している特定のショートコード、カスタムフィールド出力処理、または特定の埋め込みブロックに原因があります。
• 管理画面（/wp-admin/）も含めてサイト全体が落ちている場合：.htaccess の文法エラー、wp-config.php の構文ミス、または共通で読み込まれるプラグインや必須ファイルのFatal Errorが考えられます。
• フロントエンドは落ちているが管理画面にはログインできる場合：有効化されているアクティブテーマ（functions.php 等）に不具合がある可能性が高く、管理画面からテーマの切り替えやプラグイン停止を安全に実施できます。

2. 直前に実施した変更作業（ファイル編集・更新・設定変更）の洗い出し

Webサイトに不具合が発生する場合、その9割以上は「直前の何らかの変更」が直接の引き金となっています。直前の行動を冷静に振り返りましょう。

500エラーを引き起こす主要な5大原因と具体的解決手順

500 Internal Server Errorが発生する原因の大部分は、以下の5つのパターンに集約されます。それぞれの特徴と具体的な修復・解決手順を詳しく解説します。

原因1: .htaccess（設定ファイル）の構文ミス・記述エラー（初期化・リネーム手順）

「500エラーの原因」として最も頻繁に遭遇するのが、Webサーバー（ApacheやLiteSpeedなど）の制御ファイルである.htaccessの構文エラー（Syntax Error）です。Webサーバーは.htaccessに1文字でも文法ミスや無効なディレクティブがあると、サーバークラッシュを防ぐために即座にアクセスを遮断し、500エラーを返します。

【よくあるミスの例】

• コードのコピペ時に行頭や末尾に全角スペースが混入している
• mod_rewrite や mod_headers などのモジュールが読み込まれていない環境で、<IfModule> で囲まずにディレクティブを直接記述した
• リダイレクト記述の誤りによるリダイレクトループ（無限ループ）の発生
• 非対応の Options 指定やパーミッション不整合

【復旧手順：.htaccessのリネームと標準コードでの初期化】

1. FTPソフト（FileZilla等）またはレンタルサーバーのファイルマネージャーで、サイトのルートディレクトリ（public_html や ドメイン名直下のディレクトリ）にアクセスします。
2. ルートディレクトリにある .htaccess を見つけ、ファイル名を .htaccess_backup などにリネームします。
3. ブラウザでサイトを再読み込みします。これでエラーが解消されれば、原因は間違いなく .htaccess にあります。
4. 新しく空の .htaccess ファイルを作成し、以下のWordPress標準コードを記述して保存します。

# BEGIN WordPress
# "BEGIN WordPress" から "END WordPress" までのディレクティブは動的に生成されます。
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

標準コードでサイトが復旧した後は、管理画面の「設定」＞「パーマリンク」を開き、何も変更せずに「変更を保存」をクリックすることで、正規のリライトルールが安全に再生成されます。

原因2: PHPのメモリ上限（memory_limit）超過（wp-config.php / php.ini 編集手順）

記事の投稿時、高解像度画像のアップロード時、または高機能なプラグイン（ページビルダーやバックアップツールなど）を動作させた際に突然500エラーが発生する場合、PHPのメモリ上限（memory_limit）の枯渇が疑われます。

サーバー内部で割り当てられたメモリ許容量を超えてスクリプトを実行しようとすると、Allowed memory size of ... bytes exhausted という致命的エラーが発生し、処理が強制終了されます。

【解決手順：メモリ上限の引き上げ】

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

原因3: PHPプログラムの文法エラー・Fatal Error（debug.log有効化とログ特定）

テーマの functions.php やプラグインファイル内に文法ミス（Parse error）や致命的なエラー（Fatal Error: Call to undefined function、TypeErrorなど）があると、PHPの処理が途中で中断して500エラーを招きます。画面上が真っ白で何も表示されない場合は、WordPressのデバッグモード（debug.log）を有効化して原因を特定します。

【デバッグログの有効化設定】

サーバー上の wp-config.php を開き、デバッグ設定を以下のように記述します（画面上にエラーを出さず、ログファイルだけに安全に出力する設定です）。

/**
 * WordPress 安全デバッグ設定（画面非表示・ログ保存）
 */
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

保存後、エラーが発生しているページを再読み込みすると、/wp-content/debug.log にエラーログが記録されます。ログの末尾を確認し、エラーを引き起こしている「ファイル名」と「行番号」を特定してください。

• Parse error: syntax error… の場合：直前に編集したファイルの指定行を確認し、全角スペースの混入、セミコロン抜け（;）、カッコの閉じ忘れを修正します。
• Fatal error: Call to undefined function… の場合：存在しない関数を呼び出しています。古いプラグインの停止、または function_exists() によるガード処理を追加します。

原因4: プラグイン・テーマの競合・互換性トラブル（二分探索による原因プラグイン特定）

複数のプラグイン間での関数名重複や、テーマとプラグインの競合、サーバーのPHPバージョンとの互換性不足によって500エラーが発生するケースです。プラグインが多数ある場合、1つずつ検証するのは時間がかかるため、エンジニアも実践する「二分探索法（バイナリサーチ）」で最短特定します。

原因5: ファイル・ディレクトリのパーミッション（アクセス権限）設定の誤り（755/644への修正）

サーバー上のファイルやフォルダに対するアクセス権限（パーミッション）が不適切だと、Webサーバーがスクリプトを実行できず500エラーとなります。特にセキュリティ強化を目的に権限を厳しくしすぎたり、逆に誤って 777（全権限付与）に設定した場合に発生します。

近年の多くのレンタルサーバー（suPHPやCGIモード稼働環境）では、セキュリティ保護の仕組みにより 777 パーミッションが設定されているファイル・ディレクトリへのアクセスを自動的に500エラーとして遮断します。

パーミッションの修正は、FTPソフト（FileZilla等）の右クリックメニュー「パーミッションの変更」から、ディレクトリとファイルを一括で適切な数値（755 / 644）に適用することで完了します。

【主要レンタルサーバー別】エラーログの確認手順と.htaccessの復元方法

500エラーの真因を把握するには、Webサーバー自身が出力している「エラーログ（error.log）」を確認するのが確実です。主要レンタルサーバー各社の管理パネルにおけるログ確認手順と .htaccess 復元方法をまとめました。

1. エックスサーバー（Xserver）でのerror.log確認と.htaccess編集

エックスサーバーでは、サーバーパネルからワンクリックでエラーログを確認できます。

1. 「サーバーパネル」にログインします。
2. 「アクセス管理」カテゴリの「エラーログ」をクリックします。
3. 対象ドメインを選択し、「ダウンロード」または画面上でのログ確認を行います。
4. ログ内に .htaccess: Invalid command... や PHP Fatal error... の記述がないか確認します。
5. .htaccess を修正する場合は、「ホームページ」カテゴリの「.htaccess設定」から直接編集・復元できます。

2. ConoHa WINGでのエラーログ確認とWAF除外設定

ConoHa WINGでは、管理画面の「ログ」機能からWebサーバーおよびPHPのエラーを確認できます。

1. ConoHa WINGコントロールパネルにログインします。
2. 「サイト管理」＞「サイトセキュリティ」＞「ログ」タブを選択します。
3. エラーログをダウンロードして詳細を確認します。
4. 【WAFの確認】：管理画面や特定のプラグイン設定保存時に500エラーまたは403エラーが出る場合、「サイトセキュリティ」＞「WAF」タブを確認してください。誤検知されてブロックされたログが表示されている場合は、該当の攻撃検知シグネチャを「除外」することで即座に復旧します。

3. さくらインターネット・ロリポップでのエラーログ確認手順

さくらインターネットおよびロリポップ！での確認手順は以下の通りです。

• さくらインターネット：「サーバーコントロールパネル」にログイン後、左メニュー「アクセスログ閲覧」＞「エラーログ」を開きます。テキストエディタで開いて直近のFatal Errorやパーミッションエラー（Permission denied）を確認します。
• ロリポップ！：「ユーザー専用ページ」にログインし、「サーバーの管理・設定」＞「ログの表示」を選択します。WEBサーバーのエラーログを抽出表示して原因行を特定します。

サイト閲覧者（一般ユーザー）側で500エラーが表示された場合の対処法

ここまではサイト運営者向けの対処法を解説してきましたが、「他人のWebサイトを見ようとしたら500 Internal Server Errorが表示された」という一般ユーザー・閲覧者側の場合、クライアント側でできる対応は限られています。しかし、ブラウザのキャッシュや一時的な通信不良が影響していることもあるため、以下の手順を試してみてください。

1. スーパーリロード（キャッシュクリア）の実行

ブラウザに残っている古いキャッシュデータとサーバーの応答不整合が原因でエラー画面が表示され続けている場合があります。通常の再読み込みではなく、キャッシュを完全に無視して最新データをサーバーから再取得する「スーパーリロード」を実行しましょう。

2. 時間を置いての再アクセスとサイト運営者への問い合わせ

スーパーリロードを行ってもエラーが解消しない場合、原因は完全にサイト側のサーバー内部にあります。テレビ放映やSNSでの拡散による一時的なアクセス集中（サーバー過負荷）、またはサイト管理者がメンテナンス・プログラム更新中である可能性が極めて高いです。

• 数十分から数時間待機する：サーバーの一時的な過負荷やメンテナンスであれば、時間を置くことで自然復旧します。
• 公式SNS等を確認する：サイト運営者の公式X（旧Twitter）などで障害告知やメンテナンス情報が出ていないか確認します。
• 問い合わせ窓口へ連絡：緊急を要する手続き等の場合、別のお問い合わせフォームや公式窓口から「500エラーが発生してアクセスできない」旨を伝えて復旧を待ちましょう。

500エラーの再発を防ぐための予防策と運用ベストプラクティス

500エラーからサイトが復旧した後は、同様のトラブルを二度と発生させないための予防の仕組みづくりが不可欠です。安定したサイト運用を実現するための3つのベストプラクティスを紹介します。

1. 本番反映前のテスト環境（ステージング環境）での動作検証

プラグインの更新、テーマの改修、サーバーのPHPバージョン変更などをいきなり本番環境で行うのは極めて危険です。レンタルサーバーの「ステージング機能（テスト環境複製）」やローカル開発環境（Local by Flywheel等）を活用し、本番と同一環境のテストサイトで事前にエラーが出ないことを確認してから本番反映する運用を徹底しましょう。

2. 定期的な自動バックアップ体制の確立

万が一予期せぬエラーでサイトが落ちて原因特定に時間がかかったとしても、直前の健全な状態に戻せるバックアップがあれば数分でサイトを復旧できます。レンタルサーバーの自動バックアップ機能の活用に加え、プラグイン（UpdraftPlus等）を用いてファイルとデータベースをクラウドストレージへ日次バックアップする体制を整えておきましょう。

3. 無料診断ツール「MozCheck」によるサイト健全性と設定の定期点検

サイトの設定不備や古いプラグインの放置は、500エラーの直接原因となるだけでなく、重大なセキュリティインシデントにもつながります。当サイトが提供する「MozCheck」では、URLを入力するだけでサイトの健全性やセキュリティ設定状態を無料で定期点検できます。

まとめ：焦らずログと直前の変更履歴を確認して最短復旧を目指そう

500 Internal Server Error（HTTP status 500）は、画面が突然真っ白になるためパニックになりがちですが、「直前の操作の振り返り」「.htaccess のリセット」「デバッグログの確認」「二分探索法によるプラグイン特定」という論理的な手順を踏むことで、必ず原因を特定して解決できます。

📚 あわせて読みたい関連記事

Webサイトのトラブルシューティングやセキュリティ強化に役立つ関連記事です。安定したサイト運用にお役立てください。

• 【WordPress】Nonce（ノンス）の使い方とCSRF対策完全ガイド｜フォーム・Ajax・REST APIの実装コード集
• 【PHPセキュリティ】unserialize()の脆弱性とオブジェクトインジェクション対策｜安全な代替コード解説
• 初心者向け！WordPressのバックアップと復元の基本ステップと注意点
• 放置していたWordPressは安全？標準機能の自動更新と安全性の仕組み
• あれ、サイトの見た目が変…？WordPressの「表示が崩れた！」ときの原因と対処法
• WordPressの定期更新チェックリスト｜放置リスクを防ぐ5つの習慣