WordPressの予約投稿に失敗する原因｜時刻・wp-cron・キャッシュの確認方法

WordPressの予約投稿に失敗し、「予約投稿の失敗」や「予約投稿に失敗しました」と表示された時は、投稿を作り直す前に時刻、投稿ステータス、wp-cronの順で確認してください。原因を分けずに公開ボタンを押すと、その場では直っても次の予約投稿で同じ失敗が起きます。

結論は、まずWordPressのタイムゾーンと予約時刻を確認し、次にwp-cronが呼び出される条件とループバック通信を調べ、最後にキャッシュ、プラグイン、サーバーCronの設定を切り分けることです。公開を急ぐ記事があっても、証拠を残してから手動公開するか判断します。

よこやま良平

20年以上ITエンジニアとしてWordPressの制作・保守・復旧に携わっている、よこやま良平です。予約投稿の失敗は投稿画面だけの問題ではなく、サイトへのアクセス、サーバー通信、時刻設定が重なって起きるため、確認順が重要です。

この記事では初心者が管理画面から確認できる項目を先にし、wp-config.phpやサーバーCronは後半で扱います。設定ファイルを触る前に、ファイルとデータベースのバックアップ、現在値の記録、元へ戻す方法を用意してください。

【無料プレゼント】
WordPress緊急チェック50

「自分のサイトは今、安全なのか？」
自信を持って答えられますか？

こんなお悩みはありませんか？

• ある朝、サイトを開いたら真っ白画面になっていた
• 管理画面にログインできなくなって手が止まった
• 身に覚えのない記事やページが勝手に増えていた
• プラグインを更新したらサイト全体が崩れてしまった
• 以前バックアップを取ったか自分でも覚えていない

累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。

セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。

今すぐ無料ダウンロードする →

※登録後すぐにメールで特典をお届けします

WordPressの予約投稿に失敗した時の確認順

WordPressの予約投稿に失敗した時は、投稿の状態を記録し、サイト時刻、wp-cron、通信、競合の順で確認するのが正解です。いきなりプラグインを停止したりサーバー設定を変えたりすると、単純な時刻の勘違いまで複雑な障害へ広げます。

失敗した投稿のID・予定時刻・現在の状態を記録する

最初に投稿編集画面を開き、投稿ID、予約した日時、現在表示されるステータス、画面の警告文を控えます。失敗した時刻の前後にWordPress本体、テーマ、プラグイン、PHP、キャッシュ、WAFを変更していないかも時系列へ書きます。

同じ時間帯に複数記事を予約していた場合は、全部失敗したのか一部だけかを確認してください。一部だけなら投稿データや重い処理、すべてならwp-cronやサーバー側を優先して疑えます。公開済みへ変わっているのに一覧へ反映されないなら、予約処理よりキャッシュ表示の問題かもしれません。

管理画面の一般設定でサイト時刻を確認する

「設定」から「一般」を開き、タイムゾーン、日付形式、時刻形式、画面に表示される現在時刻を確認します。日本向けサイトなら都市名の東京、またはUTCとの時差が適切に設定されているかを見ます。夏時間を使う地域では固定UTC差より都市名を選ぶ方が安全です。

ブラウザやパソコンの時計が正しくても、WordPressのサイト時刻が違えば予約は別の瞬間に実行されます。投稿編集画面の予約日時と一般設定の現在時刻を並べ、過去時刻になっているのに未公開か、まだ実行時刻前なのかを分けてください。

サイトヘルスで予約イベントとループバックを確認する

「ツール」から「サイトヘルス」を開き、致命的な問題とおすすめの改善を確認します。予約イベントの遅延、ループバックリクエストの失敗、REST APIの問題が表示されていれば、警告文を保存してから原因を調べます。

ループバックとは、WordPressが自分自身のURLへ通信して処理を続ける仕組みです。Basic認証、WAF、IP制限、DNSの不一致、SSL証明書、メンテナンス設定などが自己通信を拒否すると、wp-cronや更新処理が動きにくくなります。

