WordPressの予約投稿が公開されないときは?日時・WP-Cron・表示の確認手順
WORDPRESS / 予約公開の確認
予約投稿が出てこないときは、まず「状態・日時・公開ページ」を分けて確認。
WordPressの予約投稿が予定時刻に公開されないときは、投稿が本当に予約済みか、サイトのタイムゾーンと日時が合っているかを確認します。公開済みなのに一覧へ出ない問題とは分けましょう。予約公開にはWP-Cronという仕組みも関わるため、繰り返す場合はサイトヘルスやサーバー側の記録まで確認します。この記事は、自分で管理するWordPressサイトを主な対象にしています。
情報確認日:2026年10月24日。画面や条件は変更される場合があります。実際の操作では、利用中のサービスの最新案内も確認してください。
朝6時に予約した記事が、まだTOPにありません。予約に失敗したのでしょうか?
TOPにないことだけでは決められません。僕なら、管理画面の投稿の状態と、記事そのものの公開URLを先に見ます。下書きのままなのか、予約時刻が違うのか、公開済みで一覧だけ古いのかを分けると、次の確認がはっきりします。
この確認のために、記事を新しく複製する必要はありません。まず元の投稿を特定し、タイトル・投稿ID・設定した日時を残します。記事を二つ作ると、どちらを公開する予定だったのか分からなくなり、リンクや告知も分かれてしまいます。本文の書き直しより、いまの状態を確かめるところから始めましょう。
投稿の状態で、調べる場所を分ける
WordPressの管理画面で「投稿」の一覧を開き、対象のタイトルを探します。似た記事があるなら、編集画面のURLなどで投稿IDも照合します。WordPress公式は、投稿一覧で状態や日付を確認できることを案内しています。画面の列や表記は、導入した機能や権限で異なる場合があります。
出典:WordPress公式:投稿一覧画面(2026年10月24日確認)
| 管理画面などの状態 | 最初の見方 | 調べること |
|---|---|---|
| 下書き | 予約を確定していない可能性 | 未来日時を入れた後、予約の保存まで終えたか |
| レビュー待ち | 公開前の承認が残っている可能性 | 誰が公開・予約を確定する運用か |
| 予約済み | 予定時刻と現在時刻を比較 | 日付・時刻・タイムゾーンが意図どおりか |
| 公開済み | 記事そのもののURLを開く | 本文が読めるか、一覧だけ反映が遅れていないか |
| 予約時刻を過ぎても予約状態 | 公開処理の遅延などを調べる段階 | WP-Cron・サイトヘルス・サーバーの状態 |
上の表は原因を断定する診断結果ではなく、調べる順番の目安です。たとえば「予約時刻を過ぎている」と思っても、日付が翌月になっている場合と、正しい日時なのに処理が進んでいない場合では対応が違います。気付いた時点で何度も日時を書き換える前に、元の設定を記録してください。
表示が「非公開」やパスワード保護になっている場合も、一般の読者が読める公開状態とは区別します。プレビューで自分だけが見られたことは、誰でも読める確認にはなりません。記事全体を一般公開したい意図なのかを確かめてから、必要な設定を判断しましょう。
出典:WordPress公式:投稿・固定ページの状態と公開設定(2026年10月24日確認)
予約日時とタイムゾーンを確認する
未来の日付を選んで保存したはずです。どこを見直せばいいですか?
年・月・日・時刻、それから保存後の状態まで見ます。時刻を選んだだけで予約が確定したと思わないことが大切です。僕なら、投稿一覧でも同じ日時の予約済みになっているかを確かめます。
対象の記事を特定する
タイトル、投稿ID、スラッグを照合します。複数タブを開いている場合は、別の記事や別サイトを触っていないかも確認します。
保存されている日付と時刻を読む
未来の年月日になっているか、午前と午後や24時間表記を取り違えていないか見ます。希望した日時ではなく、実際に保存された値を確認します。
サイトのタイムゾーンを確認する
管理画面の「設定→一般」でタイムゾーンの表示を確認します。権限がなく見られない場合は、管理者へ確認します。サイト全体へ影響するため、その場しのぎで変更しません。
予約済みの状態を確認する
エディターの保存完了と、投稿一覧の状態・予定日時を確かめます。更新に失敗した通知が出ていないかも確認します。
時刻後は公開状態と本文を確認する
管理画面で公開済みになったかを見て、公開URLで本文を確認します。一覧にない場合は、そのあとで一覧側の問題として調べます。
出典:WordPress公式:一般設定のタイムゾーン(2026年10月24日確認)
たとえば「11月1日6時に出したい」という作業メモがあっても、サイトの設定が想定と違えば時刻の解釈にずれが出ます。日本向けの運営なら、運用で使う基準の時刻を決め、外部ツールを併用する場合もどのタイムゾーンの値なのかを確認します。これは設定例で、すべてのサイトを同じ地域に変える指示ではありません。
予約公開の日時が、記事の本文に書いた「更新日」や見出しの年と一致している必要があるのかも、自分の運用で整理します。本文に日付を入力することと、WordPressの公開日時を設定することは別です。文章に朝6時と書いても、公開処理の指定にはなりません。

