WordPressの予約投稿は、投稿編集画面で公開日時を未来に設定し、「予約」ボタンで確定するだけで利用できます。設定後は、投稿一覧に「予約済み」と表示されていることまで確認すると、日時の入力ミスや保存漏れを防げます。
指定時刻を過ぎても公開されない場合は、いきなりサーバー設定を変更しないでください。まず予約日時、タイムゾーン、投稿ステータス、表示キャッシュを確認し、その後にWP-Cron、プラグイン、サーバー側の設定を切り分ける順番が安全です。
特にアクセスが少ないサイトでは、WordPress標準のスケジュール処理の性質上、公開が遅れることがあります。重要な告知やキャンペーン記事では、公開予定時刻の前後に表示を確認できる運用も用意しておきましょう。
WordPressで予約投稿を設定する手順
ブロックエディターでは、右側の投稿設定で公開日時を未来に変更し、「予約」で確定します。日時を入力しただけでは予約は完了しないため、確定後の投稿ステータスまで確認してください。
ブロックエディターで公開日時を未来の日時に変更する
投稿を新規作成、または下書きとして開いたら、画面右上の設定アイコンを押してサイドバーを表示します。「投稿」タブ内にある公開日時の項目を開き、公開したい日付と時刻を未来の値に変更してください。サイドバーが見当たらない場合は、保存・公開ボタン付近の設定アイコンから表示できます。
日時はサイト設定のタイムゾーン基準で扱われます。日本向けのサイトなら、WordPressのタイムゾーンも「東京」など日本時間に合わせたうえで、公開日時を入力するのが安全です。日付だけでなく、午前・午後や時刻の入力間違いにも注意しましょう。
出典：Learn WordPress「Scheduling posts and pages」
「予約」ボタンを押し、投稿一覧でも予約状態を確認する
未来の公開日時を設定すると、画面右上のボタンが「公開」から「予約」へ変わります。内容と日時を見直してから「予約」を押し、確認画面が出る場合は指定日時を再確認して確定してください。
設定後は「投稿」一覧へ戻り、対象記事が「予約済み」となっているかを確認します。編集画面にも予約日時が表示されます。日時を変更しただけで画面を閉じたり、下書き保存だけをしたりすると予約は完了しないため、投稿一覧での状態確認までが設定作業です。
出典：WordPress.org Documentation「Page/Post Settings sidebar」
クラシックエディターでは「すぐに公開する」の編集から設定する
クラシックエディターを利用している場合は、編集画面右側の「公開」ボックスを確認します。「すぐに公開する」の横にある「編集」を押し、将来の日時を入力して「OK」を選択してください。その後、表示が「予約」に変わったことを確認し、「予約」ボタンで確定します。
クラシックエディターでも、時刻はWordPressの一般設定にあるタイムゾーンを基準に処理されます。24時間表記で入力する画面では、たとえば午後1時は13:00として指定します。
出典：Make WordPress Support「Schedule a Post」
予約投稿が公開されないときに最初に確認する項目
公開されない原因は、WordPressやサーバーの障害とは限りません。管理画面だけで確認できる事項から順に見れば、不要な設定変更を避けながら原因を絞り込めます。
| 確認した状況 | 考えられる原因 | まず行うこと |
|---|---|---|
| 投稿が下書き・非公開 | 予約が未確定、または公開範囲が異なる | 日時を設定し直して「予約」で確定する |
| 管理画面では公開済み | ブラウザ、CDN、キャッシュの表示が古い | ログアウト状態で確認し、必要に応じてキャッシュを削除する |
| 予約済みのまま時刻を過ぎた | WP-Cronや代替Cronが実行されていない | WP-Cron無効化設定とサーバーCronを確認する |
| 時刻が意図とずれた | タイムゾーン設定の不一致 | 一般設定と投稿の予約日時を見直す |
予約日時とWordPressのタイムゾーンが正しいか確認する
最初に、「設定」→「一般」でタイムゾーンを確認してください。サイト運営の基準時刻と異なる地域やUTCが設定されていると、意図した時刻と実際の公開時刻がずれます。夏時間を採用する地域向けのサイトでは、固定のUTCオフセットよりも都市名を選ぶほうが時刻調整を管理しやすい場合があります。
続いて投稿編集画面で、予約日時が本当に未来になっているかを確認します。過去の日時や現在時刻に近すぎる日時では、操作中に公開済みへ移行したり、確認のタイミングによって原因を判断しにくくなったりします。複数人で運用するなら、サイト全体で基準タイムゾーンを統一してください。
出典：WordPress.org Documentation「Settings General screen」
投稿が「予約済み」のままか、下書き・非公開になっていないか確認する
「投稿」一覧で対象記事を探し、状態を確認します。「下書き」なら予約が確定していません。「非公開」はログインして権限を持つユーザーだけが閲覧できる状態であり、通常の公開予約とは異なります。「予約済み」のまま公開時刻を過ぎている場合は、次のWP-Cronの確認へ進みます。
公開予定を変更したいときは、記事を開いて日時を再設定し、もう一度予約を確定します。緊急性が高く、内容確認も済んでいる場合は、原因調査と並行して手動公開を判断しても構いません。ただし、公開済みの記事を誤って重複投稿しないよう、投稿一覧の状態を先に確認しましょう。
出典：Learn WordPress「Scheduling posts and pages」
管理画面で公開済みならキャッシュを切り分ける
管理画面上では公開済みなのにサイトで記事が見えない場合、予約処理そのものは成功している可能性があります。まずログアウト状態、またはシークレットウィンドウで記事URLや投稿一覧を確認してください。ブラウザ、キャッシュ系プラグイン、CDN、ホスティングのキャッシュが古い表示を返していることがあります。
キャッシュ削除を行う際は、利用中のサービスごとの手順に従います。全キャッシュの削除がサイト表示に影響する環境もあるため、作業前に影響範囲を確認しましょう。公開済みなら再投稿せず表示を調査することが重要です。
WP-Cronが原因で予約投稿が遅延・失敗するときの対処法
日時・状態・キャッシュに問題がなければ、WordPressが予約処理を実行する仕組みであるWP-Cronを確認します。ここから先はサイト構成によって対応が変わるため、ファイルやサーバー設定を変更する前に、管理者またはホスティング事業者へ確認するのが安全です。
アクセスの少ないサイトではWP-Cronの実行が遅れることがある
WP-Cronは一般的なOSのCronのように常時動作する仕組みではなく、通常はサイトへのアクセスをきっかけに、実行時刻を過ぎたタスクを確認します。そのため、公開予定時刻の直後にサイトへのアクセスがなければ、予約投稿の公開が遅れる可能性があります。
低アクセスサイトほど定刻公開に注意が必要です。次のアクセスが発生すれば期限を過ぎたタスクが実行される設計ですが、分単位で正確な公開が必須の用途には向きません。重要な記事では、公開前後に担当者が表示を確認するか、サーバー側のスケジューラを利用する運用を検討します。
出典：Developer.WordPress.org「Cron」
wp-cron.phpの無効化設定とサーバーCronの有無を確認する
サイトによっては、アクセス時にWP-Cronを起動する処理を停止し、代わりにサーバーCronなどから定期実行する構成になっています。この場合、wp-config.phpでWP-Cronを無効化する設定だけが入り、代替のCronが未設定または停止中だと、予約投稿を含む時間指定タスクが動きません。
wp-config.phpにある設定の確認や変更は、入力ミスでサイト全体が動かなくなるおそれがあります。自分で管理していないサイト、共同運営サイト、設定の意味を判断できない場合は、無効化の解除を自己判断で行わないでください。まずサーバー管理者に、WP-Cron無効化の有無と代替ジョブの設定状況を確認しましょう。
出典：Developer.WordPress.org「Hooking WP-Cron Into the System Task Scheduler」
サーバーCronを利用する場合に確認したい実行間隔と実行先
サーバーCronを使う場合は、WordPressのwp-cron.phpを定期的に呼び出す設定になっているかを確認します。実行間隔が長すぎれば予約投稿の遅延につながり、短すぎればサーバー負荷や重複実行の懸念が生じます。必要な正確性、サイト規模、ホスティングの仕様に合わせて判断してください。
設定画面の名称、指定できる間隔、実行方法はホスティング事業者ごとに異なります。公式マニュアルにあるWordPress向けのCron設定例を確認し、URLの指定先や認証の要否も含めて設定します。外部からのアクセス制限、WAF、Basic認証などを使っているサイトは、Cron実行がブロックされていないかも確認対象です。
出典：Developer.WordPress.org「Hooking WP-Cron Into the System Task Scheduler」
それでも予約投稿が失敗する場合の調査と運用対策
WP-Cronの設定が確認できても解決しない場合は、サイト内部のエラー、外部通信やループバックリクエストの問題、プラグイン・テーマとの競合を調べます。本番サイトへいきなり変更を加えず、バックアップまたは検証環境を前提に進めてください。
Site Health・エラーログ・プラグイン競合を順に確認する
「ツール」→「サイトヘルス」の「ステータス」では、WordPress設定に関する重要な問題や推奨改善を確認できます。予約処理に関係する手掛かりとしては、ループバックリクエストの失敗、HTTPリクエストの制限、デバッグ設定に関する警告などを確認します。「情報」タブでは、タイムゾーン、稼働中のプラグイン、サーバー情報も整理できます。
エラーログを確認する必要がある場合は、公開サイトでエラーを画面表示しないよう注意してください。WordPressのデバッグログはWP-Cron実行時に発生したエラーの確認にも役立ちますが、公式ドキュメントでも本番環境での常用は推奨されていません。プラグイン停止による切り分けは、必ずバックアップやステージング環境で行い、予約・キャッシュ・セキュリティ・最適化系のプラグインから確認するとよいでしょう。
出典：WordPress.org Documentation「Site Health screen」
出典：Developer.WordPress.org「Debugging in WordPress」
ホスティング事業者へ相談するときに伝える情報
サポートへ相談する際は、「予約投稿が失敗する」とだけ伝えるより、状況を整理したほうが調査が進みます。少なくとも、対象の投稿IDまたは管理画面URL、設定した予約日時、WordPressのタイムゾーン、実際に公開されなかった時刻、投稿の現在の状態を用意してください。
- WP-Cronを無効化しているか、サーバーCronを設定しているか
- サイトヘルスに表示された警告内容
- 発生したエラーの時刻と、取得できる範囲のエラーログ
- 直前に更新・追加したプラグイン、テーマ、サーバー設定
- 管理画面では公開済みか、フロント側だけで見えないのか
ログにはURL、メールアドレス、ファイルパスなどの情報が含まれることがあります。公開のサポートフォーラムへそのまま貼り付けず、必要に応じて伏せ字にして、契約中の事業者へ共有してください。
重要な予約投稿は公開前後を確認できる体制にする
予約投稿は便利ですが、重要な発表を完全に無監視にするのは避けたほうが無難です。公開時刻の前に、記事本文、アイキャッチ、カテゴリー、リンク先、公開日時、検索エンジンの表示設定などを確認しておきます。公開後には、管理画面で公開済みになっているか、ログアウト状態で記事が表示されるかを確認してください。
重要記事は公開直後の確認まで予定化すると、遅延や表示キャッシュの問題に早く気付けます。時刻の厳守が必要なサイトでは、通常のWP-Cron任せにせず、サーバーCronの監視や運用担当者による確認を組み合わせることが、予約投稿を安定して使う現実的な対策です。
