robots.txt 不是安全工具，而是抓取约定
很多站点在遇到不想被看到的目录时，第一反应是在 robots.txt 里写一行 Disallow。这个文件确实能告诉蜘蛛哪些路径不要抓，但它不是访问控制，也不能阻止别人直接打开 URL。它的价值在于：把有限的抓取资源引导到真正需要被发现的页面上。也正因为只有几行，写错之后往往不容易察觉，等到日志里蜘蛛访问量下降，才发现整站都被挡住了。
最常见的几个误伤场景
一行 Disallow: / 挡住全站
测试环境上线、临时关闭站点、复制模板时忘记删掉，都可能留下全站屏蔽规则。蜘蛛读到这一行后，通常不会继续抓取站内任何页面。更麻烦的是，如果这条规则只对某个 User-agent 生效，其他蜘蛛可能照常抓取，日志里看起来“还有蜘蛛来”，容易让人误判问题已经解决。
顺手屏蔽 CSS、JS 和图片
有人为了“节省抓取预算”，把 /css/、/js/、/images/ 全部 Disallow。蜘蛛虽然不直接给页面打分，但需要这些资源来理解页面渲染结果。尤其是依赖前端渲染的站点，屏蔽 JS 后，蜘蛛拿到的可能只是一副空骨架。图片同理，屏蔽图片目录会让图片搜索和相关页面表现受到影响。
规则冲突与优先级没弄清
robots.txt 的匹配不是“谁写在前面谁赢”。当 Allow 和 Disallow 同时匹配一条 URL 时，通常更具体、路径更长的规则优先。不同蜘蛛对通配符和结尾符号的支持也有差异。写规则时，最好用具体路径做测试，而不是凭印象判断。
一份可执行的 robots.txt 自查清单
- 确认 User-agent 分组：检查是否有针对特定蜘蛛的单独分组，以及这些分组是否把主站规则覆盖掉了。
- 检查 Disallow 路径是否误伤：逐条对照目录和文件类型，确认没有把 CSS、JS、图片、字体等渲染资源屏蔽。
- 确认该抓的页面没有被拦：栏目页、详情页、分页、标签页等，如果希望被蜘蛛发现，就不应出现在 Disallow 里。
- 检查 Sitemap 声明：写在这里的 sitemap 地址应可访问，并且没有被同一份 robots.txt 屏蔽。
- 不要用 robots.txt 处理重复内容：屏蔽页面只能阻止抓取，不能解决索引问题。重复内容更适合用 canonical 或 noindex 处理。
- 更新后观察日志：修改规则后，看蜘蛛对 robots.txt 的请求状态，以及后续对目标目录的抓取是否恢复。
用工具和日志验证，不要只看规则文本
规则写完后，最好用搜索资源平台提供的 robots.txt 测试工具，输入几个代表性 URL，看是否被允许抓取。也可以直接在浏览器里访问 robots.txt，确认返回的是纯文本、状态码正常，而不是被 CDN 缓存成旧版本，或者被 WAF 拦截成 403。
服务器日志里，蜘蛛请求 robots.txt 的频率和状态码值得关注。如果长期返回 5xx，蜘蛛可能降低抓取频率；如果返回 404，则相当于告诉蜘蛛没有规则，默认可以抓取。规则更新后，可以对比更新前后的抓取量，确认屏蔽和放开是否按预期生效。
robots.txt 只影响遵守规则的蜘蛛。真正需要保护的内容，应该放在登录之后或使用其他访问控制手段，而不是依赖 Disallow。
什么时候不该动 robots.txt
如果站点结构稳定、蜘蛛抓取正常、日志中没有异常，就不需要频繁修改。每次改动都可能带来新的误伤，尤其是在多域名、多语言、多子目录的站点上。把规则保持简洁，只屏蔽确实不需要抓取的路径，反而更容易维护。
小结
robots.txt 自查的重点不是“写得越多越好”，而是确认该抓的没被拦、该拦的确实拦住。定期检查规则、测试代表性 URL、结合日志观察蜘蛛行为，就能避免几行文字把正常抓取挡在门外。