先に結論を述べます。XMLサイトマップのpriorityフィールドは検索順位に影響しません。Googleは、この値を参照しないと公表しています。changefreqも同様です。実際に読み取られ、AIクローラーの巡回効率に直接影響するフィールドはlastmodです。サイトマップを生成するたびに全URLのlastmodを当日の日付へ更新していると、クローラーの助けになるどころか、この一覧は信用できないと学習させることになります。本記事では、XMLサイトマップをクローラーに信頼される変更履歴として整備し、GPTBot、ClaudeBot、PerplexityBotに最小限の巡回で最新ページを取得してもらう方法を解説します。
サイトマップの役割は順位向上ではなく、クロールとインデックスの効率化
サイトマップを用意しても、ページの検索順位が上がるわけではありません。その役割は、「これらのURLが存在し、このページは最近変更された」とクローラーに伝えることです。ページ数が数百未満で、内部リンクも適切に整備された小規模サイトなら、サイトマップの有無による差はそれほど大きくありません。Googleは通常のクロールだけでも全ページを発見できます。サイトマップが本領を発揮するのは、大規模なサイト、リンクの届かない深い階層や孤立ページがあるサイト、コンテンツを頻繁に更新するサイト、あるいは特定の変更をできるだけ早く認識してほしい場合です。AIクローラーはGoogleよりクロール予算が小さく、URLを送信できるSearch Consoleのような仕組みもありません。そのため、手掛かりとして頼れる情報は想像以上に限られています。
lastmod：現在も参照される一方、最も誤設定されやすいフィールド
Googleの方針は一貫しています。lastmodは参照しますが、その値が正確な場合に限られます。サイトマップを再生成するたびに全ページのlastmodが当日の日付へ書き換えられていると判断されれば、このフィールドの信頼性は実質的に失われます。その後、本当に重要なコンテンツを変更しても、更新シグナルが伝わりません。lastmodに記録すべきなのは、コンテンツに実質的な変更が加わった日時です。テンプレートの調整日時でも、サイト全体を再デプロイした日時でもありません。この点では、多くのCMSのデフォルト設定に問題があります。
- タイムゾーンを含むW3C Datetime形式を使用します。例：2026-07-02T14:30:00+08:00。日付だけの記載は避けてください。
- 更新するのは、コンテンツが実質的に変わったときだけです。誤字の修正、装飾画像の差し替え、CSSの微調整は含めません。
- サイトのビルド時刻やデータベースのupdated_atを、そのままlastmodに使用しないでください。デプロイのたびにサイト全体が更新されたという誤った情報を送ることになります。
- サイトマップインデックス内の各サブファイルにも、それぞれlastmodを設定します。値には、そのグループで最後に実質的な変更があった日時を指定してください。
- 技術的に正確なlastmodを出力できない場合は、サイト全体に毎日「今日」と記録するよりも、フィールド自体を空欄にするほうが適切です。
priorityとchangefreq：設定しても参照されないフィールド
Googleのエンジニアは、priorityをまったく考慮せず、changefreqも同様であると明言しています。Bingもほぼ同じ見解です。CMSがこの2つのフィールドを自動入力するのであれば、そのまま残しても問題ありません。ただし、あるページを0.8にするか0.6にするかをエンジニアに検討させる必要はありません。数値を変えても、クロールや検索順位の結果には影響しないためです。priorityに多少の意味があるとすれば、自社にとって重要なページを整理するきっかけになることです。あくまで人間向けであり、アルゴリズム向けではありません。
AIクローラーはサイトマップをどう発見し、利用するのか
GPTBot、ClaudeBot、PerplexityBot、CCBot、Google-ExtendedなどのAIクローラーには、URLを送信できるSearch Consoleがありません。最も安定した発見経路は、robots.txtに記述するSitemapディレクティブです。この記述がなければ、リンクをたどって到達してもらうほかありません。サイトマップを明示し、lastmodを正確に設定すれば、クローラーは変更のないページをスキップし、限られたクロール予算を新しいコンテンツに振り向けられます。これはGEOの目的にも合致します。目指すべきはサーバーへ何度も巡回してもらうことではなく、コンテンツが参照されることだからです。
大規模サイトのサイトマップを分割し、インデックス効率を最大化する方法
サイトマップの単一ファイルには、50,000 URLまたは非圧縮時50MBのうち、先に達したほうが上限となる厳格な制限があります。上限を超える場合はファイルを分割し、サイトマップインデックスでまとめる必要があります。インデックス自体には、最大50,000件の子サイトマップを登録できます。実務では、ファイルが上限に達してから分割するのではなく、当初からコンテンツ種別ごとにグループ化する方法が有効です。Search Consoleで各グループのインデックス登録状況を確認でき、問題のあるコンテンツ群をひと目で特定できます。
- コンテンツ種別でグループ化します。例：sitemap-blog.xml、sitemap-docs.xml、sitemap-product.xml。各ファイルのカバレッジを個別に確認できます。
- 各ファイルは50,000 URLまたは非圧縮時50MBを上限とします。超える場合は分割し、サイトマップインデックスで統合します。
- 大きなファイルはgzipでsitemap.xml.gzに圧縮します。プロトコルで認められており、帯域幅の節約にもなります。
- 料金、比較、FAQ、導入事例など、AIに参照される可能性が高い価値あるページをまとめます。これらのページは更新頻度を高め、lastmodを最も正確に保ってください。
- noindexが設定されたURL、canonicalで別ページを正規URLとして指定しているURL、4xx/5xxを返すURLは含めないでください。リスト全体の信頼性を損ないます。
pingは終了：2023年以降の更新通知はどうするべきか
Googleは2023年にサイトマップのpingエンドポイントを廃止し、Bingもこれに追随しました。現在、/ping?sitemap=へリクエストを送っても効果はありません。代替策は3段階あります。まず、正確なlastmodを維持し、クローラーが自身の巡回周期で戻ってきた際に、再クロールの要否を判断できるようにします。次に、サイトマップをSearch Consoleへ一度送信し、何度も再送しないようにします。さらにBingとYandexにはIndexNowを利用し、URL単位の変更通知をリアルタイムで送信します。ただし、GoogleはIndexNowに対応していません。多くのAIクローラーも、自身の再訪スケジュールとサイト側のlastmodを頼りにしています。すべてのクローラーへ同時に働きかけられる本当のレバーは、lastmodを正確に運用する規律です。
公開前に確認するサイトマップのチェックリスト
- robots.txtにSitemapディレクティブがあり、一般公開されたサイトマップURLを指定している。
- lastmodが実際のコンテンツ変更を反映し、タイムゾーンを含む形式になっている。サイト全体が同じ日付になる状態も発生していない。
- サイトマップには、200を返し、インデックス登録可能なページだけを掲載している。noindexやcanonicalの対象URLは除外している。
- 単一ファイルが50,000 URLまたは50MBを超えていない。大規模サイトではサイトマップインデックスを使い、コンテンツ種別ごとにグループ化している。
- Search Consoleへ一度送信し、「検出済み」の件数が実際のページ数と一致するか確認している。
ここまでの項目を正しく整えれば、サイトマップは単なる定型ファイルではなく、クローラーやAIエンジンが信頼できる変更情報になります。多くのチームが抱える問題はページの不足ではありません。サイト全体のlastmodが不正確で、さらにインデックス登録できないURLまでサイトマップに混在していることです。外部ツールでクロールすれば、こうした問題は明らかになります。サイトマップを含む技術AEO設定の不足箇所を把握したい方は、30分のGEO診断（/contact）をご予約ください。優先して修正すべきポイントを具体的にお伝えします。
