WordPressの予約投稿はいつ公開される?サイト時刻と公開結果を分けて確認する

確認済みの稿を予約したいWeb担当へ。希望時刻の入力と、予定後の公開結果の確かめ方を説明します。
希望時刻をサイトの時間帯へ換算して予約します。予定後は、投稿の状態と公開先の本文を別に確認します。
予約する前に、どの稿と公開範囲をそろえる?
予約するのは、内容と掲載条件の確認が済んだ対象稿です。公開先のサイトと投稿、確認した版、公開してよい範囲と担当をそろえてから日時を入力します。
WordPressは、管理画面で投稿などを更新する仕組みです。管理画面へ入れることと、その稿を公開してよいことは同じではありません。実際の担当権限と社内の確認をそろえ、未確認の料金や写真、顧客情報を予約だけで公開可にしないでください。
制作カレンダーには希望の公開日だけでなく、確認した版と次の担当を結び付けます。企画、原稿、事実確認の締切を組む仕事は、既存の制作カレンダーのガイドで整理できます。この記事では、その確認済みの稿を予約する操作から扱います。
最初にサイトを作り、ページや受付を用意して公開する一式は、初回サイト制作のガイドへ進みます。予約投稿の設定は、未確認のサイトや受付を使える状態にする代わりにはなりません。
希望の09:00を、そのまま入力してよい?
希望の時間帯と、サイトに設定されている時間帯が同じかを確かめます。同じ09:00という表示でも、東京の09:00とUTCの09:00は違う時点です。
タイムゾーンは、日時をどの地域や基準の時刻で読むかを決める設定です。WordPressの一般設定では都市やUTCとの差を選べます。まず既存サイトの設定を読むか、設定を確認できる管理担当へ尋ねてください。日付や時刻の表示書式は見た目の設定で、タイムゾーンとは別です。
東京はUTCより9時間進んでいます。架空例の2026年10月12日、東京で09:00に出したいならUTCでは同日の00:00です。サイトがUTCのまま09:00を入力すると、東京では18:00に相当します。希望の時点をサイトの時間帯へ換算してから入れます。
次は架空の予約記録です。入力した日時と希望した日時を対応させています。本文の公開や処理の実行は未確認で、換算が合うことだけを公開成功にはしません。
サイト時刻と希望時刻が違う予約
- 希望日時
- 2026-10-12 09:00
- 希望の時間帯
- Asia/Tokyo (UTC+09:00)
- サイトの時間帯
- UTC (UTC+00:00)
- サイト時刻で入力した日時
- 2026-10-12 09:00
- 入力日時に対応する東京時刻
- 2026-10-12 18:00
- 希望に対応するサイト時刻
- 2026-10-12 00:00
- 確認時点
- 2026-10-11 16:00 +09:00
- 確認時の投稿状態
- 予約済み
- 確認時の公開先本文
- 未確認
- 実際の処理実行時刻
- 未確認
- 予定処理の実行記録
- 未確認
- 個別の原因
- 未確認

