robots.txt 是放在站点根目录下的一份纯文本文件，用来告诉爬虫哪些路径可以抓、哪些路径不必抓。它既不是收录开关，也不是访问密码，只是抓取层面的一种约定。很多站点回头排查抓取异常，问题往往就出在这份被遗忘的小文件上。
一、先确认文件位置和访问状态
文件必须放在域名根目录，例如 https://example.com/robots.txt，放在子目录里的同名文件不会被识别。用浏览器直接访问这个地址，确认返回 200，且内容是一段纯文本。如果返回 404，说明文件缺失或路径写错；如果返回 403 或 5xx，可能是服务器权限、防火墙或重写规则把它挡住了，需要先把访问问题解决，再谈规则内容。
另外留意返回的 Content-Type，个别环境会把它当成下载文件或重定向到别的页面，爬虫拿到的就不是规则本身。
二、分清 Disallow 与 Allow 的边界
常见误区是写完 Disallow 就以为页面不会再出现在搜索结果里。实际上，禁止抓取不等于禁止索引，如果被禁止的地址有外部链接指向，仍可能以无描述的形式出现。真正想控制收录要靠 noindex，但要注意：被 robots.txt 禁止抓取的页面，爬虫读不到页面里的 noindex，效果会打折扣。这两者要配合使用，而不是互相替代。
几个高频翻车点
- 整站写成 Disallow: /，本意是测试环境用，上线后忘了改回来。
- 目录名写错一个字母，比如实际是 /temp 却写成 /tmp，规则没覆盖到目标路径。
- 使用通配符或结尾符号时，没确认目标爬虫是否支持同样的语法。
- 顺手屏蔽了 CSS、JS 目录，导致爬虫渲染页面时看不到完整内容。
- 把分页、筛选参数一并屏蔽，结果列表页后续内容长期没有入口被发现。
三、按爬虫分别写规则
可以针对不同 UA 写不同的 User-agent 段。如果只想给某个爬虫单独限制，就为它单独开一段；如果规则对所有爬虫都适用，用 User-agent: *。段落之间记得留空行，避免把下一段的 User-agent 当成上一条规则的延续。多数爬虫以匹配到的那一段为准，写混了容易出现意想不到的结果。
四、用工具和日志验证，别靠肉眼
各家站长平台一般都有 robots.txt 测试工具，输入具体 URL 就能看到是被允许还是被拦截，改完规则顺手测几个关键地址。同时可以在服务器日志里搜索该文件的请求记录，看爬虫是否成功读取、返回什么状态码。如果日志里长期没有对 robots.txt 的请求，可能是服务器把它重定向了，或者返回了非文本类型，爬虫读到的是空内容。
五、把维护纳入日常
站点改版、栏目调整、目录迁移之后，robots.txt 很容易和现状脱节。建议把它列入改版检查清单，逐条对一遍：
- 新增目录是否需要放行；
- 废弃目录是否应该屏蔽；
- 被屏蔽的路径是否还有内链指过去；
- 规则是否与 noindex、canonical 的安排冲突。
改动前先备份原文件，改动后观察一段时间的抓取日志，确认没有出现大范围抓取量下降。规则越简单清晰，出问题时越容易定位。
robots.txt 是抓取入口的规则说明，不是收录开关。写清楚、定期对一遍，比反复猜蜘蛛为什么不来的更省事。