ウェブの歴史の中で、これほど長く生き続けたファイルはそう多くありません。robots.txtは1994年に誕生しました。当時ウェブにはまだ数千のサイトしか存在しませんでしたが、30年後の今もなお、あなたのサイトとそれを巡回するロボットたちとの最前線であり続けています。その歴史は、インターネットがクローラーと共存する術を学んできた歴史でもあります。

紳士協定の誕生

このプロトコルを提案したのは、エンジニアのMartijn Kosterです。1994年、設定ミスのクローラーがサーバーをダウンさせた事件がきっかけでした。アイデアはシンプルかつエレガントでした。サイトのルートに/robots.txtというファイルを置き、ボットにどのエリアを訪問してよいか、してはならないかを伝える。技術的な障壁ではなく、あくまで紳士協定です――礼儀あるボットは自発的にこれを遵守します。

慣習から公式標準へ

30年近くの間、robots.txtは業界全体が従うデファクト標準として機能してきましたが、いかなる機関にも正式に認定されていませんでした。それが変わったのは2022年9月、IETFがRFC 9309（Robots Exclusion Protocol）を公開したときです。Googleが主導的な役割を果たしたこの標準化により、業界が当然のものとしてきたルールが、ついて曖昧さなく公式の文書として記録されました。

基本的な仕組み

機能の本質はほとんど変わっていません：

• User-agentでルールを適用するボットを指定します。
• DisallowとAllowで禁止・許可するパスを指定します。
• ワイルドカード（*と$）が使え、より具体的なルールが優先されます。
• SitemapでサイトマップのURLを指定します。

シンプルで読みやすく、移植性に優れています。どのサーバーでも、これを遵守するどのボットに対しても、同じように機能します。

AI時代の試練

最大の試練は、AIクローラーの登場とともにやってきました。ここ数年でrobots.txtには新しい名前が次々と加わりました――GPTBot、ClaudeBot、Google-Extended、PerplexityBot。コンテンツ発信者たちが、誰が自分のコンテンツをモデルのトレーニングやAI回答生成に使用できるかを制御しようとしているからです。1994年のプロトコルは、意図せずして、AIと著作権をめぐる議論の戦場になりました。

限界も変わらない

robots.txtが何ではないかを忘れないでください。技術的に誰かをブロックするものではありません。悪意のあるボットは無視することができます。機密コンテンツの保護にもなりません――それにはサーバー認証やアクセス制御が必要です。また、他のサイトがリンクを張ることでページがインデックスされる可能性を排除するものでもありません。robots.txtは意思表明であり、壁ではないのです。

Spiderがどう役立つか

30年経った今も、核心的な問いは変わりません――あなたのルールは意図通りに機能していますか？Spider.esはあなたのrobots.txtを各ボットの視点で解釈し、Googlebotから最新のAIクローラーまで100以上のクローラーに対して、サイトのどの部分にアクセスできるかを明確に示します。これほど長い歴史を持つ標準への最大の敬意は、自分のrobots.txtが正しく書かれているかどうかを確認することではないでしょうか。