図の内容を文章で読む
架空例:希望日時は2026-10-12 09:00、希望の時間帯はAsia/Tokyo (UTC+09:00)。サイトの時間帯はUTC (UTC+00:00)。希望に対応するサイト時刻は2026-10-12 00:00。一方、サイトへ入力した日時は2026-10-12 09:00で、東京では2026-10-12 18:00に対応する。確認時点は2026-10-11 16:00 +09:00、投稿状態は予約済み。公開先本文、実際の処理実行時刻、予定処理の実行記録、個別の原因は未確認。実WordPress画面や実サイトの予約結果ではない。
この例の入力は、希望より9時間後の時点です。希望が東京09:00のままなら、対象稿の承認された日時を確認してUTC00:00へ対応させる必要があります。個人の都合だけでサイト全体のタイムゾーンを変えると、ほかの担当が使う時刻の基準まで変わります。
ほかの地域では季節によりUTCとの差が変わることもあります。実際には対象の日付と時間帯で換算し、境界を越える場合は日付も見直します。この架空の東京とUTCの例を、すべての地域の固定差へ広げません。
当事者の相談でも、サイトのUTC設定と複数地域の担当者の希望時刻が合わない問題が挙がっています。これは時間帯をそろえる必要の根拠であり、こちらが実サイトの設定や操作を再現した結果ではありません。
WordPressで、どう予約を確定する?
対象の下書きで、公開日時を未来の日時へ変更し、予約の操作を確定します。日時欄へ入力しただけで終えず、対象稿の状態と登録された日時を確認してください。
ブロックエディターでは、投稿の設定にある公開日時を開くと、日付や時刻を選ぶ操作があります。確認済みの対象稿を開き、サイトの時間帯へ換算した日付と時刻を入れます。12時間表示なら午前・午後もそろえ、意図する未来の日時かを見直します。
未来の日時を選んだときは、公開操作が「予約投稿」やScheduleとして示される場合があります。確定画面が出る版では対象と日時を読み、予約を確定します。その後、投稿一覧や再読込した対象稿で、予約の状態と日時が登録されたかを確認します。
ボタンの位置や日本語表示はWordPressの版、エディター、追加機能や権限で異なります。表示が違うときは、画面の見た目だけで別の稿へ操作せず、公開日時と対象稿を確認できる担当へ照合してください。
変更や取消も、対象稿と公開してよい条件をそろえて行います。公式の学習資料には下書きへ戻して予約を取り消す操作例がありますが、版によって表示が違うため、今の画面で使える方法を確認します。予定を過ぎた稿を、原因確認の代わりにその場で即公開する手順にはしません。
なぜ、予約時刻と処理の時刻が違うことがある?
WordPressの標準的な予定処理は、時計を常に動かしている仕組みではありません。WP-Cronという予定処理の仕組みが、ページが読み込まれた時に期限の来た仕事を調べます。
予定時刻は、処理の対象となる日時です。WP-Cronはページの読込を契機に、期限を迎えた仕事があるかを確認し、実行する処理へつなぎます。公式資料は、ページ読込がなければ予定処理がその時点で呼ばれないことがあると説明しています。
そのため、予約日時の登録と、実際に処理が動いた時点は分けて読みます。ただし個別サイトでは、外部から予定処理を呼ぶ方式など、設定が異なる場合があります。この記事から実サイトの方式やアクセス、処理の実行記録を補完しません。
予定超過だけを見て、アクセス不足や追加機能、サーバーの障害を原因と確定しないでください。標準の仕組みの説明から、すべての予約が必ず遅れる、必ず定刻に出る、必ずあとで公開されるという保証もしません。
時刻を過ぎたら、どこまで確認すればよい?
同じ対象稿の現在の状態と、許可された公開先で対象本文を読めるかを確認します。確認した時点を添え、予約の登録と公開結果を別に記録します。
次の二つは、どちらも東京09:00を予定し、東京09:10に確認した架空例です。一方は予約表示のままで対象本文を確認できず、もう一方は公開済みの状態で本文を読めています。処理の実行時刻や原因は、どちらも未確認です。
同じ希望日時・入力日時・確認時点の二つの架空投稿でも、投稿状態と公開先本文の観測が異なります。別の投稿なので、後の例を前の例の修正後や回復結果とは扱いません。09:10に本文を読めた記録も、09:00に処理が実行された証拠ではありません。
確認時の投稿状態
- 予約表示の投稿
- 予約済み
- 本文を読めた別の投稿
- 公開済み
確認時の公開先本文
- 予約表示の投稿
- 確認時に対象本文を確認できず
- 本文を読めた別の投稿
- 確認時に対象本文を読めた
二つの投稿で共通する日時の条件
- 希望日時
- 2026-10-12 09:00
- 希望の時間帯
- Asia/Tokyo (UTC+09:00)
- サイトの時間帯
- Asia/Tokyo (UTC+09:00)
- サイト時刻で入力した日時
- 2026-10-12 09:00
- 入力日時に対応する東京時刻
- 2026-10-12 09:00
- 希望に対応するサイト時刻
- 2026-10-12 09:00
- 確認時点
- 2026-10-12 09:10 +09:00
両投稿とも未確認の処理記録と原因
- 実際の処理実行時刻
- 未確認
- 予定処理の実行記録
- 未確認
- 個別の原因
- 未確認
09:10に本文を読めたことは、その確認時点の公開先の観測です。09:00ぴったりに処理が実行された証拠へ変えません。投稿に表示された公開日欄も、それだけで実行ログとは扱いません。
確認時に対象本文を読めなかった場合も、その時点の記録として残します。永久に未公開、公開件数が0、処理の原因が確定したとはしません。公開URLと対象本文の対応、確認した時刻、読めた範囲をそろえます。
公開先を確かめるときは、同名の別稿やプレビューを公開結果へ混ぜないでください。ログインした担当だけの表示と、対象の公開範囲で本文を読めることの違いも、担当が確認します。
まだ予約表示なら、次に何を確かめる?
サイトの時間帯、入力した日時、対象稿の現在状態、確認時点と公開先の観測をそろえます。その資料から、予定処理の方式と実行記録を管理担当へ確認します。
まず希望時刻と入力の換算が合っているかを見直します。次に、予約の確定後の状態と日時を、同じ対象稿で読みます。予定を過ぎているなら、公開先の対象本文を確認した時刻と結果を合わせ、何が未確認かを記します。
管理担当には「このサイトではWP-Cronを何が呼びますか」「この対象稿の予定処理と実行記録を確認できますか」「確認時刻の投稿状態と公開先本文は対応していますか」と尋ねます。ログがない、取得できない場合も未確認として残します。
予約投稿が出ないという当事者の相談には、後の変更で公開できたという本人の返答もあります。そこから個別の原因や他サイトへの解決を確定しません。無条件の追加機能導入、予定処理の解除、外部ジョブの設定は、この確認手順の前提にしないでください。
今日の一歩は、確認済みの一稿について、希望の時間帯と日時、サイトの時間帯、入力する日時を一組で照合することです。予約後は登録状態を、予定後は公開先の本文を確かめます。制作の体制や公開前の確認全体は、既存のメディア運営ガイドへ接続できます。
仕事の流れから、顧客との接点まで。
一体で見直す、最初の一歩を。


