まずはジャーニー、ページの役割、優先度から始める
誤ったルートで実害が出るページを選びます：サービスや製品、カテゴリ、問い合わせやコンバージョン、サポート、アカウント作業、復旧手順などです。各ページについて、想定される流入ページ、訪問者の疑問、有用な次ページ、想定アクション、親やハブへの戻りルートを記録してください。ハブページはトピックを整理し、詳細ページはより狭い疑問に答え、ナビゲーションやパンくずは方向付けを提供します。ユーザーが別の真に有用なセクションへ到達するのを阻むような人工的なサイロ（隔離）を作らないでください。深いページへの直接ランディングとホームページから始まるジャーニーの両方をテストしてください。
利害に直結する収益、アカウント、サポート、安全、法務、復旧のパスを利便性リンクより先に修正します。
重要な各ページには適切なインバウンド経路と、関連または親コンテンツへの明確な導線を与えます。
行き先を説明するアンカーテキストを書く
アンカーテキストはユーザーがクリックする可視の文言です。Google は、説明的で妥当に簡潔、かつ現在のページと遷移先の双方に関連する文言を推奨しています。W3C はリンクの目的がテキスト単独、またはプログラム的に判別できる関連文脈から決定できるべきだとし（WCAG 2.4.4 を参照）、“click here” や重複する “learn more” のような曖昧なラベルは置き換えてください。たとえば遷移先が正確に示されるなら “年間プランと月額プランを比較する” のような表現を使います。同じ目的には同じ文言を使い、異なる遷移先には異なる文言を使い、アンカーを無理なキーワード列にしないでください。画像のみのリンクには説明的な代替テキスト（alt）を付けてください。
リンクだけ、または関連する文と一緒に読んで、読者が行き先を予測できるか確認します。
遷移先のタイトル、見出し、冒頭がアンカーで約束した内容を満たしていることを確認します。
重要な経路はすべてクロール可能かつ利用可能にする
見た目がクリック可能でも、必ずしも信頼できるナビゲーションリンクとは限りません。重要な経路には、実際の URL に解決する href を持つ HTML の a 要素を使用してください。Google は、レンダリングされたマークアップがその形をとる場合、動的に挿入されたリンクはクロール可能になり得ると述べていますが、イベントのみのコントロールからは到達先を確実に抽出できないとしています。JavaScript、同意（consent）、CDN、パーソナライズのレイヤーが走った後のレンダリング結果を検査してください。別途、レスポンスステータス、リダイレクト、canonical、noindex 指示、認証、robots 制御を確認してください：一度のクリックに成功したからといってすべての検索条件が満たされているとは限りません。MDN も href を持つアンカーがハイパーリンクを作り、キーボードで操作可能になることを指摘しています。
ページ移動にはリンク（a）を使い、その場での操作にはボタンを使ってください。見た目のためだけにボタンをリンク代わりに使わないでください。
共有ナビゲーションやルーティング変更の後、代表的なレンダーテンプレートと重要な経路をテストしてください。
オーファンページを防ぎ、変更された経路を整理する
オーファンページとは内部リンクが一切向けられていないページです。Google のガイダンスは、重要なページには少なくとも別のページからのリンクがあるべきだと述べています。これは多数のリンクを要求するものではありません：プライベート、重複、期限切れ、ユーティリティ用の URL は意図的にリンクされない場合があります。例外リストを所有者とレビュー日付きで維持してください。CMS の在庫、サイトマップ、クロール出力、ランディングページのデータを比較して、インリンクのないページ、壊れたソースページ、フッターやサイトマップにしか現れない URL を見つけます。公開時はハブ、親、既存コンテンツから関連するリンクを追加し、廃止時はソースを更新してリダイレクトが実質的に関連のある置換になっていることを検証してください。
重要なインデックス可能ページは、インバウンドおよび戻りルートがレビューされるまで公開しないでください。
訪問者が古い選択肢に出会わないよう、文脈参照の更新とリダイレクトの両方を行ってください。
リンク数目標ではなく証拠に基づいて監査する
Google はページ上の理想的なリンク数などという魔法の数字は存在しないと言っています。作業は影響順にランク付けしてください：チェックアウト、パスワードリセット、重要なサポートの失敗は低価値の記事より優先されます。内部の HTML リンクをクロールして、ソース、ターゲット、アンカーまたはアクセシブルネーム、配置、最終ステータス、リダイレクト先、優先度、オーナー、検証結果を記録します。Search Console の Links レポートは方向性の発見信号として使い、完全な在庫ではないことに注意してください：Google はサンプリングを行い、カノニカル URL をグループ化し、重複を結合し、テーブルを制限します。自前のクロールや CMS リストと比較してください。デスクトップとモバイルでキーフローを実際に試し、キーボード利用も含めて、ローンチ前やテンプレートの大幅変更後に実行してください。
重大な修正の後は、ライブのソースと意図した最終到達先を再テストしてください。
テンプレートレベルの欠陥は個別ページを繰り返し編集するのではなく、エンジニアリングのバックログに入れてください。
経路の整合性をリリース準備に組み込む
ナビゲーションやテンプレートのデプロイは同時に多くのパスを変える可能性があります。サーバー自体が正常でも、重要なルートがそのページに届かなくなっていれば訪問者は恩恵を受けられません。Status Is UP はこれを事前の最適化と修復として扱います（ダウンタイム監視ではない）：優先すべき公開ジャーニーを事前に決め、期待する到達先とオーナーを記録し、避けられる摩擦が発生する前に経路の失敗を修正してください。公開速度に合わせたレビュー頻度を設定し、マイグレーション、ナビゲーションの再設計、ルーティング変更、コンテンツ廃止の際には追加の重点監査を行ってください。
収益、アカウント、サポート、復旧、安全、法務、高い意図を持つカテゴリ経路を事前検証します。
ソース、期待されるターゲット、最終結果、レビュー担当者、修正担当者を示す日付付きのテスト記録を保持してください。