クローラーはsitemap順に見ていない。実ログ19万件で巡回の順番を解析した

結論

当サイトの運営者は、別に日本株の開示情報を扱うメディアを1つ運営しています。そちらは全ページのUser-Agentをサーバー側で記録しているので、クローラーが実際にどの順番でページを見に来ているかを生ログで確かめられます。

今回、そのサイトの31日分のログ——bot判定された190,179リクエスト・17,986パス（サイトマップ登録URLは約2,300件）——を解析しました。

結果、sitemapの並び順では見ていません。

連続する2リクエストがサイトマップ上で隣同士（インデックス+1）だった割合は、Googlebotで6.0%、GoogleOtherで3.4%、ClaudeBotで1.2%。セッション内の巡回順とサイトマップ順の順位相関（Spearman）は全botで ρ = 0.00〜+0.11、つまり無相関です。前方向に進む割合も約50%で、方向すらありません。

代わりに見えたのは、次の3層構造でした。

Figure

実ログから見えた巡回の3層

1. 1

   第1層: 入口

   セッション最初の1本。robots.txt から入るbot、sitemap.xml から入るbot、いきなり本文ページに来るbotの3種類に分かれる

2. 2

   第2層: URL種別ごとの一気読み

   銘柄ページなら銘柄ページだけを数百件連続で取る。同じ種別が次に来る確率はClaudeBotで87.4%（ランダムなら26.2%）

3. 3

   第3層: 塊の中の順番

   ここがsitemap順でも連番順でもない。過去の巡回で作った自前の待ち行列を消化しているだけで、外から見ると順不同

この構造から出てくる実務的な帰結は2つです。どちらも「サイトマップをどう書くか」ではなく、サイトの作りそのものの話になります。

1つめ。AIクローラーにとって、内部リンクは補助ではなく唯一の経路です。 ClaudeBotは31日間で2,257パスを取得していますが、ページURLが列挙されたファイルを1度も読んでいません（取得したのはサイトマップの索引だけで、子サイトマップは0回）。GPTBotも同じです。

2つめ。ディレクトリは「一気見される単位」なので、中身が揃っていないとバーストが丸ごと無駄になります。 このサイトでは、旧URL形式と死んだURLが溜まった2つのディレクトリ（/investors と /en）だけで bot全リクエストの35.8% を吸っていました。その大半はリダイレクトか404に消えています。

以下、順に実データを出します。

何をどう測ったか

Next.jsの proxy（旧middleware）で全リクエストのUser-Agentを判定し、path / bot_name / occurred_at をデータベースに記録しています。今回はそのうちブラウザ判定を除いたbotの行だけを取り出し、30分以上の間隔が空いたら別セッションとして区切って解析しました。

サイトマップ側は、実際に配信されている /sitemap.xml（sitemapindex）と、そこから参照される5本の子サイトマップを取得し、<loc> の出現順をそのままインデックス番号にしています。

なお、この判定はUser-Agentの自己申告に基づくもので、逆引きDNSでの検証はしていません。ログ全体のうちスキャナー由来と見られる怪しいパス（/.git/config、/.env など）は133件で、全体の0.07%でした。

検証1: sitemap順で見ているか → ノー

各botについて、連続する2リクエストの両方がサイトマップに載っているケースだけを取り出し、インデックス番号の差を数えました。

bot	対象ペア数	差が+1（次の行）	差が-1（前の行）	前方向に進んだ割合
GoogleOther	58,580	3.4%	6.0%	35.3%
Googlebot	1,621	6.0%	2.1%	52.0%
OAI-SearchBot	3,355	2.1%	2.3%	49.4%
AhrefsBot	1,369	1.5%	0.9%	54.2%
MJ12bot	1,258	1.7%	2.7%	38.1%
PerplexityBot	922	0.9%	1.0%	49.9%
ClaudeBot	243	1.2%	0.8%	46.1%

サイトマップに2,255件のURLがあるので、完全にランダムなら「差が+1」は0.04%です。数%は出ていますが、順番に読んでいるなら数十%になるはずの値です。前方向の割合が軒並み50%前後という点も、方向を持って読み進めていないことを示します。

さらにセッション単位で、巡回順とサイトマップ順の順位相関を取りました。子サイトマップ内で20件以上を取ったセッションだけを対象にした中央値です。

Figure

巡回順とsitemap順の順位相関（Spearman ρ）

meta-externalagent

+0.11

24セッション

GoogleOther

+0.1

247セッション

OAI-SearchBot

+0.08

56セッション

ClaudeBot

+0.07

5セッション

Googlebot

0

25セッション

MJ12bot

0

36セッション

