意図するページと再利用可能な証拠から始める
検索者に見つけてほしい公開ページを一覧にする：主要な製品、記事、カテゴリ、移行したURLなど。各ページについて、優先URL、期待応答、インデックス可能性、テンプレート、オーナー、優先度を記録する。正当な除外は別に管理する。
代表的なURLについては、未認証の応答、ヘッダ、リダイレクト経路、ページソース、レンダリング後のビュー、内部リンクの状態、サイトマップの状態を取得する。すべてのテンプレートとURLパターンをサンプリングする。証拠には日付を付ける：CDNの設定、デプロイ、同意レイヤー、パーソナライゼーションで後から変わる可能性がある。
ホームページが通れば済むとは限らない。リスティング、製品バリアント、ローカライズされたルートが機能しているかを確認する必要がある。
修正や後の回帰と比較できるように、日付入りのヘッダとレンダリング証拠を保管する。
インデックス可能性を意図的な決定にする
インデックス可能性とは、ページが検索インデックスに含まれる可能性があることを指し、クロールやランキングとは同義ではない。HTML内のmeta robots 指令と、HTTP応答ヘッダの X-Robots-Tag を確認する。noindex 指令は検索エンジンにページを表示しないよう伝えるもので、X-Robots-Tag は PDF など非HTMLファイルにも適用される。
robots.txt は別に確認する。クローラは noindex 指令を見るためにページにアクセスする必要があるため、そのURLをブロックすると指令が見えなくなる可能性がある。デプロイされた公開応答を確認すること：CMS 設定や環境フラグがルールを追加することがある。noindex はアクセス制御ではない：機密資料は認証と適切なセキュリティレビューで保護する。
意図したインデックス対象ページで noindex、ログイン応答、ステージング参照、重要なアセットのブロックをフラグする。
HTML head が存在しない場合でも、HTTP 応答ヘッダが指令を含むことがある。
1つの優先URLを一貫させる
カノニカリゼーションは、HTTP と HTTPS、ホスト、追跡パラメータ、フィルタ、印刷用ページなどの重複または類似バージョンの中で優先URLを特定することを意味する。canonical 要素、内部リンク、サイトマップのURL、リダイレクト先を比較する。インデックス可能なページでは、通常それらは同じ絶対的な優先URLを指しているべきである。
重複を廃止する際はサーバー側の恒久的リダイレクトを使用する。Google は恒久的リダイレクトと rel=canonical を強いシグナルとして説明しており、サイトマップの包含は弱いヒントである。信号を整合させることで優先度が強化される。robots.txt を使ってカノニカル化したり、1つのページに対して競合するカノニカルを与えないこと。自己参照の canonical は優先バージョンを示すのに有用だが、検索エンジンの選択は制御外である。
バリアント、優先ターゲット、必要な制御、およびオーナーを文書化する。
移行前に古いURLから新しいURLへのマッピングをテストし、戻せるリダイレクト変更を用意しておく。
ステータスコードとリダイレクト挙動を確認する
ステータスコードはブラウザやクローラに何が起きたかを伝える。重要なライブページは、意図したコンテンツを含む意味のある2xx応答を返すべきである。置換がないページは適切に404や410を返すべきで、移動したコンテンツは最も近い関連する置換先に到達するべきだ。エラーだけを表示する200ページはソフト404として扱われることがある。
すべてのリダイレクトホップを記録する。Google は一般的なウェブクロールで最大10ホップまで辿るとされるが、チェーンは遅延と脆弱性を増す。Google は 5xx と 429 応答がクロールを一時的に遅らせる可能性があり、持続するサーバーエラーは最終的にインデックスされたURLの削除につながり得ると述べている。アプリケーション、CDN、オリジン、キャッシュ、依存関係、デプロイ層にまたがって定期的な失敗をエンジニアリングオーナーと調査する。
元のURL、ホップ、コード、最終URLと期待状態を保存する。
別のホップを追加するのではなく、CMS、CDN、ホスト、ロケール、スラッシュの重複ルールを削除する。
JavaScript のレンダリングとルートを検証する
主要テンプレートについては初期のHTMLとレンダリング後のビューの両方を検査する。主要コンテンツ、見出し、リンク、canonical、robots 指令、状態がレンダリング後に存在することを確認する。Google はクロール、レンダリング、インデックスのフェーズが分かれていると説明し、レンダリング後のHTMLに見えないコンテンツはインデックスされ得ないと述べている。
ナビゲーションには href 属性を持つアンカー要素を使用する。フラグメントのみのルートで異なるコンテンツを読み込む方法は発見性が安定しない。存在しない製品、記事、フィルタ済みURLを直接リクエストしてみる。クライアントサイドアプリケーションは実際のエラー状態を持つ必要がある：Google はサーバー404にルーティングするか noindex を追加してソフト404を避けることを文書化している。サーバーサイドレンダリングやプリレンダリングが助けになる場合があるが、デプロイされた応答を検証すること。
レスポンスHTML、レンダリング後のHTML、人間のブラウザ表示で重要な差異がないか確認する。
ソースHTMLを優先する。もし JavaScript が設定する場合は、競合しない単一の canonical を確保する。
サイトマップと内部リンクをクリーンに保つ
サイトマップは発見の地図であり、インデックスの命令ではない。成功している意図された優先カノニカルURLを含め、リダイレクト、エラー、noindex ページ、パラメータ重複、保護されたURLは除外する。Google は完全修飾の絶対URLを推奨し、サイトマップの包含はカノニカルのヒントと扱われる。
サイトマップを検証し、意図したインデックスリストやナビゲーションと比較する。Google は UTF-8 エンコーディングと、サイトマップは未圧縮で50MBまたは50,000URLの制限があることを文書化している。大規模サイトでは有用なグループに分割し、インデックスファイルを使う。lastmod は重大で検証可能なページ変更のときのみ更新する。
意図したURL、サイトマップの項目、内部リンクの間に意味のある差があれば調査する。
ルーティングやCMS変更後に生成されたサイトマップと、記載されたURLのサンプルを確認する。
パフォーマンスを測定し監査を制度化する
利用可能なフィールドデータと、再現性のあるラボテストを使って Core Web Vitals（コアウェブバイタル）を調査する：読み込みでは Largest Contentful Paint（LCP）、応答性では Interaction to Next Paint（INP）、視覚的安定性では Cumulative Layout Shift（CLS）を測る。平均は壊れた高価値テンプレートを隠すことがあるので、ページタイプ別とデバイス別にセグメント化する。
画像、CSS/JavaScript、サードパーティタグ、フォント、埋め込み、キャッシュなどをたどって遅いまたは不安定な配信を追跡する。1つの測定された変更を行い、レンダリングとユーザーフローを再チェックする。フィールドデータは実ユーザーを反映し、ラボデータは再現に役立つ。どちらも将来のすべてのクローラや訪問者を予測するわけではない。リスクの高いリリース後は重点的な回帰チェックを繰り返し、移行やプラットフォーム変更の後はより完全な監査を行う。
収益に直結する、または使用頻度の高いテンプレートでの失敗を、他の小さなスコア改善より先に修復する。
応答、カノニカル、レンダリング後コンテンツ、サイトマップ状態、関連パフォーマンス証拠を閉鎖前に再確認する。