robots.txtとは|『クローラーへの指示書』の本質と運用5要件

『robots.txt』って、なんとなく「クローラーをブロックするファイル」だと思っていませんか?

株式会社Cameen 西村温裕ことおんゆーです。

近年、SEOやテクニカル運用の文脈で「robots.txtを設置しましょう」「robots.txtでクロール制御しましょう」、こういう話題を見かける機会が増えましたよね。WordPressの初期セットアップ記事でも、SEOツールのチェックリストでも、ほぼ必ず登場する基本ファイルです。

で、いざ「robots.txtって具体的に何のためにあるの?」「Disallowで指定すれば本当にアクセス禁止になるの?」「meta robotsタグとは何が違うの?」と聞かれると、答えに詰まる方が多いんですよね。「クローラーを制御するファイル」という認識で止まって、本質的な役割まで理解している人は意外と少ないんです。これ、自分だけだと思ってませんか?

うちで複数の自社サイトとクライアントサイトを運営してきた中で、robots.txtの誤解と誤運用は本当に頻繁に見てきました。「Disallowで指定したのに検索結果に出ている」「Sitemapを宣言してなくてクロールが遅い」「機密ディレクトリをDisallowに書いたら逆に公開URL一覧化してしまった」、こういう事故が後を絶たないんですよね。

もう1つ繰り返し観察したのは、「robots.txtを書けばクローラーを完全に止められる」という根本的な誤解。robots.txtは法的強制力のない「お願いベース」の仕組みで、Googlebotなど主要クローラーは従いますが、悪意のあるボットは無視します。機密情報の保護目的でrobots.txtを使うのは、根本的に道具の選択ミスなんです。

今回はその「今さら聞けないrobots.txt」を、表面的な書き方の解説ではなく、構造の核心と運用の落とし穴まで一気に深掘りしていきます。読み終わる頃には、自分のサイトのrobots.txtを正しく設計でき、クローラーとの付き合い方が紙に書き出せるレベルになっているはずです。

結論:robots.txtの核心は「アクセス制限」ではなく「クローラーへの指示書」

robots.txtの本当の正体は、「検索エンジンクローラーに対するアクセス制御の指示書(任意拘束力)」のことです。サイト管理者がクローラーに「ここは見ていいですよ」「ここは見ないでください」とお願いするためのテキストファイルなんです。

業界の体感として、robots.txtを正しく運用しているサイトは全体の3〜4割程度。残りは「とりあえず置いただけ」「コピペで動いている」「実は何も書かれていない」という運用状態です。SEOチェックツールでrobots.txtの記述ミスを検出する機能があるのは、これだけ誤運用が多いからなんですよね。

robots.txtで最も重要な性質は「任意拘束力」だということ。GooglebotやBingbotなど主要検索エンジンのクローラーは、礼儀としてrobots.txtを読んで指示に従います。でも法的強制力はなく、悪意のあるスクレイピングボットや無名のクローラーは完全に無視します。これ、本質的に「物理的なロックではなく、紙に書かれたお願い」なんですよね。

だから、機密情報の保護にrobots.txtを使うのは決定的な道具選択ミス。むしろ「ここに重要なファイルがあります」と全世界に告知してしまうことになります。robots.txtの本来の役割は、検索エンジンに対してサイトのクロール優先度を伝え、クロールバジェット(クロール予算)を効率的に使ってもらうこと。SEO技術の中でも「サイト全体のクロール最適化」を担う基盤ファイルなんです。

なぜ「robots.txt」と名付けられたのか

もう少し深く掘ります。なぜこのファイルは「robots.txt」と名付けられたのか。命名の背景と歴史を整理します。

「robots」は英語で「ロボット」のこと。Web世界において「ロボット」とは、人間ではなく自動的にWebサイトを巡回するプログラム、つまりクローラー(crawler)・ボット(bot)・スパイダー(spider)のことを指します。robots.txtは「ロボットたちへの指示を書いたテキストファイル」という意味なんですよね。

