サイト更新の前後には、変更した箇所と、その影響を受ける機能を確認します。文章の修正なら表示とリンク、フォームの改修なら入力から通知まで、PHPの更新ならWordPressや定期処理までというように、必要な範囲は変わります。

毎回全ページを同じ深さで試す必要はありません。以下の項目から、今回の変更に関係するものを選ぶと進めやすくなります。

変更内容別の主なテスト項目

公開前は変更による不具合、公開後は本番環境での動作が中心です。変更箇所に応じた確認範囲の例を挙げます。

変更したもの公開前に見たい点公開後に見たい点
文章・画像誤字、内容、画像サイズ、リンクスマホ表示、更新の反映
共通メニュー・CSS主要ページの表示、開閉、画面幅キャッシュの影響、リンク先
フォーム必須入力、エラー案内、保存、通知本番の送信先と自動返信
テーマ・プラグイン表示、ログイン、保存、依存機能エラー、フォーム、定期処理
PHP・サーバー互換性、DB接続、メール、SSL外部からの利用、ログ、負荷

テスト送信や決済確認には、専用の宛先やテストモードを使います。顧客へ通知や請求が発生しない設定が前提です。

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

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

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

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

更新前の正常な状態を記録する

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

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

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

戻せる時点と復旧時間を確かめる

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

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

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

検証環境では失敗する操作も試す

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

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

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

公開可否と作業中止の条件を決める

公開後に不具合が出たとき、対応できる時間帯かどうかも重要です。問い合わせや受注が集中する時間を避け、問題が起きたときに技術担当者と業務担当者が連絡できる時間を選びます。作業終了後の確認時間も含めて予定を確保します。

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

作業中止の条件も具体的にします。「予定時間を超えた」「管理画面へ入れない」「重要導線が動かない」など、止める状態を決めます。例えばフォームが送れない状態なら、表示の微調整とは扱いを分け、公開延期や復旧を優先する判断になります。

公開直後と一定時間後を分けて確認する

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

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

定期処理・メール配送・キャッシュ更新は、公開直後には結果が出ないことがあります。数十分後や翌営業日など、機能に合う再確認時刻を決めます。「公開直後には動いたが、翌朝の処理で失敗した」ということもあるため、機能が実行される時刻まで分けて見ると抜けを減らせます。