1. 失敗した投稿ID、予約日時、警告文、発見時刻を記録する
2. サイトのタイムゾーンと現在時刻を確認する
3. サイトヘルスで予約イベントとループバックの警告を見る
4. 同時間帯の他の予約記事や定期処理も止まっているか確認する
5. 直前の更新、キャッシュ、WAF、サーバー変更を時系列へ並べる
6. 原因候補を一つずつ検証し、変更ごとにテスト予約する

WordPress修正の依頼前チェックリスト｜原因を切り分ける方法

WordPressの時刻設定で予約投稿がずれる原因

WordPressの予約投稿時刻がずれる原因は、サイトのタイムゾーン、サーバー時刻、利用者の想定時刻を同じものとして扱うことです。投稿予約はWordPressが保存した時刻を基準にするため、まず管理画面上のサイト時刻を基準として確認します。

タイムゾーンを変えると既存の予約時刻にも影響する

タイムゾーンがUTCのままなら、日本時間で入力したつもりでも9時間ずれて見えることがあります。ただし、失敗に気づいた直後にタイムゾーンを変更すると、既存予約の表示や実行予定を誤解する可能性があります。変更前の値と予約一覧を保存してください。

サーバー時刻が正しくてもWordPress設定は別に確認する

管理画面、サーバー管理画面、外部Cronの三つで時刻を比較し、どの時刻表記が基準かを記録します。推測で数時間ずらして予約し直すのではなく、同じ基準時刻へそろえる方が再発を防げます。

予約時刻を過去に変更するだけでは根本解決にならない

失敗した投稿の予約日時を現在より少し前へ変え、更新する方法で公開されることがあります。しかし、これはwp-cronが一度だけ動いただけの可能性があり、次の予約が正常に動く保証にはなりません。

WordPressのアップデート・保守をしないと危険｜放置で起こる深刻なリスクとは

WordPressのwp-cronが予約投稿を実行する仕組み

WordPressのwp-cronは、一般的なサーバーCronと違い、通常はサイトへのアクセスをきっかけに期限が来た処理を確認します。そのためアクセスが少ないサイト、自己通信が遮断されたサイト、wp-cronを無効化したサイトでは、予約投稿が予定時刻を過ぎることがあります。

wp-cronは常時動く時計ではなくアクセスで起動する

標準設定では、ページへアクセスが来るとWordPressが実行時刻を過ぎたイベントを確認し、別リクエストで処理を進めます。毎秒監視する常駐プログラムではないため、予定時刻に訪問がなければ次のアクセスまで遅れることがあります。

アクセスが多いサイトでも必ず安全とは限りません。キャッシュやCDNがWordPress本体へリクエストを渡さない構成、ループバックが拒否される構成、PHP処理が混雑している構成では、訪問数があってもイベントが遅れます。

DISABLE_WP_CRONが有効なら外部Cronが必要になる

wp-config.phpにDISABLE_WP_CRONがtrueで設定されていると、通常アクセスをきっかけにしたwp-cron実行は停止します。負荷対策としてサーバーCronへ移行したサイトでは正常な設定ですが、代わりの定期実行が消えていると予約投稿も止まります。

define( 'DISABLE_WP_CRON', true );

この記述を見つけても、すぐ削除しないでください。サーバー管理画面のCron設定、運用資料、制作会社の引き継ぎ記録を確認し、wp-cron.phpを定期実行する設定があるか、直近の実行結果が成功しているかを見ます。二重実行を避けるため、標準wp-cronと外部Cronのどちらを使うか決めます。

ループバック失敗は認証・SSL・WAF・DNSを分けて見る

サイトヘルスでループバック失敗が出た場合は、HTTPステータス、接続先URL、証明書、名前解決を確認します。Basic認証のあるステージング、管理画面だけのIP制限、国外IP遮断、WAFの誤検知が自己通信を止めることがあります。

