lastmodは見られ、priorityは無視される｜AI検索時代のXMLサイトマップ設計

結論：lastmodは効く。priorityとchangefreqは無視される

先に結論を書きます。XMLサイトマップの3つの任意タグのうち、AI検索時代に手を入れる価値があるのはlastmodだけです。

• lastmod（最終更新日時）：GoogleもBingも利用すると公式に明言しています。特にBingは「AI検索では鮮度シグナルが検索結果とAI生成回答への反映速度に直接影響する」とし、lastmodを再クロールの優先度判断に使うと2025年7月の公式ブログで説明しました。
• priority（優先度）とchangefreq（更新頻度）：GoogleもBingも「無視する」と公式ドキュメントに明記しています。0.9に設定してもクロールもランキングも変わりません。
• AI専用クローラ（GPTBot、OAI-SearchBot、PerplexityBotなど）がサイトマップをどう使うかは、各社の公式ドキュメントに記載がありません。ここは「仮説と実測」の領域です。本記事の後半で、確認できる事実と確認できない部分を分けて整理します。

つまり、「priorityを調整してAIクローラを誘導する」という発想は最初から成立しません。やるべきことは、正確なlastmodを維持し、サイトマップを分割して発見性を保ち、robots.txtで場所を宣言するという地味な整備です。本記事はその実装手順と判断基準をまとめます。

定義：XMLサイトマップとAIクローラの関係

XMLサイトマップとは、サイト内のURL一覧と各ページの最終更新日時（lastmod）をクローラに伝えるファイルである。役割は「許可・拒否」ではなく「発見性」の提供であり、アクセス制御を担うrobots.txtとは機能が異なる。AI検索との関係では、(1) Google AI Overview・GeminiはGoogle検索のインデックスを参照するため、サイトマップは通常のGoogleインデックス登録を通じて間接的に効く、(2) BingはAI検索文脈でlastmodによる鮮度伝達を公式に重視している、(3) OpenAIやPerplexityの独自クローラがサイトマップを参照するかは公式に明言されておらず、サーバーログでの実測が必要、と整理できる。

この定義がそのまま本記事の構成です。順に見ていきます。

各タグは実際どう扱われているか：一次情報の整理

まず、推測を排除して各社が公式に書いていることだけを表にします。

補足すると、sitemaps.orgのプロトコル定義では、priority（デフォルト0.5）もchangefreqも元々「ヒント」であり命令ではありません。そのヒントすら現在の主要検索エンジンは使っていない、というのが2026年時点の公式見解です。

lastmodで最も多い失敗：サイトマップ生成日時を入れてしまう

Bingが名指しで注意しているのがこれです。WordPressのプラグインやサイトジェネレータの設定によっては、サイトマップを再生成した日時が全URLのlastmodに入ってしまうことがあります。全ページのlastmodが毎日同じ日時で更新されるサイトマップは、Googleの言う「一貫して検証可能なほど正確」の条件を満たしません。ページ本文を照合すれば更新されていないことが分かるため、lastmodというシグナル自体が信用されなくなります。

lastmodに入れてよいのは、そのページの主要コンテンツが実際に変わった日時だけです。形式はISO 8601（例：2026-07-28T17:20:00+09:00）で、日付だけでなく時刻まで入れることをBingは推奨しています。なお「更新した事実」をlastmodに反映する以上、何をもって更新とするかの編集運用が前提になります。この運用設計はAI検索を意識したコンテンツ更新の考え方で扱っています。

AIクローラはサイトマップを読むのか：確認できる事実と仮説

ここが本記事の核心で、かつ最も誤情報が流通している部分です。主要なAIクローラについて、公式ドキュメントで確認できることを整理します。

この表から言えることは3つです。

