生成前に掲載可否ルールを決める
XML サイトマップは機械可読な URL の一覧と任意のメタデータです。クローラのエクスポートではなく、掲載可否ルールから始めてください：ページは検索向けで意図された公開取得可能かつコンテンツの代表版である場合のみ含めます。ファセット化されたカテゴリ URL、内部検索結果、キャンペーン変種、ログイン先、プレビューは、意図的な公開検索対象でない限り除外します。
検索向けに意図された、公共で有用なページで、1 つの推奨 URL を持つもの。
リダイレクト、エラー、重複、noindex ページ、プライベートなルート。
発見の助けにはなっても、クロールやインデックス化を保証するものではありません。
到達方法のすべてではなく正規 URL を列挙する
正規 URL は、類似するバージョンの中で検索エンジンに代表ページとして扱ってほしい版です。サイトマップの掲載は弱い正規化シグナルなので、リダイレクト、自己参照の canonical タグ、内部リンクと矛盾してはなりません。一つの安定した HTTPS フォーマットを選び、その正確な版を出力してください。
http と https、www 有無、末尾スラッシュ規則、大文字小文字、印刷ページ、フィルタ、トラッキングパラメータを確認してください。URL がリダイレクトする場合は、最終的な正規先だけを列挙します。独立して意図されたローカライズ版ごとにそれぞれ正規 URL を与え、サイトマップで異なるローカライズコンテンツをまとめてしまわないでください。
相対パスではなく完全なスキームとホストを記述してください。Google は記載された URL をそのままクロールします。
サイトマップ、canonical タグ、内部リンク、リダイレクト方針が同じページを指すこと。
重複をブロックしても優先版の指定にはなりません。
XML を小さく、有効で、正直なものにする
Sitemap プロトコル（Sitemap Protocol）の構造に従ってください：UTF-8 の XML、urlset、名前空間、各 URL の loc を使います。URL 値中の XML に敏感な文字はエスケープしてください。自動化は文字列連結で XML を手作りするより、シリアライズして出力するようにします。
各サイトマップファイルは最大 50,000 件の URL、かつ非圧縮で 50 MB を超えてはなりません。これらは上限であり目標ではありません。製品、記事、ロケール、コンテンツ種別で運用上の境界ができるなら早めに分割してください。
lastmod はページの実際の重要な変更日だけに使ってください。Google はそれが一貫して検証可能で正確な場合に参照します。単なる著作年の更新は該当しません。生成日時で全 URL に印を付けてはいけません。Google は changefreq と priority を無視するので、省略して構いません。
loc は必須。lastmod は任意で、ページそのものを説明する日付であること。
gzip で転送量を減らせますが、展開後のファイルは 50 MB 未満である必要があります。
XML の整形式、取得可能性、リストされたページの挙動を確認してください。
インデックス（index）で規模を伸ばしつつ所有権を保つ
サイトマップインデックスはサイトマップファイルの一覧です。単一ファイルの上限を超える場合や別個の目録が必要な場合に使います。編集部門、製品、ヘルプセンターなど所有単位でグループ化してください。インデックスにも 50,000 アイテムと 50 MB 非圧縮の上限があります。
子ファイルは対象サイトに置き、安定した URL にしてください。プロトコルは一般にサイトマップに記載可能な URL をサイトマップのホストと場所に紐づけます。クロスサイトの取り決めは所有確認が必要です。
テスト可能な目的（コンテンツ種別、ストアフロント、言語セット、デプロイ境界）で分割してください。ジェネレータ、所有者、期待される件数を記録します。
個別の子ファイルを逐一送るより、完全なインデックスを送信してください。
インデックスの lastmod はページではなくサイトマップファイル自体を示します。
公開・送信・結果の正しい解釈
サイトマップは安定した公開取得可能な HTTPS アドレスでホストし、できればルート付近に置きます。robots.txt に絶対的な Sitemap 指示を追加してください。Google Search Console や Bing Webmaster Tools にサイトマップ（またはインデックス）を送信して処理の詳細を確認します。
Search Console では「Success（正常）」はサイトマップがエラーなく取得・読取されたことを意味します。「Has errors（エラーあり）」は読み取りにエラーがあったこと、「Couldn’t fetch（取得できませんでした）」は取得不能だったことを示します。配信、認証、DNS、robots、リダイレクト、XML の問題を修正して再送信してください。
発見されたページ数はスコアではなく診断入力です。発見されたページが必ずクロールやインデックスされるわけではありません。サンプル URL を正規 URL、レスポンス、インデックスレポートと照合してください。
robots.txt による発見と、ツール送信による処理レポートの露出です。
Search Console は送信済みのファイルや API での登録ファイルを一覧にします。robots.txt から発見されたすべてを個別に示すわけではありません。
サイトマップをリリース重要インフラとして運用する
CMS プラグインの変更、デプロイによる正規ホストの変更、キャッシュルールが古い出力を返す、バルク処理が未完成ページを公開するなどでサイトマップ品質は退化します。サイトマップ検査をプレリリースおよびロールバック作業の一部にしてください。完全な目録が空や壊れたファイルに静かに置き換わらないようにします。
既存の正常なサイトマップを保持し、予期しない件数変化をフラグし、公開前に追加・削除をサンプリング確認してください。パスが変わるときはリダイレクト、canonical タグ、内部リンク、サイトマップを一つの変更セットとして調整します。これは能動的な稼働時間最適化です：クローラや訪問者が壊れたパスを見つける前に発見可能な公開面を保護します。
無効、空、ホスト誤り、非正規なサイトマップ出力のときは公開を止めること。
既知の良好なアーティファクトとジェネレータ設定をロールバック用に用意しておく。