【最短3分復旧】WordPressの500 Internal Server Error完全ガイド｜原因特定と即時チェックリスト

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

500 Internal Server Error（HTTP status 500）は、Webサーバー側でプログラムの異常停止や設定不備など“想定外の致命的なエラー”が起きたことを示すHTTPステータスコードです。WordPressで「500エラー 突然」と検索してトラブルに見舞われる主な原因には、.htaccessの文法エラー、PHPメモリ上限（memory_limit）の超過、プラグインやテーマの競合・PHPバージョン非互換などが挙げられます。

サイトが非表示になっている間はユーザーの離脱や売上機会の損失だけでなく、長引くと検索順位の下落やSEO評価への悪影響に直結するため、最短ルートで原因を絞り込み、即座に復旧させることが何よりも重要です。

本記事では、いま画面の前で焦っている読者が最短3分でサイトを復旧できるよう、ファーストビュー直下の「即時チェックフロー」をはじめ、.htaccessの再生成、wp-config.phpでの安全なデバッグモード（WP_DEBUG）有効化、PHPメモリ制限の引き上げ手順まで、コピペで使えるコードとチェックリスト付きで徹底解説します。

---

【最優先】突然の500エラーを最短3分で復旧する即時チェックフロー

WordPressで「500エラー 突然」が発生した場合、原因の8割以上は「.htaccess」「プラグイン」「PHPメモリ上限」の3点に集約されます。管理画面（ダッシュボード）にアクセスできない状態でも、サーバーのファイルマネージャーやFTP経由で以下の即時切り分けフローを上から順に試すことで、素早く表示を復旧できます。

即時チェックリスト（コピペで確認）

復旧作業に入る前に、以下のチェックリストを順に確認してください。

• 直前の操作を振り返る：プラグイン更新、テーマのfunctions.php編集、サーバーのPHPバージョン変更、.htaccessの編集などを行っていませんか？
• 全ページで発生しているか確認：トップページだけか、管理画面（/wp-admin/）も入れないか、特定記事のみかを確認します。
• ブラウザキャッシュをクリア：Ctrl+Shift+R（MacはCmd+Shift+R）やシークレットウィンドウで実際のHTTP応答を確認します。
• バックアップの確保：可能であればFTPで .htaccess や wp-config.php をローカルにダウンロード退避しておきます。

---

【3分でわかる】500エラーの原因と最短復旧早見表

「500 Internal Server Error」が発生する主なシチュエーションと、考えられる根本原因、最短の復旧アクションを一覧表にまとめました。直前の操作や発生状況に合致する行を確認してください。

症状・発生タイミング	考えられる主な原因	緊急度・難易度	最短の復旧・確認アクション
プラグイン/テーマ更新・有効化の直後	プラグイン・テーマの競合、致命的PHPエラー（Fatal Error）、構文ミス	【高】★☆☆	FTPでwp-content/pluginsフォルダ名を一時変更（またはWP-CLIで全停止）して復旧
.htaccess編集後やパーマリンク更新後	.htaccessの文法エラー、不正なリダイレクトループ、記述漏れ	【高】★☆☆	FTPで.htaccessをバックアップの上、WordPress標準の記述に初期化
特定ページアクセス時や画像アップロード時	PHPのメモリ上限（memory_limit）超過、実行タイムアウト	【中】★★☆	wp-config.phpにdefine('WP_MEMORY_LIMIT', '256M');を追記して上限解放
ファイルアップロード時や特定フォルダのみ500	ファイル・ディレクトリのパーミッション（権限・所有者）不正	【中】★★☆	FTP・SSHでフォルダを755、ファイルを644に一括修正
サーバー移行後やPHPバージョン変更直後	PHPバージョンの非互換、必須PHP拡張モジュールの不足、パスの不整合	【高】★★☆	サーバー管理画面で直前のPHPバージョンへ切り戻し、エラーログを調査
何もしないのに突然サイト全体が500エラー	Webサーバー（Apache/Nginx）の過負荷、DB接続上限、ホスティング障害	【高】★★★	サーバー管理画面の障害・稼働状況を確認し、WP_DEBUG_LOGやサーバーログを調査

