robots.txt 是放在站点根目录下的一个纯文本文件，用来告诉爬虫哪些路径可以抓、哪些不要抓。它的语法很简单，但正因为简单，很多站点在改版、换域名、上线测试环境之后忘了同步更新，结果一行 Disallow 就把整站的抓取通道堵住了。下面梳理一份可以照着走的自查清单，帮你在站点运营中把这份文件真正管起来。
先弄清楚它能做什么、不能做什么
robots.txt 是约定，不是强制。遵守协议的搜索引擎爬虫会读取它，但不保证所有抓取程序都照做，它也不能替代权限控制。不要用它来隐藏后台、用户数据或接口地址，真正需要保护的内容应该用登录校验、IP 限制或服务端鉴权。
另外，它只影响抓取，不直接等于不收录。被屏蔽的 URL 仍然可能因为外部链接被索引，只是爬虫看不到页面内容。如果目标是让某个页面彻底从索引中消失，正确做法是允许抓取、在页面上加 noindex，而不是简单 Disallow。
逐项自查清单
1. 是否误封了整站
- 检查是否残留 Disallow: / 或 Disallow: /* 这类全站屏蔽规则。
- 确认 User-agent 分组没有写错，比如把正式爬虫的规则误写进了测试 UA 分组。
- 检查是否同时存在多份 robots.txt，例如 http 与 https、带 www 与不带 www 各有一份，内容还不一致。
2. 是否挡住了样式与脚本
早期不少站点为了省抓取预算，会把 /css/、/js/ 目录屏蔽掉。现在主流爬虫需要渲染页面来判断内容质量，如果样式和脚本抓不到，它看到的很可能是一个近乎空白的页面。除非确有性能压力，一般建议放开这些静态资源目录。
3. 通配符与结尾符的写法
- * 匹配任意字符，例如 Disallow: /*?sort= 可以挡住排序参数产生的组合地址。
- $ 匹配结尾，例如 Disallow: /*.pdf$ 只挡 PDF 文件。
- 通配符写得太宽容易误伤，比如 Disallow: /*print 会连带挡住正常路径中含 print 的页面。
4. Sitemap 是否声明
在文件末尾写上 Sitemap: 并指向站点地图的完整地址，可以帮助爬虫更快找到入口。这里要用绝对 URL，且协议与域名建议和当前站点保持一致。
5. 路径大小写与目录层级
robots.txt 的路径匹配区分大小写，/Admin/ 和 /admin/ 是两条不同的规则。如果站内 URL 本身大小写混用，规则很容易漏网。建议在服务器层面统一为小写，从源头减少这类歧义。
6. 多域名与 CDN 场景
如果站点同时存在多个可访问域名，例如带 www 与不带 www、多语言子域、CDN 回源域名，那么每个域名根目录下都应当有一份一致的文件。曾经出现过主站规则正常，但旧域名仍然完全开放的情况，结果重复地址被大量发现和抓取。迁移或换绑之后，记得回头检查旧地址。
怎么验证规则是否生效
- 直接访问域名根目录下的 robots.txt，确认返回状态正常且内容是最新版本，而不是缓存的旧文件。
- 使用搜索引擎站长平台提供的 robots 测试工具，输入具体 URL，看判定结果是允许还是屏蔽。
- 观察服务器日志里爬虫的抓取路径分布。如果样式、脚本或整个栏目区突然消失，先回头看这份文件。
- 把它纳入版本管理和发布流程，改版、迁移、上新环境时同步检查一遍。
和 URL 发现的关系
蜘蛛池、外链、站点地图这些手段解决的是“入口从哪来”，robots.txt 解决的是“入口进来之后走不走得通”。如果通道本身是堵的，再增加入口也不会带来有效抓取。对运营来说，这两件事最好放在同一张检查表里：先保证路径通畅，再考虑扩大入口。
一个成本很低的习惯：每次站点结构或域名有变动，第一件事就是打开 robots.txt 看一遍。它挡掉的多半是低级事故，但这类事故往往最难排查。
小结
robots.txt 不需要什么高深技巧，需要的是稳定的维护习惯。把它当成站点配置的一部分，跟着发布流程走，定期复核屏蔽规则、静态资源、Sitemap 声明与域名一致性，就能避开大部分“整站抓不到”的坑。