【第8回】WordPress予約投稿の公開後検証｜状態・URL・表示を確かめる

記事ID 202の完了条件は、承認済みの下書きを空き枠へ入れ、WordPressから再取得して future と予約日時が正しく保存されたことです。指定時刻に記事が公開されたことまでは証明しません。

本記事は、その後の公開後検証だけを扱います。予約時刻を過ぎたら、WordPressの状態、外部から見えるURL、読者が読む表示内容を別々に確認します。

予約処理から検証対象を引き継ぐ

公開確認を始める前に、予約工程から次の値を受け取ります。

タイトル検索で対象を探し直すと、似た記事を取り違える可能性があります。予約した投稿IDを起点に再取得し、引き継いだ値と照合します。

WordPress REST APIの投稿には future、publish などのstatusがあり、date はサイトのタイムゾーン、date_gmt はGMTの日時を表します。確認時は予約時の応答を使い回さず、時刻経過後の実状態をGETで取り直します。

最初に見るのは次の項目です。

publish なら次のURL確認へ進みます。時刻を過ぎても future のままなら、未公開として記録し、公開成功にはしません。

管理者としてログイン中のブラウザは、一般読者に見えないプレビューや権限付き画面を表示することがあります。公開URLはログアウト状態またはプライベートウィンドウで開きます。

HTTP 200だけでは十分ではありません。リダイレクト後の最終URL、ページタイトル、投稿IDに対応する本文の目印も照合します。

検索結果へまだ出ないことは、公開失敗の判定材料にしません。検索エンジンへの反映は公開URLの確認とは別工程です。

WordPressの本文データが正しくても、テーマ、プラグイン、画像、キャッシュによって公開画面は崩れます。PCとスマートフォン相当の幅で、次を確認します。

全リンクを無差別に再検査するのではなく、今回の更新で追加・変更したリンクと、記事の主要導線を優先します。外部サービス側の反映待ちは、WordPress本文の不具合と分けて記録します。

WordPressの予約投稿にはWP-Cronが使われます。公式資料では、WP-Cronは常時動くシステムcronではなく、ページ読み込み時に期限到来のタスクを確認する仕組みと説明されています。そのため、アクセス状況やサイト構成によって予定時刻から処理が遅れる余地があります。

ただし、future のままだからといって原因をWP-Cronに決めつけません。次の順で切り分けます。

同じ公開操作を何度も送る前に、WordPress側で何が成立しているかを読み取ります。

公開されていない、URLが違う、本文が崩れている場合は、すぐに publish 更新を再送しません。最初の操作が遅れて成立している途中なら、二重通知や意図しない日時変更を招くためです。

異常記録には、確認時刻、予定公開時刻、取得したstatus、最終URL、HTTP応答、表示不良の箇所、最後に正常だった工程を残します。認証情報は含めません。

手動公開、再予約、パーマリンク変更、キャッシュ削除は、それぞれ影響が違います。原因と対象記事を人が確認し、実施する処置を一つ選んでから操作します。

公開後検証は、一つの真偽値にまとめず三層で保存します。

層	成功条件
WordPress状態	対象IDが `publish` で、日時が予定と対応する
外部URL	未ログインで最終URLへ到達し、対象記事を識別できる
表示内容	タイトル、本文、画像、主要導線が読者向けに成立する

三層すべてが成功した時点を、記事公開の確認完了とします。一部だけ成功した場合は「公開済み」と丸めず、どこが未確認かを残します。

検証が完了したら、実際の公開日時、URL、確認者、確認結果を運用記録へ保存します。後日の検索表示、アクセス解析、内容更新は別の保守工程です。

この分離により、記事ID 202は予約を正しく保存する工程、記事ID 212は読者が読める状態を証明する工程になります。予約更新の成功を公開成功と言い換えないことが、シリーズ最終回の要点です。