
WordPressで更新に失敗しました サーバーから有効な応答を取得できませんでしたと出る時の対処法
ブロックエディターで「更新に失敗しました。サーバーから有効な応答を取得できませんでした」と表示されて固定ページや投稿を保存できない場合、原因はエディターとサーバー間をつなぐREST APIの通信エラーだ。パーマリンク設定の再保存とWordPressアドレス、サイトアドレスの一致確認から始めると解決できることが多い。
なぜ「更新に失敗しました」と表示されるのか 原因を切り分ける

編集画面でこのエラーが出るとき、書いた内容がサーバーに届いていない。ブロックエディターは保存処理をREST API(レストエーピーアイ / エディターとサーバーがデータをやり取りする仕組み)経由で実行する。この通信が通らなければ「有効な応答が取得できない」状態になる。原因として多いのは次の4つだ。
- パーマリンク設定の乱れ(書き換えルールの不整合)
- WordPressアドレスとサイトアドレスの不一致(httpとhttpsの混在など)
- WAF(ウェブアプリケーションファイアウォール)による /wp-json/ の遮断
- サーバー側のPHP設定やメモリ上限による処理停止
Twenty Twenty-Fourなどのブロックテーマを使い、プラグインを入れていない環境でもこのエラーは発生する。テーマやプラグインの競合だけに原因を絞らず、サーバーとエディターの通信経路を疑うのが最短の解決につながる。
「ブラウザーに保存されたバックアップが現在の内容と異なる」というメッセージが出る場合も、保存処理自体が失敗していることを示す副次的な症状だ。バックアップを復元しても保存に失敗するのは、エディターからサーバーへの通信が断たれているためである。
上から順に確認すると原因を特定しやすい。次から各手順を詳しく見ていく。
最初に試すのはパーマリンク設定の再保存

管理画面の「設定」→「パーマリンク設定」を開き、「投稿名」を選択した状態で「変更を保存」を押す。見た目上は何も変わっていなくても、内部の書き換えルールが再生成されてREST APIの経路が修復されることがある。「昨日まで普通に保存できていたのに急にエラーになった」という場合の定番対処だ。
パーマリンク設定の画面に「.htaccessを更新できません」という趣旨のメッセージが表示されていれば、サーバー上の .htaccessファイルの書き込み権限を確認する必要がある。FTPまたはサーバー管理画面のファイルマネージャーで権限を確認し、必要なら664や666に変更してから再度保存を試す。
WordPressアドレスとサイトアドレスの一致を確認する

「設定」→「一般」を開くと「WordPressアドレス (URL)」と「サイトアドレス (URL)」の2つの欄がある。この2つが完全に一致していることを確認する。特にhttpとhttpsが混在している、片方だけサブディレクトリが付いている、といった不一致があると保存処理が失敗しやすい。
ここで重要なのは、この2つの欄を管理画面から安易に変更してはいけないという点だ。間違えて変更すると、サイト全体と管理画面にアクセスできなくなることがある。値が食い違っているのを見つけても、すぐに手を加えず、次の復旧方法を読んでから作業するのが安全だ。
サイトヘルスでREST APIエラーを特定する

「ツール」→「サイトヘルス」を開き「REST APIでエラーが発生しました」という表示を探す。この表示が出ていれば、サーバー側のファイアウォール(WAF)が /wp-json/ への通信を遮断している可能性が高い。レンタルサーバーの管理画面からWAF設定を一時的に無効にするか、サーバー会社に問い合わせて「/wp-json/ へのリクエストがブロックされていないか」を確認する。
サイトヘルスにエラーが出ていない場合でも、通信が不安定なケースはある。ブラウザーの開発者ツールで「ネットワーク」タブを開き、保存ボタンを押したとき /wp-json/ へのリクエストが403や500になっていないかを確認する方法も有効だ。ここで明確なステータスコードが出れば、サーバー会社に伝える情報として使える。
サイトアドレスを変更してサイトが開けなくなった時の復旧

「WordPressアドレス」と「サイトアドレス」の値を管理画面から変更したあと、サイトも管理画面も開けなくなることがある。この状態はwp-config.phpまたはデータベースから直接修正すれば復旧できる。まずはwp-config.phpに定数を追記する方法が簡単だ。
wp-config.phpに定数を追記して復旧する
FTPまたはサーバー管理画面のファイルマネージャーでwp-config.phpを開き、以下のコードを追記する。example.comの部分は実際の独自ドメインに置き換える。
define( 'WP_HOME', 'https://example.com' );
define( 'WP_SITEURL', 'https://example.com' );この2行を追記すると、データベースに保存された値より優先してWordPressがURLを認識するようになる。管理画面に再ログインできたら「設定」→「一般」で正しい値を入力し、追記した2行を削除する。
phpMyAdminからオプション値を直接修正する
wp-config.phpを編集できない環境なら、phpMyAdminでwp_optionsテーブルを開き、siteurlとhomeの2つのオプション値を正しいURLに直接変更する。こちらも修正後に管理画面へアクセスできるようになる。
誤ったアドレス変更をしても、ファイルまたはデータベースから正しい値を戻せばサイトは復旧する。慌てずどちらかの方法を試す。
ブロックテーマのテンプレートとヘッダー警告への対応

Twenty Twenty-Fourはブロックテーマなので、固定ページのレイアウトはすべてテンプレートで決まる。新しいページを追加したときに同じテンプレートが自動適用されるのは仕様であり、異常ではない。エディター右側の設定サイドバーを開き、「ページ」タブにある「テンプレート」プルダウンで別のテンプレートに切り替える。「タイトルなし」や「ブランク」などの選択肢が用意されている。
「ヘッダーが削除されました」という警告は、テンプレートパーツのヘッダーが編集されて整合性が取れなくなっている状態を示す。テンプレートパーツ内のタイトルを直接編集した場合などに起きやすい。「外観」→「エディター」→「パターン」→「テンプレートパーツ」→「ヘッダー」を開き、三点メニューから「リセット」を選ぶと初期状態に戻る。この操作でテンプレートパーツの問題は解消する。
よくある質問
パーマリンク設定を再保存しても直らない場合はどうすればよいか
次にWordPressアドレスとサイトアドレスの一致を確認する。それでも直らなければサイトヘルスでREST APIのエラーを調べ、WAFによる遮断がないかサーバー会社に問い合わせる。
サイトヘルスに「REST APIでエラーが発生しました」と表示されたら
サーバー側のファイアウォールが /wp-json/ への通信を遮断している可能性が高い。レンタルサーバーの管理画面でWAF設定を確認するか、サーバー会社に /wp-json/ へのブロック解除を依頼する。
サイトアドレスを間違えて変更して管理画面に入れなくなった
wp-config.phpにWP_HOMEとWP_SITEURLの定数を追記して強制的に正しいURLを指定する。FTPが使えない場合はphpMyAdminからwp_optionsテーブルのsiteurlとhomeを修正する。
ブロックテーマで固定ページごとに違うレイアウトにする方法
エディター右側の設定サイドバーを開き、「ページ」タブの「テンプレート」プルダウンからページごとに別のテンプレートを選ぶ。Twenty Twenty-Fourには複数のテンプレートが標準で用意されている。
「ヘッダーが削除されました」という警告の直し方
外観>エディター>パターン>テンプレートパーツ>ヘッダーを開き、三点メニューから「リセット」を選ぶ。テンプレートパーツが初期状態に戻り、警告は消える。
この記事のポイント
- 保存エラーの主因はエディターとサーバーをつなぐREST API通信の失敗
- 最初にパーマリンク設定を再保存して書き換えルールを修復する
- WordPressアドレスとサイトアドレスの一致を確認し、安易に変更しない
- 誤ってアドレスを変更して開けなくなったらwp-config.phpで復旧する
- ブロックテーマのテンプレート切替とテンプレートパーツのリセットでレイアウトを整える

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WP Statisticsの移行処理が0%で止まる原因と直し方
WP Statisticsの移行処理が3つとも0%で止まる場合、多くのケースでサーバー自身へのループバックリクエストがCloudflareやファイアウォールに遮断されている。管理画面から再試行しても進まない場合は、WP-CLIで処理を直接実行すると解決できる。
移行処理が0%で止まる原因は何か

WP Statisticsの移行処理はブラウザの画面表示とは独立したバックグラウンドジョブとして動く。管理画面で移行を開始すると、WordPressは自身のサーバーに対してadmin-ajax.phpへPOSTリクエストを送り、そのリクエストがバッチ処理を実行する仕組みだ。
このリクエストが何らかの理由でブロックされると、移行処理のカウンターは0%のまま動かなくなる。特にCloudflareのプロキシを有効にしている環境や、サーバー側のファイアウォール、セキュリティプラグインが自サーバーからのリクエストを遮断していることが多い。
上の図は移行処理が止まったときの対処フローを示している。まずループバック障害の有無を確認し、ネットワーク経路の問題なら設定変更で直す。それでも進まない場合はWP-CLIでHTTPリクエストを経由せずに処理を実行する。
「ループバックリクエスト」とは、サーバーが自分自身のURLに対してHTTPリクエストを送る仕組みのことだ。WordPressのバックグラウンド処理やCronジョブの多くはこの仕組みに依存しており、これが遮断されるとジョブは開始されないまま成功扱いになる。
ループバック障害を確認する方法

最初に確認すべきはWordPressのサイトヘルス画面だ。管理画面の「ツール」→「サイトヘルス」を開き、「ループバックリクエストを完了できません」という警告が出ていないか確認する。
サイトヘルスで警告を確認する手順
管理画面左メニューの「ツール」をクリックし、「サイトヘルストップ」を選択する。「ステータス」タブに表示される項目のうち、ループバックリクエストやREST APIに関する警告を探す。警告が複数ある場合は、それぞれの詳細をクリックして原因のヒントを確認する。
サイトヘルスにループバック警告が表示されていない場合でも、実際にはブロックされていることがある。特にCloudflareのプロキシを経由している環境では、サイトヘルスの診断はサーバー内部からのループバックのみを確認するため、外部経路の問題を見逃すことがある。
コマンドラインでループバックを手動確認する
サーバーにSSH接続できる場合は、curlコマンドでadmin-ajax.phpへのアクセスを確認できる。ただし単純なGETやPOSTでは移行ジョブのアクションが含まれないため、0が返ってきたからといってループバックが正常とは言い切れない。
より確実なのは、WP Statisticsの移行画面を開いたまま数分間待ち、カウンターが動くかを確認することだ。カウンターが一切動かない場合は、バックグラウンドリクエストがどこかで止まっていると判断できる。
WP-CLIで移行処理を直接実行する

