Glovrex
Englishお問い合わせ

ジャーナル

llms.txtに200を返す246サイト、本物は114件

Trancoの上位1,000ドメインを2026-10-06に調べると、到達できた742件のうち本物のllms.txtを返したのは114件で、122件は200でHTMLページを返していました。ファイルのよくある誤り、HEADがリンク切れを多く数える理由、確認用スクリプト。

Arne Rei5 分

llms.txtの普及を「/llms.txtに200を返すサイトの数」で数えると、本当の数の2倍以上になります。2026-10-06に上位1,000ドメインを調べました。200を返したのは246件。そのうち本当にllms.txtのファイルを返したのは114件でした。残りの132件が返したのは、ログイン画面、ステータス200の「見つかりません」ページ、トップページ、シングルページアプリの外枠です。

この記事は、その測定と、素朴なチェックが間違える3つのパターンと、間違えない20行ほどのスクリプトです。

測ったものと、先に限界

  • リスト: Trancoのリスト56WKN、2026-10-05生成、上位1,000件。Trancoは登録可能ドメインを複数の通信量の指標を組み合わせて順位付けしているので、Webサイトをまったく持たないインフラ用のドメイン(CDNのホスト名、APIのドメイン、広告サーバー)も入っています。
  • いつ、どこから: 2026-10-06の06:30〜06:37 UTCにファイルを取得し、リンク切れの再確認はその後の1時間に行いました。日本の普通の回線1本からです。国によって応答を変えるサイトもあり(いくつかは/jp/や/ja-jp/のページにリダイレクトされました)、別の場所から実行すると端のほうの数字は変わります。
  • リクエスト: https://<domain>/、/llms.txt、/llms-full.txtに1回ずつGET。User-AgentはデスクトップのChromeで、Accept: text/plain,text/markdown,*/*を付けました。https://<domain>が応答しなければhttps://www.<domain>を試し、リダイレクトは追いました。
  • 「ファイルなし」に数えていないもの: 70ドメインは/llms.txtに401か403を返しました。ボット対策の層に阻まれただけで、実はファイルがあるサイトもあるかもしれません。不明として数え、なしとはしていません。

これは1回のスナップショットで、有無の確認に2回目はありません。静的ファイルのステータスコードはトップページよりずっと安定していますが、1回は1回です。

1,000ドメインのうち、HTTPSに応答したのは742件でした。特に断りがない限り、以下の分母はこの742件です。

主な数字

/llms.txtが返したもの ドメイン数
llms.txtの形をしたテキストファイル 114
200だが、HTMLページ 122
200だが、別のページへのリダイレクトがテキストで返ってきた(私のAcceptヘッダーがテキストを求めたため、ページをmarkdownに変換して返すサーバーがいくつかあった) 8
200だが、そもそもファイルではない(IPを返すだけのサービス、JSONのエラー) 2
404または410 388
401または403(不明) 70
それ以外(400、5xx、202、タイムアウト) 38

つまり、**到達できた742件のうちllms.txtを返したのは114件(15%)**です。上位100では、応答した75件のうち8件でした。cloudflare.com、github.com、fastly.net、wordpress.org、digicert.com、adobe.com、opera.com、sentry.ioです。114件のうち16件は、兄弟ドメインのファイルへリダイレクトして条件を満たしています。たとえばunity3d.comからunity.com、macromedia.comからadobe.comです。

llms-full.txtを返すドメインは17件あり、どれもllms.txtも持っていました。ちなみにllms-full.txtはllms.txtの提案にはまったく出てきません。ドキュメント系のプラットフォームが広めた慣習です。

素朴なチェックが間違える3つのパターン

1. HTMLページの200

122ドメインは、ステータス200でHTMLページを返しました。そのうち37件は/llms.txtそのものでHTMLを返しています。未知のパスを全部同じ外枠に流す、シングルページアプリの典型的な動きです。instagram.com、linkedin.com、pinterest.com、chatgpt.comがこのグループです。残る85件は先にリダイレクトしていました。38件はトップページへ、それ以外はログイン画面か、200を返す「見つかりません」ページへ。netflix.comは/NotFoundに、tiktok.comは/404に着地します。

