robots.txt写法：测试工具能访问而实际用户失败时怎样复现条件

📍 WDQWDWQD987AAAAA:216.73.216.56
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /35fd6874973f.html
📄

robots.txt写法：测试工具能访问而实际用户失败时怎样复现条件

先给结论：测试工具能访问、真实用户失败，通常不是规则本身写错，而是你复现时漏掉了真实请求携带的某个条件。最常见的是请求路径的规范化差异、User-Agent 分支、协议或主机名不一致，以及 CDN 或缓存层在中间做了改写。要做的不是继续改规则，而是先把真实失败请求的完整条件抓下来，再在受控环境里逐项还原。下面按“保留、改写、退出”三种取舍展开，说明各自成立的前提。

先判断该保留规则、改写规则还是退出这轮排查

三种取舍对应三种不同的证据状态，选错方向会让排查无限延长。

判断依据是：先看真实失败请求的响应状态和响应头，再看它是否与测试工具发出的请求落在同一条规则上。两者不一致，才说明是复现条件缺失。

复现条件里最容易被漏掉的四类差异

测试工具往往做了“善意简化”，而真实用户请求保留了原始形态。逐项核对以下四点，通常能定位遗漏条件。

路径规范化差异

robots.txt 的路径匹配是区分大小写的，且按前缀比较，不做自动解码或去斜杠。测试工具可能自动把 /Private/ 转成 /private/ 再请求，于是匹配不上你的规则，显示“可访问”；真实用户输入的原始路径则原样命中 Disallow。要复现，就把真实请求里的路径字符串原封不动复制出来，包括百分号编码。

User-Agent 分支

如果你写了针对特定爬虫的 User-agent 分组，测试工具可能用默认 UA 去匹配通配组，得出与真实爬虫不同的结论。复现时需要把真实请求的完整 UA 字符串带进去，而不是只填一个工具名。

协议与主机名

robots.txt 只对同一主机、同一协议下的路径生效。测试工具访问的是 https://www.example.com/robots.txt，而真实用户请求落在 http://example.com/，两者读取的可能是不同文件或不同缓存副本。核对时以真实请求的 scheme 和 host 为准。

中间层改写

CDN、反向代理或缓存可能对特定 UA、特定路径做重写或直接返回缓存结果。测试工具直连源站时看不到这层。复现方法是从真实用户所在网络路径发起请求，或至少在请求头里带上与真实用户一致的字段。

一个注明假设的短例子

假设你的规则是 Disallow: /search，测试工具请求 /search?q=test 显示被拦，符合预期；但真实用户访问 /Search?q=test 却能打开页面。这里的差异只有首字母大小写。测试工具在发送前做了小写化，所以匹配到了规则；真实请求保留了大写，前缀比较失败，规则不生效。动作是补一条 Disallow: /Search，或把规则改成能覆盖两种写法的形式。改完后，下一步不是立刻宣布修复，而是用真实请求的原始路径再验证一次，确认响应从“可访问”变为“被拦”。这个结果才决定你要不要继续排查其他路径变体。

复现之后怎样验证，避免假阳性

把真实条件还原后，验证要盯住请求本身，而不是工具给的结论标签。

  1. 记录真实失败请求的完整 URL、UA、scheme、host 和响应状态。
  2. 在受控环境里用同样这组条件发起请求，对比响应是否一致。
  3. 如果一致，说明找到了遗漏条件，再决定保留还是改写规则。
  4. 如果不一致，说明还有第二层差异（例如缓存、地域节点），继续收窄。

需要提醒的是：抓取被拦不等于页面从索引中移除，两者是不同机制。测试工具显示“被拦”只说明抓取路径受限，不能据此推断搜索结果里的表现。另外，站点地图提交不保证收录，HTTPS 也不保证页面安全或排名，这些都不能作为复现成功的判断依据。不同搜索引擎对 robots.txt 的支持范围和读取时机需要分别核查，不要用一次测试结果套用到所有引擎。

什么时候应该退出这轮排查

如果真实请求的响应状态是 5xx、403 或跳转到登录页，且与 robots.txt 规则无关，就应停止调规则。这类失败属于访问控制或服务端问题，继续改 robots.txt 不会改变结果，只会掩盖真正原因。退出的前提是你已经确认失败请求没有命中任何 Disallow 规则，且测试工具与真实请求在同一 host 和 scheme 下结论一致。此时把精力转向服务器日志和权限配置，才是下一步该做的动作。

图1 图2
nginx