ループバックのブロックを回避する最も確実な方法は、WP-CLIを使って移行処理をサーバー上で直接実行することだ。WP-CLIはWordPressのコマンドライン操作ツールで、HTTPリクエストを経由せずにPHPコードを直接実行できる。
WP-CLIがインストール済みか確認する
SSHでサーバーに接続し、WordPressのインストールディレクトリに移動して次のコマンドを実行する。WP-CLIのバージョン情報が表示されれば利用可能だ。
wp --infoコマンドが見つからない場合は、WP-CLIをインストールする必要がある。公式ドキュメントに従ってpharファイルをダウンロードし、実行権限を付ける方法が手軽だ。
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp移行ジョブを実行するPHPスクリプト
以下のPHPスクリプトをWordPressのルートディレクトリに保存する。ファイル名は「wps-run-jobs.php」など分かりやすい名前でよい。
<?php
// WP Statisticsの移行ジョブをWP-CLIで直接実行する
use WP_Statistics\Service\Database\Migrations\BackgroundProcess\BackgroundProcessFactory;
$keys = [
'visitor_columns_migrator',
'update_unknown_visitor_geoip',
'summary_totals_data_migration',
];
foreach ($keys as $key) {
$process = BackgroundProcessFactory::getBackgroundProcess($key);
if (!$process || !$process->is_queued()) {
WP_CLI::log("{$key}: キューがありません");
continue;
}
// バッチ処理を同期的に実行する
do {
$process->handle();
WP_CLI::log("{$key}: バッチ処理を実行中");
} while ($process->is_queued());
WP_CLI::success("{$key}: 完了しました");
}
スクリプトを保存したら、WordPressのルートディレクトリで以下のコマンドを実行する。
wp eval-file wps-run-jobs.php処理が開始されると、バッチ処理の進捗がCLI画面に表示される。データ量が多い場合は数分〜数十分かかることがある。最後に「完了しました」というメッセージが表示されれば移行は終了している。
WP-CLIが使えない場合の代替手段
WP-CLIをインストールできない場合は、管理画面から移行処理を再開する前に、問題を引き起こしている可能性の高い設定を一時的に無効化する方法がある。
まずCloudflareの管理画面で該当ドメインのプロキシを一時的にオフにする。もしくは「Speed」→「Bot Fight Mode」やファイアウォールルールでadmin-ajax.phpへのアクセスを許可する設定を追加する。セキュリティプラグインがサーバー自身のIPをブロックしていないかも確認する。
移行処理を再開できない場合の追加対処

上記の方法でも移行が進まない場合、WP Statisticsの状態が不正になっている可能性がある。プラグインが保存しているジョブの進捗情報をリセットして、最初からやり直す方法を取る。
ジョブの進捗情報をリセットする
データベースのoptionsテーブルには、移行ジョブのバッチ情報やプロセスロックが保存されている。これらを削除すると、移行処理を初期状態から再開できる。phpMyAdminやWP-CLIのdbクエリで以下のSQLを実行する。
DELETE FROM wp_options WHERE option_name LIKE 'wp_statistics_visitor_columns_migrator_batch_%';
DELETE FROM wp_options WHERE option_name LIKE '%wp_statistics_visitor_columns_migrator_process_lock%';
DELETE FROM wp_options WHERE option_name = 'wp_statistics_visitor_columns_migrator_status';
DELETE FROM wp_options WHERE option_name LIKE 'wp_statistics_summary_totals_data_migration_batch_%';
DELETE FROM wp_options WHERE option_name IN (
'wp_statistics_summary_totals_data_migration_total',
'wp_statistics_summary_totals_data_migration_processed'
);
DELETE FROM wp_options WHERE option_name = 'wp_statistics_jobs';SQLを実行した後、管理画面の移行画面に戻って「移行を開始」ボタンをクリックする。ただしこの方法はあくまで状態のリセットであり、根本的なループバック障害が残っていると再び0%で止まる。
Cronジョブの状態を確認する
WP Statisticsの移行処理はWordPress Cronからもトリガーされる。Cronが正常に動作しているか確認するには、管理画面の「ツール」→「サイトヘルス」でcron関連の警告を確認するか、サーバー上でwp-cron.phpを手動実行する。
curl -s "https://example.com/wp-cron.php?doing_wp_cron"URLの「example.com」は自分のサイトのドメインに置き換える。このコマンドでcronジョブが実行されるが、移行処理はcron経由でも結局はループバックリクエストに依存するため、ブロックされていれば動かない。
よくある質問
移行処理を実行しないまま放置してもサイトに影響はあるか
移行処理はバックグラウンドで安全に実行される設計のため、移行が完了していなくてもサイト自体は通常どおり動作する。ただし訪問者データの集計やGeoIP情報が最新化されないため、統計表示に誤差が出ることがある。
WP Statisticsのバージョンを更新しても移行が0%で止まるのはなぜか
プラグインのバージョンではなく、サーバー環境のネットワーク設定やファイアウォールが原因であることが多い。バージョンを更新してもループバックのブロックは解消されないため、同じ現象が続く。
Cloudflareのプロキシを無効化する以外の方法はあるか
Cloudflareのファイアウォールルールで、サーバー自身のIPからのadmin-ajax.phpへのアクセスを許可する設定を追加できる。もしくは「Bot Fight Mode」をオフにする、WP StatisticsのジョブをWP-CLIで実行するといった代替手段がある。
WP-CLIのスクリプト実行でエラーが出る場合はどうすればよいか
クラスの名前空間やメソッド名はWP Statisticsのバージョンによって異なる可能性がある。エラーメッセージを確認し、該当するクラスが存在するかPHPファイルを調べる。どうしても解決しない場合は、プラグインのサポートフォーラムに問い合わせる。
移行処理が途中まで進んで止まるのは別の原因か
0%から進まない場合はリクエスト自体のブロックが原因だが、途中まで進んで止まる場合はPHPの実行時間やメモリ制限が原因のことが多い。サーバーのタイムアウト設定やPHPのメモリ上限を引き上げると解決する場合がある。
この記事のポイント
- WP Statisticsの移行処理が0%で止まる主な原因はループバックリクエストの遮断
- サイトヘルスで警告を確認し、Cloudflareやファイアウォールの設定を見直す
- WP-CLIを使えばHTTPリクエストを経由せずに移行処理を直接実行できる
- 進捗情報をリセットしてから再試行する場合は根本原因の解消が先
- 移行処理が止まってもサイトの表示自体には大きな影響はない

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WordPressをサブディレクトリ運用でHeartbeatが404になる時の修正方法
なぜサブディレクトリ運用でHeartbeatが404になるのか

WordPressにはホームURLとサイトURLの2つの設定がある。ルートで運用していればどちらもexample.comになるが、サブディレクトリ運用ではホームURLがexample.com、サイトURLがexample.com/wpのように分かれる。
この場合、AJAXのエンドポイントはexample.com/wp/wp-admin/admin-ajax.phpが正しい。ところが、Media Library Assistantにはjs/mla-define-ajaxurl-scripts.jsというファイルがあり、グローバル変数ajaxurlに /wp-admin/admin-ajax.phpというハードコードされたパスを代入するフォールバック処理が含まれている。
Heartbeatは本来heartbeatSettings.ajaxurlに正しいURLを持っているが、グローバル変数window.ajaxurlを優先して参照してしまう。このため、サブディレクトリの /wp部分が欠けたURLへリクエストが飛び、404を返す。
パスが1つ違うだけでHeartbeatが404になる流れを示している。
window.ajaxurlの値を確認して原因を特定する手順

Ajax周りの404は別の原因でも発生するため、まずはwindow.ajaxurlを確認して切り分ける。ログイン中のフロントエンドで調査するのがポイントだ。
DevToolsのConsoleでwindow.ajaxurlを確認する
ChromeやFirefoxの開発者ツールを開き、Consoleタブにwindow.ajaxurlと入力して実行する。返ってきた値が /wp-admin/admin-ajax.phpのようになっていれば、サイトURL側の /wp部分が欠けている。管理画面ではajaxurlが最初から正しい値になるため、この症状はフロントエンドでしか現れない。
Networkタブで404になっているリクエストを探す
Networkタブを開き、admin-ajax.phpという文字列で絞り込む。404と表示されているリクエストが複数回発生していれば、Heartbeatが誤ったパスへ送信している。リクエストのURLを確認すると、/wpの部分が抜けていることが分かる。
プラグインを1つずつ無効化して切り分ける
Media Library Assistantを無効化してから再度window.ajaxurlを確認すると、値がundefinedになるか正しいURLに変わる。無効化で症状が消え、再有効化で再発するならそのプラグインが原因だ。ほかのプラグインでも同様のハードコードがある可能性があるため、1つずつ確認する。
ハードコードされたajaxurlを修正する実践手順