SSL化後にhttpとhttpsが混在している、wwwあり・なしが循環する、サーバー移転後に内部DNSが旧IPを向くといった設定も原因になります。表面のページが開くかだけでなく、WordPress自身がサイトURLへ到達できるかをサーバーログとサイトヘルスで確認してください。

WordPressプラグイン更新でエラーが出る時の復旧方法と安全なアップデート手順

WordPressのwp-cron停止を安全に診断する方法

WordPressのwp-cron停止を診断する時は、管理画面の警告、設定ファイル、イベント一覧、サーバーログの順に確認します。本番サイトでイベントを無条件に一括実行すると、メール配信、バックアップ、同期処理まで同時に動くため、対象と影響を理解してから操作してください。

サイトヘルスの警告文と発生時刻を保存する

サイトヘルスに「予約したイベントが遅れています」などの警告がある場合は、イベント名、遅延時間、確認時刻を保存します。画面を再読み込みしただけで警告が消えても、アクセスをきっかけに一時的に処理された可能性があります。

wp-config.phpとサーバーCronの対応関係を確認する

SFTPまたはサーバーファイルマネージャーでwp-config.phpを確認する場合は、変更前ファイルをダウンロードし、閲覧だけで保存し直さないよう注意します。DISABLE_WP_CRONの有無と値、重複定義、環境別設定ファイルの読み込みを調べます。

サーバーCronを使う設計なら、実行間隔、コマンド、対象ドメイン、最後の成功時刻、エラー通知を確認します。サイトURL変更後も旧ドメインを呼んでいる、PHPの場所が変わった、契約プラン変更でCronが無効になったケースがあります。

*/5 * * * * curl -fsS 'https://example.com/wp-cron.php?doing_wp_cron' > /dev/null 2>&1

上は5分ごとにwp-cron.phpへアクセスする考え方の例です。実際のURL、サーバー仕様、認証、負荷、実行方式に合わせる必要があります。エラー出力をすべて捨てたままでは失敗に気づけないため、導入時はログや通知を確認し、安定後も監視方法を残してください。

WP-CLIはイベント一覧を見て対象だけ検証する

SSHとWP-CLIを使える環境では、期限、フック名、次回実行時刻を一覧で確認できます。まず一覧を保存し、遅れているイベントと予約投稿に関係するイベントを特定します。実行権限、WordPressのパス、利用者を間違えると別サイトを操作するため、対象を確認してください。

wp cron event list
wp cron event run publish_future_post

サーバーログでブロックとタイムアウトを確認する

アクセスログでwp-cron.phpのHTTPステータスと応答時間を確認します。403ならWAFや認証、404ならURL、5xxならPHPエラーや資源不足を疑い、PHP・WAF・Cronの各ログを同じ時刻で照合してください。

WordPressバックアップと復元方法｜サイト引越し完全ガイド

WordPressのキャッシュとプラグイン競合を切り分ける

WordPressの予約投稿失敗でキャッシュを疑う時は、「Cronが動かない問題」と「公開済みなのに古い画面が見える問題」を分けてください。ページキャッシュを消せば必ずwp-cronが直るわけではなく、原因を隠すだけになる場合があります。

投稿ステータスが公開済みなら表示キャッシュを確認する

投稿一覧やREST APIでは公開済みなのに、トップページ、カテゴリー一覧、関連記事へ出ない場合は表示キャッシュを確認します。ブラウザ、WordPressプラグイン、サーバー、CDNの順に、どの層が古いHTMLを返しているかを分けます。

フルページキャッシュはwp-cronの呼び出し頻度へ影響する

CDNやサーバーがHTMLを完全に返し、WordPressのPHPへほとんど到達しない構成では、訪問があっても標準wp-cronの起動機会が減ることがあります。この場合はキャッシュを無効化し続けるのではなく、サーバーCronで安定して呼び出す設計を検討します。

プラグイン競合はステージングで一つずつ確認する

