WordPressのMaximum execution time exceededを直す方法

最初に結論：処理を特定・分割し、必要な場合だけ実行時間を延ばす

1. エラー全文、ファイルパス、行番号、発生操作を保存する
2. 同じ操作を小さい件数・小さい画像で試す
3. プラグインやインポート機能の分割設定を使う
4. PHPバージョン、メモリ、外部通信の待ち時間を確認する
5. 正常な長時間処理に限り max_execution_time を段階的に変更する

30秒からいきなり0（無制限）へせず、60秒、120秒のように段階的に試します。同じ行で毎回止まるなら、時間不足ではなく不具合や外部通信待ちを疑います。

実行時間超過が示すもの

PHPは一つのリクエストが長時間サーバーを占有しないよう上限を設けています。大量インポート、画像生成、バックアップ、外部API待ち、重いデータベース処理、プラグインのループで上限に達します。エラーファイルと行番号が最重要の手掛かりです。

手順1：エラーログから停止した処理を特定する

PHPエラーログの時刻、ファイルパス、行番号を控えます。 wp-content/plugins/製品名/... なら該当プラグイン、テーマパスならテーマ処理が候補です。

管理画面の操作時刻と一致する記録だけを見ます。古いエラーを現在の原因と決めつけず、同じ操作を一度だけ再現して新しいログを確認します。

手順2：処理量を減らして完了できるか試す

CSVは100件ずつ、画像は数枚ずつ、バックアップはデータベースとファイルを分けるなど、機能が許す範囲で小分けにします。外部API取得はタイムアウト設定や再試行回数を確認します。

小分けで安定するなら、上限不足または一件あたり処理が重い状態です。特定データだけで止まるなら、その行の文字コード、URL、画像形式を調べます。

手順3：PHP設定を段階的に変更する

エックスサーバーのphp.ini設定で対象ドメインを選び、 max_execution_time を60秒など必要範囲へ変更します。プラグイン側に実行時間設定がある場合は、サーバー上限との関係を公式仕様で確認します。

変更後は同じ件数・同じ入力で時間を測ります。時間を増やすたび停止地点も後ろへずれるだけなら、根本的な処理効率を改善します。

延長してはいけないケースと戻し方

CPU使用率が上がり続ける、同じログが大量発生する、外部サイトから応答がない、無限ループが疑われる場合は延長を中止します。対象プラグインを停止し、更新版またはサポートの修正を待ちます。

試験後は変更前の値へ戻すか、運用上必要な根拠を記録します。無制限の0を常用せず、同時アクセスへの影響も確認してください。

症状ごとの判断をもう一段深くする

少量なら成功、大量で失敗

この状態では、まず 処理量と実行時間 を優先します。件数を分割するだけで結論を出さず、変更前の画面・発生時刻・対象URLを残し、同じ条件で一項目ずつ比較してください。別の症状まで同時に出る場合は、個別ページより共通するサーバー設定やWordPress全体の処理を先に確認します。

同じファイル・行で停止

この状態では、まず プラグイン不具合・外部通信 を優先します。製品ログと公式情報を確認だけで結論を出さず、変更前の画面・発生時刻・対象URLを残し、同じ条件で一項目ずつ比較してください。別の症状まで同時に出る場合は、個別ページより共通するサーバー設定やWordPress全体の処理を先に確認します。

画像だけで停止

この状態では、まず 巨大画像・メモリ・画像ライブラリ を優先します。寸法を縮小して比較だけで結論を出さず、変更前の画面・発生時刻・対象URLを残し、同じ条件で一項目ずつ比較してください。別の症状まで同時に出る場合は、個別ページより共通するサーバー設定やWordPress全体の処理を先に確認します。

管理画面全体が遅い

この状態では、まず DB・cron・外部API を優先します。Query Monitorやログで処理を特定だけで結論を出さず、変更前の画面・発生時刻・対象URLを残し、同じ条件で一項目ずつ比較してください。別の症状まで同時に出る場合は、個別ページより共通するサーバー設定やWordPress全体の処理を先に確認します。

管理画面へ入れる場合・入れない場合の進め方

管理画面へ入れる場合

サイトヘルス、対象機能の設定画面、更新履歴を先に確認し、直前の変更を一件だけ戻します。変更後は未ログイン画面を開き、キャッシュされた管理者表示だけで判断しません。

管理画面へ入れない場合

サーバーパネルのファイル管理とエラーログを使い、対象ドメインとWordPress設置先を照合します。フォルダ名変更などの一時停止は対象一件に限定し、元の名前と変更時刻を記録します。復旧後は管理画面から正式な更新・設定を行い、一時変更を放置しません。

サポートへ相談するときに伝える内容

「直りません」だけでなく、記事タイトルの症状が出たURL、発生時刻、エラー全文、直前の操作、再現手順、試した項目と結果、PHP・WordPress・対象製品のバージョンをまとめます。ログに個人情報、Cookie、APIキー、パスワードがあれば伏せてください。

サーバー会社にはHTTP状態・PHPログ・DNSやWAFなど基盤側の確認を、プラグイン提供元には製品名・バージョン・再現操作を伝えます。問い合わせ先を分けると、同じ確認を何度も繰り返さずに済みます。

直ったと判断する条件

対象処理が想定件数まで完了し、生成物や取り込み件数が一致し、PHPログへ新しい実行時間超過が出ず、公開ページと管理画面の応答が悪化していない状態です。

• 停止ファイルと行番号を記録した
• 少量実行で比較した
• 必要最小限の時間へ設定した
• 処理結果の件数を照合した
• 他ページの応答速度を確認した

よくある質問

まとめ：時間を延ばす前に停止処理を特定する

ログのファイルと行、発生操作を照合し、少量実行で処理量依存かを確認します。正常な長時間処理だけ上限を段階的に延ばし、結果件数と他ページへの影響まで見て完了です。