调整 robots.txt 往往是站点运营里成本最低的一次「开关」，但很多改动之后，日志里看不出任何反应：新增的 Disallow 没有让抓取量下降，删掉的规则也没有让被挡住的目录重新被访问。原因不在于规则没生效，而在于 robots.txt 作用于抓取链路的入口，它的结果要经过读取、缓存、排队和调度几层延迟才会显现。
robots.txt 在抓取链路里的位置
蜘蛛在请求一个 URL 之前，需要先取得该主机的 robots.txt 并解析规则。这意味着它是一道前置判断：允许，URL 才可能进入抓取队列；不允许，请求根本不会发出。所以它影响的不是「抓取结果」，而是「抓取机会」。理解这一点，就能理解为什么改动后的表现总是滞后的。
收紧规则：加了 Disallow 之后会发生什么
已抓取的页面不会自动消失
Disallow 只阻止抓取，不负责移除。已经被抓取并建立索引的 URL，在规则生效后仍可能出现在搜索结果里，只是蜘蛛无法再读取内容。如果目标是让页面退出索引，robots.txt 并不是合适的工具，用 noindex 或者页面本身的其他处理更直接——但要注意，被 Disallow 的页面蜘蛛读不到 noindex 标签。
抓取量的下降是渐进的
日志里常见的表现是：改动当天几乎没变化，之后几天被屏蔽目录的请求逐步减少，同时蜘蛛把请求转移到仍然允许的路径上。如果站点整体抓取预算有限，这部分请求不一定会消失，可能只是换了落点。
放开规则：解除屏蔽后，蜘蛛什么时候回来
解除限制不会立刻带来抓取。被长期屏蔽的 URL 往往已经不在活跃队列里，需要重新被发现。可以按下面的顺序做：
- 确认 robots.txt 能被正常访问，返回 200，Content-Type 正确。
- 把需要恢复的 URL 放进 Sitemap，并保证从站内链接可以直接到达。
- 观察日志中该目录的请求是否出现，先看有没有被重新请求，再看抓取频率。
- 给出足够的时间窗口，通常以周为单位评估，不要只看一两天。
容易被忽略的几个细节
- 文件不可用时的差别：robots.txt 返回 404 通常按「允许全部」处理，而持续返回 5xx 可能让蜘蛛收紧甚至暂停抓取。迁移、发布或权限配置出错时，这种情况比规则本身更危险。
- 缓存：蜘蛛可能对 robots.txt 保留一段时间的缓存，改动不会每次都被立即读到，尤其在高频抓取的大站上。
- crawl-delay 的支持并不统一：写进去不等于会被遵守，用它来控制并发并不可靠，服务器端的限速更可控。
- 文件体积限制：robots.txt 有大小上限，规则过多时后面部分可能被忽略，长清单更适合交给 Sitemap。
- Sitemap 指令：可以在 robots.txt 里声明 Sitemap 地址，但它只是一种告知，不等于提交。
变更时的操作建议
把 robots.txt 的修改当成一次发布来对待，而不是随手编辑：
- 改之前保存一份当前版本，记录改动时间和内容。
- 用工具验证规则是否命中预期路径，特别是带参数和中文的 URL。
- 改之后在日志里按目录、状态码分组，对比前后几天的请求量。
- 如果只是想让某些页面少被抓，可以先调整内链和 Sitemap，而不是直接屏蔽。
robots.txt 决定的是「能不能来」，不是「来不来」和「留不留」。改动之后的空档期，往往比改动本身更需要被监控。
把规则变更与日志观察绑定在一起，才能看清一次改动影响的到底是抓取机会、抓取路径，还是仅仅是蜘蛛的请求分布。