根本的にはプラグイン側の修正を待つのが望ましい。ただし実務ではすぐに解消したいため、子テーマのfunctions.phpに一時的な修正を入れる手順を示す。
子テーマへ修正を追加してから確認するまでの流れを3手順に整理した。
子テーマのfunctions.phpにwp_add_inline_scriptを追加する
以下のコードを子テーマのfunctions.phpに追記する。admin_urlを使い、WordPressの設定から正しいパスを動的に生成してwindow.ajaxurlに代入する。wp_footerで出力するため、プラグインのスクリプトが読み込まれた後に確実に上書きできる。
function fix_heartbeat_ajaxurl_for_subdirectory() {
// 管理画面では不要なので除外する
if ( is_admin() ) {
return;
}
$ajax_url = admin_url( 'admin-ajax.php' );
echo '' . "\n";
}
add_action( 'wp_footer', 'fix_heartbeat_ajaxurl_for_subdirectory', 999 );wp_add_inline_scriptを使う手もある。ただし対象プラグインのスクリプトがHeartbeatより後に読み込まれる場合は上書きされるため、wp_footerで最後に定義するのが確実だ。子テーマを使っていない場合は、まず子テーマを作成してからfunctions.phpを編集する。
修正後にキャッシュをクリアして確認する
コードを追加したら、ブラウザキャッシュとキャッシュプラグインのキャッシュを削除する。その後、ログインしたままフロントエンドのページを開き、DevToolsのConsoleでwindow.ajaxurlを確認する。正しいパスになっていれば、NetworkタブでHeartbeatが200を返すようになる。
プラグイン本体の更新で根本解決する
Media Library Assistantでは、このajaxurlのハードコードについて開発元に報告されており、後続バージョンでの修正が見込まれる。まずは対象プラグインの最新版が出ていないかを確認する。ほかのプラグインで同じ症状を発見した場合は、開発元のサポートフォーラムやバグトラッカーに再現手順を添えて報告すると、根本修正につながりやすい。
再発を防ぐためにプラグイン側で確認したいポイント

同じ問題を避けるには、プラグイン開発者がajaxurlをハードコードしないことが最も重要だ。WP AJAX用のURLはadmin_urlかwp_localize_scriptで動的に渡すのがWordPressの標準的な作法である。サイト運営者側では、リニューアルやサブディレクトリ移設の際にHeartbeatの404が増えていないかを監視する。
アクセスログでadmin-ajax.phpに対する404が頻発していないか、定期的に確認すると早期発見できる。プラグインを新しく導入した直後に軽くフロントエンドを動かして、Networkタブを確認する習慣を付けるとよい。
よくある質問
Heartbeatが404を返すとサイトにどんな影響があるか
主にログイン中のユーザーに影響する。ページの自動保存、セッション期限の通知、投稿のロック処理などが不安定になる。編集作業中にサーバーと通信できないため、下書きの保存が失敗することがある。
Media Library Assistant以外のプラグインでも起きるか
起きる可能性がある。window.ajaxurlをハードコードで定義するプラグインはどれも同じ挙動になる。特に管理画面以外で独自のAjax処理を実装したプラグインで注意が必要だ。
wp_add_inline_scriptを追加するのは本番環境で安全か
管理画面以外のフロントエンドだけに適用するコードなので、比較的安全だ。ただしfunctions.phpの編集は必ず子テーマで行い、編集前にバックアップを取る。ステージング環境で1日程度様子を見るのが望ましい。
プラグインのJavaScriptファイルを直接編集して直せないか
直すことはできるが、プラグインの更新で上書きされるため推奨しない。子テーマのfunctions.phpに一時しのぎを置き、開発元の修正版を待つのが安全だ。
サブディレクトリからルートへ移設すれば解決するか
解決はするが、移設はサーバー設定やパーマリンク、検索エンジンへの影響が大きい。この不具合だけのために移設するのは過剰だ。まずはajaxurlの修正で対応するのが現実的だ。
この記事のポイント
- サブディレクトリ運用ではadmin-ajax.phpの正しいパスが /wp/wp-admin/ になる
- プラグインがwindow.ajaxurlをハードコードするとHeartbeatが404を繰り返す
- DevToolsのConsoleでwindow.ajaxurlを確認して原因を切り分ける
- wp_add_inline_scriptで正しいURLを渡すと即座に解消できる
- 一時しのぎは子テーマのfunctions.phpに置き、根本修正はプラグイン更新を待つ

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

Woostify更新後に商品ギャラリーの動画が消えた時の原因と直し方
WooCommerceの商品ギャラリーに設定した動画が突然表示されなくなった場合は、Woostifyなどテーマの更新でギャラリー表示用テンプレートが変わったか、キャッシュが古いまま残っていることが多い。キャッシュを削除し、テーマとプラグインの更新状態を確認してから競合を切り分けると原因にたどり着ける。
商品ギャラリーの動画が表示されなくなる原因とは

商品ギャラリーに動画を追加できるのは、WooCommerceの標準機能ではなくテーマか専用プラグインが提供する機能だ。Woostifyテーマには商品画像ギャラリーに動画を表示する仕組みが含まれている。テーマの更新でその処理が変わったり、更新が途中で止まったりすると、動画だけが消えたように見える。
更新直後に表示がおかしくなった場合は、まずテーマ更新を第一の原因として扱う。一方で、サイト側のキャッシュやCDNが古いページを配信し続けているケースもあるため、切り分けはテーマ更新、キャッシュ、プラグイン競合の順で進める。
上記の順で確認すると、原因をテーマ・キャッシュ・プラグインの3つに絞りやすい。
キャッシュ削除と更新確認で直す手順

最初にやるべきは、更新状況の確認とキャッシュの削除だ。これだけで表示が戻るケースが多い。
テーマとWooCommerceの更新状態を確認する
WordPress管理画面の「ダッシュボード」から「更新」を開き、WoostifyテーマとWooCommerceに更新が出ていないかを確認する。更新がある場合は、事前にバックアップを取った上で適用する。更新が失敗している場合は、テーマやプラグインのファイルが途中まで反映されて動画の処理が止まっている可能性がある。
サイトキャッシュとブラウザキャッシュを削除する
キャッシュ系プラグインを利用しているなら、管理画面の専用メニューから「全キャッシュをクリア」や「キャッシュを削除」を実行する。ブラウザ側もキャッシュを削除するか、シークレットウィンドウで商品ページを開き直すと、古いページが残っていない状態で確認できる。CDNを使っている場合は配信側のキャッシュもクリアする。
キャッシュ削除後にもう一度商品ページを確認する
商品ページを再読み込みし、商品ギャラリーの動画が表示されるかを確認する。動画が戻っていれば、キャッシュが原因だったと判断できる。まだ表示されないときは、テーマとプラグインの競合を調べる段階に進む。
テーマとプラグインの競合を切り分ける手順

キャッシュと更新確認で直らない場合は、テーマ側かプラグイン側かを特定する。テーマの一時切り替えとプラグインの無効化を順に行い、原因を絞り込む。
テーマを標準テーマに一時的に切り替える
管理画面の「外観」から「テーマ」を開き、WordPressに標準で同梱されているテーマへ一時的に切り替える。動画機能そのものはテーマ由来のため、標準テーマでは表示されなくなる可能性が高い。ただし、ここでは特定のテーマだけが原因かを確かめることが目的だ。切り替え前には必ずバックアップを取る。
プラグインを1つずつ無効化する
WooCommerce以外のプラグインを一時的にすべて無効化し、商品ページを確認する。表示が戻った場合は、無効化したプラグインを1つずつ有効化して原因を特定する。キャッシュ系・最適化系プラグインが動画の読み込みを止めていることもある。
子テーマとテンプレートの上書きを確認する
子テーマを使っている場合は、親テーマの商品ギャラリー用テンプレートに変更が入り、子テーマ側の古いテンプレートと干渉している可能性がある。子テーマのファイルを確認し、Woostifyの更新内容と照合する。不要な上書きがあれば一時的に外して表示を確かめる。
動画が再び消えないようにするための設定と注意点

原因を特定して表示が戻った後は、同じ症状を防ぐための設定を見直す。更新のタイミングとバックアップ体制を整えておくことが重要だ。
テーマとプラグインの更新タイミングをずらす
更新が原因で表示が崩れる場合は、更新適用前にステージング環境で確認するのが安全だ。自動更新を有効にしているなら、WoostifyテーマとWooCommerceの更新タイミングをずらすと、問題が起きたときに原因を特定しやすい。
バックアップとステージング環境を用意する
更新作業の前には必ずバックアップを取る。ステージング環境があれば、更新後に商品ギャラリーの表示を確認してから本番へ反映できるため、更新由来の不具合を未然に防げる。
商品ページ更新後のキャッシュを自動でクリアする
キャッシュが原因の再発を防ぐため、商品ページやギャラリーを変更した後はキャッシュを自動でクリアする設定にしておく。どうしても表示が追いつかない場合は、ステージング環境で素の状態を確認し、キャッシュ由来か本体の不具合かを見分ける。
よくある質問
商品ギャラリーに動画を追加できるのはWooCommerceの標準機能ですか?
WooCommerceの標準機能には商品ギャラリーへの動画追加は含まれない。テーマ(Woostifyなど)や専用プラグインが動画表示機能を提供している。そのため、テーマやプラグインが更新されると表示が変わることがある。
動画が表示されなくなった直後に行うべきことは?
まずテーマとプラグインの更新状態を確認し、キャッシュを削除する。更新直後に発生したならテーマ更新を疑って、標準テーマへの切り替えで原因を切り分ける。
Woostifyテーマの更新が原因の可能性はありますか?
ある。テーマ更新で商品ギャラリー用のテンプレートが変更され、動画表示が止まることがある。テーマの更新履歴や子テーマの上書きを確認し、必要なら以前の状態へ戻す。
ブラウザキャッシュだけでは直らない場合の次の手順は?
サイト側のキャッシュとCDNキャッシュをクリアし、プラグインを1つずつ無効化して競合を特定する。それでも直らない場合は子テーマやテーマのサポート情報を確認する。
この記事のポイント
- 商品ギャラリーの動画はテーマやプラグインの機能で表示される
- 更新直後に消えたらテーマ更新とキャッシュを最初に確認する
- 標準テーマへの切り替えで原因をテーマ側かプラグイン側か判別する
- 再発防止にはステージング環境とバックアップを用意する

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

Beacon Eventsで開始日時と終了日時が保存されない時の直し方
Beacon Eventsでイベントの開始日時・終了日時を入力しても保存されず、カレンダーに表示されない場合は、日時フィールドが途中までしか入力されておらず、ブラウザが値を未入力と判定している。最新版(0.27.0)に更新し、開始日時と終了日時を完全な形で入れ直すと解消する。
なぜ開始日時と終了日時が保存されないのか

