期限切れの記事を下書き・非公開・リダイレクトにする（そして確認したら戻す）

更新期限を管理するプラグイン、と聞くと、期限が来たら記事が自動で消えるものだと思われがちですが、コンテンツ更新管理では消えません。削除もしないし、本文も書き換えない。期限を過ぎたときにできるのは、その記事の見せ方を変えるところまでで、しかも既定は「何もしない」です。導入した日に何かが非公開になる、ということは起きない。

この記事では、期限切れのときに選べる処理と、それがいつ実行され、確認が終わったらどう戻るのか（あるいは戻らないのか）を書きます。次回確認日や担当者をどう決めるかという全体の話は更新期限と担当者を管理する記事に譲ります。

選べる処理は、管理する単位で違う

期限切れ処理は管理対象ごとに1つ選びます。選択肢は管理単位で異なり、共通しているのは「どれも本文やフィールドの値を書き換えない」ことです。

管理単位	選べる期限切れ処理
投稿（固定ページ・カスタム投稿タイプ「投稿」「固定ページ」とは別に用意する独自の投稿の種類。物件・店舗・用語のように同じ形の情報を、通常の記事と混ぜずに管理する。含む）	管理画面で警告のみ／投稿を下書きへ変更／投稿を非公開へ変更／指定URLへリダイレクトあるURLを開いたとき、別のURLへ自動で転送すること。ページを消す代わりに関連ページへ送ると、検索エンジンからの流入やブックマークを失いにくい。（301・302）
管理ブロック（コンテンツ更新管理セクション）	管理画面で警告のみ／フロント画面でブロックを非表示／代替メッセージを表示
ACFAdvanced Custom Fields。投稿に独自の入力欄（カスタムフィールド）を追加するプラグインの定番。無料版と有料のPro版がある。フィールド・カスタムフィールド投稿に本文とは別の「項目名と値」を持たせる入力欄。資本金や営業時間のような値を本文の外で管理でき、ACFなどのプラグインで追加するのが一般的。	管理画面で警告／通知のみ

投稿単位で「下書きへ変更」を選んでも、記事の中身には手を入れません。ステータスが下書きになるだけで、編集画面を開けば本文はそのままあります。フィールドに至っては警告と通知しかできません。ACFやカスタムフィールドの値は任意のテーマやプラグインが出力するので、値を消したり隠したりすると、どこが壊れるか予測できないためです。

既定値は設定画面で管理単位ごとに変えられますが、それは入力欄の初期値になるだけで、既存の管理対象には効きません。

いつ実行されるか、何回実行されるか

期限の判定は日単位、サイトのタイムゾーン基準です。次回確認日の翌日0:00以降に「期限超過」となり、その後の最初の毎時処理で期限切れ処理が走ります。分単位で切り替わるものではなく、定期処理はWP-CronWordPressが予約投稿や定期処理を動かす仕組み。サーバーの時計ではなく、誰かがサイトを開いたタイミングで動くため、アクセスの少ないサイトでは遅れることがある。に乗っているので、アクセスの少ないサイトでは実行がさらに遅れることがあります。

実行は確認サイクルごとに一度だけ。同じ日に定期処理が何度走っても二重には実行されず、実行したことは履歴に「期限切れ処理実行」として残り、担当者・承認者・エスカレーション先へ通知が飛びます。承認待ちや差し戻し中に期限を超過した場合も実行します。

すでに手動で下書きや非公開にしてあった投稿はどうなるか。ステータスは変えず、履歴に「処理不要」と記録するだけです。人が先に手を打っていたなら、プラグインが上書きする理由はない。

最初の設定は「警告のみ」で十分なことが多い

警告のみを選ぶと、投稿の編集画面に通知が出て、管理対象の一覧にバッジが付き、ダッシュボードの期限超過の件数に入る。フロントは何も変わりません。

