WordPressの予約投稿が公開されないときの確認ポイント｜時刻とWP-Cronを順に切り分ける

WordPressで公開日時を設定したのに、予定時刻を過ぎても記事が公開されない。

こういうときに慌ててプラグインを入れたりサーバー設定を変えたりすると、原因が見えにくくなるうえ、別の不具合まで増やしかねません。

予約投稿の失敗は「記事設定」と「実行の遅れ」を分けて確認する

最初にやるべきなのは、次の二つを分けて考えることです。

• 記事が予約投稿として正しく保存され、意図した日時を持っているか
• 時刻になった記事を公開する処理が、きちんと動く状態か

予約投稿の公開には、WP-Cronという仕組みが使われています。

WP-CronはOSのcronのように常に動いているわけではなく、ページが読み込まれたタイミングで、実行時刻を過ぎた処理がないかを確認します。

そのため、記事の日時設定が正しくても、公開処理のきっかけが遅れることがあるんです。

とはいえ、「予約投稿が失敗したらWP-Cronのせい」と決めつけるのは早計です。日時の見間違いやサイトのタイムゾーン、予約操作の確定漏れ、直前の更新や環境の変更でも、同じ症状は起こります。

変更範囲の小さい項目から順番に確かめていくのが近道です。

変更する前に記事とサイトの状態を記録する

原因を調べ始める前に、対象記事とサイトの今の状態を残しておきましょう。

スクリーンショットでも作業メモでも構いません。少なくとも次の項目があると、後から状況を追いやすくなります。

記録の目的は、原因を言い当てることではありません。何を確認した後に状態が変わったのかを、あとでたどれるようにするためです。

WordPressの予約投稿が公開されないときの確認手順

記事そのものの状態から始めて、少しずつサイト全体へ範囲を広げていく順番です。

1. 対象記事が公開済みか予約状態かを確認する

まずは管理画面の投稿一覧と、読者が見る公開URLの両方を見ます。管理画面だけで「未公開」と判断すると、キャッシュや表示条件による違いを見落としがちです。

逆に、公開URLが開けても、それはログイン中の管理者にだけ見えているのかもしれません。

公開URLは、ログインしていないブラウザやプライベートウィンドウでも開いてみてください。投稿一覧では、対象記事が予約済みの状態のままなのか、下書きやレビュー待ちに戻っていないかを確認します。

予定時刻を過ぎているなら、表示されている日時と、確認した時刻もメモしておきましょう。

この段階では、状態を確認するだけにしておきます。原因が分からないまま手動で公開してしまうと、予約投稿が動かなかった理由を後から追いにくくなるからです。急いで公開しなければならない場合も、記事の状態と日時を記録してから操作しましょう。

2. 予約日時とサイトのタイムゾーンを確認する

次に、対象記事に設定した日時を見直します。午前と午後、日付、年、分まで確認しましょう。

複数人で運用しているなら、依頼した人が想定していた時刻と、WordPressに入力された時刻が一致しているかも確認ポイントです。

サイト全体の時刻の基準は、管理画面の「設定」→「一般」にあるタイムゾーンで決まります。ここは「東京」のように、自分と同じタイムゾーンの都市を選ぶのが基本です。

保存後に表示されるUTCとローカル時刻を見れば、設定が合っているかを確かめられます。

たとえば運営者が日本時間の午前9時のつもりで予約しても、サイトのタイムゾーンが別の地域になっていれば、公開予定時刻そのものがずれて解釈されます。

ただし、サイト全体のタイムゾーンを変えると、既存の記事やほかの時間ベースの処理にも影響が出るかもしれません。

誤りを見つけても、対象記事だけの問題なのか、サイト全体の設定の問題なのかを見極めてから変更してください。

3. 予約操作が確定しているかを確認する

日時を入力しただけでは、予約が確定していないことがあります。

クラシックエディターの場合は、「すぐに公開する」の横にある「編集」から未来の日時を指定し、最後に公開ボタンを押して初めて予約が設定される流れです。

ブロックエディターでも、公開日時を未来に変えてから公開ボタンで確定する考え方は同じです。ただ、ボタンの位置や文言はバージョンによって変わることがあるので、実際に使っている画面で確かめてください。