編集画面の日時入力欄に値が表示されていても、データベースの wp_postmeta で _beacon_start と _beacon_end が空のままなら、入力欄の値が完了していない。ブラウザの日時入力は、日付と時刻のすべての部品が揃わないと、画面上の見た目にかかわらず入力値そのものを空として扱う。
具体的には、日付は入力したが時刻の一部(午前・午後の指定など)が未完了の場合や、カレンダーで日にちだけ選んで時刻を選ばなかった場合が当てはまる。途中まで入力されたフィールドには未設定部分に記号やプレースホルダーが表示されるため、完了しているように見えてしまう。
さらに、すでに入力済みの時刻を書き換えた直後は、フィールド全体が一時的に空になることがある。このタイミングで更新ボタンを押すと、日時を空のまま保存してしまい、イベントがカレンダーに出なくなる。Beacon Eventsの旧バージョン(0.18.2より前)は、この未完了状態をチェックせずに保存できたため、入力したはずの日時だけが失われる。
保存ボタンを押す前に、日付と時刻の最後の項目まで入力が完了しているかどうかが保存可否を分ける。
Beacon Eventsを最新版へ更新して保存処理を修正する

旧バージョンでは日時の入力を未完了のまま更新できてしまうが、新版では保存前に入力ミスを表示し、未完了のまま更新できないように改善されている。まずBeacon Eventsを0.27.0へ更新する。
- WordPress管理画面の「ダッシュボード」→「更新」を開く
- 更新対象の一覧にBeacon Eventsが出ていることを確認する
- チェックボックスをオンにして「プラグインを更新」を押す
- 更新後、イベント編集画面を開きなおして表示が変わっていることを確認する
更新後に表示される警告とイベント一覧の表記
新しいBeacon Eventsは、日時フィールドが未完成の状態だと入力欄の下に未保存の表示を出し、更新ボタンを無効化する。また、イベント一覧では開始日時を持たない記事に対して「開始日時なし(英語表示ではNo start date)」のように表示し、カレンダーに載らない理由がひと目でわかる。
保存されていない既存イベントの開始日時と終了日時を入れ直す

更新後、旧バージョンで日時が抜けたままのイベントは自動修正されない。イベント一覧から対象を見つけて、開始日時と終了日時を入れ直す必要がある。
日時の入れ直しは、各イベントを開いて保存しなおすだけで済む。
イベント一覧で開始日時が空の記事を特定する
Beacon Eventsは開始日時を持たないイベントを一覧上で明示するため、その表示を目印に対象を選ぶ。英語表示のままの場合は「No start date」というラベルを探す。
入力の途中で保存しないための注意点
日時フィールドは日付部分と時刻部分が揃うまで入力を完了させる。特に時刻を編集した直後は一瞬値が空になるため、更新ボタンを押す前にフィールド全体が確定表示になっていることを確認する。
REST APIとwp_postmetaで保存状況を確認する

日時が保存されているかは、REST APIのレスポンスかデータベースの wp_postmeta テーブルで確認できる。REST APIの場合、ブラウザで次のURLにアクセスし、該当イベントのメタフィールドを確認する。
/wp-json/wp/v2/(イベント投稿タイプ)/(投稿ID)レスポンスの meta セクションは次のようになっている。
{
"id": 123,
"meta": {
"_beacon_start": "",
"_beacon_end": ""
}
}ここで _beacon_start と _beacon_end が空文字列なら、イベントの開始日時と終了日時はまだ保存されていない。REST APIで確認すると、表示上の入力状態と実際の保存状態を切り分けられる。
直接wp_postmetaを書き換える方法は最終手段
旧バージョンでの回避策として wp_postmeta を直接更新する方法があるが、保存形式を誤るとカレンダーが日時を正しく解釈できなくなる。管理画面から入力しなおす方が安全だ。
同じ問題を再発させないための確認ポイント

- 開始日時と終了日時は日付と時刻の最後の項目まで入力し終えてから更新する
- 入力欄の下に未保存の警告が出ている場合は更新ボタンを押さない
- 保存後はイベント一覧で開始日時が表示されているか確認する
- Beacon Eventsは常に最新版へ更新しておく
よくある質問
日時の入力欄に表示されているのに保存されないのはなぜですか?
日時の途中までしか入力されていないと、ブラウザは見た目の表示にかかわらず入力欄全体を空の値として扱います。午前・午後の指定や時刻の最終桁を設定しないまま更新すると、データベースには何も書き込まれません。
保存されなかったイベントはどのバージョンから修正されますか?
入力が未完了のまま保存できた問題は0.18.1と0.18.2で修正されています。その後も改善が続いており、本記事執筆時点の最新版は0.27.0です。このバージョン以降に更新して日時を入れ直せば保存されます。
REST APIで _beacon_startと _beacon_endが空か確認する方法は?
該当するイベントのREST APIレスポンスのmetaフィールドを確認します。_beacon_startと _beacon_endが空文字列なら開始日時と終了日時は未保存です。表示上は入力されていても保存されていない状態を特定できます。
最新版に更新しても日時が保存されない場合はどうすればいいですか?
まず日時を最後の項目まで入力しているかを確認します。それでも保存できない場合は、テーマや他のプラグインとの競合が考えられます。標準テーマに切り替え、他のプラグインを一時的に無効化して切り分けます。
保存されていないイベントが大量にある場合はどう直せばいいですか?
管理画面で1件ずつ開いて入れ直すのが最も安全です。どうしても大量の件数を一括で直す必要がある場合は、REST APIで正しい日時情報を送る方法もありますが、保存形式に合わせた値を指定する必要があります。
この記事のポイント
- Beacon Eventsで日時が保存されない主因は、日時入力が未完了のまま更新ボタンを押すこと
- 未完了の日時はブラウザが空の値として扱い、wp_postmetaの _beacon_startと _beacon_endに何も書き込まれない
- 最新版(0.27.0)に更新すると、未保存の表示と更新ボタンの制御で同じ操作を防げる
- 旧バージョンで日時が抜けたイベントは、1件ずつ開いて日時を入れ直す
- 保存状況はREST APIのmetaフィールドで確認できる

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

Elementor更新で重大なエラーが発生して管理画面に入れない時の復旧方法
Elementorを更新した直後に「このサイトで重大なエラーが発生しました」と表示され、管理画面から締め出された場合は、まずWordPressが自動送信するリカバリモードのメールを確認する。メールが見つからないなら、FTPでElementorフォルダをリネームして一時的に無効化し、PHPバージョンが7.1 / 7.3などの古い状態ならPHP 8.xへ更新してからプラグインを戻す。
なぜElementor更新で重大なエラーが起きたのか

今回のトラブルの根本原因は、サポートが終了した古いPHPバージョンのままElementorを最新版へ更新したことだ。PHP 7.1と7.3はどちらもセキュリティ修正を含む公式サポートがすでに終了している。一方、Elementorの現行バージョンはPHP 7.4以上で動作し、PHP 8.xを推奨している。
古いPHPの環境で最新版のElementorを有効化すると、プラグインの新しいコードが古いPHPでは解釈できず、サイト全体が致命的なエラーで停止する。WordPress 5.2以降はこうした致命的なエラーを検知すると自動的にサイトを「技術的な問題が発生」した状態にして、管理画面もフロント側もアクセスできなくする仕組みになっている。
つまり、プラグインの更新操作そのものが悪かったのではなく、「動作要件を満たさない環境のままプラグインだけ先に最新化してしまった」ことが問題だ。順番を逆にして、先にPHPを8.xへ移行してからElementorを更新していれば、このエラーはほぼ確実に回避できていた。
古いPHPのままプラグインだけ最新化すると、互換性が切れてサイト全体がエラーになる。
管理画面に入れない状態を復旧する手順

管理画面から締め出された状態は、次の順番で対処すれば短時間で復旧できる。一番確実なのはFTPでElementorプラグインのフォルダ名を変更して強制的に無効化する方法だ。
復旧は「メール確認 → プラグイン無効化 → 再ログイン → PHP更新」の順で進める。
リカバリモードのメールが届いていないか確認する
WordPressが重大なエラーを検知すると、登録されている管理者メールアドレス宛に「あなたのサイトで技術的な問題が発生しました」という件名のメールが自動送信される。このメールにはリカバリモードへログインするための専用リンクが記載されており、リンクからアクセスするとエラーが起きた状態のまま管理画面へ入れる。
ただし、このメールは「新規ユーザー登録」や「コメント通知」など他のWordPress通知メールと同じ送信元から届くわけではなく、使用しているメールサーバーの設定によっては迷惑メールフォルダに入っていることもある。受信トレイに加えて迷惑メールフォルダも確認する。
リカバリモードのリンクは有効期限が1日程度と短い。メールが届いていた場合は早めにクリックし、管理画面へ入れたら最初に該当プラグインを無効化する。
FTPでElementorフォルダをリネームして強制的に無効化する
リカバリモードのメールが見つからない場合は、FTPソフトやレンタルサーバーのファイルマネージャーを使ってプラグインを手動で無効化する。サイトのファイルに直接アクセスできるため、管理画面に入れない時でも確実に復旧できる。
接続先はWordPressをインストールしたディレクトリで、その中の /wp-content/plugins/ フォルダを開く。そこにある elementor というフォルダ名を elementor_disabled のように変更するだけでよい。フォルダ名が変わるとWordPressはプラグインを認識しなくなり、エラーの原因になっていたElementorが読み込まれなくなる。
この状態で管理画面にアクセスすると、WordPressの標準ログイン画面が通常どおり表示される。ログイン後、プラグイン一覧を見るとElementorが「無効」になっていることが確認できる。
全プラグインを無効化して切り分ける場合
Elementorを無効化してもまだ管理画面に入れない場合は、プラグインフォルダ全体を一時的にリネームして全プラグインを一括で無効化する手もある。/wp-content/plugins/ を /wp-content/plugins_disabled/ に変更すれば、すべてのプラグインが読み込まれなくなる。
その後管理画面へ入れたら、フォルダ名を元に戻してから1つずつプラグインを有効化していく。問題を起こしているプラグインを特定するための切り分け作業だ。ただし、テーマ側に原因がある場合はこの方法では解決しないため、その場合は標準テーマへ切り替えることも検討する。
登録されている管理者メールアドレスを確認する方法

