robots.txt 是站点给爬虫的第一份约定。它不复杂，但影响范围很大：改错一行，可能让某个栏目长时间没有新的抓取记录。更麻烦的是，这类问题往往不会立刻报错，只能从抓取日志和收录变化里慢慢看出来。所以每次改动前后，都值得按下面几项过一遍。

一、先确认文件本身能被正常读取

• 用浏览器直接访问域名根目录下的 robots.txt，确认返回 200，而不是 404、403 或 5xx。文件不存在时爬虫会按默认放行处理，但这不代表可以放任不管。
• 不要用 301 或 302 把 robots.txt 跳到别处。部分爬虫对跳转的处理并不一致，规则可能被忽略。
• 返回的内容类型保持 text/plain，不要返回一个 HTML 页面。
• 注意大小写：在 Linux 环境下，robots.txt 与 Robots.txt 是两个不同路径，写错就无法被读取。
• 它只能放在域名根目录。子目录下的同名文件不会被当作主规则文件。

二、检查 Disallow 有没有误伤

大部分事故都出在这一步。常见情况包括：

• 写成 Disallow: /，本意是屏蔽测试目录，结果屏蔽了整站。
• 想屏蔽 /search，却因为前缀匹配，把 /search-guide 这类正常页面也一起挡掉。
• 用通配符时范围过大，例如把所有带问号的地址都排除，包括本该抓取的分页或规范后的地址。
• 规则末尾的匹配符号缺少或多余，导致命中范围和预期不一致。

判断时不要只看规则本身，最好把站内主要目录、栏目入口、详情页路径各挑几个，逐一对照是否会命中。规则条目越多，越需要这样核对。

三、别把 CSS、JS 和图片一起挡掉

如果站点依赖前端渲染，而 robots.txt 里屏蔽了 /assets、/static、/js 这类目录，爬虫拿到的页面可能是不完整的。现在主流搜索引擎会执行页面脚本，但前提是这些资源本身可抓取。

• 检查样式、脚本、字体、主要图片目录是否在 Disallow 列表里。
• 如果确实要限制部分资源，尽量缩小到具体文件，而不是整个目录。

四、看清爬虫分组的写法

robots.txt 支持按 User-agent 分组，不同爬虫可以有不同的规则。这里最容易出问题的两点：

1. 分组之间要用空行分隔，否则后面的规则可能被并入上一组。
2. User-agent: * 是通配分组，如果它下面写了 Disallow，其他没有单独声明的爬虫都会继承。

做抓取观察时，经常会看到不同 UA 的访问。建议把关键爬虫的规则单独列出，并记录每次调整的原因，方便后续对比抓取频次的变化。

五、robots.txt 不能替代 noindex

Disallow 的作用是阻止抓取，不是阻止索引。如果一个页面已经被其他站点链接，搜索引擎仍可能在没有抓取内容的情况下把它放进索引。想让页面不出现，更合适的方式是允许抓取、再用 noindex 标记。

反过来，如果一个页面已经加了 noindex，就不要同时在 robots.txt 里把它封掉。爬虫抓不到页面，也就看不到那行标记，结果可能适得其反。

六、顺手确认 Sitemap 声明

robots.txt 里通常可以写一行 Sitemap，指向站点地图地址。检查两点：地址是否可访问、是否与实际使用的 sitemap 一致。如果站点有多个地图文件，这里是补充发现入口的地方，但不要指望它替代正常的内链和栏目结构。

七、改动后的验证流程

1. 先在本地或测试环境写好规则，逐条对照目录列表核对。
2. 用搜索引擎官方提供的 robots 测试工具模拟抓取，确认目标地址是允许还是阻止。
3. 发布后再次访问 robots.txt，确认线上内容与预期一致，没有返回旧版本。
4. 观察一段时间内的抓取日志，看重点目录的抓取次数是否明显变化。
5. 把本次改动内容、时间、原因记录下来，方便下次排查。

robots.txt 平时很少被打开，但正因为如此，它的问题容易被忽略很久。把它当成一份需要定期核对的配置，而不是一次写完就不用管的文件，能减少很多后续排查的成本。