robots txt，怎样形成可复用检查清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a2dc2f9e524a.html
📄
robots txt，怎样形成可复用检查清单
把 robots txt 检查做成可复用清单，核心是从交付结果倒推：先明确“要证明什么”，再列出必须收集的资料、必须执行的任务、每项任务的责任人，以及可判定的验收标准。一份合格的清单应当让不同的人在相同站点上得到一致结论，而不是依赖个人记忆。
先确定交付结果：三份可核对的证据
检查 robots txt 通常不是为了“看一眼文件”，而是为了回答某个具体问题，例如：某目录是否被禁止抓取、规则是否误伤整站、线上文件与预期版本是否一致。对应的交付结果可以固定为三份证据。
- 规则原文：目标路径下 robots txt 的实际内容，含 User-agent、Allow、Disallow、Sitemap 等行。
- 抓取结果：用搜索引擎官方抓取测试工具或命令行请求该文件后得到的 HTTP 状态码与响应体。
- 影响范围说明：哪些目录或参数被覆盖，哪些未被覆盖，以及本次结论能支持什么、不能支持什么。
这三份证据决定了清单的最小结构：资料项、执行项、验收项。缺少任何一份，结论都只能算推测。
资料清单：检查前必须拿到的东西
资料不全时，最容易把“可能原因”写成“已经定位的原因”。建议在清单开头固定以下收集项，并标注来源与获取时间。
- 目标站点的完整域名与协议，例如
https://example.com，用于拼接 robots txt 的请求地址。 - 当前线上 robots txt 的原始文本，保留换行与大小写，不要手动重排。
- 代码仓库或 CMS 中对应的源文件，用于与线上版本比对。
- 站点主要目录结构清单，至少覆盖需要判断的几层路径。
- 已知的抓取异常现象描述，例如“某目录页面长期不出现”，并注明观察时间。
如果站点使用多域名或多环境，资料项要按环境分别收集。测试环境的 robots txt 不能代表生产环境，反之亦然。
执行清单：从请求到逐行判定
执行部分建议写成可勾选步骤，每一步都给出判断依据，而不是只写动作。
- 请求目标文件，记录 HTTP 状态码。200 表示可读取；404 表示文件不存在；5xx 表示服务端异常。状态码不同，后续结论完全不同。
- 核对响应内容是否与源文件一致。若不一致，可能原因包括缓存、CDN 分发、构建流程覆盖或人工改动，需要逐项排查，不要直接断定是某一环节。
- 逐行读取规则，按 User-agent 分组。确认通配符
*与具体爬虫名称的优先级关系，并注意 Allow 与 Disallow 同时存在时的最长匹配判断。 - 检查是否存在误封整站的写法，例如对
/的 Disallow。若存在，先确认是否为有意设置。 - 检查 Sitemap 行指向的地址是否可访问，并明确它只是辅助发现，不保证收录。
- 检查是否把 robots txt 当成移除索引的手段。抓取限制与索引移除是两件事，禁止抓取不等于页面会从结果中消失。
一个简短的假设例子：若线上文件包含 Disallow: /，而源文件没有，则说明线上与预期不一致。此时结论应写成“线上规则禁止全部抓取”，而不是“页面被搜索引擎删除”。前者是已定位的事实，后者需要额外证据。
责任与验收：让清单可交接
可复用的关键是每项任务都有归属和通过条件。可以在清单中增加三列：责任人、完成时间、验收标准。
- 责任人：资料收集、线上请求、源文件比对、结论撰写分别指定，避免全部压在一人身上。
- 验收标准：例如“线上与源文件逐行一致”“状态码为 200”“受影响路径已列出并注明依据”。
- 复核方式：由未参与执行的人按同一清单重跑一次，若结论一致则视为通过。
验收时要区分支持范围：本清单能证明规则内容与抓取可达性，不能证明收录、排名或流量变化。涉及不同搜索引擎时，需分别核查各自对规则的支持情况，不能用一个平台的结果代替另一个。
下一步：把清单落到一次真实检查
选一个当前有疑问的路径，按上面的资料项、执行项、验收项完整跑一遍，把实际结果填回清单。跑完后若发现某项资料总是缺失或某个判断反复出现分歧，就把该项拆成更细的检查点。经过两三次真实使用后，这份 robots txt 检查清单才会稳定下来，成为团队可直接交接的工具。
