Hara Daizo WordPressの予約投稿を使うと、作成済みの記事を指定日時に公開できます。ただし、WordPressの時刻設定やWP-Cronの動作によっては予定時刻を過ぎても公開されず、「予約投稿の失敗」と表示されることがあります。
公開日時を正しく指定する操作に加え、失敗時の切り分けと監視方法まで決めておくことが安定運用の要点です。SNSへ同時配信したい場合の考え方も含めて説明します。
WordPressの予約投稿とは
予約投稿は、投稿の公開日時を未来に設定し、その時刻になった後にWordPressが公開処理を実行する機能です。編集者が操作しているブラウザーを開いたままにする必要はありません。一方、OSの常駐スケジューラーのように指定時刻ちょうどの実行を保証する仕組みでもありません。
標準のWP-Cronはページアクセスなどをきっかけに期限到来済みの処理を確認します。そのため、アクセスが少ないサイトやCronへのリクエストが遮られる環境では遅れる可能性があります。ページキャッシュによる見え方の違いは「サーバーキャッシュの影響」も参照してください。
WordPressで予約投稿する手順
ブロックエディターでは、投稿設定の公開日時から指定します。
- 予約したい投稿を開き、右側の「投稿」設定を表示する
- 「公開」の日時をクリックする
- カレンダーと時刻で未来の日時を入力する
- 画面上部のボタンが「予約投稿」に変わったことを確認する
- プレビュー、カテゴリー、アイキャッチ画像、URLを見直す
- 「予約投稿」を押し、確認画面でも日時を確かめて確定する
保存後は投稿一覧でステータスが「予約済み」になり、予定日時が表示されます。時刻を変えるときは投稿を開いて日時を修正し、更新します。過去日時を指定すると即時公開になるため、日付だけでなく年と時刻も確認してください。
予約投稿前にタイムゾーンを確認する
「設定」→「一般」のタイムゾーンが、運営で使う地域と一致しているか確認します。日本向けなら都市名の「東京」を選ぶと、地域のルールに基づく時刻を扱えます。UTCの固定オフセットを使う場合は、夏時間がある地域でのずれに注意が必要です。
編集画面の予定日時はサイトのタイムゾーンを基準にします。サーバーOSの時刻、閲覧者の端末時刻、担当者の滞在地とは別です。海外の担当者と作業する場合は、「サイト時刻で何月何日何時」と公開管理表へ明記します。
予約投稿が公開されない・失敗する原因
主な原因は次の4系統です。
| 系統 | 起きやすい状況 | 見る場所 |
|---|---|---|
| 時刻 | タイムゾーンや年の指定違い | 一般設定、投稿の公開日時 |
| WP-Cron | 低アクセス、無効化、外部リクエスト遮断 | 設定ファイル、サーバーログ、サイトヘルス |
| 実行エラー | プラグイン競合、PHPエラー、処理過多 | デバッグログ、エラーログ |
| 表示 | 公開済みだが古いキャッシュが残る | 投稿URL、キャッシュ、CDN |
「予約投稿の失敗」は、予定時刻を過ぎても公開処理を完了できなかった状態です。まず投稿一覧の状態と、ログアウトしたブラウザーで対象URLを見比べます。管理画面上の問題と公開ページの表示問題を混同しないことが大切です。
「予約投稿の失敗」を解決する手順
最初に投稿内容を退避し、現在のステータスと予定時刻を記録します。その後、影響の小さい順に切り分けます。
- 一般設定のタイムゾーンと投稿日時を見直す
- 投稿を手動公開できるか試し、権限や投稿データの問題を分ける
- サイトヘルスにループバックや予約イベントの警告がないかを見る
- wp-cron.phpへのアクセスがセキュリティ機能で遮られていないかログで調べる
DISABLE_WP_CRONが有効なら、サーバー側スケジューラーの登録状況を確認する- 検証環境で関連プラグインを停止し、競合やPHPエラーを調べる
アクセスが少ないサイトでは、ホスティングのCronからWordPressのCron処理を一定間隔で呼び出す構成を検討できます。設定方法はサーバーごとに異なるため公式マニュアルに従い、WordPress標準の呼び出しを止める場合は外部実行が動くことを先に検証します。
予約公開と同時にSNSへ自動投稿する方法
WordPressの予約投稿だけでは、SNSへの配信は行いません。SNS連携プラグイン、SNS管理サービス、Zapierなどの自動化サービスを使い、「投稿が公開された」ことを起点に配信します。記事作成から公開までの基本操作は「記事の投稿方法」で確認できます。
連携前に、対象SNS、投稿文、画像、短縮URL、再投稿の条件を決めます。下書き保存や更新でも発火する設定だと重複しやすいため、新規公開だけを対象にします。WordPress側が遅れて公開された場合、SNSも遅れて実行されるのか、予定時刻で失敗扱いになるのかをサービス仕様で確認してください。
Xへの自動投稿・連携で確認すること
Xへの投稿は、プラグイン名より接続方式が重要です。公式APIを使うのか、外部配信サービスが仲介するのか、利用プランで自動投稿が許可されているかを導入時点の公式情報で調べます。仕様や料金は変わるため、過去の手順だけで認証情報を作らないでください。
連携では、投稿先アカウント、アプリ権限、トークンの保管、画像の対応形式、文字数超過時の処理をテストします。認証情報を投稿本文や公開リポジトリへ置かず、使わなくなった連携はX側とWordPress側の両方で取り消します。
予約投稿を使った安全な運用
重要記事を予約しただけで完了にせず、公開後の確認を予定へ含めます。少なくとも投稿一覧の状態、公開URL、画像、内部リンク、キャッシュ、SNS投稿を確認できる担当者を決めます。
複数記事を同時刻に設定すると、画像処理、メール、SNS連携などの処理が重なります。大規模な公開では時刻を分散し、事前にステージング環境で関連ジョブを試します。公開直前の大きな更新は避け、失敗時に手動公開へ切り替える基準と連絡経路も用意します。
よくある質問
WordPress標準の予約投稿は、新規記事の未来公開が中心です。公開済み本文の変更を未来時刻に反映する機能は標準では同じように扱えないため、対応プラグインや編集ワークフローを別途検討します。
標準WP-Cronだけなら、期限到来後のアクセスを契機に処理される場合があります。時刻精度が必要なら、ホスティングが提供するサーバーCronなどで定期実行する構成を検討してください。
設定できます。ただし、同時に動く処理が増えるため、サーバー負荷やSNS連携の上限を事前に試し、必要なら数分ずつ分散します。
まとめ
WordPressの予約投稿は、未来の公開日時を指定するだけで使えますが、サイトのタイムゾーンとWP-Cronの動作が前提です。公開されないときは、時刻、Cron、実行エラー、キャッシュの順に分けて調べます。SNS連携は別のサービスで新規公開だけを起点にし、公開後のページと配信結果を人が確認するところまで運用手順へ組み込みましょう。