500 Internal Server Error（HTTP status 500）とは？

500 Internal Server Error（HTTP status 500 / 内部サーバーエラー）は、Webサーバーがリクエストを受け取ったものの、サーバー内部で予期せぬ障害やプログラムのエラーが発生し、処理を正常に完了できなかったことをクライアント（ブラウザ）へ通知するHTTPステータスコードです。

404 Not Found（ページが存在しない）や403 Forbidden（アクセス権限がない）などの「4xx系エラー（クライアント起因）」とは異なり、HTTP status 500などの500番台（5xx系）は100%サーバー側の問題となります。そのため、閲覧者側でブラウザを再読み込みしても根本解決することは稀で、サイト管理者・サーバー管理者による修正対応が不可欠です。

他の5xxエラー（502 / 503 / 504）との違い

HTTPステータスコードの500番台には複数の種類があり、それぞれ原因の所在が異なります。

ステータスコード	正式名称	意味と主な発生要因
500	Internal Server Error	サーバー内部の汎用エラー（PHPの致命的エラー、.htaccess文法違反、メモリ不足など）
502	Bad Gateway	ゲートウェイやリバースプロキシ（Nginx/Cloudflare等）が上流サーバー（PHP-FPM/Apache等）から不正な応答を受信
503	Service Unavailable	アクセス集中による一時的なサーバー過負荷、または意図的なメンテナンス中
504	Gateway Timeout	プロキシ・CDNが上流サーバーからの応答を待つ間にタイムアウト（重いDB処理・スクリプト停止）

重要ポイント：HTTP status 500は「サーバー内部で何らかの処理が異常終了した」という大枠の通知に過ぎません。具体的なエラーメッセージ（Fatal errorなのか、構文ミスなのか、メモリ超過なのか）は画面上に隠されていることが多いため、ログの確認と設定ファイルの切り分けが最短復旧の鍵となります。

なぜ「何もしないのに500エラーが突然」起きるのか？

サイト管理者が何も編集・更新していないにもかかわらず、「500エラー 突然」が発生する主な背景には以下の要因があります。

• プラグイン・テーマ・コアの自動バックグラウンド更新：深夜やバックグラウンドで自動更新が走り、他プラグインやPHPバージョンとの間で致命的競合（Fatal Error）が発生した。
• WordPressの定期実行タスク（WP-Cron）によるメモリ上限超過：予約投稿やバックアッププラグイン、データベース自動最適化タスクが起動した瞬間にmemory_limitを突破した。
• レンタルサーバー側の仕様変更やPHPバージョン強制移行：サーバー会社側でのPHPバージョンアップやセキュリティモジュール（WAF/mod_security）の適用により、既存の.htaccessやテーマ構文がエラーになった。
• データベースの肥大化・接続数（max_connections）の上限到達：アクセス急増時やセッションテーブル等の肥大化によってDB応答が停止した。

---

まず取るべき行動（立場別の初動対応）

500 Internal Server Errorに直面した際、あなたがどの立場（一般閲覧者／サイト運営者／開発・インフラ担当）にいるかによって取るべき初動が異なります。

【閲覧者】一般ユーザーとしてできること

• ページの再読み込み（ハード再読み込み）：一時的な通信不整合の可能性があるため、Ctrl+F5（Mac: Cmd+Shift+R）でキャッシュを無視して再読込します。
• 時間を置いてアクセスする：サーバーの一時的な過負荷やメンテナンスが原因の場合、数分〜数十分待つと復旧することがあります。
• サイト運営者へ報告する：復旧しない場合は、SNSや問い合わせフォーム（別ドメインの場合）等でエラーの発生URLとスクリーンショットを伝えると迅速な解決につながります。

【運営者】サイト管理・広報担当の初動