robots.txtの仕組みは、1994年にオランダのエンジニアMartijn Koster氏によって提唱されました。当時、検索エンジン初期のクローラーがサーバーに過剰な負荷をかける事例が多発しており、サイト管理者がクローラーの動きを制御する標準的な方法が必要だったんです。Koster氏はこれを「Robots Exclusion Protocol(REP)」と名付け、業界のデファクトスタンダードとして広まりました。

そして約30年もの間、robots.txtは「業界慣習として動くデファクトスタンダード」でしたが、2022年にIETF(Internet Engineering Task Force)がRFC 9309として正式に仕様化しました。これでようやく、世界中の検索エンジン・クローラー開発者が参照できる「公式仕様書」が存在することになったんです。30年越しの公式化、これ、業界の歴史としてもなかなか興味深いですよね。

命名から仕組みまで一貫しているのは「クローラーへの指示」という性格。アクセス制限・認証・ブロックではなく、あくまで「ロボットへのお願い」という設計思想なんです。だから、robots.txtを正しく扱うには、この「お願いベース」という前提を絶対に外してはいけないんですよね。

robots.txt運用の現場で何が起きているか

命名と歴史がわかったところで、実際の運用現場で何が起きているかを5段階に分けて整理します。robots.txtの設計から監視まで、サイト運営者の「頭の中」と「実作業」を1人称で描写していきますね。

段階1: 設計

「うちのサイト、robots.txtちゃんと書けてるんだろうか」、こういう問い合わせが起点になります。サイト管理者の頭の中では「管理画面・テスト環境・検索除外したいページ」が浮かんでいる状態。でも、いきなり書き始めるとミスります。

正しい設計の順番は、サイト構造の全体像を把握→クロール優先したいページを明確化→クロール不要なディレクトリを整理→Sitemap.xmlとの整合性を確認、こういう流れ。「何をDisallowするか」より「何をAllowするか」を先に設計するのがコツなんですよね。

段階2: 記述

設計が終わったら、いよいよrobots.txtを書きます。基本構文は「User-agent」「Disallow」「Allow」「Sitemap」の4つだけ。シンプルなのに、ここで意外と事故が起きます。

たとえばUser-agentに「*」を書き忘れて全クローラー対象にしたつもりが、特定のクローラーにしか効いてなかった。Disallowで「/」と書いてしまい全クロール拒否事故を起こした。Allow指定をDisallowより上に書いたら優先度がおかしくなった。こういう細かいミスが、SEOに致命的な影響を与えるんですよね。

段階3: 検証

記述したら、必ず検証段階に入ります。Google Search Consoleには「robots.txtテスター」というツールがあり、URLを入力して「クロール許可されるか・拒否されるか」を確認できます。これ、絶対やってほしい工程なんです。

うちの経験では、検証をスキップして本番公開した結果、「重要ページが全部Disallow対象になっていた」「Allowしたつもりがクローラーから見えてなかった」という事故が頻発します。検証なしで本番に出すのは、テストなしで飛行機を飛ばすようなものなんですよね。

段階4: アップロード

検証が通ったら、robots.txtをサイトのルートディレクトリにアップロードします。配置場所は必ず「https://example.com/robots.txt」というURLでアクセスできる位置。サブディレクトリ(/blog/robots.txt等)に置いてしまうと、検索エンジンが認識しません。これ、初心者が一番よくやらかすミスですね。

WordPressサイトの場合は、テーマやプラグイン経由で自動生成されることもあります。Yoast SEO・All in One SEO・SWELLなどの主要SEOプラグインには、robots.txt編集機能が組み込まれているんですよね。FTPでアップする手間が省けるので便利です。

段階5: Search Console確認

アップロード後は、Google Search Consoleで「robots.txtが正しく読み込まれているか」を確認します。「設定」→「robots.txt」セクションで、Googlebotが最後に取得した日時とステータスがわかります。

