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の肥大化を防止した

参考

WordPressで「保存できない」500エラー完全解決ガイド：DB肥大化を防ぐリビジョン制限とPHP最適化による根本対策 - サイエンスサーチコンソール