• サーバー障害情報の確認：利用しているホスティングサービス（エックスサーバー、さくら、AWS等）で大規模障害や緊急メンテナンスが起きていないか確認します。
• 発生範囲と影響規模の把握：サイト全体が落ちているのか、特定の記事・フォーム送信時・ログイン画面（/wp-login.php）だけなのかを調査します。
• ユーザーへの一次告知（必要時）：ECサイトや主要メディアの場合、SNS公式アカウント等で「現在システム不具合が発生しており緊急調査中」である旨を一次発信し、二次被害を抑制します。

【開発・サーバ担当】技術的な最短ルート

1. 実HTTPステータスの確認：curl -I https://example.com/ を実行し、正確なステータスコード（HTTP status 500 / 502 / 503 / 504）とレスポンスヘッダーを取得します。
2. CDN／プロキシの切り分け：CloudflareやCloudFront等を経由している場合、CDN側のエラー画面か、オリジンサーバーが返した500かを判定します。
3. ログの即時確認と切り分け：後述の「原因別の具体的復旧手順」に従い、エラーログから原因行を特定して修正します。

---

WordPressで500エラーが出たときの原因別・具体的復旧手順

ここからは、WordPressで500 Internal Server Errorが発生した際の最も確実な復旧手順を原因別にステップ・バイ・ステップで解説します。管理画面に入れない場合でも、FTPクライアント（FileZilla等）やサーバー管理画面のファイルマネージャー、SSH/WP-CLIがあればすべて実施可能です。

【手順1】.htaccess の再生成と文法エラー修復

WordPressにおける500エラーの最多原因の1つが、サーバーのルートディレクトリにある .htaccess ファイルの記述ミスや文法エラー（Syntax Error）です。
セキュリティプラグインやキャッシュプラグインの導入・削除時、またはリダイレクト設定を手動で追記した際に不正なディレクティブが含まれると、Webサーバー（Apache/LiteSpeed）は即座に500エラーを返します。

【復旧ステップ】

1. FTPまたはファイルマネージャーで接続：WordPressをインストールしたルートディレクトリ（wp-config.php がある階層）を開きます。
2. .htaccess をリネーム退避：.htaccess を .htaccess_backup などの名前に変更します（隠しファイル表示をONにしてください）。
3. ブラウザでサイトを再読み込み：この時点でトップページが表示されれば、原因は .htaccess の記述にありました。
4. 標準の .htaccess を新規作成：新規に空の .htaccess ファイルを作成し、以下のWordPress公式デフォルトコードを貼り付けて保存します。

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

管理画面に入れる場合の再生成方法：
ダッシュボードにログインできる場合は、左メニューの「設定 > パーマリンク」を開き、何も変更せずに画面下部の「変更を保存」ボタンを1回クリックするだけで、WordPressが自動的に正しい .htaccess を再生成してくれます。

【手順2】プラグイン・テーマの競合切り分けと一括無効化

プラグインの更新直後や新しいテーマを適用した直後に500エラーが発生した場合、PHPプログラムの競合や関数呼び出しの不整合による「致命的エラー（Fatal Error）」が発生しています。

【FTPによる一括無効化と特定手順】

1. FTPで wp-content/ ディレクトリを開きます。
2. plugins フォルダの名前を plugins_disabled に変更します。これですべてのプラグインが一括で強制無効化されます。
3. サイトを再読み込みし、画面が表示されるか確認します。表示されればプラグインが原因です。
4. フォルダ名を元の plugins に戻します（この時点では管理画面上ですべて無効化された状態を維持）。
5. WordPress管理画面の「プラグイン > インストール済みプラグイン」から、1つずつ有効化していき、再度500エラーが発生したプラグインを「原因プラグイン」として特定します。

【WP-CLI（SSH接続）が使える場合の高速コマンド】

# 全プラグインを一括停止
wp plugin deactivate --all

# デフォルトテーマ（Twenty Twenty-Five等）に切り替え
wp theme activate twentytwentyfive