ここで「未取得」「エラー」が出ていたら即修正。クロール統計レポートで、Disallow指定したページが本当にクロールされなくなっているかも確認します。これ、月次でチェックすると安心ですよ。サイト構造が変わったときにrobots.txtの整合性が崩れることがあるからです。

身近な話で全体像をつかむ

ちょっと身近な話で、robots.txtの全体像を掴み直しましょう。専門用語が続くと頭が疲れますからね。

たとえば、あなたが大きな会社のオフィスを管理する立場だとして、警備員さんに巡回ルートの指示書を渡すシーンを想像してください。ロビーは必ず見回りしてください、応接室には入らないでください、地下倉庫は許可がある場合だけ確認してください、こういう紙を1枚渡しますよね。

この警備員さん向けの指示書、これがまさにrobots.txtなんです。サイトの各エリアに対して「巡回OK」「巡回NG」を書いた紙を、入り口(ルートディレクトリ)に1枚貼っておく。警備員(Googlebot等のクローラー)はそれを読んで、巡回ルートを判断するわけです。

でも、ここで重要なポイントがあります。この指示書、あくまで「お願い」レベルなんです。マナーのいい警備員(主要検索エンジン)は必ず読んで従ってくれますが、忍び込もうとする泥棒(悪意のあるボット)は指示書を無視します。だから「絶対に見られたくない部屋」には、指示書ではなく物理的な鍵(認証・パスワード保護)をかけるべきなんですよね。

もう1つの落とし穴があります。「応接室には入らないでください」と指示書に書くと、外から見て「あ、応接室っていう特別な部屋があるんだな」と存在がバレてしまうんです。これ、まんまrobots.txtでDisallowを書く危険性そのもの。「Disallow: /admin/」と書くと、世界中に「このサイトには/admin/というディレクトリがあります」と告知することになります。

つまりrobots.txtは「警備員に渡す巡回指示書」であって、決して「金庫のロック」ではない。この感覚を掴むだけで、robots.txtの誤運用は8割減るんですよね。サイト設計の最初の段階で「rrobots.txtに書いて済む話」と「物理的に保護すべき話」を切り分ける目線が必須です。

robots.txt運用5要件

業界の人間からすると「robots.txt運用の王道」は明確に存在します。でも初心者ほど、この王道を外してしまうんですよね。なぜか?「とりあえずDisallowを書けばいい」という思い込みからスタートしてしまうからです。

いやちょっと待ってください。Disallowは「最後に書く要素」なんです。先に「どこに置くか」「誰に向けて書くか」「Sitemapはどこか」を固めてから、最後にDisallow/Allowを記述する。この順番を守るだけで、運用事故は激減します。

わかりますか?robots.txtの正解は「Disallowをたくさん書く」じゃないんです。「ルート配置→User-agent指定→Allow/Disallow明示→Sitemap宣言→公開情報のみ管理」という運用思想を守ることなんですよね。技術的にはシンプルですが、運用思想を外すと事故ります。

robots.txt運用で失敗する典型3パターン

うちでクライアントサイトのrobots.txtを多数レビューしてきた中で、運用事故はだいたいこの3パターンに分類できます。技術的な書き方ミスではなく、設計思想の誤りです。

この3パターン、技術的な細かいミスではなく「robots.txtの本質を誤解している」ことが共通項なんですよね。「Disallowで強制ブロックできる」「機密保護に使える」「書かなくても問題ない」、こういう誤解が事故の根っこにあります。

うちでrobots.txt運用してわかった本音

うちで複数サイトのrobots.txtを運用してきて、わかった本音をお伝えします。SEO本に書いてある建前と、実運用で見えてくる現実は、けっこう違うんですよね。

本音1: robots.txtだけでSEOは改善しない