Cron管理、キャッシュ、セキュリティ、バックアップ、メール配信、予約機能のプラグインは、定期イベントを追加したり、HTTP通信を制限したりします。直前に更新したプラグインがあっても、それだけで原因と断定せず、ログと再現試験で確認してください。

オブジェクトキャッシュとデータベースの遅延も確認する

Redisなどのオブジェクトキャッシュ、データベースのロック、ディスク容量不足、PHPワーカー枯渇があると、イベントの取得や投稿更新が遅れることがあります。管理画面が重い、保存に時間がかかる、他の定期処理も失敗するならサーバー資源を確認します。

Webページがうまく表示されない？キャッシュ削除で解決！

WordPressの予約投稿を復旧して再発を防ぐ手順

WordPressの予約投稿を復旧した後は、テスト予約、他イベント、表示キャッシュ、監視の四つを確認して完了にします。一つの記事が公開されたことだけでは、wp-cron全体が安定したとは判断できません。

原因に合わせて一つだけ修正する

タイムゾーンが誤っていれば基準時刻を決めて修正し、DISABLE_WP_CRONと外部Cronの不整合なら運用方式を一つに整えます。ループバック失敗なら認証、SSL、WAF、DNSの該当箇所だけを修正します。

短いテストと長いテストを分けて実施する

最初は10分から15分後に非重要なテスト投稿を予約し、予定時刻前、直後、数分後の状態を確認します。次に通常運用と同じ時間帯で予約し、低アクセス時間や夜間でも動くかを確認します。

他のCronイベントと失敗履歴も確認する

予約投稿が直っても、バックアップ、更新確認、メール送信、外部同期が遅れていないか確認します。特定イベントだけが重い場合は、処理を分割する、実行間隔を見直す、外部APIのタイムアウトを調整するなど個別対策が必要です。

定期監視と運用ルールを決める

重要な予約投稿があるサイトは、公開URLの死活監視だけでなく、予約失敗、Cron遅延、バックアップ失敗、ディスク容量を確認します。通知先を一人に固定せず、休暇や夜間でも対応方針が分かるようにします。

1. 原因候補を一つ修正し、変更前後の値を記録する
2. 10分から15分後のテスト予約で基本動作を確認する
3. 通常運用と同じ低アクセス時間帯でもテストする
4. 公開状態、直接URL、一覧表示、通知連携を確認する
5. 他のCronイベントとサーバーログに遅延がないか見る
6. 監視、失敗通知、担当者、復旧手順を運用メモへ残す

WordPressの予約投稿失敗に関するよくある質問

WordPressの予約投稿失敗でよくある疑問を、応急対応と再発防止に分けて回答します。

WordPressの予約投稿失敗は時刻・wp-cron・表示を分けて直す

WordPressの予約投稿に失敗したら、投稿を作り直す前に、失敗した投稿の状態、サイト時刻、サイトヘルス、wp-cron設定を確認してください。時刻のずれ、標準wp-cronの起動不足、DISABLE_WP_CRONと外部Cronの不整合、ループバック遮断は確認方法が異なります。

キャッシュは、Cronが動かず未公開の問題と、公開済みなのに古い画面が見える問題を分けます。プラグインやWAFを一斉停止せず、バックアップと変更履歴を残して一つずつ検証することが安全な復旧につながります。

よこやま良平が実務で重視するのは、短いテスト予約だけで終わらず、低アクセス時間帯、他の定期イベント、サーバーログ、表示キャッシュまで確認することです。公開時刻が重要なサイトはサーバーCronと監視を整え、失敗時に誰が何を確認するか運用へ落とし込んでください。

WordPressの予約投稿トラブルを自分で直せない時は

WordPress保守・不正アクセス対策・マルウェア駆除・WordPressクイックレスキュー365

ワードプレスのWordPressエラートラブル解決をしたいなら
クイックレスキューが解決します。

これらでお悩みなら最短30分ですぐに解決します！

いまなら期間限定で