WordPressからの通知メールがどのアドレスに送られているかわからない場合、データベースを直接確認するのが確実だ。レンタルサーバーの管理画面からphpMyAdmin(データベース管理ツール)にアクセスできれば、数クリックで確認できる。
phpMyAdminでwp_optionsテーブルを調べる
phpMyAdminを開いたら、まず対象のWordPressサイトで使っているデータベースを選択する。左側の一覧からWordPress用のデータベースをクリックし、その中の wp_options というテーブルを開く。テーブル名の先頭部分(プレフィックス)はインストール時に変更している場合があり、wp_options ではなく wp2_options や wpx_options のような名前になっていることもある。
テーブルを開いたら、option_name カラムの中から admin_email という行を探す。その行の option_value に表示されている値が、WordPressに登録されている管理者メールアドレスだ。SQLで検索する場合は次のようなクエリを実行する。
SELECT option_name, option_value FROM wp_options WHERE option_name = 'admin_email';このアドレス宛にリカバリモードのメールが送信されている。もし自分がそのメールアドレスにアクセスできないなら、必要に応じてここで別のアドレスへ書き換えることも可能だが、その前にFTPでの復旧を試すことを優先する。
サーバーの管理画面からメール設定を確認する
phpMyAdminにアクセスできない場合でも、レンタルサーバーのコントロールパネルにメールアカウント一覧やフォワーダー設定が表示されることがある。WordPressからの通知は、多くの場合「WordPress<wordpress@ドメイン名>」のような送信元になっているため、サーバー側のメールログや送信履歴に手がかりが残っている場合もある。
また、WordPressの初期セットアップ時に使ったメールアドレスがそのまま管理者メールとして登録されているケースが非常に多い。サイトのドメインに紐づくメールアドレスや、普段使っている代表メールアドレスを片っ端から確認すると見つかることもある。
PHP 7.1 / 7.3からPHP 8.xへ安全に移行する方法

今回のエラーを根本から解決するには、PHPバージョンを7.xから8.xへ引き上げる必要がある。PHP 7.1と7.3はすでにサポートが終了しており、WordPress本体や主要プラグインの動作要件を満たしていない。Elementor以外のプラグインでも、今後更新のたびに同じようなエラーが起きる可能性が高い。
レンタルサーバーの管理画面でPHPバージョンを切り替える
多くの国内レンタルサーバーでは、コントロールパネルからPHPバージョンを簡単に切り替えられる。メニューに「PHPバージョン管理」や「PHP設定」のような項目があり、ドロップダウンから「PHP 8.1」「PHP 8.2」などを選択して保存するだけで変更が反映される。
切り替え作業は通常数分以内に完了し、サーバーの再起動は不要だ。ただし、共有サーバーの場合、同じサーバー内の他のユーザーには影響しないようサイト単位で設定できる仕組みになっていることが多い。操作に自信がない場合は、契約しているサーバー会社のサポートに「PHPバージョンを上げたい」と伝えれば案内してもらえる。
PHPを上げる前に互換性を確認する
PHPを8.xへ変更する前に、現在使っているすべてのプラグインとテーマがPHP 8.xに対応しているかを確認する。対応していないプラグインが残っていると、PHPを切り替えた瞬間に別の致命的エラーが発生する恐れがある。
確認方法は、各プラグインの公式ページや更新履歴を読むのが基本だ。更新が長期間止まっているプラグインはPHP 8.x未対応の可能性が高い。そうしたプラグインは、PHPを上げる前に代替プラグインへ乗り換えるか、開発元に対応状況を問い合わせる。
できれば本番サイトでいきなり変更するのではなく、ステージング環境(テスト用の複製サイト)でPHPを切り替えて動作確認してから本番に反映するのが安全だ。ステージング機能を提供しているサーバーなら、管理画面から数クリックで複製を作れる。
よくある質問
リカバリモードのメールが届かないのはなぜですか
考えられる原因は、管理者メールアドレスが自分が確認できるものではない、メールが迷惑メールフォルダに振り分けられている、サーバーのメール送信機能が停止している、の3つが多い。phpMyAdminでadmin_emailの値を確認し、迷惑メールフォルダも含めて見直すのが近道だ。
FTPが使えない場合はどうすればよいですか
レンタルサーバーのコントロールパネルには通常、ブラウザ上でファイルを操作できるファイルマネージャーが用意されている。FTPソフトの設定がわからない場合は、このファイルマネージャーで同じ操作を行える。
PHPを8.xに上げるとサイトが壊れるのではと不安です
PHP 7.xから8.xへの移行では、古いコードの書き方に依存したテーマやプラグインが動かなくなる可能性はゼロではない。だからこそ、事前の互換性確認とバックアップが重要になる。バックアップがあれば、万一問題が出ても元の状態へ戻せる。
Elementorを無効化したらレイアウトは消えてしまいますか
Elementorで作成したページのレイアウトデータはデータベースに保存されているため、プラグインを無効化しても消えることはない。ただし一時的にページの見た目が崩れたり、ショートコードがそのまま表示されたりする。フォルダ名を元に戻して有効化すれば、元のデザインに戻る。
更新前に取っておくべきバックアップは何ですか
サイト全体のファイルとデータベースの両方をバックアップする。WordPressはファイルとデータベースが分離しているため、片方だけでは完全に復元できない。プラグインを使ったバックアップか、サーバーのバックアップ機能を活用するのが現実的だ。
この記事のポイント
- 古いPHPのままElementorを更新すると重大なエラーが起きる
- FTPでElementorフォルダをリネームすれば最短で復旧できる
- 管理者メールはphpMyAdminのwp_optionsテーブルから確認できる
- PHPは7.xから8.xへ移行してからプラグインを更新する
- 更新直前にはデータベースとファイルの完全バックアップを取る

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

Burst Statisticsのアップグレードが3.69%で止まる原因と直し方
Burst Statisticsのデータベースアップグレードが3.69%で停止し、SQLエラーが何度も記録される場合、wp_optionsテーブルに残ったアップグレード実行フラグを削除すると移行処理がリセットされ、症状が収まる。
アップグレードが3.69%で止まりSQLエラーが続く原因

Burst Statisticsはアクセス解析プラグインだ。バックグラウンドでデータベースの移行処理を実行する際、進捗状況をwp_optionsテーブルのオプションとして記録する。このフラグが何らかの理由で削除されずに残ると、管理画面には「バックグラウンドでアップグレードが実行中です。現在の進捗は3.69%です」という趣旨の通知が表示され続ける。
照合順序の不一致が比較処理を止める
最初に起こりやすいのが照合順序(コレーション)の不一致だ。データベースのテーブルやカラムごとに文字の並び順と比較規則を定める設定があり、MySQLではutf8mb4_unicode_ciとutf8mb4_unicode_520_ciのように複数の種類が存在する。
統計テーブルのplatformカラムとプラットフォームテーブルのnameカラムを比較しようとしたとき、双方の照合順序が異なると「照合順序の混在により演算が実行できない」というSQLエラーが発生する。比較処理はそこで停止し、移行処理全体が失敗に終わる。
存在しないカラムを参照してエラーが繰り返される
移行処理が途中まで進行した状態で中断すると、データベースのスキーマと実行中のクエリが噛み合わなくなる。アップグレード処理が統計テーブルのreferrerカラムを参照しようとしても、そのカラムは既に削除済みか存在しないため、「Unknown column」というエラーがphpエラーログに数百件単位で蓄積する。
さらにホスティング移行などのタイミングでデータベースの取り込みが不完全だった場合、page_idカラムが欠落するなど別の不整合も発生しやすい。結果として複数のSQLエラーが同時期に記録される。
アップグレードフラグが残留して移行を再実行し続ける
移行処理が失敗すると、本来なら終了時に削除されるはずのフラグ(burst_db_upgrade_move_referrers_to_sessions)がwp_optionsテーブルに残る。プラグインはアクセスのたびにこのフラグの存在を確認し、未完了と判断して移行を再実行しようとする。ところが移行は既に実行済みで、カラム構成が変わってしまった状態のため、何度実行しても同じSQLエラーで失敗する。
これが数ヶ月にわたって進捗が3.69%のまま停止しているように見える仕組みだ。フラグを削除して「移行は完了済み」と認識させれば、再実行ループは止まる。
アップグレードフラグを削除して移行をリセットする手順

症状を解消するには、残留したフラグをwp_optionsテーブルから削除する。SQLを直接実行する方法と、PHPのスニペットで削除する方法の2つがある。まず全体の流れを確認しよう。
この手順では取り除くのはフラグだけであり、アクセスログや統計データが保存されたテーブルには手を加えない。
phpMyAdminでSQLを実行して削除する
レンタルサーバーの管理画面からphpMyAdminを開き、対象サイトのデータベースを選択する。SQLタブに以下のクエリを入力して実行する。
DELETE FROM wp_options WHERE option_name = 'burst_db_upgrade_move_referrers_to_sessions';WordPressのデータベースプレフィックスがwp_以外の場合(例えばwp_ab12_など)は、wp_optionsの箇所を実際のプレフィックスに置き換える。プレフィックスはwp-config.phpの「$table_prefix」で確認できる。
実行後に「1行が削除されました」のような結果が表示されれば成功だ。該当行が存在しない場合は既に削除済みか、プレフィックスが異なる可能性がある。
PHPスニペットで削除する方法
phpMyAdminにアクセスできない場合や、コードから安全に削除したい場合は、以下のPHPスニペットを子テーマのfunctions.phpに一時的に追加する方法がある。
add_action( 'admin_init', function () {
delete_option( 'burst_db_upgrade_move_referrers_to_sessions' );
} );このコードを追加したら、WordPress管理画面を一度開く。admin_initフックが実行され、フラグが削除される。削除を確認したら、このコードは必ずfunctions.phpから取り除く。残しておくと管理画面を開くたびに削除処理が走り続けるためだ。
functions.phpを直接編集せずに済ませたい場合は、Code Snippetsなどのコード管理プラグインを使って同じコードを一時的に実行する手もある。
削除後に確認すること
- Burst Statisticsのダッシュボードから進捗表示が消えたか
- phpエラーログに新しいSQLエラーが記録されていないか
- 統計グラフや概要データが正常に表示されるか
- プラグインを無効化せずに済むか
進捗表示が消えて統計も正常に表示されれば、この問題は解決している。もし通知が残る場合は、キャッシュ系プラグインの一時停止やブラウザキャッシュの削除も試すとよい。
照合順序の不一致を確認して統一する

