WordPressの予約投稿が失敗する原因｜「予約投稿の失敗」の直し方

最初に結論：時刻とwp-cronを確認し、テスト予約で再発しないことを確かめる

1. 設定→一般でタイムゾーンを「東京」または正しい地域にする
2. 失敗投稿の予定日時と現在時刻を照合する
3. ツール→サイトヘルスで予約イベントとループバックを確認する
4. wp-config.phpのDISABLE_WP_CRONとサーバーcronを確認する
5. 5〜10分後のテスト投稿を予約し未ログイン画面で自動公開を確認する

閲覧が少ないサイトでは、訪問をきっかけに動くwp-cronが遅れることがあります。確実な時刻公開が必要なら、サーバーcronから wp-cron.php を定期実行します。

予約投稿が動く仕組みと失敗の意味

標準のWordPressはOSのcronではなく、ページアクセス時に期限イベントを確認する疑似cronを使います。指定時刻にアクセスがない、内部HTTP通信が失敗する、cronを無効化したのに代替設定がない場合、投稿は未来日時のまま残ります。

手順1：投稿時刻とサイト時刻を合わせる

「設定 → 一般」のタイムゾーンを確認し、固定のUTCではなく地域名を選ぶと夏時間にも対応できます。投稿編集画面の公開予定日時と、画面下部などに表示される現在時刻を比較します。

時刻設定を変えた後は既存予約の日時が意図どおりか一件ずつ確認します。ずれた投稿をそのまま一括変更すると公開順が崩れます。

手順2：サイトヘルスとcronイベントを確認する

「ツール → サイトヘルス」で「予約したイベントが遅延」「ループバックリクエストが失敗」などを確認します。セキュリティプラグイン、Basic認証、WAFが自サイトの wp-cron.php を遮断していないかログで見ます。

WP Crontrolなどを使う場合は、期限を過ぎたイベントとフック名を確認するために限定し、内容不明のイベントをまとめて削除しません。

手順3：DISABLE_WP_CRONとサーバーcronを照合する

wp-config.php に define('DISABLE_WP_CRON', true); がある場合、サーバー側の定期実行が必須です。無効化だけ残っていないか確認します。

サーバーcronは5分間隔を目安に公式例どおり設定し、対象ドメインの wp-cron.php を呼びます。二重実行を避けるため、標準cronを止めるかどうかを設計してから変更します。

失敗投稿の復旧とテスト方法

公開期限を過ぎた投稿は内容、カテゴリー、アイキャッチを確認して手動公開します。その後、非公開のテスト記事を5〜10分後へ予約し、管理画面を閉じた状態で待ちます。

予定時刻後に未ログインの別回線でURL、TOP、カテゴリ、feedを確認します。予約ステータスが公開済みに変わり、二重公開がないことも確認してください。

症状ごとの判断をもう一段深くする

予定時刻がずれている

この状態では、まず WordPressタイムゾーン を優先します。設定→一般を修正だけで結論を出さず、変更前の画面・発生時刻・対象URLを残し、同じ条件で一項目ずつ比較してください。別の症状まで同時に出る場合は、個別ページより共通するサーバー設定やWordPress全体の処理を先に確認します。

低アクセス時だけ遅れる

この状態では、まず wp-cronの起動不足 を優先します。サーバーcronを設定だけで結論を出さず、変更前の画面・発生時刻・対象URLを残し、同じ条件で一項目ずつ比較してください。別の症状まで同時に出る場合は、個別ページより共通するサーバー設定やWordPress全体の処理を先に確認します。

サイトヘルスでループバック失敗

この状態では、まず Basic認証・WAF・SSL を優先します。内部通信を許可だけで結論を出さず、変更前の画面・発生時刻・対象URLを残し、同じ条件で一項目ずつ比較してください。別の症状まで同時に出る場合は、個別ページより共通するサーバー設定やWordPress全体の処理を先に確認します。

全予約が失敗

この状態では、まず DISABLE_WP_CRON・cron停止 を優先します。wp-configとサーバー設定を照合だけで結論を出さず、変更前の画面・発生時刻・対象URLを残し、同じ条件で一項目ずつ比較してください。別の症状まで同時に出る場合は、個別ページより共通するサーバー設定やWordPress全体の処理を先に確認します。

管理画面へ入れる場合・入れない場合の進め方

管理画面へ入れる場合

サイトヘルス、対象機能の設定画面、更新履歴を先に確認し、直前の変更を一件だけ戻します。変更後は未ログイン画面を開き、キャッシュされた管理者表示だけで判断しません。

管理画面へ入れない場合

サーバーパネルのファイル管理とエラーログを使い、対象ドメインとWordPress設置先を照合します。フォルダ名変更などの一時停止は対象一件に限定し、元の名前と変更時刻を記録します。復旧後は管理画面から正式な更新・設定を行い、一時変更を放置しません。

サポートへ相談するときに伝える内容

「直りません」だけでなく、記事タイトルの症状が出たURL、発生時刻、エラー全文、直前の操作、再現手順、試した項目と結果、PHP・WordPress・対象製品のバージョンをまとめます。ログに個人情報、Cookie、APIキー、パスワードがあれば伏せてください。

サーバー会社にはHTTP状態・PHPログ・DNSやWAFなど基盤側の確認を、プラグイン提供元には製品名・バージョン・再現操作を伝えます。問い合わせ先を分けると、同じ確認を何度も繰り返さずに済みます。

直ったと判断する条件

管理画面を開いていない状態でもテスト投稿が予定時刻付近に自動公開され、TOP・カテゴリ・feedへ反映し、サイトヘルスの遅延イベントが解消している状態です。

• タイムゾーンが正しい
• 期限超過イベントを確認した
• DISABLE_WP_CRONと代替cronが整合した
• テスト予約が自動公開された
• TOP・カテゴリ・feedを確認した

よくある質問

まとめ：失敗記事だけでなく次の自動公開まで確認する

時刻、ループバック、wp-cron無効化、サーバーcronの順で確認し、失敗投稿を復旧します。最後に管理画面を閉じたままテスト予約し、周辺ページへの反映まで確認して完了です。