# プラグインを1つずつ有効化して原因を調査
wp plugin activate <plugin-name>

【手順3】wp-config.php でのデバッグモード有効化（WP_DEBUG）とログ解析

エラーの原因が分からない場合、WordPressのデバッグ機能（デバッグログ）を有効化して、サーバー内部で起きているエラー内容をファイルに書き出させます。
本番サイトで画面上にエラーメッセージを露出させず、ログファイル（debug.log）にのみ安全に出力する設定を行うのが鉄則です。

【設定手順】

WordPressルート直下の wp-config.php を開き、/* That's all, stop editing! Happy publishing. */（編集が必要なのはここまでです）という行の直前に、以下のコードを記述（または既存の WP_DEBUG 行を書き換え）します。

// デバッグモードを有効化（ログ出力用）
define( 'WP_DEBUG', true );

// エラー内容を wp-content/debug.log に記録する
define( 'WP_DEBUG_LOG', true );

// 本番画面上にはエラーメッセージを表示させない（訪問者へのセキュリティ配慮）
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

保存後、500エラーが発生しているページを再度リロードします。その後、FTPで wp-content/debug.log をダウンロードして中身を確認します。

【ログの読み解き方】

[26-Aug-2026 01:15:20 UTC] PHP Fatal error: Uncaught Error: Call to undefined function get_header() in /var/www/html/wp-content/themes/my-theme/index.php:12
[26-Aug-2026 01:15:45 UTC] PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-content/plugins/heavy-plugin/heavy.php:89

• PHP Fatal error の後ろに続くファイルパスと行番号（例：/wp-content/plugins/heavy-plugin/...:89）を見ることで、どのプラグインやテーマのどの行でプログラムが停止したかが一目瞭然になります。
• Allowed memory size of ... exhausted と表示されている場合は、次章の「PHPメモリ制限の引き上げ」が必要です。

⚠️ 【重要】復旧後の後片付け：
原因を特定・修復した後は、必ず wp-config.php の WP_DEBUG を false に戻してください。デバッグモードのままだとログファイルが肥大化してディスクを圧迫するほか、内部パスの露出リスクにつながります。

【手順4】PHPメモリ制限（memory_limit）の変更・引き上げ方法

高画質な画像のアップロード時、WooCommerce等の多機能プラグイン使用時、またはバックアップ処理時などに500エラーが出る場合、PHPに割り当てられたメモリ上限（memory_limit）を超過したことによる強制終了が原因です。

以下のいずれかの方法でPHPのメモリ上限を 256M または 512M に引き上げます。

方法A：wp-config.php に追記する（最も簡単・推奨）
wp-config.php の /* That's all, stop editing! Happy publishing. */ の直前に以下を追記します。

// 通常ページのPHPメモリ上限を256MBに設定
define( 'WP_MEMORY_LIMIT', '256M' );

// 管理画面側のPHPメモリ上限を512MBに設定
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

方法B：.htaccess に記述する（Apache / LiteSpeed環境）
.htaccess ファイルの先頭に以下を追記します。

php_value memory_limit 256M

方法C：php.ini または user.ini で設定する
サーバーの php.ini を直接編集できる場合は、以下のディレクティブを変更します。

memory_limit = 256M
max_execution_time = 300
post_max_size = 64M
upload_max_filesize = 64M

方法D：レンタルサーバーの管理画面（コントロールパネル）から変更する
エックスサーバー、ConoHa WING、さくらのレンタルサーバ、ロリポップ等では、管理画面の「PHP設定」>「php.ini設定」から memory_limit の数値をフォーム上で直接引き上げることが可能です。

【手順5】ファイル・ディレクトリのパーミッション（権限）修正

FTPでファイルを手動アップロードしたり、サーバー移行を行った後に500エラーが出る場合、ファイルやフォルダのパーミッション（アクセス権限）が不正になっているケースがあります。Webサーバーのセキュリティ機構（suPHPやCGIモード等）は、権限が緩すぎる（777等）ファイルへのアクセスを拒否して500エラーを返します。

