クライアントのWordPressで「予約投稿が10分遅れる」「バックアッププラグインが夜中に動かない」と言われたとき、最初に疑うのが wp-cron（疑似cron） です。アクセスが少ないサイトや、キャッシュが強いブログでは、訪問者のタイミングまで定期処理が待たされがちです。私もフリーランスで複数案件を触るので、WordPress wp-cron サーバーcron への切り替えを、本番反映前にXserverのサーバーcronで一度試す運用にしています。
本記事は、新規サーバー契約の話ではなく、すでにXserverでWordPressを動かしている人が、wp-cron依存をやめる手順に絞ります。プラグインの入れ替え一覧ではなく、「なぜ遅れるのか → 止める → サーバー側で叩く → 動作確認」までを、制作・運用の視点で書きます。SVGやプラグイン最小化はWordPressプラグインの見直しやSVGのサニタイズ手順と別軸ですが、公開タイミングのズレはクライアント不信感に直結するので、先に直す価値があります。
この記事でわかること
- wp-cronが遅延の原因になる条件
DISABLE_WP_CRONを入れる位置と注意点- Xserverサーバーcronに書くコマンド例
- 切り替え後の確認と、問題時の戻し方
先に結論
- 向いている人: 予約投稿・自動バックアップ・在庫連携など「時間どおり動いてほしい」処理があるWordPress。アクセスが少ないテスト環境や、キャッシュプラグインでフロントが静的化されているサイト
- 向かない人: ローカルだけで触っている個人ブログで、予約投稿を使っていない人（わざわざ触らなくてよい）
- 私のおすすめ: ステージングでDISABLE → サーバーcron設定 → 予約投稿のテストの順。本番はメンテ時間帯に。サーバー契約や移設の全体像はXserver移設チェックリストと納品前チェックリストも参照してください
私は「cronを切ったら壊れる」と怖がるクライアントが多いので、最初は5分後の予約投稿で成功体験を作ってから本番に入ります。
この記事には、Google AdSense による広告およびアフィリエイトリンクが含まれる場合があります。紹介経由で購入や申し込みがあると、私に紹介料が入ることがあります。
wp-cronが遅れる理由（仕組みの整理）
WordPressは、本来サーバー側のcronの代わりに wp-cron.php をHTTPで叩く疑似cron を使います。ページが表示されるたびに「定期処理の時間か？」をチェックし、必要ならバックグラウンドで処理を走らせます。
問題は、誰もサイトに来ない時間帯では処理が起きないことです。さらに、キャッシュやCDNでフロントがほぼ静的になると、管理画面以外のアクセスが減り、wp-cronの起動回数も減ります。結果として次のような症状が出ます。
- 予約投稿が数分〜数十分遅れる
- バックアップ・SEO・在庫系プラグインの「毎日3時」が実際には午前中まで動かない
- WooCommerceなどの定期タスクがまとめて後から実行される
公式ドキュメントでも、高トラフィックサイトではサーバーcronへの移行が推奨される旨が説明されています（執筆時点の一般情報）。体験として、アクセスはあるがキャッシュが強いブログでも同じことが起きます。
事前に揃えるもの
- FTPまたはファイルマネージャで
wp-config.phpを編集できる権限 - Xserverサーバーパネルの「cron設定」画面（サーバーcron）
- サイトのURL（例:
https://example.com）。マルチサイトの場合はネットワークの主URLを確認 - 可能ならステージング。無い場合はバックアップを取ってから本番で行う（プラグイン更新の考え方でもバックアップ前提を書いています）
契約プランにステージングが無い場合は、Xserverのプラン表でステージング可否を確認するか、別サブドメインにクローンを置く方法を検討してください。私は「本番をいきなり触らない」をルールにしています。
手順1：wp-config.phpでwp-cronを無効化する
wp-config.php を開き、「That’s all, stop editing!」の直前に次の1行を追加します。
define('DISABLE_WP_CRON', true);
ポイントは次のとおりです。
- true は小文字で書く（PHPの定数として一般的な表記）
- 既に
define('DISABLE_WP_CRON', false);がある場合は true に変更する - 保存後、フロントが表示されるかだけ軽く確認する（この時点ではサーバーcron未設定なので、定期処理はまだ動きません）
ここで止めると定期処理が完全に止まるため、手順2を同じメンテ枠で続けて行うのが安全です。クライアント案件では「cron停止〜サーバー設定まで最大30分」と事前告知します。
設定を入れた直後に管理画面を開き、致命的エラーが出ないかだけ見てからパネルに移る癖がついています。
手順2：Xserverのサーバーcronに登録する
Xserverのサーバーパネルで cron設定 を開き、新規ジョブを追加します。実行間隔は、多くのサイトで 5分おき（/5 * * * ） から始める人が多いです（一般論）。プラグインのドキュメントが「1分ごと」を要求する場合だけ短くしてください。
コマンド例（URLは自分のドメインに置き換え）:
/usr/bin/curl -sS -o /dev/null "https://example.com/wp-cron.php?doing_wp_cron" >/dev/null 2>&1
補足です。
- https で統一する（リダイレクトループを避ける）
- Basic認証やメンテナンスプラグインでフロントがロックされていると、cronも失敗します。テスト時は一時的に除外設定を確認
- マルチサイトは、ネットワークの主サイトURLで
wp-cron.phpを叩く運用が一般的です（環境により異なるため、ステージングでログを見る）
Xserverのcronはサーバー側で動くため、訪問者がいなくても5分ごとに処理が走る状態になります。新規にレンタルサーバーを検討する場合も、cronが使えることは制作運用の必須条件のひとつです。Xserverの公式資料でcronの可否と回数制限を確認してから契約すると、後からプラン変更で困りにくいです。
手順3：動作確認（予約投稿が一番わかりやすい）
- 管理画面で 現在時刻の5〜10分後に予約投稿を1本作成する
- フロントにログインせず、時間を待つ（ブラウザでサイトを開き続けると wp-cron ではなく人間アクセスで動くため、わざと開かない）
- 予定時刻を過ぎたら、投稿が公開されているか確認する
- バックアッププラグインを使っている場合は、実行ログのタイムスタンプがずれていないか見る
うまくいかないときのチェック順は次です。
wp-config.phpのDISABLE_WP_CRONが true か- cronのコマンドURLが間違っていないか（サブディレクトリ設置の
/wordpress/など） - セキュリティプラグインが
wp-cron.phpをブロックしていないか - サーバーのエラーログ（Xserverパネル）に curl の失敗が出ていないか
プラグイン独自cronとの関係
有名なバックアップ・SEO・EC系プラグインは、WordPressのcron API（wp_schedule_event）に登録されます。サーバーcronで wp-cron.php を叩けば、多くのプラグインタスクもまとめて実行されるのが通常です。例外は、プラグインが「外部のクラウドcron URL」を要求するタイプです。その場合は公式手順を優先し、二重にcronを走らせないよう注意してください。
制作案件では、クライアントに「このプラグインは毎晩動く」と説明しているものほど、wp-cron移行後にログ画面のスクショを一枚残すとトラブルが減ります。納品物の説明テンプレは進捗報告の型に近いですが、cronは技術メモとして別添えでも十分です。
失敗しやすい点
- DISABLEだけしてサーバーcronを忘れる — 定期処理が完全停止し、予約投稿もバックアップも止まります。必ず同じ作業枠でセットにする
- キャッシュ除外とcron — ページキャッシュを「全URL除外」にしすぎてパフォーマンスを落とす必要はありません。cronは
wp-cron.php直叩きなので、フロントのキャッシュ設定とは別問題です - ローカルと本番の取り違え —
wp-config.phpを環境ごとに分け、本番だけ DISABLE する。ローカルでDISABLEすると、開発中のスケジュールイベントが動かなくなることがあります
価格・プラン・パネル画面は執筆時点（2026年9月・日本時間）の情報です。変更されることがあるため、作業前にXserverの公式を確認してください。
よくある質問
Q. wp-cronを止めるとサイトが表示されなくなる？
A. 通常は表示されます。 DISABLE_WP_CRON は定期処理の起動方法を変えるだけで、フロントのPHPテンプレート表示とは別です。もし保存直後にエラー画面になる場合は、追記した行のスペルミスや、引用符の閉じ忘れを疑ってください。私は編集前に wp-config.php をダウンロードしてローカルに退避します。
Q. 5分間隔は重すぎませんか？
A. 多くのブログ・コーポレートサイトでは問題になりにくいのが一般論です。一方、在庫同期やキュー処理が秒単位のサイトは、プラグイン要件とサーバー負荷を見て間隔を調整します。最初は5分で予約投稿が通ることを確認し、必要ならプラグインの推奨値に合わせて短くする、という順が安全です。
Q. 元のwp-cronに戻せますか？
A. 戻せます。 wp-config.php の define('DISABLE_WP_CRON', true); を削除するか false にし、Xserverのサーバーcronジョブを削除すれば、再びアクセス連動のwp-cronに戻ります。ただし遅延問題も戻るので、原因調査のための一時戻しか、恒久運用かを決めてから操作してください。
Q. ステージングが無い案件はどうする？
A. バックアップとメンテ告知が必須です。アクセスの少ない早朝に、DISABLEとサーバーcronを連続で設定し、予約投稿テストまで30分以内で終えるのが目安です。ステージング付きプランへの変更も選択肢なので、長期運用ならXserverのプラン比較をクライアントに共有してもよいです（決定はクライアント側）。
まとめ
WordPress wp-cron サーバーcron への切り替えは、DISABLE_WP_CRON と Xserverのサーバーcronをセットで入れ、予約投稿で確認するのが最短です。制作フリーランスの視点では、見た目のデザインより先に「夜中に動くはずの処理」が信頼に効く場面が多いです。
今日やること: ステージング（またはバックアップ後の本番）で wp-config.php に1行追加 → サーバーcronに wp-cron.php を5分間隔で登録 → 10分後の予約投稿が公開されるか確認してください。問題なければ、バックアッププラグインのログ日時も見て完了です。
関連: WordPressプラグイン最小化 / Xserver移設チェックリスト / 納品前チェックリスト
