WordPressの投稿・固定ページが保存できない「500エラー」を切り分けて直す【本番/Local両対応】
はじめに
WordPressの編集画面で保存ボタンを押した瞬間に「500 Internal Server Error」が出て、変更が反映されない——という事象は、本番サーバーでもローカル開発環境（Local by Flywheel）でも頻繁に起こります。
原因は毎回同じではなく、プラグインの競合／.htaccessの破損／PHPのメモリ不足／DBの肥大化のいずれかに大別できます。本記事では、原因の切り分け方から具体的な直し方、再発防止のための恒久対策、そして現場で使える対応記録テンプレートまでを一気通貫でまとめます。
この記事でわかること
- 500エラーの原因を素早く切り分けるチェックポイント
- 本番サーバー／Local環境それぞれでの具体的な復旧手順
- リビジョン肥大化などDB側の根本原因への対処
- 障害対応後にそのまま使える日報・技術共有テンプレート
原因別 早見表
| 症状・きっかけ | 疑うべき原因 | 対処セクション |
|---|---|---|
| プラグイン更新直後から発生 | プラグイン競合 | 本番① |
| サイト移行・.htaccess編集後 | .htaccess破損 | 本番② |
| 画像や長文投稿の保存で発生 | PHPメモリ不足 | 本番③ |
| Localでのみ発生 | ローカル特有の設定競合 | Local環境 |
| サイトが全体的に重い・DBが大きい | リビジョン肥大化 | 再発防止 |
本番サーバーでの復旧手順
① PHPのメモリ上限を引き上げる
エディター上で大量のブロックを扱ったり、重いプラグインを併用していると、サーバー側のメモリ上限（Memory Limit）を超えて処理が落ちることがあります。まず疑うべきはここです。
wp-config.php の /* 編集はここまでです */ の直前に以下を追記します。
define( 'WP_MEMORY_LIMIT', '256M' );
② プラグインを一時停止して切り分ける
管理画面にログインできる場合は「プラグイン」→「インストール済みプラグイン」から一括無効化し、保存できるかを確認します。1つずつ有効化していけば原因プラグインを特定できます。
ログインすらできない場合は、FTPやサーバーのファイルマネージャーで wp-content/plugins フォルダ名を plugins_old などにリネームすると、全プラグインを強制停止できます。
③ .htaccessを再生成する
サーバーのアクセス制御を担う .htaccess が破損記述を含んでいると500エラーの原因になります。
-
wp-config.phpと同階層にある.htaccessを.htaccess_bkなどにリネーム（バックアップ） - 管理画面の「設定」→「パーマリンク」を開き、内容を変えずに「変更を保存」をクリック
- 初期状態の正しい
.htaccessが自動で再生成される
④ デバッグログで原因ファイルを特定する
上記で解決しない場合は、サーバーのエラーログを確認するか、wp-config.php の以下の記述を有効化してブラウザに直接エラーを出力させます。
define( 'WP_DEBUG', true );
サポートに相談する際は「利用サーバー名」「エディタの種類（ブロックエディタ/Elementor等）」「発生直前の作業内容」の3点を伝えると解決が早まります。
Local by Flywheel特有の対処
ローカル環境ではサーバー側ではなく、PCに割り当てたメモリ・ローカルPHP設定・セキュリティソフトとの競合が主な原因になります。
① php.iniのmemory_limitを変更する
サイトフォルダ（Local Sites/サイト名/）内の conf/php/php.ini.hbs を開き、値を引き上げます。
memory_limit = 512M
変更後は必ずLocalアプリで対象サイトを Stop site → Start site して反映させます。
② Router Modeをlocalhostに切り替える
Localのデフォルト接続方式（Site Domains）がファイアウォールやセキュリティソフトと衝突するケースがあります。
Localの Preferences → Advanced タブから Router mode を localhost に切り替えると、http://localhost:ポート番号 形式に変わり、競合を回避できます。
③ Site Shellでログとデバッグを有効化する
Localの「Open site shell」からターミナルを開き、logs/nginx/error.log や logs/php/error.log を確認できます。手早く原因を突き止めたい場合は、app/public/wp-config.php に以下を追記してデバッグ出力を常時オンにします。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
この状態で再度保存操作を行うと、原因となっているプラグイン名やPHPファイル名が画面に直接表示されます。
再発防止：DB肥大化とパフォーマンスの根本対策
500エラーは一時対応で直っても、**データベースに溜まったリビジョン（更新履歴）**が原因で再発することがあります。ここでは恒久対策をまとめます。
リビジョン数を制限する
wp-config.php に以下を追記すると、以降に生成されるリビジョン数を制御できます。
// リビジョンの最大保存数を3件に制限
define( 'WP_POST_REVISIONS', 3 );
// リビジョンを一切保存しない場合
// define( 'WP_POST_REVISIONS', false );
// ゴミ箱を7日で自動的に空にする
define( 'EMPTY_TRASH_DAYS', 7 );
既存の肥大化データを掃除する
| プラグイン | 特徴 | 向いているケース |
|---|---|---|
| WP-Optimize | 自動スケジュール削除、画像圧縮・キャッシュ機能も統合 | 定期メンテナンスを自動化したい人 |
| WP-Sweep | 単機能で動作が軽い、手動実行のみ | 必要な時だけ入れて掃除し、終わったら削除したい人 |
どちらもDBを直接操作するため、実行前に必ずバックアップを取得してください（Local環境ならサイトを右クリック→Export）。
そのほかの負荷軽減策
- PHPバージョンの更新：古いPHP（7.x系など）は処理速度が落ちやすいため、PHP 8.1〜8.2への切り替えを推奨
- Heartbeat通信の制限：編集画面が数秒おきに行う自動通信が低スペック環境では負荷になるため、「Heartbeat Control」で間隔を調整
- 画像の軽量化：EWWW Image Optimizerなどで自動圧縮し、WebP形式での運用に統一する
- 不要なプラグイン・重いテーマの整理：無効化だけでなく完全削除し、デフォルトテーマ（Twenty Twenty-Four等）で動作比較する
障害対応後にそのまま使える記録テンプレート
チームでの共有や日報にコピペで使える形式です。
【対応記録】WordPress 500エラー対応報告
■ 発生日
YYYY年MM月DD日
■ 環境
（本番 / ローカル(Local) / ステージング）
■ 発生した事象
記事・固定ページの保存時に500 Internal Server Errorが発生し、変更が保存できない状態を確認。
■ 原因
（例）PHPのメモリ割り当て上限に達したことによるFatal Error
■ 対応内容
- 該当ファイル（php.ini.hbs / wp-config.php 等）のmemory_limitを256M→512Mへ変更
- サイトコンテナを再起動（Stop→Start）
- 保存操作を再実行し、正常に反映されることを確認
■ 再発防止策
- WP_POST_REVISIONSでリビジョン数を制限
- 定期的なDBクリーンアップ（WP-Optimize等）をスケジュール
まとめ：チェックリスト
- 最近更新・追加したプラグインを1つずつ無効化して切り分けた
-
.htaccessを一旦退避し、パーマリンク設定から再生成した -
memory_limit/WP_MEMORY_LIMITを256M〜512Mに引き上げた -
WP_DEBUGを有効化してエラーの発生源を特定した -
Local環境ではRouter Modeを
localhostに切り替えて競合を確認した -
WP_POST_REVISIONSでリビジョン数を制限し、DBの肥大化を防止した