WordPressの推奨標準パーミッション：

• すべてのディレクトリ（フォルダ）：755（または 705）
• すべてのファイル：644（または 604）
• wp-config.php：400、440、または 600（セキュリティ強化時）
• .htaccess：644 または 604

SSH接続が可能な環境では、以下のコマンドで一括適正化が可能です。

# ディレクトリを755に一括修正
find /path/to/wordpress/ -type d -exec chmod 755 {} \;

# ファイルを644に一括修正
find /path/to/wordpress/ -type f -exec chmod 644 {} \;

【手順6】データベース接続・破損チェックとURL不整合の修正

「データベース接続確立エラー」ではなく500エラーとして表面化するケースもあります。特にデータベースのテーブルがクラッシュしている場合や、サイト移行直後に siteurl と home のURL設定が食い違っている場合に発生します。

• データベースの自動修復機能を利用する：
  wp-config.php に define('WP_ALLOW_REPAIR', true); を追記し、ブラウザで https://example.com/wp-admin/maint/repair.php にアクセスして修復を実行します（修復完了後は設定行を削除）。
• wp-config.php のDB接続情報を再点検：
  DB_NAME, DB_USER, DB_PASSWORD, DB_HOST の値に余計なスペースやタイポがないか確認します。

---

サーバー・ミドルウェア別の具体的対処ポイント

Webサーバー環境ごとのエラーログ配置場所と、特有のトラブルシューティングポイントを整理しました。

Apache

• エラーログ確認：/var/log/apache2/error.log または /var/log/httpd/error_log を確認します。
• .htaccess のディレクティブエラー：許可されていないディレクティブ（AllowOverride 不足）や mod_rewrite のループ設定を点検します。
• リクエスト制限：LimitRequestBody などの制限によるファイルアップロード時エラーを疑います。

Nginx

• 構文チェックとリロード：nginx -t で設定ファイルの文法を確認し、systemctl reload nginx を実行します。
• FastCGIタイムアウト：fastcgi_read_timeout や proxy_read_timeout を適切に引き上げます。
• try_files の設定ミス：WordPress用のリライトルール（try_files $uri $uri/ /index.php?$args;）が正しく記載されているか確認します。

PHP-FPM

• プロセスの枯渇：アクセス集中時に pm.max_children に達してリクエストがキュー溢れしていないかログ（/var/log/php-fpm.log 等）を確認します。
• 実行時間超過（Max Execution Time）：request_terminate_timeout や max_execution_time を調整します。

Cloudflare / CDN

• エッジエラーとオリジンエラーの判別：Cloudflareのブランド入りエラー画面（Error 520〜527）はCDN・オリジン間通信の異常、素の500エラーはWordPressオリジンサーバー側の異常です。
• 開発モード（Development Mode）の活用：一時的にCDNキャッシュをバイパスしてオリジンへ直接接続し、挙動の違いを検証します。

---

再発防止とSEOへの悪影響を最小化するポイント

500エラーは一時的に復旧させるだけでなく、SEO評価の防衛と再発防止の仕組みづくりまで完遂して初めて対応完了と言えます。

SEOへの影響とGoogle Search Consoleでのリカバリー手順

Googleのクローラー（Googlebot）は、ページ巡回時に500番台エラー（HTTP status 500）に遭遇すると「サーバーの一時的な障害」と認識し、クロール頻度を落とします。しかし、500エラーが数日以上にわたって継続すると「存在しない・廃止されたページ」とみなされ、検索インデックスから除外されたり検索順位が急落する重大なリスクがあります。

復旧後のSEOリカバリー手順：

1. Google Search Console の「ページ」レポートを確認：エラーとして検出されているURLの一覧を把握します。
2. URL検査から再クロールをリクエスト：重要ページについてURL検査を実行し、「公開URLをテスト」で正常なHTTP 200が返ることを確認した上で「インデックス登録をリクエスト」を送信します。
3. XMLサイトマップの再送信：サイト全体のクロールを早めるため、sitemap.xml を再送信します。