フラグを削除しても照合順序の混在エラーが再発する場合は、テーブル間の照合順序を統一する必要がある。特にBurst Statisticsが作成したテーブルと、WordPress標準テーブルの間で照合順序が異なる場合に比較演算が失敗しやすい。
各テーブルの照合順序を調べる
phpMyAdminで該当データベースを開き、Burst Statistics関連のテーブルを選択して「構造」タブを確認する。各カラムの「照合順序」列にutf8mb4_unicode_ciやutf8mb4_unicode_520_ciなどの値が表示される。統計テーブルとプラットフォームテーブルで値が異なると、比較演算でエラーが発生する。
WordPressの標準データベースは、多くの環境でutf8mb4_unicode_ciが使われている。新旧のMySQLバージョンが混在するサーバー移行を経ると、utf8mb4_unicode_520_ciのテーブルが混ざることがある。
照合順序を統一するSQL
照合順序を統一するには、ALTER TABLEでテーブル全体を変換する。以下は統計テーブルをutf8mb4_unicode_ciに揃える例だ。
ALTER TABLE wp_burst_statistics CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;実際のテーブル名やプレフィックスは環境によって異なるため、phpMyAdminでBurst Statistics関連のテーブル名を確認してから実行する。1つずつ確認し、不一致があるテーブルだけを変換すると安全だ。
照合順序の変換は既存データの文字情報を保持したまま実行されるが、作業前に必ずデータベース全体のバックアップを取る。変換後は統計画面とサイトの表示を確認する。
統計データを保ったままプラグインを復旧する

フラグの削除や照合順序の統一で解決しない場合、プラグインの再インストールを検討する。ただし、Burst Statisticsが記録したアクセスログを消さないように、データ保持の設定を確認してから進める。
アンインストール時にデータを残す設定
プラグインの設定画面に「データ保持」や「アンインストール時にデータを削除する」という趣旨の項目がある場合、そのチェックがオフになっていることを確認する。オフのままアンインストールすると、データベーステーブルが残り、再インストール後に統計が復元される。
この設定が見当たらない場合は、作業前にphpMyAdminからデータベース全体をエクスポートして手元に保存しておく。これだけで再インストールの失敗リスクを大幅に下げられる。
プラグインを無効化して再インストールする
WordPress管理画面の「プラグイン」からBurst Statisticsを無効化する。その後、プラグイン一覧から削除し、「新規プラグインを追加」から最新版をインストールして有効化する。データテーブルが残っていれば、統計は引き継がれる。
再インストール後は、ダッシュボードの進捗表示が消えていることと、統計データが正常に表示されることを確認する。もしエラーログに新しいSQLエラーが記録される場合は、照合順序の不一致を再度確認する。
よくある質問
アップグレードフラグを削除すると統計データは消えるのか
消えない。wp_optionsテーブルのフラグは移行処理の進捗管理専用であり、アクセスログや集計データは別のテーブルに保存されている。フラグの削除は「移行処理が完了済み」とプラグインに知らせるだけだ。
phpMyAdminが使えない場合はどうするのか
PHPスニペットを子テーマのfunctions.phpに追加して削除できる。Code Snippetsなどのプラグインを使えば、functions.phpを直接編集せずに同じ処理を実行できる。いずれも削除確認後にコードを取り除くこと。
SQLを実行しても進捗表示が消えない場合は
まずデータベースプレフィックスが正しいか確認する。wp_以外のプレフィックスを使っている場合、SQL文のwp_optionsの箇所を置き換える必要がある。また、ページキャッシュやオブジェクトキャッシュが有効だと管理画面の表示が古いままになるため、キャッシュのクリアも試す。
照合順序の統一をしないとどうなるのか
フラグ削除後も再びSQLエラーが発生し、統計の集計が正しく動作しない可能性がある。特にサーバー移行を経た環境では、テーブルごとに照合順序がばらつきやすい。不一致を解消しておくと、今後のプラグインアップデートにも強くなる。
プラグインを削除して再インストールしても問題ないのか
データ保持の設定が正しければ問題ない。ただし、フラグ削除という軽量な対処で解決できるケースが多いため、再インストールは最後の手段として考えるのが安全だ。どうしても再インストールする場合は、作業前に必ずデータベースをバックアップする。
この記事のポイント
- アップグレードの進捗が3.69%で止まる原因は、wp_optionsに残った実行フラグ
- burst_db_upgrade_move_referrers_to_sessionsを削除すると再実行ループが止まる
- SQLとPHPスニペットの2通りの削除方法がある
- 照合順序の不一致もSQLエラーの引き金になるため確認する
- 再インストール前には必ずデータベースのバックアップを取る

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

ads.txtが消えた時の復旧手順とプラグイン更新後の対処法
Ads.txt管理プラグインをバージョン2.0.29に更新した後、設定では有効になっているのにads.txtが消えて復元できない場合、プラグインの仮想配信が更新によって止まっていることが主な原因だ。設定の再保存、キャッシュの削除、物理ファイルの作成という順に確認すれば、ほとんどのケースで復旧できる。
なぜプラグイン更新後にads.txtが消えるのか

ads.txtは広告配信の透明性を保つためのテキストファイルで、ドメインのルートに置く。Google AdSenseや広告配信プラットフォームがこのファイルを読み取り、認証済みの広告販売元かどうかを確認する。ファイル自体は数行のテキストだが、広告収益に直結するため、消えたまま放置すると広告配信の承認に影響が出る。
多くのads.txt管理プラグインは「仮想配信」と呼ばれる仕組みを採用している。物理的なファイルをサーバーに置くのではなく、WordPressのURLルーティング機能を使って /ads.txtへのアクセスを横取りし、データベースに保存した内容をその場で返す方式だ。この仕組みは便利だが、プラグイン更新時にURLルーティングの設定(リライトルール)が更新後のコードと整合しなくなることがある。その結果、設定画面では有効と表示されていても、実際の配信処理が動いていない状態に陥る。
もう1つの原因はキャッシュだ。更新前に /ads.txtが一時的に404エラーや空の応答を返した場合、その古いエラー応答がサイトキャッシュやCDNに残ってしまう。設定を直しても、キャッシュが期限切れになるまでエラーが返り続けるため、「復元しても直らない」ように見える。
ads.txtが正しく配信されているか確認する

まずは実際に /ads.txtが配信されているか、ブラウザで直接確認する。確認にはシークレットウィンドウ(プライベートブラウジング)を使う。通常のブラウザウィンドウではローカルキャッシュの影響で古い結果が表示されるため、配信状況を正確に判断できない。
確認するURLは、自サイトのドメインの直後に /ads.txtを付けたものだ。たとえば https://example.com/ads.txt という形になる。このexample.comの部分を自分のドメインに置き換えてアクセスする。
正しく配信されている場合は、設定した広告販売元の行がテキストで表示される。404エラーや白紙ページが出る場合は、仮想配信が止まっているか、キャッシュが古い応答を返している。
仮想ads.txtを復旧させる方法

配信が止まっていることを確認したら、以下の順番で復旧作業を進める。最初の設定再保存だけで直ることが多いが、キャッシュ削除まで進めると確実だ。
STEP 2で直ればそれ以上の作業は不要だ。直らなければSTEP 3、それでもだめならSTEP 4に進む。
プラグイン設定を再保存する
ads.txt管理プラグインの設定画面を開き、内容を確認した上で保存ボタンを押す。設定を変更していなくても、保存操作を行うことでプラグイン内部の配信フックが再登録される。保存後、数分待ってからシークレットウィンドウで /ads.txtに再度アクセスし、復旧したか確認する。
パーマリンク設定を再保存する
プラグインの再保存で直らない場合は、WordPressの「設定」→「パーマリンク」を開き、何も変更せずに「変更を保存」を押す。これによりデータベースに保存されているリライトルールが再構築される。ads.txt管理プラグインは独自のリライトルールを使うことが多いため、この再構築で仮想配信が復活することがある。
サイトキャッシュとCDNキャッシュを削除する
キャッシュ系プラグインを利用している場合は、その管理画面から全キャッシュを削除する。CDNを利用している場合は、CDN側の管理画面からキャッシュのパージも実施する。キャッシュを削除したら、シークレットウィンドウで /ads.txtを再確認する。キャッシュが原因だった場合は、この時点で正しい内容が表示される。
物理ads.txtをFTPで作成する手順

