robots.txt 放在站点根目录，是蜘蛛进入站点前第一眼会看的文件。它通常只有几十行，平时没人动，改版、测试、域名迁移时才被想起来。也正因如此，它是最容易埋雷的地方之一：一行规则写错，可能让整站或整批栏目从抓取队列里消失，而页面上看不出任何异常。

先弄清它能做什么

robots.txt 是一份约定，主流搜索引擎会遵守，但它不是访问控制，也不是安全措施。不要指望把后台地址、内部测试页写进去就等于藏起来了——这个文件本身是公开可读的，任何人访问 /robots.txt 都能看到你列出的路径，等于主动交出一份目录清单。

它主要做两件事：告诉蜘蛛哪些路径不建议抓取，以及站点地图放在哪里。至于页面是否进入索引，更可靠的手段是页面级的 meta robots 标记或 noindex 响应头。

常见的几种误伤

从根目录开始的整站屏蔽

测试环境里习惯性写着 Disallow: /，上线时忘记删掉。表现是蜘蛛仍然会来，但几乎不抓内容，日志里反复出现的只有对 robots.txt 的请求。这类事故排查起来并不难，难的是发现得晚。

通配符用得太宽

Disallow: /*? 本意是挡掉带参数的筛选页，结果把大量通过参数正常访问的栏目页一起挡了。更稳妥的做法是把规则收窄到具体路径下的特定参数，而不是全站一刀切。每加一个通配符，都要想清楚它实际能匹配到多少条 URL。

顺带屏蔽了资源目录

把 /js/、/css/、/images/ 一并写进 Disallow，页面渲染和图片搜索都会受影响。现在搜索引擎需要抓取样式和脚本才能还原页面内容，除非确认某个目录里只有与页面无关的素材，否则不要屏蔽它们。

把匹配方向理解错了

robots.txt 的路径是从根开始的前缀匹配，不是关键词匹配。写 Disallow: /news 会连带挡掉 /news-list、/newspaper 这类同前缀路径，并不管它们是不是真的在 /news 目录下。要精确到目录，记得补上结尾斜杠；要放开个别文件，就用对应的 Allow 行单独写出来。

规则冲突时谁说了算

当 Allow 和 Disallow 同时命中一条路径时，通常按匹配字符更长的那条执行；长度相同时，Allow 优先。但不同引擎的实现细节存在差异，与其依赖优先级，不如把规则写清楚，避免互相覆盖，也避免以后自己都看不懂当初为什么这么写。

写完一段规则，自己拿几条典型 URL 还原一遍：它会命中哪几行？最终结果是允许还是屏蔽？想不明白的规则，就是有风险的规则。

上线前后的检查动作

• 直接访问 /robots.txt，确认返回 200，且内容是最新版，不是缓存或旧部署留下的版本。
• 用搜索引擎官方提供的 robots 测试工具，输入几条典型 URL，看判定结果是否符合预期。
• 分环境管理：测试站与线上站使用不同的配置模板，避免测试规则被带到线上。
• 声明站点地图：在文件末尾写上 Sitemap 的完整地址，方便蜘蛛顺着找到入口。
• 观察服务器日志：如果内容页的抓取量突然下降，而 robots.txt 的请求一切正常，先回来查规则。

什么时候该改，什么时候别动

域名迁移、目录结构调整、关闭某个频道、上线大批量筛选页，这些场景需要动 robots.txt。每次修改后留一份变更记录，写明改了什么、为什么改、什么时候生效，出问题时能快速回滚。日常没有明确目标时，不要顺手改它。

最后一个容易被忽略的顺序问题：如果某个页面只是不想被索引，但还需要蜘蛛读到页面里的 noindex 标记，就不要用 robots.txt 把它挡在门外——被挡住的蜘蛛读不到页面中的任何指令。两种手段用错顺序，往往就是「页面明明写了不索引却还是被收录」，或者「想删掉的页面怎么也删不掉」的根源。