WP-Cronは、予約時刻ぴったりの実行を保証する仕組みではない
WordPressには、時刻に関係する処理を扱うWP-Cronという仕組みがあります。公式の開発者向け説明では、予約公開などにも使われ、ページの読み込みをきっかけに期限を迎えた処理を確認します。常に一定時刻に動き続けるサーバーのCronとは動き方が違います。
出典:WordPress公式:WP-Cronの仕組み(2026年10月24日確認)
アクセスがないと、予約が遅れることもあるんですか?
標準のWP-Cronはページの読み込みをきっかけに処理を確認するため、アクセスのタイミングが関係します。ただ、遅れた理由が必ずアクセス数とは限りません。日時と状態を確かめたうえで、処理や通信の問題がないかを見ます。
ここで「TOPを何百回も開けば解決する」と考えないようにしましょう。公式の予約投稿案内には、ログアウトしてTOPを訪れる確認が紹介されていますが、それで公開されなければ別の要因も調べます。繰り返しアクセスすることより、何をした後に状態が変わったかを一度記録する方が役立ちます。
出典:WordPress公式:予約投稿の基本確認(2026年10月24日確認)
もし記事を今すぐ公開したいなら、予約の遅れの原因調査と、当該記事を手動で公開する判断を分けます。公開してよい内容か、関係者の確認が終わっているかを見たうえで、元の投稿を操作し、同じURLで公開されたか確かめます。手動で一度出せたことは、次回の予約も正常に動くという検証にはなりません。
公開済みなのに見えないときは、個別ページと一覧を分ける
管理画面が公開済みなのにTOPへ出てこない場合は、予約公開そのものの失敗とは限りません。個別ページが読めるか、カテゴリー一覧には出るか、ログイン中とログアウト時で違うかを分けます。キャッシュや一覧の表示条件などが関係する可能性がありますが、現物を確認する前に原因を確定しません。
| 確認場所 | 見ること | 判断を分ける理由 |
|---|---|---|
| 記事の公開URL | 本文・タイトル・画像が一般の表示で読めるか | 個別ページの公開と一覧掲載は別 |
| TOPの新着記事 | 対象の記事が出るか、並び順はどうか | 固定表示や一覧の設計が関わる場合がある |
| カテゴリー一覧 | 付けた分類の一覧へ出るか | 分類や表示条件を確かめるため |
| ログアウトした表示 | 管理者だけの見え方になっていないか | ログイン状態の差を分けるため |
| 別の端末やブラウザ | 同じURLで違いが出るか | 端末側とサイト側の表示を整理するため |
キャッシュを調べるときも、どのページに古い表示があるかを先に残します。ブラウザ、WordPressの機能、ホスティング側、CDNなど、複数の場所が関わることがあります。利用していない仕組みまで推測で設定し直すのではなく、導入状況を確認し、公式の操作案内に沿って対象を絞ります。
「Google検索に出ていない」と「公開されていない」も別の話です。まず公開URLで読めるかを確認します。検索エンジンへの登録や検索結果への表示には別の処理があるため、予約時刻に検索へ出ないことだけで予約失敗とはしません。記事を複製して何本も出す対応は避けましょう。
繰り返すときは、サイトヘルスと管理者への相談へ
毎回遅れるので、プラグインを全部止めた方がいいですか?
まず、記録とサイトヘルスの表示を確認したいです。フォームや広告、販売の機能まで動いている本番サイトで、一度に全部止めると別の問題が起きることがあります。僕なら、変更前の状態を残して、管理者と確認範囲を決めます。
管理画面の「ツール→サイトヘルス」では、サイトの状態や技術情報を確認できます。公式は、ループバックリクエストが予約されたイベントの実行にも使われると説明しています。関連する警告があれば、その文言と日時を記録します。ただし警告が一つあるだけで、今回の予約失敗の原因まで確定するわけではありません。
出典:WordPress公式:サイトヘルスとループバックリクエスト(2026年10月24日確認)
最近、ホスティングの変更、アクセス制限、プラグインやテーマの更新、外部の予約ツールの導入をしていないかも整理します。変更直後に起きたことは手掛かりになりますが、時期が近いだけで原因とは決めません。必要な検証は、バックアップやテスト環境を用意し、一つずつ行う方が結果を読み取りやすくなります。
メモへ管理画面のパスワードや認証コードを入れる必要はありません。ログを渡す場合も、相手が必要とする範囲を確認し、非公開情報を含む全文を公開掲示板へ貼らないようにします。権限を持つ担当者へ、正規の窓口で確認するのがよいですね。
次回から残す記録と、公開前後の確認手順
予約投稿を日々使うなら、作成と確認を分けた小さな記録があると便利です。予定表にタイトルだけを並べるのではなく、投稿IDと日時、保存後の状態、公開後の結果も残します。予約を入れたことと、公開されたことを同じチェック欄にしないのがポイントです。
- 保存前:対象の原稿・リンク・画像を確認する。
- 保存後:投稿ID・予定日時・予約済みの状態を確認する。
- 予定時刻後:公開状態と個別URLを確認する。
- 表示確認:本文・画像・一覧への掲載を必要に応じて見る。
- 問題発生時:元の状態、時刻、行った操作と結果を残す。
たとえば「予約設定済み」「個別ページ公開済み」「一覧確認済み」の三つに分ければ、作業のどこが残っているかを見つけやすくなります。公開日時を過ぎた記事の扱いも、勝手に削除するのか、手動公開してよいのかを事前に決めておくと、共同運営でも判断が揃いやすいと思います。
一回だけ遅れた場合も、サーバー設定を変えますか?
一度の遅れだけで、すぐ大きな設定変更をする必要があるとは限りません。日時と投稿状態、公開確認の結果を残し、同じ条件で繰り返すかを見ます。重要な告知で時刻厳守が必要なら、予約しただけで任せきりにせず、公開前後を確認できる運用も検討します。
予約の失敗は、本文が長いからですか?
本文の長さだけからは決められません。まず保存できているか、予約状態なのか、処理時に何が起きたかを確認します。特定の画像や本文を疑う場合も、元原稿を保管し、必要な範囲で検証してから判断します。問題のない内容を一括削除して様子を見るより、対象を絞りましょう。
WordPressを使い始めたばかりで、投稿とサイト全体の設定を整理したい方は、WordPressの始め方と基本の準備も参考にしてください。ブログを続ける意味や作業の考え方は、ブログを運営するメリットにも書いています。予約を入れる作業だけでなく、読者さんが実際に読めるところまで確かめる習慣を作っていきたいですね。