仮想配信がどうしても復旧しない場合は、物理的なads.txtファイルをサーバーのドキュメントルートに直接作成する方法がある。FTPソフトがあれば数分で完了する。
ads.txtの基本フォーマット
ads.txtの各行は、認証済み広告販売元のドメイン、販売元ID、関係性、認証IDをカンマ区切りで書く。Google AdSenseの場合の例は次のとおりだ。
google.com, pub-0000000000000000, DIRECT, f08c47fec0942fa0pub-0000000000000000の部分は自分のAdSense発行元IDに置き換える。認証IDのf08c47fec0942fa0はAdSenseの公式ドキュメントに記載されている固定値だ。他の広告ネットワークを利用している場合は、各ネットワークの管理画面でads.txt用の行を確認してそのまま記載する。
FTPでドキュメントルートにアップロードする
FTPソフトでサーバーに接続し、public_htmlまたはhttpdocsなどのドキュメントルートディレクトリにファイル名ads.txtでアップロードする。文字コードはUTF-8、改行コードはLFを選ぶ。ファイルのアクセス権は644で問題ない。アップロード後、シークレットウィンドウで /ads.txtにアクセスして内容が表示されるか確認する。
プラグインと物理ファイルの優先関係
ads.txt管理プラグインが有効な状態では、仮想配信が物理ファイルより優先されることが多い。物理ファイルをアップロードしても、プラグインの仮想配信が働いていると内容が上書きされてしまう。物理ファイルを利用する場合は、プラグインを無効化するか、物理ファイルと同じ内容をプラグイン設定にも反映させておく。二重管理を避けるため、どちらか一方に統一するのが安全だ。
それでも直らない場合の切り分け手順

ここまでの手順で復旧しない場合は、プラグイン同士の競合や更新自体の不具合を疑う。順番に切り分けていく。
全プラグインを無効化して切り分ける
一時的にads.txt管理プラグイン以外の全プラグインを無効化し、標準テーマに切り替える。その状態で /ads.txtにアクセスして、復旧するか確認する。復旧した場合は、1つずつプラグインを有効化して、どのプラグインが競合しているかを特定する。競合相手が特定できたら、そのプラグインの設定を調整するか、代替プラグインを検討する。
旧バージョンに戻す
競合ではなく更新自体が原因の場合は、プラグインを旧バージョンに戻すのが確実だ。プラグイン公式リポジトリから旧バージョンのzipファイルをダウンロードし、FTPで現在のプラグインディレクトリを上書きする。またはWP Rollback系のプラグインを使うと、管理画面から数クリックで旧バージョンに戻せる。戻した後は設定を再保存し、/ads.txtが正しく配信されるか確認する。
プラグイン公式サポートに問い合わせる
それでも解決しない場合は、プラグインの公式サポートに問い合わせる。症状(バージョン2.0.29への更新後にads.txtが消えた)、環境(WordPressバージョン、PHPバージョン)、/ads.txtにアクセスした際のHTTPステータスコードを伝えると、回答が早い。更新直後に発生したことを明確に伝えれば、既知の不具合として認識されている場合に対処法を案内してもらえる。
よくある質問
ads.txtがなくても広告配信にすぐ影響は出るのか
ads.txtは広告配信の承認プロセスで定期的に確認される。ファイルが消えた直後に即座に広告が止まるとは限らないが、Googleなどの広告プラットフォームが再クロールした際に不承認や警告の対象になる可能性がある。早めに復旧させるのが安全だ。
仮想ads.txtと物理ads.txtはどちらが優先されるのか
一般的にはプラグインによる仮想配信が優先される。物理ファイルを置いても、プラグインが有効な間は仮想配信が /ads.txtへのアクセスを横取りするため、物理ファイルの内容は反映されない。物理ファイルを使うなら、プラグインを無効化するか設定を統一する必要がある。
プラグインを無効化するとads.txtはどうなるのか
プラグインを無効化すると仮想配信も停止する。物理ファイルが存在しない場合は /ads.txtが404エラーになる。物理ファイルを別途作成している場合は、その内容が配信されるようになる。
旧バージョンに戻すと設定したads.txtの内容は失われるのか
ads.txtの設定内容は通常データベースに保存されているため、旧バージョンに戻しても設定は残る。ただしプラグインによっては更新時に設定形式を変更することがある。念のため、戻す前に設定内容をメモしておくと安心だ。
キャッシュ削除をしても直らない場合は何を試すのか
次に試すのは物理ads.txtの作成だ。それでも直らない場合は、全プラグインの無効化による切り分け、旧バージョンへの巻き戻し、プラグイン公式サポートへの問い合わせという順で進める。
この記事のポイント
- プラグイン更新で仮想ads.txtの配信が止まることがある
- 設定の再保存は最初に試すべき復旧作業
- パーマリンク設定の再保存でリライトルールを再構築できる
- キャッシュ削除はサイト側とCDN側の両方を確認する
- 物理ads.txtはFTP経由でいつでも作成できる
- 直らなければ旧バージョンへの巻き戻しも有効

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WhatsAppボタンがモバイルで機能しない原因とゼロ幅スペースの除去方法
WhatsAppボタンをスマホでタップしても「その電話番号はWhatsAppに登録されていません」と表示され、リンクが機能しないときは、URLに目に見えないゼロ幅スペース(%E2%80%8B)が紛れ込んでいる可能性が高い。対象プラグインを最新版に更新し、設定画面で保存し直すだけで解消できる。
ワッツアップボタンがモバイルで反応しない原因はゼロ幅スペース

WhatsAppボタンのリンクに「ゼロ幅スペース」と呼ばれる不可視の文字が混入すると、モバイル版WhatsAppが電話番号を正しく認識できなくなる。ゼロ幅スペースは、画面上では見えないままURLの一部として送信されるため、一見すると正しいリンクに見える。
具体的には、電話番号の直後に%E2%80%8Bというエンコードされたゼロ幅スペースが付与されると、WhatsApp側で「番号に不正な文字が含まれる」と判断される。ブラウザで直接リンクを開くと動作するのは、デスクトップ版や一部の環境でゼロ幅スペースを無視するためだ。
この問題は、プラグインがWhatsAppリンクを自動生成する際に、プリフィルドメッセージ(あらかじめ入力されるメッセージ)と電話番号の結合処理で発生しやすい。特に、電話番号フィールドの末尾に目に見えないホワイトスペースや手動コピー由来の文字が混入すると、リンク全体が壊れる。
ゼロ幅スペースを除去してWhatsAppリンクを正常化する手順

多くの場合、プラグインのアップデートでこの自動生成ロジックが修正されている。以下の手順で解決できる。
更新後は、念のため一度設定画面を開いて保存し直すことで、古いキャッシュや設定値が残っていても新しいリンク生成ロジックが適用される。
リンクに含まれるゼロ幅スペースを手動で確認する方法
ブラウザのデベロッパーツールを使うと、実際にボタンに設定されているリンクを確認できる。電話番号の直後に「%E2%80%8B」という文字列が見えたら、それが原因だ。正常なリンクは次のようになる。
正しいリンク
https://wa.me/49208883522?text=Hello
不正なリンク
https://wa.me/49208883522%E2%80%8B?text=Helloゼロ幅スペースは見た目に存在しないため、コピー&ペーストで気づかないことがほとんどだ。リンクをメモ帳などのプレーンテキストエディタに貼り付けて、カーソルを動かすと不自然な停止がある場合もある。
プラグインを更新した後も直らない場合の確認ポイント

更新や保存後にも改善しないときは、次を順にチェックする。
電話番号フィールドに隠れた空白や全角文字が残っていないか
設定画面の電話番号フィールドに、コピー&ペースト時に混入した半角スペースや改行、全角数字が含まれていると、ゼロ幅スペースとは別にリンクが壊れる原因になる。電話番号は半角数字のみで入力し、先頭の「+」は国番号として正しく付ける。
プリフィルドメッセージを空にして保存できるか
古いバージョンでは、プリフィルドメッセージを空にできない仕様のプラグインがあった。メッセージ欄に自動挿入される文字列が原因でゼロ幅スペースが付与されるケースでは、メッセージを完全に空にして保存できるか確認する。空にできない場合は、メッセージを短い英数字のみに変更して様子を見る。
ブラウザキャッシュとCDNキャッシュを削除する
設定を保存しても、ブラウザやCDN(コンテンツデリバリネットワーク / 配信網)に古いリンクがキャッシュされていると、スマホでは以前の不正なURLが読み込まれる。キャッシュを削除してから再度確認する。
よくある質問
ゼロ幅スペースとは何か
ゼロ幅スペース(Zero-width space)とは、幅を持たない特殊な空白文字だ。主にテキストの改行位置を制御するために使われるが、URLに混入すると端末やアプリが正常に解釈できなくなる。
WhatsAppボタンだけが機能しなくなる理由は
WhatsAppのモバイルアプリは電話番号のパース処理が厳格で、番号の直後に不正な文字があると認識エラーを返す。他のSNSボタンは許容する場合が多く、問題が顕在化しにくい。
デスクトップでは動作するのにモバイルで失敗するのはなぜか
デスクトップ版WhatsAppやブラウザは、ゼロ幅スペースを含むURLを自動的に無視したり正規化する処理が入るため、同じリンクでも動作する。モバイルアプリはより厳密にURLを検証する。
プラグインを更新せずに手動で修正できるか
可能ではある。デベロッパーツールで該当のボタンのHTMLを編集し、URLからゼロ幅スペースを取り除けば一時的に動く。ただし、テーマやプラグインの更新で元に戻るため、恒久対応としてはプラグイン本体のアップデートが推奨される。
この記事のポイント
- WhatsAppリンクにゼロ幅スペースが混入するとモバイルで番号が認識されない
- プラグインの最新版では電話番号とプリフィルドメッセージの生成処理が修正されている
- 設定画面を開いて保存し直すだけで新しいリンク生成ロジックが適用される
- 改善しない場合は電話番号の全角文字や空白、キャッシュを確認する
- プリフィルドメッセージを空にできると今後の再発防止につながる

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている

WordPressで重大なエラーが表示された時のPHPメモリ不足の対処法
WordPressで「このサイトで重大なエラーが発生しました」と表示される場合、まずPHPのメモリ上限(メモリリミット)を疑う。ログに「Out of memory」が記録されていれば、原因はほぼ特定できたも同然だ。対処は、エラーログの確認、メモリ上限の引き上げ、プラグインの切り分けの3ステップで進める。
なぜ「このサイトで重大なエラーが発生しました」と表示されるのか

