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

robots txt怎么写_用可复查的状态证据避免协作返工

要取得可复查的状态证据，关键不是把规则写得多复杂，而是让每一次 robots.txt 变更都留下“谁改了什么、依据是什么、改后如何验证”的记录。具体做法是：把 robots.txt 当作受版本控制的配置文件，每次修改前先抓取线上原文并留档，修改后分别验证语法、抓取行为和实际返回内容，最后把验证结果与变更说明一起归档。这样多人协作时，下一位接手者能直接看到当前状态和判断依据，而不是靠口头描述猜测。

准备阶段：先固定“改前状态”的证据

很多人直接打开编辑器改文件，改完就发布，结果出了问题无法判断是本次改动导致还是原本就存在。要避免这种情况，改动前应完成三件事。

• 抓取线上 robots.txt 原文并保存，记录抓取时间、完整内容、HTTP 状态码和响应头中的 Content-Type。这是后续对比的基线。
• 记录当前生效的规则及其意图，例如哪些目录被禁止、哪些爬虫被单独指定。意图要写成一句可判断的话，而不是“优化一下”。
• 确认文件位置和访问路径。robots.txt 只能放在站点根目录，子目录下的同名文件不会被当作站点级规则使用。

这一步的产出是一份基线快照。它让“改坏了”和“本来就这样”可以被区分开，是后续所有复查的前提。

实施阶段：写法要能被机器解析，也要能被人读懂

robots.txt 的基本结构是若干条记录，每条记录由 User-agent 开头，后跟若干 Allow 或 Disallow 规则。写法上有几个容易引发返工的点。

第一，User-agent 与规则之间不要插入其他记录，空行表示一条记录的结束。第二，Disallow 后面为空表示允许抓取全部，写成 Disallow: / 才是禁止全部。第三，路径区分大小写，/Admin 和 /admin 在多数实现中不是同一条规则。第四，注释用 # 开头，但注释不能写在规则值中间。第五，通配符和结尾匹配符号的支持程度因抓取方而异，使用前应针对目标抓取方分别核查，不要假设所有抓取方行为一致。

一个可执行的短例子如下，仅作语法示意，不代表任何真实站点：

User-agent: * Disallow: /tmp/ Allow: /tmp/public/

这段写法表达的是禁止抓取 /tmp/ 下内容，但放行其中的 /tmp/public/。要注意，更具体的 Allow 是否覆盖较宽的 Disallow，取决于抓取方对规则优先级的实现，因此这属于需要实测确认的项，不能凭直觉断言。

验证阶段：这是本题最关键的一步

验证要分层做，单看文件内容通过不算完成。

1. 语法检查：确认没有拼写错误的指令、没有缺失冒号、没有把注释写进规则值。语法错误可能导致整条规则被忽略。
2. 抓取测试：用目标抓取方提供的测试方式，分别请求一个应被禁止的 URL 和一个应被允许的 URL，记录返回结果。不同搜索引擎的测试入口和支持情况需要分别核查，不能用一个平台的结果推断另一个平台。
3. 线上内容比对：再次抓取线上 robots.txt，与准备阶段的基线逐行对比，确认实际发布的内容与预期一致，而不是只改了本地文件。
4. 状态码与响应头复核：确认返回 200 且内容类型合理。若返回 404，抓取方可能按“无限制”处理，这与“禁止抓取”是完全不同的结果。

把每一步的结果写成可复查的证据：时间、执行人、命令或操作方式、原始输出。判断标准是——另一个人不看聊天记录，只读这份证据，也能得出同样的结论。如果做不到，说明证据还不完整。

维护阶段：把证据和变更绑在一起

robots.txt 的限制只作用于抓取行为，它不等于可靠的索引移除。已经收录的页面不会因为新增一条 Disallow 就自动消失，这一点必须在交付说明里写清楚，否则容易产生错误预期。同理，站点地图提交不保证收录，HTTPS 也不保证安全无漏洞或排名提升，这些都不能当作 robots.txt 变更的替代手段。

维护时建议把每次变更做成一条记录，包含：变更原因、变更前后的完整内容、验证结果、生效时间、复查时间。若多人协作，规则中涉及具体抓取方的部分应注明依据来源。历史规则或已废弃的写法不要描述成当前仍然有效，需要时用当时的存档说明，并附上现在的核查方法。

下一步可以直接做一件事：把当前线上 robots.txt 抓取下来，连同这次验证的四项结果整理成一份变更记录，作为下一次修改的基线。这样每次改动都有对照，返工自然会减少。