robots.txt
よみ: アールオービーオーティーエスティーエックスティー
検索エンジンのクローラーに「クロールして良い領域 / してほしくない領域」を伝えるテキストファイル。サイトルート(/robots.txt)に配置し、User-agent(対象クローラ)・Disallow(クロール禁止 URL)・Allow(許可)・Sitemap(sitemap.xml の URL)を記述する。Web の基本ファイルで、ほぼすべてのサイトに必要。
本書のスタンス(Lesson 6-3)は「誤った設定で全ページ非クロールにする事故が頻発」(重大リスク領域)。公開直前の 5 重大リスク領域に含まれ、業者から確認書を受け取る項目。「Disallow: /」(全クロール禁止)をステージング環境用に設定したまま本番に反映 → 全ページがインデックスから消える、という事故が定番。
正しい運用:本番では基本的に空に近い設定(管理画面 /wp-admin/ のような不要領域だけ Disallow)、sitemap.xml への参照を必ず記述、ステージング環境は別ドメイン + Basic 認証で守る(robots.txt に依存しない)、本番反映前後で robots.txt の差分を必ず確認、Search Console の robots.txt テスターで Google の解釈を確認、リニューアル時の URL 構造変更でも robots.txt を見直し。
落とし穴は、ステージング用の Disallow: / を本番に反映して全ページがインデックスから消える(発見まで 1〜2 週間、復旧まで 1 ヶ月以上)、noindex 用のページに Disallow を併用(クロールされないと noindex も読まれない)、robots.txt で隠したつもりが URL リストが公開されていてセキュリティ事故、AI クローラ(GPTBot / ClaudeBot / PerplexityBot)を Disallow するか許可するかの方針が不明、sitemap.xml の参照を書き忘れる。
言葉をよく利用する人
- コーダー / フロントエンドエンジニア
- インフラエンジニア
- SEO 担当者
- Web 担当者(発注側)
- ディレクター
会話上での使用例
リニューアル後にインデックス数が急減した場面
-
SEO 担当者
リニューアル後、Search Console のインデックス数が 1,200 → 30 に激減
-
Web 担当者
robots.txt を最優先確認。ステージング用の Disallow: /が混入している可能性が極めて高いです。即座に確認 → 修正 → Search Console で再申請の手順を
AI クローラの扱いを議論する場面
-
広報
robots.txt で GPTBot を Disallow すべき?
-
Web 担当者
本書の方針は許可(Good SEO is Good GEO)。AI 検索で引用されることでブランド露出 + 指名検索の増加が期待できます。商用利用を厳密に拒否したい記事だけ個別ページ単位で対応する方針で