WordPressの予約投稿が公開されないときの確認手順｜時刻・状態・WP-Cronを分ける

WordPressで予約した記事が予定時刻を過ぎても公開されないときは、最初に「予約した対象」「サイトの時間帯」「現在の投稿状態」「ログインしていない人が見る公開画面」を照合します。管理画面の表示だけで、記事が公開された、あるいはWP-Cronが壊れたと決めないことが大切です。

この記事は、企業の更新担当者と、そのWordPressを支える制作・保守担当者向けです。担当者が自分で確認できる範囲と、サーバーや追加機能の調査が必要な範囲を分け、急ぎの公開判断と再発防止の記録を作ります。本記事の説明は特定サイトでの障害診断や復旧実績ではありません。

1．予約した記事と、見えていない場所を特定する

記事の編集URL、予定していた公開URL、投稿タイトル、予約を設定した日時を控えます。似たタイトルの下書き、別言語のページ、試験サイトを見ていないかも確認してください。「トップに出ない」のか「詳細URLが開かない」のかで、調べる場所は違います。

管理画面と公開画面の状態を一組で記録する

管理画面で対象記事の状態と日時を読み取り、別のログインしていないブラウザーで公開URLを確認します。機密の下書きを共有する必要はありません。確認者、確認時刻、URL、期待する表示、実際の表示を記録すると、後の調査で同じ対象を話せます。

2．サイトの時間帯と、保存された予約日時を照合する

担当者のパソコンの時計と、WordPressで扱う時間帯は同じとは限りません。管理者へサイトの一般設定にある時間帯を読み取ってもらい、予約日時が意図した日時になっているかを確認します。日付の表示形式を変えることと、時間帯を変えることも別です。（WordPressの一般設定）

予約日時は、投稿の設定画面で確認します。時間の入力方式や表示は使用中の編集画面によって異なるため、数字だけを伝えず、日付・時刻・時間帯・保存後の状態を揃えてください。WordPress公式の予約公開の説明でも、未来の日時とサイトの時間帯を確認して予約します。

「時差らしい」という理由だけで本番の時間帯を変更すると、他の予約や日付の扱いにも影響する可能性があります。先に設定値と対象の予約を照合し、変更が必要なら対象と影響を管理者と決めます。予定を再設定した場合も、保存後の表示を読み直してください。

3．WP-Cronは、常に時計を見て動く仕組みではない

WordPressには、予約公開などの定期処理を扱うWP-Cronがあります。通常はページの読み込みをきっかけに実行時期の来た処理を確認します。サーバーの時計が毎分独立して呼び出す仕組みと同じではなく、アクセスや実行環境の条件も調べる必要があります。（WordPressのWP-Cron解説）

ただし「アクセスが少ないから」と断定するのも早計です。外部の実行設定があるサイト、処理を変更する追加機能、実行を妨げる通信条件など、現在の構成で原因は変わります。表示された症状と実行経路を照合し、原因候補と確認済みの事実を分けてください。

実行担当へ渡す情報を揃える

対象記事のID、予定日時と時間帯、現在の状態、いつから起きたか、他の予約でも起きるか、直前の変更をまとめます。技術担当には、WP-Cronの扱い、外部からの呼び出しの有無、実行・通信・エラーの記録を確認してもらいます。認証情報をそのままメールへ添える必要はありません。

4．急いで公開する判断と、原因調査を分ける

告知の期限が迫っている場合は、記事を今公開してよいかを原稿責任者へ確認します。公開してよい原稿、掲載許可、公開先、関連する案内の整合を確認し、通常の編集操作で公開する方法を担当者と決めます。予定時刻を過ぎたからという理由だけで未承認の内容を出さないでください。

手動で公開できたとしても、それは対象記事の公開を確認した結果です。予約処理の原因が解消した証拠にはなりません。公開前の状態と操作、公開後のURLを残して、予約の調査を別に続けます。同じ記事を新規に作り直すと、二重公開や異なるURLを生む場合があります。

公開後は詳細本文、トップや一覧、リンク先、通知や連携の担当範囲を確認します。配信や反映に時間差がある場合は、どこが未確認なのかを記録します。原因不明のままプラグインを一括停止したり、キャッシュをあらゆる場所で削除したりする前に、影響を技術担当へ相談してください。

5．外部の実行設定を変更する前に、既存の担当を確認する

サーバー側の定期実行でWP-Cronを呼び出す方式もあります。WordPress公式は外部の実行設定と、ページ読み込みからの起動を止める設定を組み合わせて説明しています。先に起動だけを止めて、代わりの実行を用意しない操作は避けます。（システムのタスク実行との接続）

具体的な設定は、サーバー、設置場所、現在の呼び出し方法、権限によって変わります。他サイトのコマンドやパスをそのまま貼り付ける手順にはしません。既存の外部実行があるのか、誰が保守しているのか、監視と失敗時の通知があるのかを先に調べます。

変更票には、予約以外の処理も含める

対象環境、現在の実行経路、変更する箇所、実行間隔の理由、他の定期処理への影響、試験項目、戻し方、担当と承認を記入します。予約公開だけでなく、追加機能が定期処理を使っている可能性も確認します。記事を読んだだけで、本番の設定を変更する必要はありません。

6．試験は予約から公開表示まで通して確認する

試験環境では、原稿保存、予約状態、予定日時、時刻後の状態、ログインしていない公開表示まで確認します。本番の通知や外部連携を誤って動かさないため、環境と接続を整理してください。WordPressの試験環境を作る前の確認も参考になります。

試験環境で成功しても、本番のアクセス、通信、外部の実行設定まで同じとは限りません。本番で必要な最終確認は、公開してよい対象、日時、担当を合意して行います。架空のお知らせを無断で公開して試す方法は採用しません。

7．毎朝の投稿作業より、必要な確認と例外対応を設計する

自動化したい価値は、担当者が決めた正しい原稿を必要な時期に届けることです。予約する本数や自動実行の回数を成果にせず、日時の入力間違い、承認待ち、実行失敗、公開表示の未確認のどこが負担になっているかを調べます。

失敗の記録から、確認する範囲を決める

予定日時、実公開の確認時刻、遅れが分かった経路、対応時間、原因の確定/未確定を記録します。確認頻度は告知の重要度と実行環境に合わせて決め、すべてのサイトへ同じ頻度を押し付けません。正常に予約できている記事を、毎回作り直す必要もありません。

空いた時間は、原稿の掲載許可、読者の疑問、リンク先の案内、相談への対応に使えます。自動実行が動いたこと、担当の工数が減ったこと、読者が情報を受け取れたことを分けて確認してください。順位や問い合わせが増えたという結果を、予約機能だけから推測しません。

8．Acquaへ相談するときは、公開したい内容と残る調査を伝える

相談前には、対象サイト、記事ID、予定日時と時間帯、管理画面の状態、公開URL、直前の変更、急ぎの期限、現在の管理会社をまとめます。原因を自分で断定したり、サーバーの認証情報を最初から送ったりする必要はありません。

企業の方はWeb制作・運用の案内から、原稿更新と公開確認、WordPress保守で必要な範囲を確認できます。制作会社の方は実装・保守の依頼案内から、構成調査、実行経路の確認、必要な修正と試験の担当を相談できます。サーバー側へ対応できるかは、権限と環境を確認して合意します。

支援後は、正しい内容が公開され、予約の実行方法と異常時の担当、未確認事項が分かる状態を目指します。原稿更新だけで足りるのか、実行設定の調査や修正が必要なのかを分け、費用と作業範囲を確認します。実務支援が必要な場合はお問い合わせへ状況をお知らせください。