PerplexityBot

-0.05

17セッション

サイトマップの並び順を変えるという施策には、少なくともこのログの範囲では意味がありません。「重要なページを上に置く」といった話を見かけたら、効果検証の対象から外して構わないと考えています。

検証2: どこから入ってくるか → botごとに全く違う

セッションの先頭1本が何だったかを数えると、botの性格がはっきり分かれました。

bot	セッション数	robots.txtから始まる	sitemap.xmlから始まる
MJ12bot	119	100.0%	0.0%
ClaudeBot	95	73.7%	17.9%
Googlebot	308	56.2%	2.9%
SemrushBot	168	47.6%	0.0%
AhrefsBot	186	18.8%	57.0%
GPTBot	38	0.0%	81.6%
GoogleOther	230	0.0%	0.0%
ChatGPT-User	389	0.0%	0.5%
Amazonbot	90	0.0%	0.0%

GPTBotはrobots.txtを31日間で1度も取っていませんが、8割のセッションを /sitemap.xml から始めています。robots.txtを長期キャッシュしていると考えるのが自然です。

対照的に、ChatGPT-User（ユーザーがChatGPTで質問したときに走る取得）は389セッション中387回、いきなり本文ページ（トップページ含む）に来ています。入口の概念がなく、必要な1ページだけを取りに来る挙動です。GoogleOtherとAmazonbotも同じくrobots.txt・sitemapを一切踏みません。

Googlebotは逆で、自分のリクエストの15.4%（10,942件中1,687件）がrobots.txtでした。SemrushBotも11.6%。robots.txtの応答速度が巡回全体の速度に効くタイプのbotが実在するということです。

検証3: 塊の中は何順か → 自前のキュー順

ClaudeBotの最長セッションが分かりやすい例でした。

+     0.0s  /robots.txt
+     1.7s  /sitemap.xml
+   842.2s  /stocks/3950     ← 14分の沈黙のあと
+   842.2s  /stocks/8136
+   845.5s  /stocks/3733
+   845.5s  /stocks/6902
+   847.0s  /stocks/4641
   （以下 /stocks/ が735件連続）

その1時間前のセッションは /investors/ を627件連続、別の日は英語版記事を219件連続。1セッション＝1つのURL種別という切り方をしています。同じ種別が次に来る確率は87.4%で、ランダムに並べ替えた場合の26.2%を大きく上回ります。

そして塊の中の順番は、銘柄コード順でもサイトマップ順でもありません。決定的だったのは次の2点です。

Figure

「その場でリンクを辿っている」説の否定

セッション間でURLの重複ゼロ

49件・141件・735件の3セッション

• 3つのセッションで取った銘柄ページに1件も重なりがない
• リクエスト数÷ユニークURL数は1.1倍（ほぼ重複取得なし）
• ＝どこまで取ったかを覚えている待ち行列がある

ハブページを直前に踏んでいない

詳細ページの塊が始まる直前

• ClaudeBot 0/18セッション
• Googlebot 4/364セッション
• ＝一覧ページを開いてリンクを辿っているのではない

つまり、クローラーはセッションのたびにサイトを「読んで」いるのではなく、過去の巡回で作ったURLの待ち行列を、種別ごとに区切って消化しているだけです。その行列の並び順はクローラー側の内部事情で決まっているので、サイト側から並べ替えることはできません。

サイト側が影響できるのは「行列に何を入れるか」だけ、というのがこの解析の実務的な結論です。

副産物1: ClaudeBotとGPTBotは子サイトマップに降りていない

URLが多いサイトでは、sitemapindexから子サイトマップを参照する分割方式を使います（sitemaps.orgのプロトコルで規定され、Googleも5万URL/50MBを超える場合の方法として案内しています）。このサイトも /sitemap.xml から /sitemap/pages.xml など5本を参照しています。

31日間の /sitemap* 取得を全部数えました。