大事なのは日時を入力したかどうかではなく、投稿一覧に戻った後も、未来の日時の公開予定として保存されているかどうかです。

記事を開き直して、予定日時が残っているか、保存途中の下書きになっていないかも見ておきましょう。

権限の異なるユーザーが操作した場合は、そのユーザーの権限グループで予約公開までできたのかも確認対象です。ここでは権限を変更せず、現在の役割を記録するだけにとどめます。

4. ページを表示してWP-Cronの遅れかを切り分ける

WP-Cronは、ページが読み込まれるたびに、実行時刻を迎えた処理がないかを確認します。常に動いているシステムのcronとは違い、ページの読み込みがなければ確認のきっかけ自体が生まれません。

たとえば午後2時に予定した処理でも、次にページが読み込まれるのが午後5時なら、実行はそこまで遅れます。

予定時刻を過ぎていることを確かめたうえで、サイトの公開ページを一度表示し、少し待ってから記事の状態を見直してみてください。

これで公開されたなら、アクセスの少ない時間帯にWP-Cronの起動が遅れていた可能性があります。ただ、一度の結果だけで原因を確定せず、発生した時刻と、ページを表示した後の変化を記録しておきましょう。

何度も再読み込みする必要はありません。

設定ミスや実行時のエラーが原因なら、連打しても直らないからです。予定時刻を過ぎた処理が次の機会に動くかどうかを見る切り分けとして、一度試せば十分です。

なお、サーバーやプラグインのページキャッシュの構成によっては、ページを表示してもWordPress側の処理が走らない場合があります。

表示しても変化がないときは、この点も後の確認材料として控えておきましょう。

5. サイト全体の異常と直前の変更を確認する

記事の設定や時刻に問題がなく、ページを表示しても公開されないなら、確認の範囲をサイト全体へ広げます。

• サイトヘルスに重大な問題や改善の推奨が出ていないか
• 管理画面や公開ページでエラーが出ていないか
• ほかの予約投稿やバックアップなど、時間ベースの処理も遅れていないか
• 直前にWordPress本体、テーマ、プラグインを更新していないか
• キャッシュ、セキュリティ、メンテナンス関連の設定を変えていないか
• サーバー会社から障害やメンテナンスの案内が出ていないか

ほかの予約投稿やバックアップなど、複数の時間ベースの処理がまとめて止まっているなら、記事1件の設定よりも、WP-Cronやサーバー環境を疑う優先度が上がります。

反対に、ほかの予約投稿は問題なく、1件だけ失敗したのなら、対象記事の状態や日時をもう一度確認しましょう。

時間的な前後関係だけで原因を決めないことも大切です。「プラグインを更新した後に起きた」は有力な手がかりですが、そのプラグインが原因だと確認できたわけではありません。

6. サーバーや開発担当へ渡す情報をまとめる

WordPressの設定ファイルやサーバー側のcronを確認する段階まで来たら、本番環境で試行錯誤するより、保守担当者やサーバー会社に情報を渡す方が安全です。

次の内容をまとめておくと、問い合わせのやり取りを減らせます。

• サイトURLと、対象記事を特定できる情報
• 設定した予約日時とサイトのタイムゾーン
• 予定時刻を過ぎた後の管理画面上の状態
• 公開ページを表示した後に状態が変わったか
• 同じ時間帯にほかの定期処理が動いていたか
• 直前の更新や設定変更
• サイトヘルスやエラーログに表示された内容
• 一時的に手動で公開したかどうか

パスワードやAPIキー、秘密鍵などを問い合わせの本文に貼り付けるのは避けてください。管理画面やサーバーへのアクセスが必要なら、相手が用意している正式な共有方法を確認しましょう。

WP-Cronと時刻指定を理解すると原因を分けやすい

WP-Cronは、WordPressの中で時間に関係する処理を受け持つ仕組みです。

更新の確認や予約投稿の公開などに使われていて、ページが読み込まれたときに、期限を迎えた処理を実行します。

