robots.txt，怎样与开发人员交接问题：一份可执行清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /ac9cf8ce4332.html
📄
robots.txt，怎样与开发人员交接问题：一份可执行清单
交接 robots.txt 问题时，最有效的做法不是口头说“抓取有问题”，而是把现象、证据、期望行为和验证方式写成一份开发能直接执行的任务单。下面清单按“要查什么、怎么查、结果说明什么”组织，可直接复制到工单或协作文档里逐项填写。
先确认问题归属：抓取限制还是索引问题
要查什么：先判断问题出在抓取层还是索引层。怎么查：用搜索引擎的抓取测试工具或日志分析，查看目标 URL 返回的是 200、403、404 还是被 robots.txt 拦截；再在搜索结果里确认该 URL 是否已收录。结果说明什么：如果抓取被拦截，属于 robots.txt 配置问题，交给开发改规则；如果抓取正常但未收录，属于索引或质量判断问题，不应让开发去改 robots.txt。关键点：robots.txt 的抓取限制不等于可靠的索引移除，它能阻止抓取，但已收录页面可能仍会出现在结果中，移除需要另外的机制。
交接单必填：具体路径、规则与生效范围
要查什么：明确 robots.txt 里哪几条规则影响了哪些路径。怎么查：打开 https://站点域名/robots.txt，逐行核对 User-agent、Disallow、Allow 和 Sitemap 指令。结果说明什么：确认被拦截的是目录、单个文件还是带参数的 URL。交接时不要写“首页抓不到”，要写成“Disallow: /search 导致 /search?q=xxx 全部无法抓取”，并注明该规则是有意保留还是误加。如果规则来自模板或 CDN 配置，还要让开发说明生成位置，避免下次部署被覆盖。
用可复现的验证步骤替代“我这边看不了”
要查什么：让开发能自己复现问题。怎么查：提供三条以上具体 URL、期望的抓取结果、实际返回状态码，以及使用的测试方式（如抓取测试工具或命令行请求）。结果说明什么：如果开发按步骤能复现，说明问题定位清楚；如果复现结果不同，可能是环境、缓存或 CDN 差异，需要补充请求头、IP 或时间点。这一步能显著减少“在我机器上是好的”这类返工。
区分不同搜索引擎的支持情况
要查什么：确认问题是否只出现在某一个搜索引擎。怎么查：分别用不同搜索引擎的抓取测试工具或日志验证同一 URL，记录各自结果。结果说明什么：不同搜索引擎对 robots.txt 指令的支持范围并不一致，某些扩展指令可能被部分引擎忽略。交接时要写明“在 A 引擎被拦截、在 B 引擎可抓取”，而不是笼统说“搜索引擎抓不到”。站点地图不保证收录，所以不要把它当作收录问题的解决方案写进交接单。
交接前自检与下一步
- 路径是否具体到文件和参数，而不是整个站点。
- 是否说明了规则来源（手写、模板、CDN、框架生成）。
- 是否附上可复现的 URL 和期望结果。
- 是否区分了抓取限制与索引移除，没有把两者混为一谈。
- 是否注明涉及哪些搜索引擎，以及各自验证结果。
下一步：把以上内容整理成一条工单，指定开发负责人和验证人，改完后由提出方按同一组 URL 重新测试，确认抓取状态与预期一致再关闭。