ステータスだけで「llms.txtあり」と報告するツールは、この122件を全部数えます。Content-Typeを見て、空白以外の最初のバイトが<でないことを確かめ、リダイレクトの後にどこへ着いたかを確かめてください。

2. llms.txtではないテキストファイル

提案が必須にしているのは1つだけです。ファイルがH1、つまりサイトやプロジェクトの名前で始まること。それ以外(引用ブロックの概要、[name](url)形式のリンクの箇条書きを持つH2のセクション)は推奨の形です。

  • 114件のうち108件はH1で始まっています。
  • 97件は完全な形でした。最初にH1、H2のセクションが1つ以上、リンクになった箇条書きが1つ以上。
  • H1で始まらない6件は、「Generated by …」の行(playstation.com、moloco.com)、URLだけの行(cisco.com)、H2(agora.io、trendyol.com)、いきなりリンクの一覧(salesforce.com)で始まっています。最初の2件は生成ツールが書いたもので、その後に誰も1行目を読んでいません。
  • 11件はH1はあるものの、リンクの一覧を持つセクションがありません。porkbun.comはH2のセクションが14個あってリンクが1つもなく、サイトを文章で要約したものになっています。提案の文面上は許されますが、読んだエージェントには次に進む先がありません。

H1が2つ以上あるファイルも9件ありました。

サイズにも驚きました。中央値は11,378バイトで、これは問題ありません。ただ100 KBを超えるものが12件あり、最大のsalesforce.comのものは1,021,703バイトです。1トークンおよそ4バイトという大ざっぱな換算で、約25万トークンになります。2026年8月に公開された提案の第2版は、このファイルが"stays small enough to fit in context"(コンテキストに収まる小ささを保つ)ものだとし、詳細はリンクの先に置くべきだとしています。1 MBの索引は、手間が増えただけのサイトマップです。

同じ版は、リンク先をLLM向けのコンテンツにするよう求めています。たとえば各ページのmarkdown版をpage.mdやpage.html.mdに置く形です。リンクを含む107ファイルのうち、74件は.mdや.txtのURLに1つもリンクしておらず、リンクの大半がそれらだったのは8件でした。見たのは拡張子だけなので、普通のURLでコンテンツネゴシエーションによってmarkdownを返すサイトは、ここでは少なめに数えられています。それでも、今のファイルの大半は普通のHTMLページの一覧です。

3. リンク切れと、それについて嘘をつくHEADリクエスト

リンクを持つファイルごとに、ファイル全体から均等に最大20本を取り出しました。107ファイルで合計2,043本です。まずHEADを送り、エラーのときだけGETに切り替えました。

HEADでは81本が404か410でした。その81本をGETで取り直すと、本当に消えていたのは42本だけです。dynatrace.comは、GETなら200を返すページにHEADで404を返していて、39件の誤報のうち15件はこのサイトだけで説明がつきます。帯域を節約するためにHEADを使うリンクチェッカーは、存在しないリンク切れを報告します。

確認できた42本のリンク切れ(サンプルの2.1%)は13ファイルにあり、偏っています。moloco.comは抽出した20本のうち10本、weather.comは20本のうち9本が消えていました。42本のうち40本は、そのサイト自身のホストを指しています。ファイルは一度書かれたきりで、その下でサイトのほうが動いたのです。

Last-Modifiedから古さの指標も出したかったのですが、これは使えませんでした。114ファイルのうち74件がこのヘッダーを送っていて、そのうち24件は取得したその日の日付でした。リクエストのたびにファイルを生成しているからです。1件は1980年2月1日でした。サーバーが返すどの日付よりも、内部リンクの切れのほうが古さの指標として当てになります。

自分のサイトを確かめる

ホストごとに判定を1つ出します。bashとcurlが必要です。