第一に、Google・Bing経由のAI検索には、サイトマップは確実に「効く経路」があるということです。Google AI OverviewやGeminiのグラウンディング（検索結果に基づく回答生成）はGoogle検索のインデックスを参照します。Google-Extendedというrobots.txtトークンがありますが、これは独立したクローラではなく、既存のGoogleクローラが収集したコンテンツをGeminiの学習等に使うかを制御するスイッチにすぎません。つまりAI Overviewに載るための入口は通常のGoogleインデックス登録であり、サイトマップはそこに普通に効きます。Bingも同様で、Copilot等のAI回答への反映を含めてサイトマップとIndexNowの併用を公式に推奨しています。

第二に、OpenAI・Perplexityの独自クローラがsitemap.xmlを取得・解釈するかは、公式には確認できないということです。両社のクローラドキュメントはrobots.txtの扱いには言及していますが、サイトマップには触れていません。「GPTBotはlastmodを見て優先クロールする」といった記述を見かけたら、それは一次情報のない推測だと判断してください。当メディアとしても、この点は仮説として扱います。

第三に、確認する手段は自サイトのサーバーログしかないということです。自社サイトのアクセスログで、各AIクローラのUser-Agentが/sitemap.xmlやサイトマップ内のURLをどの順序・頻度で取得しているかを見れば、少なくとも自サイトにおける実態は確定できます。ログの見方とクローラ別の集計手順はAIクローラのログ分析で詳しく解説しているので、本記事の整備を終えたら実測に進んでください。仮説を仮説のまま放置しないことが、この領域では一番の差になります。

robots.txt・llms.txtとの役割分担：「発見性」と「許可・拒否」を混同しない

サイトマップの相談を受けると、robots.txtと役割が混ざっているケースが目立ちます。3つのファイルの分担を明確にします。

実務での接続点は1つだけ覚えれば足ります。robots.txtにSitemap:行を書くことです。

<pre><code>Sitemap: https://example.com/sitemap.xml</code></pre>

これはsitemaps.orgプロトコルで定義された正式な記法で、User-agent行とは独立に機能し、複数行書けます。Search ConsoleやBing Webmaster Toolsに登録できるのはそれぞれの検索エンジンだけですが、robots.txtへの記載は全クローラ共通の置き場所の宣言になります。OpenAIやPerplexityのクローラがサイトマップを使うとすれば、まず参照するのはこの行だと考えるのが自然です（これも仮説ですが、コストがほぼゼロなので実施しない理由がありません）。

巨大サイトのサイトマップ分割方針

sitemaps.orgプロトコル上の上限は、1ファイルあたり50,000 URLまたは非圧縮50MBです。超える場合はサイトマップを分割し、サイトマップインデックス（これ自体も上限50,000ファイル・50MB）でまとめます。ただし実務では、上限に達していなくても分割した方がよい場面が多くあります。判断基準を表にします。

分割で注意すべきなのは、分割そのものよりlastmodの精度が落ちないことです。分割ツールを導入した結果、全サブサイトマップのlastmodが再生成日時で上書きされるようになった、という本末転倒がよく起きます。分割後は必ずサイトマップの中身を開いて、更新していないページのlastmodが動いていないかを確認してください。

また、Bingを含むMicrosoft系（Copilot含む）への反映を重視するサイトは、サイトマップに加えてIndexNow（更新URLをリアルタイム通知するプロトコル）の併用をBingが公式に推奨しています。サイトマップが「全体の台帳」、IndexNowが「更新の速報」という分担です。

実装チェックリスト

自社サイトのサイトマップがAI検索時代の要件を満たしているか、以下で点検してください。

No.11まで到達すると、「自サイトではどのAIクローラが、サイトマップ経由と思われる順序でクロールしているか」を仮説ではなく事実として語れるようになります。

よくある失敗例

失敗1：priorityの微調整に時間を使う

「重要ページはpriority 1.0、その他は0.3に設定しました」という報告をいまだに見かけますが、GoogleもBingも無視すると明言している値の調整は工数の純損失です。同じ時間をlastmodの精度確認に使ってください。

