AIクローラーに送信窓口はない——sitemap.xmlとRSS、llms.txtは優先しない

NO CONSOLE｜送る場所がない

Search Engine Journal（Matt G. Southern氏）は、2026年10月1日の Search Off the Record「Do sitemaps still matter?」を記事にしています。話し手はJohn Mueller氏とMartin Splitt氏です。本稿は音声を独自に書き起こしていません。以下は、同記事が伝えた発言です。Search Engine Journal 回そのものは YouTube にあります。

Mueller氏は、サイトマップを非公開にしたいなら、珍しいファイル名にし、robots.txtには書かず、Googleへ直接送れる、と話した、と同記事は書いています。欠点は、他の仕組みが見つけられないことです。Bingには、たぶん独自の送信が要る、ともあります。AIの学習クローラーは違う、と続きます。サイトマップを送るコンソールや仕組みが、通常はない、からです。コンテンツをAIの仕組みに入れたいサイトへの提案は、標準の名前、つまり sitemap.xml と呼ぶか、RSSに寄せるか、です。

LOGS｜自分のログで両方を見た。名前は出ていない

サイトマップのプロトコルでは、robots.txtの Sitemap 行は user-agent の行とは独立で、一つのクローラーの規則には結び付かない、と同記事は書いています。フィードは、ページのHTMLの head からリンクされることが多く、見つけやすい、ともMueller氏は述べた、とあります。自分のサーバーログで、あるAIクローラーがサイトマップを取りに来たのを見た。RSSでも同じだ、と話した、と同記事は続けます。クローラーの名前は出していません。AI企業がこれを文書化しているか、ファイルをどう使うかは、自分には分からない、とも言った、とあります。

当サイトの「robots.txt・sitemap.xml・llms.txtの違い」は、三つのファイルの役割を分けています。本稿が足すのは、送る窓口がないクローラーには、標準の名前とRSSが入口になる、というこの発言です。llms.txtを置いただけで見つけてもらえる、にはしません。

LLMS.TXT｜希望は、現実より大きい

llms.txtがXMLサイトマップの代わりになるか、と問われて、Mueller氏はMarkdownのファイルをHTMLのサイトマップになぞらえた、と同記事は書いています。厳密な形式がないので、Googleの仕組みはサイトマップとしては使えない、と。希望は現実より大きい、いまは何も起きていない、試すのは構わないが頼らない、とも言った、とあります。8月には、自分のテストサイトでMarkdownを受け取ると称したクローラーはSEOのツールだけだった、という過去の発言も、同記事は参照しています。5月の案内が、生成AI機能のためにサイトがllms.txtを要しない施策の一つに挙げていた、とも書いています。

COULDN'T FETCH｜取得できない、はファイルの外にもある

Splitt氏は、正しくて公開され、robots.txtからリンクされたサイトマップが、Search Consoleで Couldn't fetch になる理由を尋ねた、と同記事は書いています。Mueller氏が挙げた一つは、ホストの負荷です。Googleの仕組みが忙しくて取れず、それも Couldn't fetch と出る、と。もう一つは、クロールの需要です。これ以上クロールする必要がないと見ると、サイトマップを飛ばすことがある、と。需要は、サイトの品質の見立てに基づくことが多い、純粋に技術の話ではない、とも言った、とあります。2月には、新しく重要なコンテンツがあると納得できなければサイトマップを使わない、とRedditで述べた、とも同記事は書いています。Search Consoleのヘルプは、需要の低さを、取得できない理由の一つに挙げ、他に robots.txt のブロック、未解決の手動対策、誤ったURLがある、とも書いています。

WEB SEARCH｜エージェントの検索は、Googleだけではない

Cloudflareの変更履歴は2026年10月2日、Web Search APIがベータで使える、と書いています。起動時の提供者は Ceramic.ai、Exa、Linkup の三社です。三社とも、Cloudflare経由のリクエストで Zero Data Retention に対応し、Cloudflareの verified bot のクロール基準に従う、と変更履歴は書いています。検索は AI Gateway を通り、各社の定価で、上乗せはない、ともあります。既存の鍵を持ち込める、とも書いています。Cloudflare Changelog

同じ日のブログは、提供者のクローラーは、開発者向け文書が公開している Verified bots の要件に合う必要がある、と書いています。検索の応答は、クロールした中身の場所へのリンクを含む、ともあります。クローラーを識別し、robots.txtを尊重し、結果の出所を示す、という書き方です。エージェントがURLを推測して取りに行く代わりに、検索から入る、というのがブログの入口です。Cloudflare Blog

これは、Googleへ送るサイトマップとは別の入口です。規則に従う、という約束が、自社のページがその索引に入ることを保証する、とはどちらにも書いてありません。ブロックすればすべてのエージェントから消える、とも書いてありません。残すなら、標準名の sitemap.xml、RSS、robots.txt、そして自社のログで、どのボットがファイルを取りに来たか、です。

META｜「train」の一文は、米国英語版から消えた

The Vergeは2026年10月17日、批判のあと、Metaの商用規約の米国英語版から、ドメインの内容を train に使ってよい、という一文が消えた、と報じています。広報のDaniel Roberts氏は同誌への続報で、まとめたクロールの条項は広告とビジネス製品にだけ適用される、と述べています。クロールの許可は残ります。ウェブクローラーの使い方は変わらない、とも述べています。コンテンツの所有者は、これまでどおり robots.txt で意向を示せる、と述べています。今回の更新は、その意向に優先する新しい権利を与えない、とも述べています。ニュースサイトをスクレイピングする話ではない、とも述べています。The Verge

elsopのAlex Savich氏は同じ日、発効を2026年10月30日と書いています。同氏が同時刻に開いた英国英語版のプレビューには、train を含む旧い一文が残っていました。残った米国英語版の目的句は、広告とビジネス製品を provide、develop、improve、research、maintain することと、製品の integrity と security を維持することです。train の語はありません。elsopは、残った文が学習を除外するとは書いていない、と注記し、法的な結論は出していません。同記事が引くクローラー案内では、Meta-ExternalAds は広告などビジネス向けの製品、Meta-ExternalAgent は基盤モデルの学習や、内容を索引して製品を改善する用途です。robots.txt の指定は、トークンごとに分かれます。規約の本文は、クローラーの名前も robots.txt も挙げていない、とelsopは書いています。robots.txt が引き続き有効だ、という説明は、The Vergeが伝えたRoberts氏の発言です。Metaの規約ページは、本稿では開いていません。elsop

WHAT TO LOG｜名前と、ログと、規則を分けて残す

確認する列は四つです。サイトマップのファイル名が sitemap.xml か、それとも送らないと見つからない名前か。RSSがHTMLから辿れるか。llms.txtを、サイトマップの代わりとして数えていないか。サーバーログに、名前の付いていないAIクローラーがサイトマップかRSSを取りに来たか。Web Search APIの三社は、verified bot の基準に従う、とCloudflareが書いた提携先です。自社の計測で、見つけられた割合は出していません。

出典： Search Engine Journal（2026-10-01の回。音声は未書き起こし。クローラー名はなし）／Cloudflare Changelog 2026-10-02／Cloudflare Blog／The Verge 2026-10-17（米国英語版から train の一文。クロール許可は残る。robots.txt はDaniel Roberts氏の発言。Metaの規約ページは未参照）／elsop 2026-10-17（発効は10月30日。英国英語版には同日時点で旧文。Meta-ExternalAds と Meta-ExternalAgent は別トークン。法的な結論は出していない）

次のリソース

Research Hubの知見を、自社の理解・比較・推薦・行動準備へつなげます。