ステージングは、本番とは別の場所で変更と戻し方を試すために使います。複製したサイトが外部へメールを送り、予約記事を公開し、決済を実行しないよう、接続と公開範囲を先に点検します。
本番のコピーへ入る前に、外部接続を分ける
フォーム通知、メール、決済、会員、外部API、analytics、cronなどを一覧にします。試験用の接続先へ置き換えるか、必要な操作を止める方法を決めます。DBを複製しただけでは、これらの設定も本番のまま残る場合があります。
試験環境の点検票
閲覧できる人：
検索への露出：
メール・通知の送信先：
外部APIと決済：
予約・定期実行：
個人情報を含むデータの扱い：noindexだけを閲覧制限の代わりにせず、必要なアクセス制限も設けます。機密や個人情報を含むデータは、必要な範囲へ絞ることを検討してください。
変更する版と、代表ページを固定する
テーマ、プラグイン、設定、記事のどれを変えるかを決め、変更前の版を残します。記事・一覧・フォーム・非公開の代表ページを選び、同じ対象を変更前後で比較します。
| 検査 | 見るもの |
|---|---|
| 表示 | スマホとPCの見出し、表、画像、操作 |
| 情報 | 本文、URL、description、canonical、robots |
| 入力 | フォームの正常・エラー・通知 |
| 公開範囲 | 下書き、予約、試験URLが見えないこと |
本番へ渡す範囲を、差分だけにする
テーマの修正なら対象ファイル、記事の修正なら対象投稿ID、設定なら対象項目を明示します。試験中に本番へ新しい問い合わせや記事が増えた場合、古いDBで全体を上書きしないようにします。
環境の区別は公式のwp-config設定も確認してください。環境名を付けたことだけで、メールや公開状態の設定が自動で変わるとは限りません。
反映後は、本番のHTTPと操作を確認する
本番へ変更を渡した後、未ログインで公開ページを読み、必要なフォームやリンクを試します。キャッシュがある構成では、実際に配信される版を照合してください。
戻す場合の対象と担当を決め、試験で戻せたことも記録します。ファイルとDBの復元はバックアップからの復旧へ分担し、今回の変更を確認できる形で反映します。