PHP更新後、WordPressの予約投稿が動かない？定期処理まで確認するチェックリスト

PHPの更新やサイト再開後、ページは表示されるのに予約していた記事が公開されない。普段は意識しない定期処理だけが動いていないと、表から見える表示確認では気づきにくくなります。

この記事では、WordPressの予約投稿を手がかりに、更新・復旧後に確認したい定期処理を整理します。PHP更新で必ず停止するという意味ではありません。予定と実行結果を照合し、運営担当と保守担当が確認範囲を共有するための手順です。

WordPressには、ページ表示とは別に予定を実行する仕組みがある

WordPress公式は、予約投稿や更新確認などにWP-Cronという仕組みを利用すると説明しています。通常の仕組みではページの読み込みをきっかけに実行予定を確認するため、指定時刻に常駐して動くサーバーのスケジューラーとは異なります。

出典：WordPress公式「Cron」

また、サーバー側のスケジューラーから実行を促す構成もあります。予約投稿が遅れたときは、まず自社のサイトがどの仕組みで動いているか確認しましょう。プラグイン独自の仕組みや外部サービスで実行する処理も、WP-Cronとひとまとめにせず整理します。

出典：WordPress公式「サーバーのスケジューラーとの接続」

最初に、時刻と公開状態を確認する

予約投稿が出ていない場合は、対象記事、設定した日時、サイトのタイムゾーン、現在の投稿状態を記録します。「午前9時のつもりだったが、別の時間として設定されていた」といった条件の違いを先に切り分けるためです。

次に、管理画面の状態と公開ページの表示を分けて確認します。投稿が公開済みなのに画面に反映されない場合は、公開処理と表示・キャッシュの確認が必要です。一方、予約のままなら、予定された処理の実行状況を確認することになります。

繰り返し状態を変更する前に、最初に見つけた時点の情報を控えます。設定を動かしてしまうと、担当者が元の状態を追いにくくなるためです。

PHP更新後は「どこから実行する処理か」を確認する

公開ページで動く処理と、サーバーの定期実行から動く処理では、設定や起動方法が異なる場合があります。保守担当には、定期処理の実行方法、直近の実行時刻、エラーの有無を確認してもらいます。

サーバー側の設定でPHPを直接起動する構成なら、起動するプログラムの場所やPHPの指定も確認項目です。これは、すべてのサイトでWeb用と定期実行用のPHPが違うという意味ではありません。「サイトのPHPを変えた」という説明が、定期処理の実行環境も含むのかを明確にするための確認です。

管理画面から見えるPHPの番号だけで、別経路の実行環境や修正状況まで確認済みとは扱わないようにしましょう。

予約投稿以外の定期処理も棚卸しする

サイトによっては、バックアップ、集計、通知、データ連携などを定期的に動かしています。これらは導入しているプラグインやサービス、独自実装によるもので、WordPressに標準ですべて備わるわけではありません。

運営側が「毎日自動で動く」と理解している作業を挙げ、保守担当に実際の実行元を確認します。記録を見る場所と正常な結果が分かれば、今後も同じ方法で確認できます。

この表は記入用の例です。自社で利用していない行は除き、追加の処理があれば実行元と確認先を追記してください。特定サイトでこれらの不具合が起きているという調査結果ではありません。

止まった処理は、まとめて再実行する前に確認する

サイト停止中に予定時刻を過ぎた処理がある場合、再開後に何が実行済みで、何が残っているかを整理します。予約記事なら古い告知が今も有効か、通知なら今から送るべき相手と内容かを、運営側で判断する必要があります。

処理の仕様によっては、再実行で通知や連携が重複する可能性もあります。「全部実行しておけば安心」とせず、担当者が処理済みの範囲と再実行時の影響を確認してから進めてください。

特に、注文や在庫、請求に関係する処理では、実行ボタンを押す前に業務担当と結果を照合します。プログラムの実行完了と、業務上の正しい状態は分けて確認しましょう。

保守担当へ渡す確認依頼の文面

お世話になっております。
PHP更新・サイト再開後の定期処理について確認をお願いいたします。

対象サイト：［URL］
処理名：［予約投稿・バックアップ・通知など］
予定日時：［日時・タイムゾーン］
確認した状態：［未実行・遅延・エラー内容など］

実行元の仕組み、直近の成功日時、今回の変更後の実行環境をご確認いただけますでしょうか。
停止中に予定された処理についても、実行済みの範囲と残件、再実行の必要性・重複の可能性を確認したうえで、対応方法をご提案ください。

設定変更で直す前に、現在の構成を確認する

ネット上で見つけた設定をそのまま追記したり、理由が分からないままスケジューラーを切り替えたりすることは避けます。既存の実行設定との関係を確認しないと、処理が動かなくなったり、複数の経路が意図せず併存したりする原因になります。

「アクセスが少ないから遅れたのか」「実行時にエラーが出たのか」「外部の実行元が呼び出せないのか」など、候補を分けて調べます。アクセス制限を外す必要があると自己判断せず、保守担当が必要な実行経路と保護方法を確認して対応を決めてください。

復旧確認には「最終成功日時」を残そう

復旧の記録には、設定を直した日時だけでなく、対象の処理が成功した日時と結果を残します。予約投稿なら公開状態、通知なら送信・受信結果、連携なら反映先の結果まで確認すると、完了条件が具体的になります。

次回以降の確認担当も決めておきましょう。毎回の作業で画面だけを見るのではなく、自社に必要な定期処理を一覧で持つことが、保守の引き継ぎにも役立ちます。

基本的な更新対応はPHP脆弱性と自社サイトの確認手順、旧環境まで含む確認はHTMLサイトで見落としやすいPHP利用箇所も参照してください。

株式会社レジットでは、ホームページ・ECサイトの制作、WordPress保守や公開後の運用についてご相談を受け付けています。定期処理の管理先が分からない、リニューアルに合わせて運用を整理したい方は、お問い合わせフォームからご相談ください。調査・対応範囲は、現在の構成と契約内容を確認したうえでご案内します。

本記事は2026年10月26日確認時点のWordPress公式資料に基づきます。個別のプラグインや外部サービスの動作は、それぞれの提供元の案内をご確認ください。