計画メンテナンス時は「503ステータス」を返す

長時間の改修やサーバーメンテナンスを行う際は、500エラーを放置するのではなく、必ず 503 Service Unavailable ステータスとともに Retry-After ヘッダー（復旧予定時刻）を返してください。これにより、Googlebotに対して「一時的な保守中でありインデックスを維持すべき」であることを明確に伝えられます。

再発を防ぐ運用のベストプラクティス

• ステージング環境（検証環境）での事前テスト：プラグイン更新やテーマ改修は本番環境で直接行わず、テスト環境で互換性を確認してから本番適用します。
• 自動バックアップの確立：サーバー側またはバックアッププラグイン（All-in-One WP Migration、UpdraftPlus等）で日次バックアップを外部ストレージに自動保管します。
• 定期的なサイト診断の実施：MozCheckなどの診断ツールを活用し、セキュリティ脆弱性やバージョンの非互換リスクを日常的に把握しておきます。

---

よくある質問（FAQ）

Q1. WordPressで突然500エラー（HTTP status 500）が発生する原因は何ですか？

最も多いのは「プラグインやテーマのバックグラウンド自動更新による競合」「.htaccessの文法ミスや破損」「定期タスク（WP-Cron）実行時のPHPメモリ上限（memory_limit）超過」です。管理画面に入れない場合でも、FTPで .htaccess のリネームや plugins フォルダ名の一時変更を行うことで即時切り分けが可能です。

Q2. 500エラーの直し方で最初にやるべきことは何ですか？

まず「直前に行った操作（プラグイン更新、ファイル編集など）」を振り返り、FTP等で .htaccess のリネーム退避と plugins フォルダの一時無効化を試してください。それでも解決しない場合は、wp-config.php で WP_DEBUG_LOG を有効化し、wp-content/debug.log を確認してエラーを出しているファイルと行番号を特定します。

Q3. .htaccess を削除・リネームしてもWordPressは壊れませんか？

壊れません。.htaccess をリネームまたは削除するとパーマリンクの書き換えルールが初期状態に戻るだけです。管理画面の「設定 > パーマリンク」で「変更を保存」をクリックするか、WordPress標準コードを記述した新しい .htaccess を配置すれば完全に正常復旧します。

Q4. 500エラーは一般ユーザー（閲覧者）側で直せますか？

500 Internal Server Error（HTTP status 500）は100%サーバー側の不具合であるため、閲覧者側で根本的な修復はできません。ブラウザのハード再読み込み（Ctrl+F5）を試しても解消しない場合は、時間を置いて再訪問するか、サイト運営者に連絡してください。

---

まとめ：チェックリストを活用して500エラーを最短解決

WordPressの「500 Internal Server Error（HTTP status 500）」は、突然画面が真っ白になるため非常に焦るトラブルですが、原因のパターンと切り分け手順は明確に決まっています。

1. 即時チェックフローで .htaccess のリネーム、プラグイン一括停止、メモリ上限引き上げを順に実施する。
2. 直らない場合は wp-config.php で WP_DEBUG_LOG を有効化し、debug.log から原因行を特定する。
3. 復旧後はデバッグモードをOFFに戻し、Search Console でインデックス登録をリクエストしてSEO影響を防ぐ。

トラブルを未然に防ぐためにも、日頃からステージング環境での検証、定期バックアップ、そしてサイト診断ツールを活用したリスク管理を徹底していきましょう。

参考・参照リンク

• MDN Web Docs: 500 Internal Server Error
• MDN Web Docs: 5xx サーバエラーの概要
• Google 検索セントラル：HTTP 5xx とクロール
• WordPress サポート：トラブルシューティング（日本語）
• WP-CLI Handbook
• Apache HTTP Server: ErrorLog / .htaccess
• Nginx: Logging & Error handling
• PHP-FPM: Configuration / Error logging
• Cloudflare: 5xx エラーのトラブルシューティング