robots.txt 和页面里的 robots 指令，平时不太会被注意到，但一旦写错，可能让蜘蛛在门口就被挡住。站点运营里，抓取指令属于“配置一次、长期生效”的东西，越是这样，越需要定期复查。
抓取指令分布在几个位置
很多人只记得根目录下的 robots.txt，其实影响抓取的规则至少还有下面这些：
- robots.txt：放在域名根目录，用来告诉蜘蛛哪些路径可以抓、哪些不要抓。
- meta robots：写在页面 head 里，控制当前页面的索引和链接跟踪行为。
- X-Robots-Tag：通过 HTTP 响应头下发，常用于 PDF、图片、视频等非 HTML 资源。
- canonical 与 sitemap：虽然不直接禁止抓取，但会影响蜘蛛把哪个地址当作主要入口。
这些位置如果互相矛盾，蜘蛛会按自己的规则取舍，站点运营者却容易以为“我已经设置过了”。
最常见的几类误配
整站被禁止抓取
开发阶段为了防止测试内容被抓，常会写 Disallow: /。如果上线前忘记删除，整站对蜘蛛就等于关闭状态。表面看访客访问正常，搜索端却几乎看不到变化，问题往往拖很久才被发现。
测试规则带到了线上
预发布环境、灰度环境、临时目录的 robots.txt 被同步到生产环境，是另一个高频问题。尤其是用同一套配置管理多个环境时，要确认发布流程里有没有把环境相关差异区分开。
误封 CSS、JS 和图片
有些站点为了“减少抓取压力”，把 /assets/、/static/、/uploads/ 等目录整体禁止。这样做可能影响蜘蛛对页面的渲染理解，也可能让图片资源无法被正常评估。除非确有原因，否则不建议把渲染所需资源一刀切。
sitemap 与 robots 各说各话
robots.txt 里声明了 sitemap 地址，但 sitemap 中又包含被 Disallow 的路径；或者页面被 noindex，却仍大量提交到 sitemap。两者不一致会增加蜘蛛的判断成本，也让运营人员难以判断问题出在哪一环。
一次可执行的自查清单
- 直接在浏览器访问 https://域名/robots.txt，确认返回 200，内容不是测试占位文本。
- 搜索 Disallow: / 和 Allow: / 这类宽泛规则，确认没有误伤整站或关键目录。
- 检查重要栏目、详情页、分页、筛选参数的抓取状态，确认不是全部被拦。
- 检查 CSS、JS、图片等资源目录，确认渲染所需文件没有被误封。
- 抽查页面的 meta robots，确认没有把该索引的页面写成 noindex、nofollow。
- 检查 PDF、图片等非 HTML 资源的响应头，确认没有意外的 X-Robots-Tag。
- 核对 robots.txt 中声明的 sitemap 地址，确认能正常访问且内容有效。
- 回顾最近一次发布记录，确认没有把测试环境的规则同步到线上。
用日志和平台工具验证
规则写对只是第一步，还要看蜘蛛实际怎么抓。可以结合服务器日志和搜索平台提供的抓取分析工具，观察几个信号：
- 重要目录的抓取量是否突然下降或归零。
- 被禁止的路径是否仍频繁出现在日志里，说明规则可能没生效或被忽略。
- 新发布的内容是否有正常发现记录，而不是长期没有抓取。
- 抓取主要集中在哪些地址，是否和 sitemap、内链入口一致。
如果发现异常，先查 robots.txt 和响应头，再查页面级指令，最后看内链和 sitemap 是否把蜘蛛引向了不该优先抓的地址。
变更要留痕
抓取指令的修改，最好和发布流程绑定：谁改的、改了什么、为什么改、什么时间生效。尤其是涉及整站或大目录的规则，变更后应在一段时间内观察日志和抓取数据，确认没有产生新的阻塞。不要把 robots.txt 当成一次性的上线配置，它更像站点运营中的基础设施，需要随着栏目调整、目录迁移和测试环境变化一起维护。
抓取指令的目标不是“让蜘蛛少来”，而是让该抓的页面顺利进入，不该抓的地址有明确边界。定期自查，比事后猜测更省成本。