このエラーは、WordPress本体・プラグイン・テーマのいずれかが処理中に致命的な失敗(PHPのFatal Error)を起こすと表示される。管理画面の表示では具体的な理由が出ないため、原因を知るにはサーバーのエラーログを見る必要がある。
相談例のあるサイトで実際に記録されていたのは「PHP Fatal error: Out of memory(メモリ不足)」というエラーだ。割り当てられたメモリを使い切ると、WordPressは処理を中断して「重大なエラー」を返す。これが出るページと出ないページがあるのは、ページごとに必要なメモリ量が違うためだ。商品一覧や投稿編集画面など、表示に多くのデータを処理するページほどメモリを消費しやすい。
すべてのプラグインを無効化すると大半のページが開けるが、一部のページだけエラーになる場合も、原因はプラグイン単体ではなく「ページの処理量×プラグインのメモリ消費」の組み合わせで上限を超えている可能性が高い。
上の図は、メモリ不足エラーが起こる仕組みを示したものだ。ページの処理量とプラグインのメモリ消費が掛け合わさり、サーバーが許容するメモリ上限を超えると「Out of memory」が発生する。
エラーログで原因を特定する手順

まず、サーバーのエラーログに何が記録されているかを確認する。ログを見れば、「このサイトで重大なエラーが発生しました」の薄い画面だけではわからない具体的な原因が判明する。
wp-config.phpでデバッグログを有効にする
FTPソフトかレンタルサーバーのファイルマネージャーでWordPressのインストール先にアクセスし、wp-config.phpを開く。ファイル内のルート定数と呼ばれるエリアに、次のコードがすでにあるかを確認する。なければ、ファイルの終わり直前にある赤い注意書きの上あたりに追記する。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );設定を保存したら、エラーが起きるページをもう一度開く。続けて、wp-contentディレクトリの中に「debug.log」というファイルが生成されていないかを確認する。このファイルに、エラーが起きた時刻・原因のファイル・メモリ使用量が記録される。
ログに「Out of memory」があるかを確認する
debug.logを開くと、次のような行が複数記録されている。ここで見るべきは「Out of memory」というキーワードだ。
PHP Fatal error: Out of memory (allocated 41943040 bytes) (tried to allocate 122880 bytes) in /home/example/public_html/wp-includes/html-api/class-wp-html-tag-processor.php on line 2644「allocated」はその時点で使っていたメモリ量、「tried to allocate」はさらに必要としたメモリ量を示す。例にある41943040バイトは約40 MBだが、これは割り当て上限に達した値であり、この数字自体がサーバーの上限を示すとは限らない。しかし、このエラーが複数回出ている場合は、WordPressのメモリ上限が不足していると判断してよい。
ログに「Fatal error: Out of memory」以外のエラーが記録されている場合は、原因が別にある。たとえば「PHP Deprecated」で始まる行は、将来のPHPバージョンで動かなくなる機能の予告であり、当面は致命的ではない。まずは「Fatal」が含まれる行を優先して確認する。
ここまでの手順で、エラーログからメモリ不足が原因かどうかを特定できる。原因がわかったら、次のどちらか、または両方の対処を進める。
PHPのメモリ上限を引き上げる方法

メモリ不足エラーが記録されていた場合、最初に試すのはPHPのメモリ上限を引き上げることだ。変更方法は、レンタルサーバーの管理画面から変更する方法と、wp-config.phpにコードを追記する方法の2つがある。
レンタルサーバーの管理画面から変更する
多くのレンタルサーバーには、PHPバージョンやメモリ上限を管理画面から変更できる機能が備わっている。とくに「PHP設定」「PHPバージョン管理」といった名称のページを探す。メモリ上限が選択式になっている場合は、現在の値より大きいものを選ぶ。たとえば今が128 MBなら256 MBに、256 MBなら512 MBに上げる。
もし管理画面にメモリ上限の設定項目が見つからなければ、サーバー会社のサポートに連絡してメモリ上限を上げてもらえるかを確認するのが確実だ。共用サーバーの場合、上限を自分で変更できない仕様も多い。
wp-config.phpでメモリ上限を指定する
サーバー側で変更できない場合や、すぐに試したい場合はwp-config.phpにコードを追加する。先ほどのデバッグ設定と同じファイルに、次の行を追記する。
define( 'WP_MEMORY_LIMIT', '256M' );これはWordPress側からPHPに対して「利用できるメモリ上限を256 MBに設定する」よう指示するための定数だ。256Mの部分は現在の設定より大きい値に変更してよい。
ただし、レンタルサーバー側でPHPのメモリ上限が128 MBに固定されている場合、このコードを書いても上限は128 MBのまま変わらないことがある。設定後にエラーログへ「Allocated memory size」の値がどう変わったか、WordPressが返す「Out of memory」の数値が変わったかを確認し、変化がなければサーバー側での変更が必要だと判断する。
メモリを上げても直らない場合は原因が別にある
メモリ上限を上げたのにエラーが続く場合は、メモリ上限を超えるほどの異常なメモリ消費を起こしている何かが存在する。典型的なのは、プラグイン同士の競合、テーマの不具合、データ量の増加だ。この場合は次のプラグイン切り分けに進む。
プラグインを切り分けて原因を見つける手順

メモリ上限を上げても改善しない場合、またはメモリ消費が極端に大きい原因を特定する場合は、プラグインの切り分けを行う。手順は、全プラグインを無効化し、サイトが正常に動くかを確認してから、1つずつ有効化して症状が再現するかを見るだけだ。
ただし、プラグインの数が多いほど手間がかかる。11個程度なら1つずつ切り分けても数十分で終わるが、数十個入っている場合はまず「更新が止まっているプラグイン」「不要なプラグイン」から削除して数を減らすとよい。
全プラグインを無効化してエラーが消えるか確認する
WordPress管理画面の「プラグイン」画面を開き、すべてのプラグインのチェックボックスを選択して「一括操作」から「停止」を選ぶ。エラーが出るページが管理画面内のページなら、その画面を開き直す。公開ページのエラーなら、別のブラウザタブで該当ページを開く。
全プラグインを無効化した状態でエラーが消えるなら、原因はプラグインか、プラグインとテーマ・本体の組み合わせにある。エラーが消えないなら、テーマまたはWordPress本体の問題を疑う。
プラグインを1つずつ有効化して症状を再現させる
エラーが消えた状態から、プラグインを1つ有効化しては同じページを再読み込みする。これを繰り返し、エラーが再び出た時点で直前に有効化したプラグインが原因の候補になる。
複数のプラグインが組み合わさってエラーを起こすこともある。1つずつ試して単体では再現しない場合も、直近で更新されたプラグインや、ログにファイル名が出ているプラグインを中心に「何と何を同時に有効化した時に起きるか」を確認する。
原因プラグインを特定した後の対応
原因のプラグインがわかったら、次の順で対処する。そのプラグインが最新版でないなら更新し、更新後も直らない場合はプラグインを無効化したままにして代替手段を検討する。とくにアクセス解析・バックアップ・セキュリティ系のプラグインは、複数が同時に動くとメモリを大きく消費しがちだ。
この切り分け手順は、原因がプラグインにあるかどうかを目で確認する最も確実な方法だ。慣れれば30分程度で完了する。
エラーの再発を防ぐためにできること

重大なエラーが出るたびに同じ調査をするのは手間が大きい。再発を防ぐには、日頃から次の3点を意識しておく。
不要なプラグインは入れない・残さない
プラグインは、サイトの表示や編集画面の読み込みのたびにメモリを消費する。とくにアクセス解析、SEO、バックアップ、セキュリティ、キャッシュなど、常駐して動作するタイプは複数入れると負荷が上がりやすい。使用していないプラグインは削除し、必要最小限の構成を保つ。
PHPバージョンを更新する時は事前に確認する
PHPバージョンを上げると、古いプラグインやテーマが新しいPHPの仕様に対応できず、メモリ消費が急に増える・エラーを起こすことがある。PHPを更新する前に、利用中のプラグインとテーマが新しいPHPバージョンに対応しているかを公式ページや変更履歴で確認する。バージョン更新は、作業前に必ずバックアップを取ってから行う。
デバッグログは定期的に確認する
WP_DEBUG_LOGを有効にしたままだと、気づかないうちにログファイルが肥大化することがある。原因調査が終わったら、WP_DEBUGとWP_DEBUG_LOGをfalseに戻しておく。ただし、不具合の予兆はそこに記録されるので、サイトの調子がおかしいと感じた時に一時的にオンにして確認する習慣をつけると、大きなトラブルを未然に防げる。
よくある質問
「このサイトで重大なエラーが発生しました」とメールが届いたが何をすればいいのか
WordPressの自動メール通知機能がエラーを検知して送ったものだ。まずはサーバーのエラーログを見て、記録されたエラーの種類を確認する。Out of memoryならメモリ上限の引き上げ、特定のプラグインが出力しているエラーならそのプラグインの無効化から始める。
管理画面にすらログインできない場合はどうするのか
FTPソフトかレンタルサーバーのファイルマネージャーからwp-content/pluginsディレクトリにアクセスし、原因と思われるプラグインのフォルダ名を一時的に変更して無効化する。これで管理画面に入れたら、管理画面から原因のプラグインを削除すればよい。
PHPのメモリ上限はどこまで上げてよいのか
共用レンタルサーバーの場合、サーバー会社が定めた最大値までしか上げられない。一般的には256 MBから512 MBの範囲で様子を見て、それ以上必要な場合はVPSや専用サーバー、マネージドWordPressホスティングへの変更を検討する。値を上げすぎるとサーバー全体の負荷が上がり、他の利用者に影響する場合もある。
エラーログに複数のFatal errorが記録されている場合はどうするのか
すべてが同じ原因とは限らないが、連続して記録されている場合は、最初に起きたエラーが後続のエラーを誘発していることが多い。一番古い時刻の「Fatal error」を優先して対処し、その後ログを消してから再度エラーを再現させる。
この記事のポイント
- 重大なエラーの原因はまずエラーログで確認する
- 「Out of memory」はPHPのメモリ不足を意味する
- メモリ上限はwp-config.phpかサーバー管理画面から引き上げる
- プラグインの全停止と1つずつの再有効化で原因を切り分ける
- 再発防止はプラグインの整理と定期的なログ確認が基本

・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
