2026年5月30日

WordPressのWP-Cronをサーバーのcronで動かす方法｜DISABLE_WP_CRONとcrontabの設定

サーバー・ホスティング

WordPress の予約投稿、プラグインの定期バックアップ、更新の確認などは、WP-Cron という仕組みで実行されます。WP-Cron は本物の cron（OS のタスクスケジューラー）ではなく、サイトにアクセスがあったときに、実行時刻を過ぎた処理があれば動く仕組みです。

そのため、次のようなことが起こります。

アクセスの少ないサイトでは、予約投稿や定期処理が予定の時刻より遅れる
アクセスの多いサイトでは、ページが表示されるたびに WP-Cron の確認が走る

この記事では、WP-Cron をページの表示から切り離し、サーバーの cron から決まった間隔で動かす手順を説明します。WordPress 公式のプラグイン開発者向けハンドブックでも、システムのタスクスケジューラーから wp-cron.php を呼ぶ方法が紹介されています。

手順1: ページ表示での WP-Cron の起動を止める

wp-config.php を開き、/* That's all, stop editing! Happy publishing. */（「編集が必要なのはここまでです」の行）より上に次の1行を追加します。

define( 'DISABLE_WP_CRON', true );

この設定で止まるのは「ページ表示のついでに WP-Cron を起動する動き」だけです。wp-cron.php を直接呼べば、予定された処理はこれまでどおり実行されます。

この設定だけを入れて手順2を忘れると、予約投稿やバックアップなどの定期処理が動かなくなります。 手順2の cron を登録してから、この設定を入れる順でもかまいません。

手順2: サーバーの cron に登録する

WP-Cron を呼ぶ方法は3つあります。使える方法を1つ選んでください。

方法	向いている環境
WP-CLI で実行する	VPS など、WP-CLI が使える環境（おすすめ）
PHP で `wp-cron.php` を実行する	WP-CLI はないが、cron から PHP を実行できるレンタルサーバー
HTTP で `wp-cron.php` にアクセスする	上の2つが使えない環境

cron を編集するユーザー

VPS では、Web サーバーと同じユーザー（Ubuntu / Debian の Apache・Nginx なら www-data）の crontab に登録します。root で実行すると、プラグインが作るファイルの所有者が root になり、あとで WordPress から書き換えられなくなることがあります。

sudo crontab -u www-data -e

レンタルサーバーでは、管理画面の「cron 設定」などの画面からコマンドを登録します。PHP のパスやドキュメントルートの場所はサーバー会社の案内を確認してください。

方法A: WP-CLI で実行する

5分ごとに、実行時刻を過ぎた処理をすべて実行する例です。--path には WordPress を置いたディレクトリを指定します。

*/5 * * * * /usr/local/bin/wp --path=/var/www/html cron event run --due-now --quiet

wp のパスは環境によって異なるので、which wp で確かめて書きます。cron は環境変数 PATH が最小限の状態で動くため、コマンドは / から始まるフルパスで書きます。

方法B: PHP で wp-cron.php を実行する

*/5 * * * * /usr/bin/php /var/www/html/wp-cron.php > /dev/null 2>&1

PHP のパス（/usr/bin/php）は which php で確かめます。レンタルサーバーでは、PHP のバージョンごとに別のパスが用意されていることがあります。

方法C: HTTP で wp-cron.php にアクセスする

*/5 * * * * curl -s -o /dev/null "https://example.com/wp-cron.php?doing_wp_cron"

URL は自分のサイトに置き換えます。この方法は Web サーバーを経由するため、Basic 認証や IP 制限をかけているサイトでは、サーバー自身からのアクセスが拒否されないか確かめてください。

実行間隔の決め方

WordPress 本体が用意している定期実行の間隔は、最短で1時間ごと（hourly）です。ただし予約投稿は分単位で時刻を指定できるため、5分ごとに実行すれば、遅れはおおむね5分以内に収まります。プラグインによってはもっと短い間隔の処理を登録するものもあるので、使っているプラグインの説明も確認してください。

手順3: 動作を確認する

WP-CLI が使える場合は、予定されている処理と次の実行時刻を一覧で確かめられます。

sudo -u www-data wp --path=/var/www/html cron event list

next_run_relative（次の実行までの時間）の列で、時刻を過ぎたままの処理（「now」のまま残っているものなど）がないかを見ます。cron の登録から数分たっても時刻を過ぎた処理が残っている場合は、cron が動いていない可能性があります。

手動で一度実行して、エラーが出ないかを確かめることもできます。

sudo -u www-data wp --path=/var/www/html cron event run --due-now

wp cron test は「ページ表示での WP-Cron の起動」が働くかを調べるコマンドです。DISABLE_WP_CRON を true にしているとエラーを返すため、この記事の構成では確認に使えません。

実行結果をログに残す

うまく動いているか分からないときは、一時的に出力をファイルに残します。ログファイルは cron を実行するユーザーが書き込める場所に置きます。

*/5 * * * * /usr/local/bin/wp --path=/var/www/html cron event run --due-now >> /var/www/wp-cron.log 2>&1

crontab では % が改行として扱われるため、日付入りのファイル名などで % を使う場合は \% と書きます。原因が分かったら、ログが増え続けないように元の行に戻してください。

マルチサイトの場合

マルチサイトでは、WP-Cron の予定はサイトごとに保存されています。WP-CLI で全サイトを順に実行する例です。

*/5 * * * * /usr/local/bin/wp --path=/var/www/html site list --field=url | xargs -I {} /usr/local/bin/wp --path=/var/www/html cron event run --due-now --url={} --quiet

注意点

cron の登録を消すときは設定も戻す: サーバーを移転するときや cron を止めるときは、wp-config.php の DISABLE_WP_CRON も消すか false にします。忘れると定期処理が止まったままになります。
重い処理と重ならないようにする: バックアップなど時間のかかる処理があるときは、間隔を短くしすぎないようにします。
プラグインのファイルを直接呼ばない: プラグインの定期処理は WP-Cron に登録されているので、wp-cron.php を呼べば実行されます。プラグイン内の PHP ファイルの URL を cron から直接呼ぶ必要はありません。

WP-Cron が動かないときの原因の調べ方は「WP-Cronが動かない場合の原因と対処法」、WP-CLI の cron コマンドは「WP-CLIでcronイベントを確認・実行する方法」を参照してください。

まとめ

WP-Cron はアクセスがあったときに動く仕組みなので、アクセスが少ないと予約投稿などが遅れます。
wp-config.php に define( 'DISABLE_WP_CRON', true ); を書き、ページ表示での起動を止めます。
サーバーの cron から、WP-CLI（wp cron event run --due-now）、PHP、curl のいずれかで5分ごとなどに実行します。VPS では Web サーバーと同じユーザーで実行します。
wp cron event list で、時刻を過ぎた処理が残っていないかを確認します。