失敗2：全URLのlastmodが同じ日時

前述のとおり、サイトマップ生成のたびに全lastmodが更新される設定は、鮮度シグナルを自ら壊します。「毎日更新されているように見せた方が有利では」という発想は逆効果です。検証可能な正確さこそが利用条件だと、Googleは明記しています。

失敗3：robots.txtで拒否したクローラ向けにサイトマップを整備する

GPTBotをrobots.txtでDisallowしながら「AIに見つけてほしいのでサイトマップを強化したい」という相談があります。発見性（サイトマップ）はアクセス許可（robots.txt）の内側でしか機能しません。まずrobots.txtのAIクローラ設定で「どのAIクローラに何を許可するか」の方針を決め、その後にサイトマップで発見性を整える、という順序が正しい設計です。

失敗4：sitemap.xmlに一度も更新されないゴミURLが堆積している

パラメータ付きURL、削除済みページ、noindexページがサイトマップに残り続けているケースです。サイトマップは「インデックスしてほしいURLの台帳」であり、台帳の信頼性が下がるとlastmodの信頼性評価にも波及しかねません。定期的な棚卸しを運用に組み込んでください。

失敗5：「AIクローラはサイトマップを見る」と断定した社内資料を作る

OpenAI・Perplexityの公式ドキュメントにサイトマップの記載がない以上、断定は事実誤認です。社内説明では「Google・Bing経由のAI検索には確実に効く。独自AIクローラへの効果は自社ログで検証中」と書き分けるのが誠実で、後から実測データで上書きできる分だけ資料の寿命も長くなります。

FAQ：サイトマップとAI検索

サイトマップを整備すればAI検索に引用されやすくなりますか

保証はできません。サイトマップが担うのは発見と鮮度伝達までで、引用されるかどうかはコンテンツ側の要因が支配的です。ただし、更新したページが古い内容のままAIに参照され続ける事態を防ぐうえで、正確なlastmodは前提整備として意味があります。

AI専用のサイトマップを別に作るべきですか

現時点で不要と判断しています。AIクローラ専用のサイトマップ仕様を公式に定義しているAI検索プラットフォームは確認できていません。標準のXMLサイトマップを1系統、正確に保つ方が優先です。LLM向けにサイト概要を提示したい場合は、サイトマップの複製ではなくllms.txtという別の枠組みの話になります。

lastmodを更新すればすぐ再クロールされますか

即時性の保証はありません。Bingはlastmodを再クロールの優先度判断に使うとしていますが、実際のクロールタイミングはサイトの信頼度やクロールバジェットに依存します。更新の即時通知を重視するならIndexNowの併用が公式に案内されている手段です。

画像・動画・ニュースサイトマップはAI検索に関係ありますか

これらの拡張サイトマップのAI検索での扱いについて、公式な言及は確認できていません。通常の検索での用途（画像検索・Googleニュース等）を基準に導入判断をすればよく、AI検索のために追加する必要は現時点ではないと考えます。

まとめ：サイトマップは「誘導装置」ではなく「正確な台帳」

XMLサイトマップでAIクローラを操作することはできません。できるのは、存在するURLと本当の更新日時を、検証に耐える正確さで宣言し続けることだけです。priorityとchangefreqを捨て、lastmodの精度に投資し、robots.txtで場所を宣言し、巨大サイトは監視しやすい単位に分割する。そのうえで、独自AIクローラの挙動はログで実測して仮説を事実に変えていく。この順序が、2026年時点で一次情報に裏付けられた実務のすべてです。

自社サイトのサイトマップ・robots.txt・構造化データがAI検索に対してどこまで整備できているかを客観的に棚卸ししたい場合は、UravationのLLMO診断（AI検索対応診断）で現状把握から始められます。まずは本記事のチェックリスト11項目でセルフチェックし、ログ実測の設計など判断に迷う箇所が出てきた段階でご相談ください。