robots.txt 放在网站根目录，内容通常只有几行，但它决定了蜘蛛能走进哪些路径、不能走进哪些路径。正因为简单，很多站点在改版、迁移或多人协作时容易忽略它，等发现抓取量下滑才回头排查。这篇文章把 robots.txt 的常见问题和维护动作整理成一份可执行的自查思路。
为什么一条规则会造成整站影响
robots.txt 的匹配方式不像很多人想象的那样只看目录名。它按路径前缀匹配，还支持 * 和 $ 通配符，且不同爬虫对规则细节的处理可能存在差异。一旦写成 Disallow: /，或者把不该屏蔽的目录写进规则，蜘蛛可能直接停止访问大量页面。更麻烦的是，这类问题往往不会让服务器报错，从监控上看一切正常，只有抓取日志和收录数据才会慢慢反映出来。
常见的几类误伤场景
- 整站屏蔽：测试环境或维护页面的规则被误同步到生产环境，文件里只留了一行 Disallow: /。
- 路径写得太宽：想屏蔽某个参数目录，却写成了 Disallow: /search，结果把正常的 /search-guide/ 之类的路径一起挡住。
- 通配符用错位置：想屏蔽带参数的地址，规则写成 Disallow: /*?，把一些静态路径也牵连进去。
- 忘记 Allow 回补：大目录被屏蔽后，其中个别需要抓取的页面没有用 Allow 单独放行。
- Sitemap 地址写错：文件里声明的 sitemap 地址不是最终可访问的版本，或者域名写成了测试域名。
- 多域名共用一份文件：主站、子站、移动站共用同一份 robots.txt，规则之间互相打架。
上线前的检查清单
每次改动 robots.txt，建议按下面的顺序过一遍，不要只靠记忆。
- 用浏览器直接访问域名根目录下的 robots.txt，确认返回 200，并且内容是最新版本而不是 CDN 缓存的旧文件。
- 全文搜索 Disallow: /，确认没有整站屏蔽；如果有，确认是否为有意为之。
- 逐条核对每条路径，尤其注意目录名后面有没有多加斜杠、有没有少写斜杠、大小写是否和实际 URL 一致。
- 检查 Allow 规则，确认需要抓取的目录没有被上一条 Disallow 误伤。
- 核对 Sitemap 行，确认协议、域名和路径都能正常访问。
- 在搜索引擎的 robots.txt 测试工具里跑一遍，输入几个典型 URL，看看结果是否符合预期。
- 把改动内容、时间、操作人记在变更记录里，方便出问题时快速回滚。
维护节奏与协作习惯
robots.txt 不需要频繁调整，但需要有人负责。可以约定一个固定的检查周期，比如每月一次，或者在改版、迁移、新栏目上线前后各看一次。多人协作的团队，最好把根目录文件的修改权限收拢到少数几个人，其他成员通过工单或需求单提出变更。服务器层面的 301、CDN 回源、测试域名解析这些环节，也可能让 robots.txt 出现和生产环境不一致的版本，部署后顺手访问一次就能发现。
robots.txt 只表达抓取意愿，不是访问控制手段。不要把内部文档、后台地址、用户数据目录等内容放在公开可访问的目录里，再指望用 robots.txt 藏起来。真要限制访问，应该用登录、权限或网络层策略。
出问题后的排查顺序
如果怀疑 robots.txt 影响了抓取，可以先看抓取日志里蜘蛛对根目录文件的请求频率和返回状态，再检查文件内容是否被改动。确认规则有误后，及时修正并提交新版本，同时观察后续几天的抓取量变化。不要因为一次误伤就频繁调整规则，稳定、可解释的规则比来回试探更有利于长期维护。
把 robots.txt 当成站点结构的一部分来管理，而不是一个写完就忘的文本文件，能减少很多不必要的抓取波动。