很多站点在服务器根目录放了 robots.txt，但真正定期检查的人并不多。它看起来只是一段文本，实际却会影响搜索引擎蜘蛛能否发现和抓取 URL。写错规则时，问题往往不会立刻暴露：页面还能正常访问，用户也能打开，只是蜘蛛不再来了。
这篇文章不讲复杂语法，只整理一份 robots.txt 自查思路，适合在改版、上线新栏目、调整目录后逐项过一遍。
先确认它是不是真的在生效
第一步不是看规则，而是确认文件位置和状态。robots.txt 必须放在站点根目录，例如 https://www.example.com/robots.txt，不能放在子目录里。用浏览器或 curl 访问，返回状态码应当是 200，内容类型通常是 text/plain。如果返回 404，蜘蛛会认为没有限制；如果返回 403 或 5xx，不同爬虫的处理方式可能不一样，容易造成抓取异常。
还要注意域名。如果有 www 和非 www、HTTP 和 HTTPS 多个版本，确认每个可访问的主机名都返回同一份规则，或者至少确认蜘蛛实际访问的那个版本没有问题。
这些常见写法容易误伤
- 全站屏蔽后忘记删除。测试环境常用的 Disallow: / 如果同步到了正式环境，会直接挡住整站抓取。上线前检查一次，比事后补救省事。
- 屏蔽 CSS、JS 等静态资源。有些规则为了省流量，把 /assets/、/static/ 整个目录 disallow。蜘蛛拿不到样式和脚本，可能影响对页面内容的理解。除非你明确知道后果，否则不要屏蔽渲染所需资源。
- 用 robots.txt 处理不该被收录的页面。robots.txt 只是“不要抓取”，不是“不要索引”。如果页面已经被外部链接指向，搜索引擎仍可能仅凭链接把它展示出来。真正不想被索引的页面，应使用 noindex，并且确保蜘蛛能访问到该页面。
- 规则顺序和匹配范围写错。User-agent、Allow、Disallow 的匹配存在优先级差异，通配符和结尾符号也容易写多写少。比如想屏蔽 /search/，却写成了 /search，可能把 /search-engine/ 之类的路径也挡住。改写后最好用官方测试工具验证。
- Sitemap 地址写错或漏写。Sitemap 声明不是必须，但写了就要保证地址可访问、内容有效。如果站点有多个子 Sitemap，也可以在这里汇总声明。
自查时重点看什么
- 确认重要栏目、详情页、列表页没有被误屏蔽。可以按目录层级逐个核对，尤其是新上线的频道。
- 确认不想被抓取的路径确实写进了规则，例如后台、搜索结果页、带参数的筛选页。但不要依赖它做安全防护。
- 确认没有把整站资源目录一棍子打死。图片、CSS、JS 是否允许抓取，要结合页面渲染方式判断。
- 确认规则没有相互矛盾。同一 User-agent 下，Allow 和 Disallow 同时出现时，理解清楚哪条生效。
- 确认文件编码和换行正常。虽然不复杂，但复制粘贴时带入特殊字符，也可能让规则解析异常。
改完之后怎么验证
不要只看文件内容。可以用搜索引擎提供的 robots.txt 测试工具，输入具体 URL，看它是否被允许抓取。也可以结合服务器日志，观察蜘蛛对重要目录的请求是否恢复。如果站点有搜索资源平台账号，抓取统计和覆盖率报告也能提供参考，但它们反映的是趋势，不是实时结果。
如果最近刚调整过目录或换了域名，建议把旧规则、新规则各留一份记录，写清楚修改时间和原因。过一段时间再回看，能快速判断某次抓取下降是否和规则变更有关。
把 robots.txt 当成一份给蜘蛛看的“站点说明书”，而不是权限系统或万能开关。它越简单、越明确，越不容易出错。
日常维护的小习惯
- 每次改版、上线新栏目、调整 URL 结构后，把 robots.txt 加入检查清单。
- 不要把测试环境的屏蔽规则直接合并到正式环境，发布前人工确认。
- 如果使用了 CDN 或 WAF，确认它们没有额外拦截蜘蛛，也没有缓存一份过期的 robots.txt。
- 定期查看服务器日志中蜘蛛的访问状态，发现大量 403、404 或超时，再回头检查规则和服务器配置。
robots.txt 本身不复杂，复杂的是站点结构变化后，规则没有跟着更新。把它当作站点运营中的一个小型配置项，定期核对，通常就能避开大部分“蜘蛛突然不来了”的误会。