XMLサイトマップには、検索結果で見せたいページのURLを載せます。しかし、掲載したURLがすべてインデックスされるわけでも、そのURLが必ず正規ページに選ばれるわけでもありません。Googleはサイトマップを発見と正規化の手掛かりとして使い、最終判断はクロールした内容や他のシグナルに基づいて行います。
新しい記事を公開した後の点検では、「サイトマップに存在するか」と「検索に表示されるか」を別の確認項目にします。登録完了だけを公開成功の証拠にしないための実務手順です。
掲載するURLを選ぶ
Googleの公式案内では、サイトマップへ完全な絶対URLを記載し、検索結果へ出したいURLを選ぶよう求めています。相対パスだけでは対象を明確にできません。同じ本文へ複数のURLから到達できるときは、代表として公開するURLを一つ決め、サイトマップにはその版を載せます。
URL一覧を出す前に、HTTP応答、noindexの有無、canonical、リダイレクト先を突き合わせます。リダイレクト元や非公開ページを載せていないかを確認し、公開意図と配信状態が食い違う項目を洗い出します。サイトマップだけを直しても、ページ側のHTMLが別URLを正規と示していれば整合しません。
Googleが選ぶ正規URLの確認方法を参照し、自己指定とGoogle選択の違いを確認してください。サイトマップへの掲載は弱い正規化シグナルであり、canonical指定やリダイレクトの矛盾を押し切る保証はありません。
lastmodを更新する条件
lastmodはページの重要な変更があった日付を示すための要素です。Googleは値が一貫して検証可能である場合に利用すると説明しています。本文、構造化データ、主要リンクの変更などは重要な更新になり得ます。一方、毎日の日付差し替えだけでページの内容が新しくなったとは言えません。
更新履歴には、URL、変更日、変更した主要要素、公開確認日時を残します。本文に手を加えていないのに全ページのlastmodを毎日進めると、日付と実際の変更の対応を示せなくなります。運用システムのビルド日時と記事の内容更新日を分けて扱います。
Googleはpriorityとchangefreqの値を無視すると案内しています。これらを高い値へ変更して検索順位や巡回頻度を操作しようとする施策は根拠がありません。どのページが重要かは、公開内容や内部リンクを含めたサイト全体の設計で伝えます。
形式と送信後の確認
XMLサイトマップは非圧縮で50MBまたは5万URLが上限です。大規模サイトで上限を超える場合は分割し、必要に応じてサイトマップインデックスを使います。小規模サイトでも、記載するURLを機械的に増やすのではなく、公開したい正規ページだけを保ちます。
送信後はSearch Consoleのサイトマップ画面で取得や処理の状態を確認し、重要URLはURL検査でも確認します。サイトマップの送信成功、Googleによるクロール、インデックス、検索表示は別の段階です。広告レポートの基本的な読み方と同じく、指標の母数と意味を分けて記録します。
保留と次の運用
掲載したい正規URL、ページの公開可否、実際の重要更新日が確認できない場合は、新しいURLの追加やlastmod更新を保留します。URLの統合や削除を伴うなら、検索以外の参照や計測への影響も先に調べます。サイトマップの見た目を揃えるためだけに本番URLを変えません。
次の確認日には、掲載URLの応答、自己指定canonical、Google選択正規URL、インデックス状態を記録します。公開直後の未登録を即座に失敗と決めず、検索エンジンが再取得する時間も考慮します。登録と成果を別々に追うことで、修正すべき技術的不整合と待つべき段階を見分けられます。
サイトマップを自動生成している場合は、記事を非公開にしたときに一覧から外れるか、公開日だけ変わったときにlastmodが不必要に進まないかを点検します。手作業の一覧なら、追加や削除の担当者と確認日を決めておきます。検索表示が少ないページを見つけても、まずはURLの状態と内容を確認し、単にサイトマップへ再送信するだけで改善するとは考えません。
日報では、公開済みURL数、サイトマップ掲載数、Googleが把握したURL数を混同しません。ページが正常に表示されていても、サイトマップ処理やクロールの時刻は別です。公開確認の時点ではHTTP応答とHTMLの正規指定を先に確かめ、検索側の反映は継続観測として記録します。
編集担当者が内容を大きく修正した場合は、どの部分が変わったかを保存します。日付だけを動かす運用よりも、読者への説明が改善したかを確認する方が重要です。検索結果の変化を判断するには、変更前後で同じ期間と指標を使い、十分な表示機会があるかも確認します。