为什么 robots.txt 值得单独检查一遍
robots.txt 是放在站点根目录的一个纯文本文件，搜索引擎蜘蛛在抓取前会先读取它。规则本身很简单，但一旦写错，影响范围往往是整站级别的：要么该被发现的页面被挡住，要么本该屏蔽的测试页面被放进来。它不像页面内容那样每天有人看，改完之后很容易被遗忘，所以更适合放进固定的检查清单里。
第一步：确认文件本身能被正常访问
- 用浏览器或命令行工具打开 https://你的域名/robots.txt，确认返回 200，而不是 404 或 500。
- 确认返回的是纯文本，没有被 CDN 或 WAF 拦截成验证页、登录页。
- 如果站点有 www 和非 www、http 和 https 多个入口，每个入口最好都能读到同一份规则。
如果 robots.txt 返回 5xx，蜘蛛通常会把整站视为暂时不可抓取；如果返回 404，则等同于没有限制。两种结果的差别很大，别靠猜。
语法自查：几个容易写错的点
- User-agent 与 Disallow 的配对：每一组规则以 User-agent 开头，后面的 Disallow、Allow 都属于它这一组，中间不要插入空行，否则会被当成新的一组。
- 路径前缀匹配：Disallow 后面跟的是路径而不是完整网址，写成 https://example.com/admin 是无效的，应该写成 /admin。
- 通配符的含义：星号匹配任意字符，美元符号表示结尾。比如 /search 会连带挡住 /search-result，而 /search$ 只匹配这一条路径。
- 大小写敏感：路径部分区分大小写，/Admin 和 /admin 是两条不同的规则。
- Sitemap 指令：可以在这里声明站点地图地址，注意写完整的绝对地址，而不是相对路径。
别把渲染需要的资源一起挡住
有些站点为了节省抓取配额，会一口气屏蔽 js、css 和图片目录。结果是蜘蛛拿到一个没有样式、没有内容的空壳，页面能被抓取，但很难被正确理解。更稳妥的做法是：只屏蔽确实不需要被抓的目录，把渲染必需的静态资源放开；如果某个具体资源不想被抓，再单独处理那一条路径，而不是砍掉整个目录。
robots.txt 与 meta robots 的分工
这两者经常被混用，但作用并不相同：robots.txt 控制的是“能不能抓”，meta robots 标签或响应头里的 X-Robots-Tag 控制的是“抓到了能不能收录”。
- 如果某个页面被 robots.txt 挡住，蜘蛛就不会去读它页面里的 noindex，页面仍可能以无描述的形式出现在结果里。
- 想彻底从索引中移除，应该让页面保持可被抓取，同时在页面层级返回 noindex；确认移除生效后，再考虑是否收紧抓取。
- 批量下线的栏目、活动页、参数页，适合用 noindex 逐个处理，而不是一条 Disallow 全砍。
和站点地图、目录结构保持一致
站点地图里提交的地址，不应该同时出现在 Disallow 列表里，这种自相矛盾会让抓取信号变得混乱。每次调整栏目或改版 URL 之后，把 robots.txt、站点地图、内链规则放在一起过一遍，看看有没有已经废弃的路径还留在文件里。
测试环境与线上环境分开处理
- 测试站、预发布域名建议整体禁止抓取，避免半成品页面被收录。
- 这条规则写在测试站自己的 robots.txt 里，而不是靠“反正没人知道这个域名”。
- 上线前再确认一次：生产环境的 robots.txt 没有被测试配置覆盖掉。
把它放进发布检查清单
- 改完 robots.txt 后，用搜索引擎提供的 robots.txt 测试工具或 URL 检查工具，验证一条具体路径是否符合预期。
- 在服务器上保留一份变更记录，写明改动内容、原因和日期。
- 每隔一段时间抽查：随机挑几个重要栏目地址，确认它们没有被误屏蔽。
robots.txt 只有几行，却直接决定了蜘蛛能看到什么。把它当作一份需要长期维护的配置文件，而不是一次写完就再也不用碰的东西，站点运营会少很多莫名其妙的“抓不到”问题。