サイト更新前のテスト項目と公開後の確認ポイント

サイト更新のテストは、すべてのページを眺める作業ではありません。今回の変更で壊れる可能性がある場所と、止まると業務へ大きく影響する導線を先に決めます。結果は更新前・検証環境・公開直後で比較します。この比較により、公開してよいかを判断しやすくなります。

確認項目だけを増やしても、誰が合否を決めるか分からなければ公開作業は止まります。変更内容・期待する結果・担当者・確認期限・切り戻し条件を一つの作業記録へまとめます。技術担当者だけでなく、問い合わせや購入を受ける業務担当者の確認も必要です。

変更した場所から影響範囲を広げる

最初に追加・削除・更新するファイルや設定を書き出します。WordPress本体・テーマ・プラグイン・PHP・DNSなど、変更の種類を曖昧にしません。制作会社へ依頼した場合は、「更新一式」ではなく対象・版・変更理由を受け取ります。

次に、直接変える場所から関連する機能へ範囲を広げます。フォームの見た目を直すなら、入力から自動返信までが一つの導線です。途中のエラー表示・送信・管理者通知も確認します。PHPを更新するなら、管理画面だけでなく予約処理や定期処理も影響候補になります。

すべてを同じ深さで試す必要はありません。問い合わせ・購入・予約・応募・会員ログインなど、売上や顧客対応に直結する機能を優先します。影響が小さい表示変更と、データを保存する機能を同じ一項目として扱わないことが重要です。

更新後だけを見ると、元からあった不具合を今回の更新が原因だと誤認することがあります。対象ページを更新前に開き、期待する表示と操作結果を記録します。主要画面の画像・フォームの受信時刻・表示速度など、変更内容に合う証拠を残します。

端末と利用者の条件も決めます。管理者としてログインしたブラウザーだけでなく、一般利用者の状態でも確認します。スマートフォン・パソコン・主要ブラウザーから、実際の利用状況と変更リスクに合う組み合わせを選びます。

表示速度に関わる更新では、更新前後を同じURLと近い条件で測ります。測定にはPageSpeed Insightsを使います。一回の点数だけで合否を決めず、主要な指標と実際の操作感を更新前の結果と比較します。

更新前には、今回の変更を戻せるバックアップを用意します。WordPress公式のバックアップ解説が示すように、復元にはデータベースとファイルの両方が関係します。片方だけ取得して完了とせず、対象と取得時刻を記録します。

自動バックアップがある場合も、保存場所・世代・復元方法を確認します。申請後に事業者が復元する方式なら、受付時間と所要時間が業務に合うとは限りません。自社で戻すのか事業者へ依頼するのかを決め、必要な連絡先を作業前に用意します。

切り戻しには期限があります。公開後に注文や問い合わせが増えた状態で古いデータベースへ戻すと、新しいデータを失います。どの不具合なら即時に戻すか、どの時刻を過ぎたら修正を優先するかを、業務責任者と決めます。

検証環境では正常に完了する操作だけでなく、入力不足・誤った形式・二重送信なども試します。利用者が間違えたときに、内容の分かる案内が出るかを確認します。データを扱う機能では、再読み込みや戻る操作で二重登録が起きないかも見ます。

外部サービスとの連携は、実際にどこまで到達したかを確認します。メールの送信画面が成功でも、受信側で迷惑メールに入る場合があります。検証用の決済やWebhookを使い、実売上や本番通知を発生させずに一連の流れを確かめます。

検証と本番の違いも記録します。本番だけにあるキャッシュ・WAF・CDN・アクセス量は、検証環境で再現できないことがあります。再現できない項目は未確認として残し、公開直後に限定した確認へ回します。

公開日時は、作業者の都合だけで決めません。問い合わせや受注が集中する時間を避け、問題が起きたときに技術担当者と業務担当者が連絡できる時間を選びます。作業終了後の確認時間も含めて予定を確保します。

公開前の記録には、検証で合格した項目・残る差・バックアップ時刻・反映手順を載せます。重大な不具合が一つでも残る場合に延期するのか、影響を限定して公開するのかを承認者が判断します。未確認を合格として扱いません。

作業中止の条件も具体的にします。「予定時間を超えた」「管理画面へ入れない」「重要導線が動かない」など、止める状態を決めます。担当者の感覚で続行せず、決めた時点で切り戻しや延期へ切り替えます。

公開直後は、本番URLを外部回線から開きます。トップページだけでなく、今回の変更箇所と重要導線を一般利用者として操作します。キャッシュを消した条件と通常の条件を使います。SSL警告・表示崩れ・フォーム送信・ログインなどを確認します。

サーバーのエラーログや監視も見ます。画面にエラーが出ていなくても、裏側で警告や外部連携の失敗が増えている場合があります。更新時刻を基準に確認し、関係のない過去の記録と混同しません。

定期処理・メール配送・キャッシュ更新は、公開直後には結果が出ないことがあります。数十分後や翌営業日など、機能に合う再確認時刻を決めます。公開日時・版・確認者・結果・残課題を記録します。次の更新時にも比較できる基準として残します。