開発者向けの関数wp_schedule_single_event()を見ると、イベントはUTCの時刻で予約され、予定時刻を過ぎた後に誰かがサイトを訪れたタイミングで処理が起動する仕組みだと分かります。管理画面に表示されるローカル時刻と、内部で扱われる時刻を混同しないための手がかりになります。

一方で、予約投稿が遅れた原因が、どのサイトでもアクセス数だけにあるとは限りません。

ホスティング環境によっては、サーバー側のcronからWordPressの処理を起動する構成もありますし、キャッシュやセキュリティ設定、外部からのアクセス制限、サーバーの構成も環境ごとに違います。

記事側の確認で解決しないときは、「WordPressのどこを変えれば直るか」と決め打ちせず、利用中のサーバー会社の公式情報と、今の構成を確かめるところから始めましょう。

予約投稿を直すために避けたい操作

早く直したいときほど、次のような操作には手を出さない方が安全です。

原因を確かめずにプラグインをまとめて停止する

予約投稿が公開されなかった時刻、直前の変更、ほかの定期処理の様子を記録してから、変更は一度に一つずつ試しましょう。

まとめて止めると、どれが効いたのか分からなくなります。本番環境で止められない機能があるなら、ステージング環境や保守担当者の手順を使うのが安心です。

ネット上のコードをそのまま設定ファイルへ追加する

検索で見つけたコードを、wp-config.phpやテーマのファイルへそのまま貼り付けるのは危険です。タイプミスや置き場所の誤りひとつで、サイトにアクセスできなくなることもあります。

サーバー側cronへの切り替えやDISABLE_WP_CRONの扱いは環境によって違うので、利用中のサーバー会社の説明を確認しないまま変更するのはやめておきましょう。

サイト全体のタイムゾーンを何度も変更する

時刻のずれを直そうとして、サイト全体のタイムゾーンを何度も変えるのも避けたい操作です。変える前に、現在の設定値、UTCとローカル時刻、対象記事の予約日時を記録しておきましょう。

サイト全体の時刻設定が正しいなら、記事側の日時だけを直す方が影響を小さく抑えられます。

記録を残さずに手動で公開する

読者への案内を優先して手動で公開する判断は、もちろんあり得ます。ただ、実行前の状態を残しておかないと、再発したときにまた同じ調査を一からやり直すことになります。

公開ボタンを押す前に、記事の状態と日時だけでも控えておきましょう。

予約投稿が向いている運用・別の方法が向く運用

数分程度のずれなら問題がなく、公開後に担当者が確認できるブログ運用であれば、WordPressの予約投稿は十分使いやすい機能です。

公開予定の一覧と確認担当を決めておけば、異常にも気づきやすくなります。

一方、キャンペーンの開始、法令上の期限、他システムとの同時公開など、時刻の正確さが重要な場面では、予約投稿だけに頼らない設計が必要です。

サーバー側での実行方法、監視、公開後の確認、失敗したときの連絡経路まで含めて、保守担当者と決めておきましょう。

小規模なサイトなら、公開予定時刻の少し後に担当者がURLを確認するだけでも、長時間の未公開は防げます。高度な仕組みを足す前に、誰が、いつ、どの画面とURLを確認するのかを決めておく方が効果的なこともあります。

公開前後のチェックリストを決めて再発を減らす

予約を設定するときと、公開予定時刻を過ぎた後に見る項目をあらかじめ決めておくと、確認漏れを減らせます。

一度問題が起きたサイトでは、発生日時、原因、行った変更、確認方法を短い運用メモに残しておくのがおすすめです。

次に同じことが起きても、推測で設定を触るのではなく、その記録から確認を始められます。

まとめ

WordPressの予約投稿が公開されないときは、いきなりWP-Cronやサーバーを疑うのではなく、記事の側から順に確認していくのが近道です。

設定ファイルの編集やプラグインの停止、サーバー側cronの確認へ進む前には、現在の状態とバックアップを確かめてください。

正確な時刻での公開が欠かせない運用なら、予約投稿に加えて、公開後の確認担当と失敗時の連絡方法まで決めておく必要があります。

まずは次の予約投稿で、設定直後と公開予定時刻の後に見るチェックリストを一つ作ってみてください。それだけでも、「公開されていなかった」と気づくまでの時間と、原因を探す手間は減るでしょう。