check_llms() {
  local host=$1 tmp
  tmp=$(mktemp)
  IFS=$'\t' read -r code ctype final < <(curl -s -L -o "$tmp" -A 'Mozilla/5.0' \
    -w '%{http_code}\t%{content_type}\t%{url_effective}\n' "https://$host/llms.txt")
  final=${final%$'\r'}
  local first
  first=$(sed -e '1s/^\xEF\xBB\xBF//' "$tmp" | grep -m1 -v '^[[:space:]]*$')
  printf '%-22s %s %-28s %s\n' "$host" "$code" "${ctype%%;*}" "$final"
  if [ "$code" != 200 ]; then echo "  -> no file ($code)"
  elif [[ "$ctype" == *html* || "$first" == \<* ]]; then echo "  -> HTML page answering 200, not an llms.txt"
  elif [[ "${final%%\?*}" != */llms.txt ]]; then echo "  -> redirected to $final, not an llms.txt"
  elif [[ "$first" != "# "* ]]; then echo "  -> text, but the first line is not an H1: ${first:0:60}"
  else echo "  -> llms.txt, $(wc -c < "$tmp") bytes, $(grep -c '^## ' "$tmp") H2 sections, $(grep -cE '^\s*[-*] \[' "$tmp") list links"
  fi
  rm -f "$tmp"
}
check_llms vercel.com; check_llms netflix.com; check_llms moloco.com; check_llms pages.dev

2026-10-06に私の環境で出た結果です。

vercel.com             200 text/plain                   https://vercel.com/llms.txt
  -> llms.txt, 4868 bytes, 9 H2 sections, 25 list links
netflix.com            200 text/html                    https://www.netflix.com/NotFound?prev=https%3A%2F%2Fwww.netflix.com%2Fllms.txt
  -> HTML page answering 200, not an llms.txt
moloco.com             200 text/plain                   https://www.moloco.com/llms.txt
  -> text, but the first line is not an H1: Generated by Moloco, this is an llms.txt file designed to he
pages.dev              200 text/html                    https://www.cloudflare.com/products/pages/
  -> HTML page answering 200, not an llms.txt

このスクリプトはリンクまでは確認しません。それには、ファイルからURLを取り出してGETしてください。HEADの404は信用しないでください。

今、サイトで変えるとしたら

llms.txtを置いていないなら、まず/llms.txtがちゃんと404を返すことを確かめてください。そこで200のHTMLページが返るのは、何もないより悪い状態です。雑なチェッカーが「対応済みです」と言ってしまうからです。置いているなら、# Your Siteの形で始め、数十キロバイト以内に抑え、URLの構成を変えるたびにリンクチェックをやり直してください。上のリンク切れを生んだのは、まさにその構成変更です。

もう1つ。llms.txtが役に立つのは、そもそもクローラーがページを取得できる場合だけです。以前の測定では、アムステルダムの自転車店サイト79件のうち19件が、多くは自分のrobots.txtに反して、少なくとも1つのAIクローラーをサーバーで拒否していました。

生データ(ドメインごとに1行のJSON、取得したファイル、プローブと分析のスクリプト)は上の日付のまま保管しています。ドメインごとの表が必要な方はご連絡ください。

ツールで確かめる場合

無料のAIクローラーチェックは、その手前の半分を確かめます。robots.txtと、サーバーがGPTBot、ClaudeBot、PerplexityBotに実際に返す応答の比較です。llms.txtは見ません。

1サイトを人の手で一通り見てほしい場合は、同じページから9,800円のミニ診断を申し込めます。AIクローラーのアクセスと機械可読性(llms.txtを含む)を確認し、そのサイト向けにそのまま貼れる修正案(修正済みのrobots.txt、ボットへの403に対するCDN/WAFの手順、metaとcanonicalの修正、JSON-LDとllms.txtの雛形)をお渡しします。公開前に必ず内容を確認してください。AIエンジンには質問を送らず、引用や順位も測りません。