WordPress 致命的エラー復旧手順|knowkoto運用で実際に直した5パターン【ssh+WP-CLI】

WordPress 管理画面に突然「このサイトで重大なエラーが発生しました」と表示されて、何も操作できなくなった経験はありませんか。私は knowkoto.com を運用する半年間で5回このエラーに遭遇し、毎回原因が違いました。本記事では、知ってさえいれば5分で復旧できる5パターンを、ssh コマンド付きで共有します。WordPress 自動更新で詰まったとき、プラグイン更新でホワイトアウトしたとき、テーマ編集でPHP構文を間違えたとき、すべてここに書いた手順で復旧できます。

結論: 復旧の優先順位

状況 復旧コマンド
1. プラグイン更新後にエラー wp plugin deactivate --all
2. テーマ編集後にエラー wp theme activate twentytwentyfive
3. PHPバージョン更新後にエラー php -v 確認 → 旧バージョンへ
4. メモリ不足エラー wp-config.php に WP_MEMORY_LIMIT
5. DB接続エラー DB認証情報・MariaDB起動状態確認

1. プラグイン更新後にエラー(最頻パターン)

WordPress 自動更新でプラグインが新バージョンに上がった瞬間、他のプラグインや WordPress 本体と互換性が崩れて致命的エラーが出るパターン。管理画面に入れないので、ssh + WP-CLI で対処します。

ssh your-server
cd /var/www/your-site
sudo -u www-data wp plugin list --status=active --path=/var/www/your-site
sudo -u www-data wp plugin deactivate --all --path=/var/www/your-site

全プラグインを無効化すると管理画面に戻れます。あとは1つずつ有効化してエラーを再現するプラグインを特定 → そのプラグインを古いバージョンに戻すか、開発元の対応待ち。

2. テーマ編集後にエラー

子テーマの functions.php をブラウザ編集して、PHP構文ミスでサイト全体が真っ白になるケース。これも管理画面に入れないので、ssh で標準テーマに戻します。

sudo -u www-data wp theme list --path=/var/www/your-site
sudo -u www-data wp theme activate twentytwentyfive --path=/var/www/your-site

標準テーマに戻ったら管理画面にログイン → 元の子テーマの functions.php を wp-content/themes/your-child-theme/functions.php で直接編集して構文を直す → 元テーマを再有効化。

テーマ編集ミスを防ぐ習慣

ブラウザの「テーマファイルエディタ」は本番直編集なので絶対に使わない、ローカル → SCP → 本番反映の流れが安全です。私はこの罠に2回ハマって学習しました。

3. PHPバージョン更新後にエラー

サーバーのOSメジャーアップデートで PHP が 8.1 → 8.3 にジャンプして、古いプラグインが非互換になるパターン。

php -v
# PHP 8.3.x (cli)

もしテスト環境を用意できる方は、まずローカルで同じ PHP バージョンに上げてプラグイン互換性を確認 → 本番反映、の流れがおすすめです。本番でいきなり踏むと半日溶けます。

復旧パターン

  • 古い PHP バージョンを併存させて切り替え(Ubuntu: update-alternatives --config php)
  • 非互換プラグインを wp plugin deactivate で無効化 → 代替プラグインに切り替え
  • WordPress 本体・全プラグインを最新化して新 PHP に合わせる(時間はかかるが推奨)

4. メモリ不足エラー

「Allowed memory size of X bytes exhausted」というエラーがログに出る場合、PHP に割り当てられたメモリが足りていません。wp-config.php の require_once ABSPATH . 'wp-settings.php'; の手前に1行追加:

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

1GB VPS では 256MB が現実的な上限。これでも足りない場合は、サーバーのスペック自体を見直す段階です(2GB プランへの昇格 or 不要プラグイン整理)。

5. DB接続エラー

「Error establishing a database connection」が出る場合は MariaDB(または MySQL)が停止しているか、認証情報が壊れている可能性。

sudo systemctl status mariadb
sudo systemctl restart mariadb
sudo journalctl -u mariadb -n 50

journalctl のログに「Out of memory」が出ていれば、サーバー全体のメモリが枯渇して MariaDB が殺されたパターン。free -m でメモリ状況確認、不要プロセスを止めて再起動。

DB認証情報の確認

sudo cat /var/www/your-site/wp-config.php | grep -E "DB_NAME|DB_USER|DB_HOST"

wp-config.php のDB認証情報を変更した直後にこのエラーが出る場合は、認証情報の打ち間違いが原因です。

復旧後にやるべき3つの対策

  1. WordPress 自動更新を「マイナーのみ」に制限:wp-config.php に define('WP_AUTO_UPDATE_CORE', 'minor');
  2. 定期バックアップを必ず設定:BackWPup や UpdraftPlus でDB+ファイルを週次バックアップ → S3 / Google Drive に保管
  3. ステージング環境を用意:同じ ConoHa VPS 内に staging.knowkoto.com サブドメインを切り、本番反映前にここで確認

エラーが直らない時の最後の手段

上記5パターンに当てはまらず、データベース・PHP・プラグインを切り分けても直らない場合、最終手段は「直前のバックアップから DB と wp-content をまるごと復元」です。バックアップを取っていない場合は復元できないので、復旧優先 → バックアップ習慣を最優先で導入してください。

まとめ

WordPress の致命的エラーは怖そうに見えますが、ほとんどはプラグイン・テーマ・PHP・メモリ・DBの5領域に絞れます。最初に wp plugin deactivate --all で切り戻せる体制を作っておくだけで、夜間トラブルの精神的負担が劇的に減ります。本記事のコマンドは ConoHa VPS 1GB + Ubuntu 24.04 + nginx + MariaDB の構成で実機検証済みですが、AWS Lightsail・Xserver・KUSANAGI でも同じ思想で使えます。

合わせて読みたい関連記事

タイトルとURLをコピーしました