何が起きているか
大きなプラグインをアップロードしたり、5,000件の商品を持つWooCommerceカタログをインポートしたり、一括処理を実行したり、管理画面を操作しているときに、PHPがプロセスを途中で強制終了することがあります：
Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/wp-includes/class-http.php on line 1
PHPは1つのスクリプトが実行できる時間に上限を設けています。デフォルトは30秒で、通常のページ読み込みには十分ですが、プラグインのインストール、画像のインポート、一括エクスポートには短すぎます。WordPressがWP_Http経由で内部HTTPリクエストを送信してリモートサーバーが応答しない場合や、大量のデータセットを処理する場合、すぐにこの上限に達してしまいます。
サーバーへのアクセス権限に応じて、この制限を引き上げる方法が4つあります。自分の環境に合ったものから試してください。
手早い修正 — wp-config.php
ファイルシステムにアクセスできる場合、これが最も手早い方法です。wp-config.phpの/* That's all, stop editing! */コメントの前に1行追加します：
<?php
// 実行時間を300秒に引き上げる
set_time_limit(300);
/* That's all, stop editing! Happy publishing. */
set_time_limit()はWordPressが起動するたびにカウントダウンをリセットします。サーバーの再起動は不要で、次のリクエストから変更が有効になります。セーフモードではこの方法はブロックされますが、セーフモードはPHP 5.4以降では廃止されています。
エラーが発生した操作を再試行してください。正常に完了すれば問題は解決です。
恒久的な修正 — php.ini
wp-config.phpの方法はWordPressにのみ影響します。サーバー全体に変更を適用するには、php.iniを直接編集します。
有効な設定ファイルを探します：
php --ini | grep 'Loaded Configuration'
CLIにアクセスできない場合は、代わりに一時ファイルをウェブルートに置きます：
<?php phpinfo();
ブラウザで開き、「Loaded Configuration File」を検索します。
パスがわかったら、このディレクティブを見つけて更新します：
max_execution_time = 300
その後、変更を適用するためにPHPハンドラを再起動します：
# PHP-FPM:
sudo systemctl restart php8.1-fpm
# Apache with mod_php:
sudo systemctl restart apache2
.htaccessによる修正（Apacheのみ）
php.iniにアクセスできない共有ホスティング環境では、.htaccessでPHPディレクティブを上書きできる場合があります。WordPressの.htaccessの先頭に以下を追加します：
php_value max_execution_time 300
多くのcPanelホストではこの方法が使えます。保存直後にサイトが500エラーになる場合、ホストがphp_valueの上書きを無効にしているため、この行を削除してwp-config.phpの方法に切り替えてください。
Nginx + PHP-FPMによる修正
Nginxを使用している場合、.htaccessは機能しません。FPMプール設定とNginxサーバーブロックの2か所に制限を設定します。
FPMプール設定（通常は/etc/php/8.1/fpm/pool.d/www.conf）：
request_terminate_timeout = 300
Nginxサーバーブロック：
fastcgi_read_timeout 300;
両方の変更を同時に適用します：
sudo systemctl restart php8.1-fpm
sudo systemctl reload nginx
共有ホスティング — cPanel / ホスティングパネル
多くの共有ホストではコントロールパネルからPHP設定を直接変更できます。cPanelではソフトウェア → PHPバージョンの選択 → オプションに移動し、max_execution_timeを見つけます。120または300に設定して保存するだけで、再起動は不要です。
設定が見つからない、または変更が反映されない場合、ホスト側で上限が設けられている可能性があります（一般的に60〜120秒）。サポートチケットを開けば、リクエストに応じて引き上げてもらえる場合があります。
テスト用WP-CLIワンライナー
タイムアウトが発生している特定のWP-CLIコマンドを実行したい場合は、設定ファイルを変更せずにインラインで制限を上書きできます：
WP_CLI_PHP_ARGS='-d max_execution_time=300' wp import content.xml --authors=create
修正が有効か確認する
本来の操作を再テストする前に、PHPが新しい値を認識しているか確認します。ウェブルートにcheck-timeout.phpとして以下を保存します：
<?php
echo ini_get('max_execution_time');
ブラウザでアクセスすると、300（または設定した値）が表示されるはずです。確認後はすぐにファイルを削除してください。診断スクリプトを本番環境に残してはいけません。
その後、元の操作（プラグインのインストール、コンテンツのインポート、一括更新など）を再実行し、最後まで完了することを確認します。
エラーが繰り返し発生する場合
制限を引き上げてもタイムアウトが続く場合、スクリプト自体に問題があります。よくある原因をいくつか挙げます：
- 外部HTTPリクエストのハング — WordPressが応答しないリモートAPIを呼び出しています。スタックトレースが
class-http.phpを指している場合、それが強いヒントです。サーバーから疎通確認をしてみてください：curl -I https://api.example.com - 遅いデータベースクエリ —
wp-config.phpでSAVEQUERIESを有効にして、1秒以上かかるクエリをログに記録します。商品数が10,000件以上のWooCommerceサイトでよく見られる問題です。 - バッチ処理なしのインポート — WooCommerceとWP All Importはどちらもバッチサイズを設定できます。500件を一度に処理しようとせず、1バッチあたり20〜50件に減らしてください。
- WP-Cronの積み重なり —
wp-cron.phpのリクエストが積み重なっている場合は、WP-Cronを無効にして実際のサーバーcronを使用してください。wp-config.phpにdefine('DISABLE_WP_CRON', true);を追加し、以下をスケジュールします：*/15 * * * * curl https://yoursite.com/wp-cron.php?doing_wp_cron > /dev/null 2>&1
どの値を設定すべきか
300秒あれば、ほぼすべてのWordPress操作をカバーできます。定常的なタスクに5分以上かかる場合、それはタイムアウトの問題ではなく設計の問題です。タイムアウトの上限を際限なく引き上げるのではなく、バッチ処理、Action Schedulerによるバックグラウンド処理、またはキューへの処理の委譲を検討してください。