SEOコンサルやテック系記事を読んでいると「robots.txtを最適化するとSEOが上がる」みたいな表現を見かけますが、これ、半分くらい誇張なんですよね。robots.txtは「クロール効率の基盤」であって、コンテンツの順位を直接押し上げる魔法のファイルではありません。

うちで複数サイトを運用してわかったのは、robots.txtを最適化しても、コンテンツの質と内部リンク構造がダメだと検索順位は上がらないということ。robots.txtは「最低限の衛生管理」レベルで、これがダメだとマイナス評価される、というのが実態に近いんです。プラス評価を狙うなら、コンテンツ・被リンク・ユーザー体験の改善が本筋です。

本音2: meta robotsとX-Robots-Tagの方が強い

「検索結果から特定のページを消したい」という用途では、robots.txtより<meta name="robots" content="noindex">やX-Robots-Tag: noindex(HTTPヘッダー)の方がはるかに強力で確実なんです。

robots.txtのDisallowは「クロールを止めるお願い」であって、すでにインデックスされているページを検索結果から消すわけではありません。むしろDisallow指定したページは、検索結果には「タイトルだけ」が残ったまま、コンテンツが取得できない奇妙な状態になることがあります。

「検索に出したくない」明確な目的があるなら、robots.txtで隠すのではなく、meta robotsのnoindexで明示的にインデックス除外を指示する。これが正しい手段なんですよね。robots.txtとmeta robotsとX-Robots-Tag、3つの使い分けを理解することが、テクニカルSEOの初歩です。

本音3: 大規模サイトほどrobots.txtの威力が出る

逆に言うと、小規模サイト(数百ページ以下)ではrobots.txtの最適化効果はほぼ感じられません。Googlebotがサイト全体を簡単に巡回できる規模だからです。

でも、ECサイトや大規模メディアサイトのように数万〜数百万URLを抱えるサイトでは、クロールバジェット(クローラーがそのサイトに使える時間予算)が枯渇する問題が出てきます。検索エンジンは無限にクロールしてくれるわけではないんですよね。

こういう大規模サイトでは、robots.txtで「重要でないパス(検索ページ・フィルター結果・印刷用ページ等)」をDisallow指定し、「重要なコンテンツページ」にクロールバジェットを集中させる戦略が有効です。うちで関わったECサイト案件では、robots.txt最適化で新商品ページのインデックス速度が約3倍向上した事例もあります。規模が大きくなるほど、robots.txtの設計は事業インパクトを持つんです。

robots.txt実装5ステップ

ここまで読んでくださった方、お疲れさまです。本質と落とし穴を理解したところで、実際にrobots.txtを実装する5ステップを整理します。これ、明日からでも実行できる順番です。

シンプルですが機能するrobots.txtの骨格が完成します。これ以上の複雑な記述(クローラー別の細かい指示・正規表現での絞り込み等)は、必要になってから追加すれば十分なんですよね。

よくある質問(FAQ)

robots.txtのDisallow指定とnoindexは、結局どっちを使えばいいんですか?

用途で使い分けるんです。「クロール自体を止めたい(サーバー負荷軽減・クロールバジェット節約が目的)」ならrobots.txtのDisallow。「検索結果に出したくない(インデックス除外が目的)」ならmeta robotsのnoindex。両方を同じパスに対して同時に使うのは矛盾するので避けます。具体的には、Disallowを書くとそもそもページがクロールされず、noindexタグが読まれないため、検索結果に「タイトルだけ残る」という中途半端な状態になります。完全にインデックスから消したい場合は、Disallowを外してnoindexを設定する方が確実です。

canonicalタグとrobots.txtは何が違うんですか?