bot	/sitemap.xml（インデックス）	/sitemap/*.xml（子）
Googlebot	30	101
Bingbot	27	90
AhrefsBot	131	18
SemrushBot	2	7
ClaudeBot	80	0
GPTBot	31	0
PerplexityBot	1	0

ClaudeBotは80回、GPTBotは31回もインデックスを取りに来ておきながら、子サイトマップを1本も取っていません。 GooglebotとBingbotは正しく降りています。

ClaudeBotが2,259パス、GPTBotが1,380パスを取れているので、リンク経由では発見できています。ただ「サイトマップを置いたからAIクローラーに全URLを伝えられている」という前提は、少なくともこの2つのbotについては成り立ちません。

Figure

分割サイトマップを使っているサイトの対応

やること

• ✓子サイトマップ /sitemap/*.xml のヒットをbot別に数える（0のbotがいるか確認する）
• ✓URL数が5万件を大きく下回るなら、分割せず1本にまとめられないか検討する
• ✓サイトマップに頼らず、一覧ページからの内部リンクでも全URLに到達できる状態を保つ

やらなくていいこと

• ✕サイトマップ内のURLの並び順を調整する
• ✕priority や changefreq の値を調整する（そもそも今回のログでは巡回順と無関係）
• ✕llms.txt に時間をかける（このログでは31日間で全bot合計0ヒット）

/llms.txt は同じ期間、全bot合計で0ヒットでした。ブラウザからのアクセスはありましたが、クローラーは1度も取りに来ていません。

副産物2: 新しいURLに最初に来るのはGoogleOther

ログ開始から10日以降に初めて現れた記事URL1,042件について、どのbotが最初に取りに来たか、最初のbotから何時間遅れたかを集計しました。

Figure

新規URLの発見速度

640件

GoogleOtherが一番乗り

1,042件中61.4%

8.0時間

Googlebotの遅れ（中央値）

カバー率81.8%

27.1時間

OAI-SearchBotの遅れ

カバー率41.7%

153時間

PerplexityBotの遅れ

カバー率39.1%

GoogleOtherはGoogleが検索以外の用途（AI関連のプロダクトを含む）で使うフェッチャーで、Googleのクローラー一覧に記載があります。このサイトではbot全リクエストの57.6%（1日あたり約3,534件）がGoogleOtherで、同じURLを平均16.4回取り直しています。Googlebotの1.9回とは桁が違います。

AIクローラー全体（GoogleOther・GPTBot・OAI-SearchBot・ChatGPT-User・ClaudeBot・PerplexityBot・meta-externalagent・Amazonbot・Applebot等）で、bot全リクエストの68.3%を占めていました。

では何が効くのか: リンク構造とディレクトリ

並び順が効かないなら、サイト側に打つ手はないのか。ログを見る限り、効くのは**「待ち行列に何が入るか」と「URLがどう束ねられるか」**の2つです。

1. AIクローラーのURLは、ほぼリンク経由でしか入っていない

ClaudeBotが31日間で取得したパスは2,257件（robots.txtとサイトマップを除く）。一方でClaudeBotが取得したサイトマップは /sitemap.xml（インデックス）だけで、そこに書かれているのは子サイトマップ5本のURLだけです。ページのURLは1件も載っていません。子サイトマップは0回。

つまりClaudeBotは、ページURLが列挙されたファイルを1度も読んでいないのに、2,257パスを知っていることになります。発見経路はリンク（内部リンクか、外部からの参照）以外にありません。GPTBotも同じ構図で、1,379パスを取得しながら子サイトマップは0回です。

Figure

ページURLの一覧を読まずに取得したパス数

2,257

ClaudeBotが取得したパス

sitemap.xml（索引）を80回取得

1,379

GPTBotが取得したパス

sitemap.xml（索引）を31回取得

0

両botの子サイトマップ取得

Googlebotは101回、Bingbotは90回

サイトマップが届いていないbotにとって、内部リンクは補助ではなく唯一の経路です。「サイトマップに載せたから大丈夫」は、AIクローラーに対しては成り立ちません。

2. 巡回はディレクトリ単位で束ねられている

第2層で見た「URL種別ごとの一気読み」は、URLの第1階層（ディレクトリ）で切ると、より鮮明になります。

bot	次のリクエストが同じディレクトリ	ログをランダムに並べ替えた場合
MJ12bot	95.3%	38.1%
ClaudeBot	87.5%	26.1%
AhrefsBot	71.2%	40.6%
GPTBot	68.2%	27.1%
PerplexityBot	67.1%	27.6%
Googlebot	51.0%	15.7%
GoogleOther	40.5%	9.8%

これはGoogleの公式ドキュメントの記述とも一致します。SEOスターターガイドは、似た話題のページをディレクトリにまとめると、Googleがディレクトリ単位で更新頻度を学習し、ディレクトリごとに異なる頻度でクロールできるようになると書いています（数千URLを超えるサイト向けの記述）。

ログで見えたのは、その挙動がGooglebotだけでなく、ClaudeBot・GPTBot・PerplexityBotでも同じように出ているということです。

裏を返すと、更新頻度の違うページを同じディレクトリに混ぜると損をします。毎日更新のページと1年変わらないページが同居していると、ディレクトリ単位の頻度学習が効かなくなるからです。

第1階層を増やすべきか、束ねて第2階層を厚くすべきか

ここで実務的に迷うのが、ディレクトリを第1階層に横並びで増やすか、束ねて第2階層を厚くするか、です。

結論から言うと、束ねる側のデメリットは観測できませんでした。botが束ねている単位は「第1階層」ではなく、実際に同種のページをまとめている階層だったからです。

このサイトには /en/articles/<id>・/en/category/<name> のように、第1階層1つの下に第2階層が並ぶ構造があります（31日間で21,803リクエスト）。ここでbotが第2階層ごとに束ねているかを測りました。

bot	/en/ 内で同じ第2階層が次に来る	ログをランダムに並べ替えた場合
MJ12bot	95.3%	49.4%
AhrefsBot	76.4%	51.7%
Googlebot	75.6%	45.6%
GPTBot	69.6%	32.4%
GoogleOther	58.5%	32.2%
OAI-SearchBot	45.2%	31.5%

第1階層が1つに束ねられていても、botは第2階層で束ねて読んでいます。 「まとめると一気見の単位が壊れる」という心配は要りません。

逆に、第1階層を増やすことの利得を示す数字は出ませんでした。Googleがディレクトリを推す理由は更新頻度の学習なので、更新頻度が同じものを第1階層で割っても、学習される情報は増えません。

Figure

ディレクトリを分ける／分けないの判断

分ける

• ✓更新頻度が明確に違う（毎日更新のものと、年単位で変わらないもの）
• ✓コンテンツの種類が違い、片方だけが大量に増えていく
• ✓片方だけをrobots.txtやnoindexで別扱いしたい

分けない

• ✕意味は違うが、更新頻度は同じ
• ✕単に整理したいだけ
• ✕URLが見た目としてきれいになるから

ひとつだけ、深さの代償を示唆する数字があります。同じ記事IDが /articles/<id>（2階層）と /en/articles/<id>（3階層）の両方で叩かれているケースが1,241件あり、取得回数は2階層側が合計15,381回、3階層側が7,353回。比の中央値は0.47で、深い方が半分以下でした。

ただしこれは深さだけの効果とは言い切れません。/en は英語版で、現在はトップへ308リダイレクトされる非推奨セクションです。言語と優先度の差が混ざっているため、参考値として扱ってください。

なお、このサイトは第3階層が /en 配下にしか存在せず、4階層以上のデータがありません。深い入れ子が不利かどうかは、今回のログでは検証できていません。

3. 一気見されるからこそ、ディレクトリの中身がそのまま結果になる

ディレクトリ単位でまとめて読まれるということは、そのディレクトリに何が入っているかが、そのままクロールの成果になるということです。良いものが入っていれば全部拾われ、ゴミが入っていればゴミを拾って帰ります。

同じサイトのディレクトリ別に、サイトマップ掲載URL数と、実際にbotが叩いたユニークURL数を並べました。

ディレクトリ	sitemap掲載	実際に叩かれたURL	うちsitemap外	リクエスト中のsitemap外率
/investors	538	10,036	9,501	72%
/en	0	2,034	2,034	100%
/stocks	667	4,082	3,415	53%
/articles	917	1,401	508	34%
/date	81	232	152	31%
/faq	10	10	0	0%
/category	14	26	12	0.3%

/category のsitemap外12URLは、31日間で合計13リクエストしか受けていません。

/investors は、サイトマップに載せているのが538件なのに、実際には10,036件のユニークURLが叩かれています。中身を見ると内訳はこうでした。

• 7,115件 が旧URL形式（/investors/加藤産業株式会社）。現在は /investors/2925 へ308リダイレクトされる
• 2,386件 がサイトマップに無い数字ID（/investors/9999 など）。404が返る

このディレクトリへのリクエストは31日間で35,528件、bot全リクエストの18.7%。そのうち72%が、リダイレクトか404に消えています。

/en はさらに極端で、32,608リクエスト（bot全体の17.1%）が、サイトマップに1件も載っていないディレクトリに入っています。現在このパスはトップページへ308リダイレクトされます。過去に存在した英語版の残骸を、botが待ち行列に持ち続けているということです。

対して /faq（10件）と /category（14件）は、サイトマップと実URLがほぼ一致しています。カバー率もGooglebot・GoogleOtherともに100%です。

Figure

ディレクトリの整い方とクロールの成果

整っているディレクトリ

/faq・/category・/date

• URL形式が1つだけ
• sitemapと実URLがほぼ一致
• カバー率 94〜100%
• リクエストがほぼ全部200に着地する

散らかったディレクトリ

/investors・/en

• 旧URL形式と現URL形式が同居
• 存在しないIDが2,386件叩かれている
• /investors のカバー率は50〜51%止まり
• bot全リクエストの35.8%がこの2つに吸われている

つまり「ディレクトリにまとめる」は、URLを詰め込むことではなく、1ディレクトリを1つのURL形式・1つの更新頻度に揃えることです。一気見される単位が揃っていないと、バーストが丸ごと無駄になります。この2ディレクトリを整理するだけで、このサイトのクロールの3分の1が別の用途に回る計算になります。

Figure

巡回の「入口」ではなく「経路」を整える

やること

• ✓一覧ページ・カテゴリページから全詳細ページに到達できる状態を保つ（サイトマップが届かないbotがいる）
• ✓同じ種類・同じ更新頻度のページを同じディレクトリにまとめる
• ✓更新頻度の高いディレクトリと低いディレクトリを分ける

やらなくていいこと

• ✕「重要ページをサイトマップの先頭に置く」（並び順は巡回順と無相関）
• ✕1回の巡回でリンクを辿らせる前提の設計（botは前回までに作った待ち行列を消化している）
• ✕更新頻度がバラバラのページを1つのディレクトリに同居させる

なお、俗に言う「ハブ&スポーク」という言葉自体はGoogleの公式ドキュメントには出てきません。公式に書かれているのは「サイトを論理的に整理する」「似た話題をディレクトリにまとめる」「リンクをクロール可能にする」の3つです。今回のログは、そのうち後ろ2つが実際にクローラーの挙動として観測できる、という話になります。

自分のサイトで同じことを確かめる手順

サーバーログかCDNのログがあれば同じ検証ができます。特別なツールは要りません。

Figure

ログから巡回順を検証する手順

1. 1

   botの行だけ取り出す

   User-Agentからbot名を判定し、ブラウザの行を除く。この判定は自己申告ベースなので、逆引きDNSで検証するとより厳密になる

2. 2

   30分の空白でセッションに区切る

   1本のセッション＝1回の巡回。先頭1本が robots.txt か sitemap.xml か本文かを数えると、botの性格が出る

3. 3

   URL種別ごとの連続を見る

   次のリクエストが同じ種別である確率を、ログをランダムに並べ替えた場合と比べる。大きく上回れば「種別ごとの一気読み」をしている

4. 4

   サイトマップの並び順と突き合わせる

   <loc>の出現順を番号に振り、連続する2リクエストの番号差を数える。+1が数十%出なければsitemap順ではない

5. 5

   子サイトマップのヒットをbot別に数える

   分割している場合、インデックスだけ取って降りていないbotがいないか確認する

この解析の限界

標本は1サイト・31日分です。サイトの規模（約2,300URL）、更新頻度（ほぼ毎日）、ジャンル（日本株の開示情報）に依存する結果が混じっている可能性があります。

とくに次の3点は、他サイトで同じになるとは限りません。

• GoogleOtherの比率の高さ。57.6%は明らかに偏っており、このサイト固有の事情がある可能性があります
• ClaudeBotの最終アクセスが2026-08-21で止まっていること。以降の12日間、1件も来ていません
• 子サイトマップの未取得。分割の仕方（5本／最大916URL）やインデックスの記述による可能性を排除できていません

また、突き合わせに使ったサイトマップは期間の最終日に取得したスナップショットです。期間中に並び順が変わっていた可能性は排除できません。ただし、相関がゼロという結果はbot・セッション・期間を通じて一貫しており、並び順の変化だけでは説明しきれません。

User-Agentの逆引きDNS検証もしていないため、botを詐称したアクセスが混じっている可能性も残ります。怪しいパスへのアクセスは全体の0.07%でした。

一方で「サイトマップの並び順と巡回順が無相関」という点は、bot・セッション・期間を問わず一貫して出ました。ここは他サイトでも再現しやすいと考えています。

よくある質問

サイトマップの先頭に重要なURLを置く意味はありますか

今回の31日分のログでは、サイトマップの掲載順と実際の巡回順に相関はありませんでした。重要なURLは順番で示すのではなく、一覧・カテゴリページからクロール可能なリンクで到達できる状態にしてください。

AIクローラーはサイトマップを読まないのですか

クローラーによって異なります。今回のサイトではClaudeBotとGPTBotがサイトマップインデックスを取得した一方、参照先の子サイトマップは取得していませんでした。GooglebotとBingbotは子サイトマップまで取得しています。

ディレクトリを浅くすれば巡回が増えますか

今回のデータだけでは断定できません。2階層と3階層の差には、言語やページの優先度も混ざっています。階層の深さより先に、同じ種類・更新頻度のページをまとめ、旧URLや404を減らしてください。