書き手としての判断を言うと、期限切れ処理は導入時に張り切って設定するものではなく、確認の運用が回り始めてから足すもの。担当者が期限どおりに確認できているうちは、警告だけで十分です。「期限を過ぎたら公開を止める」を選ぶのは、公開され続けることの損害が、一時的に非公開になることの損害より大きいページ——古い料金で申し込まれると困る、終了した条件で問い合わせが来ると困る——に絞るのが現実的だと思います。

リダイレクトは301か302か、そして検索とフィードから外れる

リダイレクトは転送先のURLと、301か302かを選びます。転送先はサイト外のURLでも保存できますが、自分自身へのリダイレクトと、このプラグインが管理するリダイレクトどうしで10段を超えるチェーンになる設定は保存できません。javascript: のような危険なスキームも拒否します。

301と302の使い分けは、確認が終わったあとに戻す前提かどうかで決まります。後述するとおり、リダイレクトは確認完了で自動解除されるので、「確認して直したらまた見せる」ページなら302。ブラウザや検索エンジンに恒久的な移転として覚えられたくないからです。統合先が決まっていて戻すつもりがないページなら301でもよいのですが、そういうページはそもそも更新管理の対象から外して、恒久的なリダイレクトとして別に設定するほうが素直です。

リダイレクト中の投稿は、投稿ステータスは公開のまま維持されます。ただしサイト内検索・フィード・アーカイブからは除外されるので、一覧ページに出てきてクリックしたら別のページへ飛ばされる、という体験にはなりません。

ここで1つ、設計上の制約を書いておきます。運用ルール（投稿タイプやカテゴリの条件で管理設定を自動で当てる仕組み）では、期限切れ処理に「指定URLへリダイレクト」を選べません。ルールは条件に一致した投稿にまとめて設定を当てるものなので、遷移先のURLを持てない。転送先が空のリダイレクト対象を作ると、フロントでは何も起きないのに履歴には「実行しました」と残り、その投稿の編集画面は保存が通らなくなる。3つ同時に壊れる設定は作れないようにしました。「一致した全投稿を同じURLへ飛ばす」という案も検討しましたが、強すぎるので採っていません。リダイレクトは投稿ごとに編集画面で設定します。

確認が終わったら戻るもの、人が戻すもの

確認完了——承認者を置いていれば承認された時点、置いていなければ担当者が確認結果を登録した時点——で、次の3つは自動で解除されます。

解除も履歴に「期限切れ処理解除」として残ります。

一方で、下書きへ変更・非公開へ変更にした投稿は、確認が完了しても自動では戻しません。「以前の公開状態へ戻す」というボタンが投稿の編集画面と管理対象の詳細画面の両方にあり、それを人が押します。押せるのは、その投稿を公開できる権限と管理対象の操作権限を持つユーザーです。

この仕様にしたのは、「公開に戻す」を人の明示操作にしておきたかったからです。リダイレクトや非表示は「確認中なので一時的にこう見せている」状態で、確認が終われば元に戻るのが自然。でも下書きや非公開は、確認の結果として「やはり公開を止めておく」という判断があり得ます。確認結果を登録した瞬間に勝手に公開されると、直しきれていない記事が表に出る。戻す操作が1つ増える不便より、そちらのほうが困ると考えました。

戻し方の手順としては、次のようになります。

確認が完了すると次回確認日が完了日と更新頻度から再計算され、次のサイクルに入ります。

記事全体ではなく、一部分だけ差し替えたいとき

料金表や注意事項のように、記事の中の一部だけが古くなるページでは、投稿ごと下書きにするのは大げさです。管理ブロックで囲んだ範囲だけを非表示にするか、「現在、この情報は確認中です。」という代替メッセージに差し替えれば、記事は公開されたまま、その範囲だけが確認中の表示になります。記事の一部分だけに期限をつける方法は、ブロックの置き方や保存の注意も含めて別に書いています。

製品ページは コンテンツ更新管理 にあります。