役割が根本的に違います。robots.txtは「このページを見ないでください」という指示、canonicalは「重複ページがあるけど、正規版はこちらです」という指示。たとえばECサイトで色違いの商品ページが5パターンあるとき、robots.txtで4つをDisallowにしてしまうと、商品情報自体が検索エンジンに伝わりません。canonicalで「正規版は黒の商品ページ」と指定すれば、5パターンすべてのリンク評価が正規版に集約されます。重複コンテンツ問題は、原則canonicalで解決すべきで、robots.txtのDisallowは最後の手段です。

WordPressサイトで、robots.txtを自分で書くべきですか?それともプラグイン任せでいいですか?

プラグイン任せで問題ないケースがほとんどです。Yoast SEO・All in One SEO・SWELLなどの主要SEOプラグインは、WordPress標準の最適なrobots.txtを自動生成してくれます。「Disallow: /wp-admin/」「Allow: /wp-admin/admin-ajax.php」「Sitemap宣言」が含まれた、業界標準的な記述です。自分でカスタマイズが必要なのは、特殊なディレクトリ構造を持つサイトや、大規模ECサイトで個別のクロール制御を行いたい場合のみ。小規模・中規模サイトはプラグイン標準で十分機能します。

robots.txtを変更したら、検索結果にすぐ反映されますか?

すぐには反映されません。Googlebotがrobots.txtを再取得し、変更内容を解釈し、サイト全体のクロール挙動を変えるまでに数日〜数週間かかります。とくに既にインデックスされているページを「Disallowに追加した」場合は、検索結果から消えるまでにかなり時間がかかります。緊急の場合は、Search Consoleの「URL検査ツール」で個別URLを再クロールリクエストするか、削除ツール(古いコンテンツの削除)を使う方が確実です。robots.txtの変更は、長期的な運用方針の調整として位置付けるのが現実的です。

主要クローラーは、本当にrobots.txtに従ってくれるんですか?

主要な検索エンジンクローラーは従ってくれます。具体的にはGooglebot(Google)・Bingbot(Microsoft)・Yandexbot(Yandex)・Baiduspider(百度)など、商用検索エンジンの公式クローラーはRobots Exclusion Protocolに準拠しています。一方、悪意のあるスクレイピングボットや、無名のクローラーはrobots.txtを完全に無視することがあります。クローラー名と挙動の業界目安を参考にすると、Googlebotは順守率ほぼ100%、Bingbotは順守率高、無名ボットは順守率低、というのが実態です。重要なのは「主要クローラーには通じるが、すべてのアクセスを止められるわけではない」という前提を持つこと。

クローラー名	運営	robots.txt順守率(業界目安)
Googlebot	Google	ほぼ100%
Bingbot	Microsoft	順守率高
Yandexbot	Yandex	順守率高
Baiduspider	百度(Baidu)	順守率中〜高
無名スクレイピングボット	各種	順守率低(無視多数)

まとめ

で、結局robots.txtとは、こういうことです。

• 本質は「クローラーへの指示書」 — アクセス制限ファイルではなく、Robots Exclusion Protocolに基づく「クローラーへのお願い」。法的強制力はない
• 運用5要件を守る — ルート配置・User-agent指定・Allow/Disallow明示・Sitemap宣言・公開情報のみ管理。この5つを揃えればSEO基盤が固まる
• 機密保護には絶対に使わない — Disallowに書いたパスは公開URL一覧として全世界に告知される。機密はBasic認証・IP制限・サーバー側アクセス制御で保護する

robots.txtは、サイト運営の世界では「最低限の衛生管理」レベルの基本ファイル。ここを正しく設計できれば、検索エンジンとのコミュニケーションが安定し、SEOの土台が整います。逆にここで事故ると、検索結果から消えたり、機密情報が漏洩したり、想定外のダメージを受けるんですよね。

うちで複数サイトを運用してきた経験から言うと、robots.txtで最も大切なのは「お願いベースであることを忘れない」こと。強制力を期待してはいけない、機密保護には使わない、変更は長期的な運用方針として扱う。この3つの姿勢を持っているだけで、運用事故の8割は防げます。

ではでは。