巨大なスキャンではなく、重要なジャーニーから始める
5〜10件のURLを選び、それぞれの期待結果（確認ページ、領収書、CRMレコード、プロバイダへの引き渡しなど）を定義します。収益、信頼、サポート需要、法的義務を生む公開ページと操作を含めてください。ログアウト状態のウィンドウとスマートフォンで訪問者としてテストします。
サードパーティが重要なステップを所有する場合は、ハンドオフとサポート連絡先をマップします。遷移をテストできますが、そのプロバイダ自体を認定することはできません。所見はブロッカー、重大な劣化、改善として分類し、見た目の修正で壊れたジャーニーが埋もれないようにしてください。
収益、信頼、サポート需要、または法的義務を生むルートを網羅してください。
重大な所見には必ず名前のある担当者と目標日を付けてください。
見た目だけでなく、アクセシブルな利用を確認する
アクセシビリティとは、さまざまな入力方法や支援技術でサイトを認識し操作できることを指します。選んだページでTabキー操作によりナビゲーション、メニュー、コントロール、フォームをたどってください。可視のキーボードフォーカス、マウス無しでの主要コントロール操作、主要コンテンツへのルートを確認します。W3CのEasy Checksはキーボードフォーカスやスキップリンクを初回レビューの有用項目として挙げています。
意味のある画像テキスト、ページタイトル、見出し、コントラスト、拡大時の挙動、必要な場合の代替メディア、フォームラベル、必須項目、理解しやすいエラーを点検します。非機密のテスト送信を行ってください。これは適合性監査ではありません：W3Cはクイックチェックに合格しても重大な障壁が残る可能性があると注意喚起しており、リスクの高い作業や設計変更、既知の問題には資格のある評価を用いてください。
ラベル、指示、エラー、確認に到達する実際の経路をテストしてください。
代替テキストは画像の目的を伝え、見出しはページを構成すべきです。
検索での見つけやすさをレビューする（順位を約束するものではない）
SEOは検索エンジンにコンテンツを理解させ、人々が検索から訪問するかを判断する手助けをします。優先ページごとに、タイトル、主要見出し、冒頭の文、URL、内部リンクを新規来訪者の視点で読みます。目的を明確に示し、有用な次のステップにつながっているべきです。Googleは説明的なURL、有用なコンテンツ、説明的なリンクテキストを推奨しています。
Google Search Console を使っている場合は、重要URLを重要なリリース後にインスペクトしてください。GoogleはURL Inspectionがページをクローラがどう見ているか、重要なリソースにアクセスできるかを確認するのに役立つと述べています。誤ってブロックされている箇所、壊れた内部リンク、不明瞭な経路を修正し、再クロールの時間を与えてください。Google はインデックス化やランキングを保証しません。
ログアウト状態で内部リンクを開き、404、ループ、無関係な遷移を記録してください。
訪問者が感じる配信を観察する
配信にはサーバー応答、画像、フォント、スクリプト、キャッシュ、サードパーティが含まれます。優先ページでブラウザのパフォーマンスチェックを実行し、その後実際のスマートフォンでコアタスクを繰り返します。主要コンテンツの遅延、操作の遅さ、レイアウトのジャンプ、リソースの失敗、タスクを妨げるバナーなどを記録してください。Core Web Vitals は web.dev のユーザー体験フレームワークであり、計測値は調査に集中するために使い、ジャーニーテストの代わりにしないでください。
実装担当者と新しいタグ、ウィジェット、埋め込み、フォント、画像変更を確認してください。HTTPキャッシュは以前のレスポンスを再利用します。MDN は Cache-Control がキャッシュの指示を伝えること、キャッシュされたレスポンスが fresh（新鮮）か stale（陳腐化）かになり得ることを説明しています。リリース後は通常と新しいブラウザセッションを比較し、技術担当にヘッダとCDNルールを調べてもらってください。プライバシーやリリース影響を理解せずに一括キャッシュ変更を避けてください。
主要コンテンツが表示されるか、ページが安定しているか、必須コントロールが応答するかを記録してください。
MDN はクッキー単体がレスポンスを「非公開」にするわけではないと指摘しています。パーソナライズされたキャッシュは技術担当にレビューしてもらってください。
セキュリティの基礎を確認し、支払い変更を保護する
オーナーチェックで目に見えるギャップを見つけられますが、これは侵入テストではありません。公開サイトをHTTPSで開き、HTTPも試してください。OWASP は全ページでの TLS を推奨しており、公開HTTPトラフィックをHTTPSにリダイレクトする一般的な方法を説明しています。証明書や混在コンテンツの警告、予期しないドメイン、HTTPページが安全にリダイレクトされずにコンテンツを提供している場合はエスカレーションしてください。
公開、ドメイン、DNS、支払い、プラグイン、バックアップのアクセスと所有権が現在のものであるか確認してください。TLS 設定、パッチ適用、認証、サーバー設定、ログについては資格のあるセキュリティ専門家やプロバイダにレビューしてもらってください。支払いに関しては、プロバイダ承認のテスト手法か安全な非本番環境のみを使用してください。非公式なテストで実際のカードデータや資格情報を使ったり、視覚的な確認だけでPCI適合を主張したりしないでください。
証明書警告、非安全コンテンツ警告、予期しないリダイレクトは、調査されるまでリリース停止扱いにしてください。
侵害の疑い、セキュリティ要件、支払いコンプライアンスの質問は資格あるレビュワーへ回してください。
復旧を実証し、ループを閉じる
優先ジャーニーを再構築するために必要なものを列挙してください：アプリケーションのバージョン、データベース、アップロード済みメディア、設定の所在、DNS とドメインアクセス、統合設定、ベンダー連絡先など。CISA は重要データの特定、ウェブサイトと運用データベースの保護、バックアップの確保と復旧テストを助言しています。いつ復元がテストされたか、何が復元されたか、どれくらい時間がかかったか、誰が承認できるかを尋ね、可能な範囲で安全にリハーサルを行ってください。
リリース前に、前のバージョン、巻き戻しのトリガー、承認者、DNS、キャッシュ、データベーススキーマ、サードパーティ変更の扱いを特定してください。バックアップは即時の解決ではなく、ロールバックが外部データや支払いイベントを元に戻さない場合があることを理解してください。所見、証拠、担当者、日付、再テスト結果の台帳を保持してください。
範囲、日付、結果、ギャップの記録は「バックアップは実行している」より強力です。
修正後、関連する環境で元の失敗経路を検証してください。