WP-Cronは訪問をきっかけに予定処理を確認するWordPressの仕組みで、サーバーCronは決めた時刻にサーバーから処理を呼び出す仕組みです。 アクセスが少なく、予約メールや在庫同期などを時刻どおり動かしたいサイトでは、サーバーCronへ切り替える価値があります。通常ブログで予約投稿が問題なく動くなら、急いで変更する必要はありません。
この記事では、まずWP-Cronが遅れる条件を確認し、サーバーCronを追加してからWP-Cronを止める安全な順番、二重実行と完全停止を避ける確認方法を説明します。
WP-CronとサーバーCronの違い
| 項目 | WP-Cron | サーバーCron |
|---|---|---|
| 起動 | サイトアクセスをきっかけに確認 | サーバーの時刻設定で呼び出す |
| 低アクセス | 実行が遅れる可能性 | 設定時刻に起動しやすい |
| 設定 | WordPress標準 | サーバーパネルとwp-config.php |
| 失敗リスク | 遅延・重複 | URL・コマンド・間隔の誤りで停止 |
WP-Cronは厳密な時刻保証ではありません。アクセスがない時間は確認が遅れます。一方、サーバーCronも実行先やPHPパスを間違えれば動きません。「サーバーCronにすれば必ず成功」ではなく、実行ログと対象イベントで確認します。
WP-Cronは時計のように毎分動いていると思っていました。訪問がきっかけなら、夜中のアクセスが少ないサイトで遅れる理由が分かります。
仕組みが分かると症状とつながるね。
ただしアクセスが少ないだけでなく、キャッシュやループバック失敗もあるから、サイトヘルスも見よう。
サーバーCronを作れば、WP-Cronをすぐ無効にして軽くできますか？まだ新しい方が動くか自信がありません。
無効化は最後だよ。
まずサーバー側を追加し、イベントが一回動いた証拠を確認してから切り替えようね。
切り替えが必要か確認する
- 「ツール → サイトヘルス」でループバックリクエストや予定イベントの問題を見る。
- 遅れた処理名、予定時刻、実行時刻を記録する。
- 低アクセス時間だけ遅れるか確認する。
-
キャッシュ・WAF・Basic認証が
wp-cron.phpを妨げていないか見る。 - プラグイン固有のCron一覧やログがあれば対象イベントを確認する。
予約投稿だけが一度遅れた場合、タイムゾーンや投稿状態の問題もあります。複数の予定処理がアクセスの少ない時間に継続して遅れるなら、サーバーCronの検討材料になります。
安全な切り替え順
- サーバーパネルのCron設定画面を開く。
- タイムゾーンと最小実行間隔を確認する。
- サーバー公式のWordPress向けコマンドまたはURL呼び出し例を確認する。
- 5分〜15分など、必要性に合う過度でない間隔で追加する。
- WP-Cronをまだ有効のまま、対象イベントが実行されるか待つ。
- 実行時刻とログを確認する。
-
正常なら
wp-config.phpへdefine( 'DISABLE_WP_CRON', true );を適切な位置に追加する。 - 次の実行も成功し、二重実行がないことを確認する。
先に
DISABLE_WP_CRON
を設定しないでください。サーバーCronが未完成のまま無効化すると、予約投稿、通知、プラグインの定期処理がすべて止まる可能性があります。
Cron設定に「毎分」が選べたので、細かいほど遅れなくて安心かと思いました。メール処理が5分ごとなら、毎分にする必要はないんですね。
必要以上に呼ぶと、同じサイトへ余計な負荷を増やすよ。
イベントの必要間隔とサーバーの最小間隔を合わせよう。
実行ログが一回成功したら、wp-config.phpを書き換えていいですか？行を入れる場所も少し不安です。
既存定義の重複がないか検索し、wp-config.php末尾の編集終了を示す案内より前に一度だけ置こうか。
変更前のファイルを保存し、次の実行まで確認すれば戻せるよ。
二重実行・完全停止を見分ける
| 症状 | 原因候補 | 確認 |
|---|---|---|
| メールが2通届く | WP-CronとサーバーCronの二重起動 | 定義とCron設定を照合 |
| 予定処理が全停止 | サーバーCron失敗後にWP-Cron無効 | 一時的に定義を戻し実行先修正 |
| 実行時刻がずれる | サーバーとWordPressのタイムゾーン | 両方の表示時刻を確認 |
| 403・401 | WAF・Basic認証 | Cron呼び出しのアクセス許可 |
完全停止した場合は、まず
DISABLE_WP_CRON
を変更前へ戻し、WordPress標準の呼び出しで動くか確認します。サーバーCronを削除する前にコマンド、PHPパス、対象URL、実行ログを保存します。
Cron設定を管理しやすいサーバー
サーバーCronが必要なサイトは、Cron設定画面、PHPパス、ログ、サポートの分かりやすさを重視します。通常ブログだけなら、この機能のために乗り換える必要はありません。
エックスサーバー
Cron設定、PHP、ログを同じサーバーパネルで確認し、定期処理を安定させたい人向けです。
向いている人： 予約メールや同期処理を時刻どおり動かしたいWordPress運営者
利点： WordPress運用の設定情報とサポートを探しやすい
注意点： Cronコマンドと最小間隔は最新マニュアルを確認し、WP-Cron無効化は実行成功後に行ってください。
料金： スタンダード月額693円〜目安（キャンペーン・契約期間で変動）
エックスサーバーのCron対応と料金を見る
ConoHa WING
WordPress管理とサーバー設定を一つの画面で進め、定期処理の環境も確認したい人の比較候補です。
向いている人： ブログから予約・通知機能へ運用を広げたい人
利点： WordPressかんたんセットアップとPHP環境をまとめて管理しやすい
注意点： Cronの提供条件・設定方法・実行間隔は契約前に公式情報で確認してください。
料金： WINGパック月額659円〜目安（キャンペーン・契約期間で変動）
ConoHa WINGの最新機能と料金を見る広告・PRを含みます。料金・提供条件は公式ページで最新情報をご確認ください。
切り替え後24時間の確認
- 対象イベントが予定間隔で実行
- メール・同期・予約が重複しない
- CPU負荷が周期的に跳ねすぎない
- サイトヘルスに予定イベント遅延がない
- エラーログにCron関連の失敗がない
切り替え前によく迷う3つの判断
WP-Cronは何分間隔で呼び出せばいい？
最初は5〜15分間隔を目安にし、予約投稿や定期メールが許容時間内に動くか確認します。毎分実行は処理回数が増えるため、記事公開が少ない個人サイトで最初から選ぶ必要はありません。締切時刻が厳しい処理だけ、プラグイン仕様とサーバー負荷を確認して短くします。
DISABLE_WP_CRONを追加するだけで軽くなる？
いいえ。無効化だけでは予定処理の呼び出し元が消え、予約投稿や更新確認が止まる可能性があります。先にサーバーCronを登録し、実行履歴や予約投稿で成功を確認してから無効化してください。軽さよりも、処理を取りこぼさない順番が優先です。
切り替え後に予約投稿が動かなかったら？
まずwp-config.phpへ追加した行を一時的にコメントアウトするか削除し、標準WP-Cronへ戻します。次にCronの実行URL、PHPコマンド、サイトURL、間隔を一つずつ確認してください。一度に複数項目を直すと原因が分からなくなるため、変更時刻と結果をメモして再実行します。
切り替え当日だけでなく、翌日の定期処理まで確認すると、日次処理の取りこぼしや二重実行にも気づけます。サーバーパネルの実行履歴、WordPressの予約投稿、通知メールの3か所で同じ時刻を照合できれば、運用を継続できる状態です。
まとめ：新しい呼び出しを確認してから標準を止める
WP-Cronを止めることから始めると思っていました。新しいCronを追加して、一回動いた証拠を見てから切り替えるなら怖さが減ります。
止める前に代わりを働かせる順番を守れたね。
予定処理は見えにくいから、実行時刻と結果を記録することが安心につながるよ。
毎分にしたくなる気持ちは残りそうですが、必要な間隔だけにします。二重メールも翌日まで確認します。
それで大丈夫だよ。
一度の成功で終わらず、次の周期まで見て、問題があれば標準WP-Cronへ戻せる状態を残そうね。
サーバーCronへの切り替えは、追加、実行確認、WP-Cron無効化、次周期確認の順です。アクセスが少ない時間の重要処理にだけ使い、通常運営で問題がなければ変更しません。