robotstxt，怎样形成可复用检查清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /164fff483d08.html
📄
robotstxt，怎样形成可复用检查清单
把 robots.txt 检查做成可复用清单，核心是固定检查对象、固定取证方式、固定结论口径。清单不按“今天谁有空看什么”来写，而按“每次上线、改版、迁移时都必须确认哪些行、哪些路径、哪些环境”来写。每项至少包含三列：查什么、怎么查、结果说明什么。这样多人协作时，任何人拿同一份清单都能得到可复核的结论，减少口头交接和返工。
先固定清单的检查对象，不要从工具开始
可复用的前提是对象稳定。建议把 robots.txt 检查拆成五类固定对象：文件是否存在、语法是否可解析、规则是否匹配目标路径、抓取限制是否被误用为索引移除、线上与预发是否一致。每类对象写成独立条目，不混在一起。例如“文件是否存在”只回答能否在站点根目录取到；“规则是否匹配”只回答某条 User-agent 和 Disallow/Allow 组合对某路径的判定结果。对象固定后，换人执行也不会漏项。
每项都写清查什么、怎么查、结果说明什么
下面是一份可直接改用的清单骨架。示例中的路径和域名均为假设，仅用于说明写法。
- 查什么：根目录能否取到 robots.txt。
怎么查：用命令行请求
https://example.com/robots.txt，记录状态码和响应体前若干行。 结果说明什么：状态码 200 且返回文本，说明文件可被读取；404 说明该地址没有文件；403 或 5xx 说明访问被拦截或服务异常，需要先解决再谈规则。 - 查什么：语法是否可解析。 怎么查：逐行检查是否只有允许的字段，如 User-agent、Disallow、Allow、Sitemap；检查是否误写通配符、正则或注释位置错误。 结果说明什么：无法解析的行可能被忽略，导致实际抓取行为与预期不同。这里只能判断“可能被忽略”，不能仅凭一行就断定某搜索引擎一定如何处理。
- 查什么：目标路径是否被规则命中。
怎么查：列出本次要保护的路径，如
/admin/、/search/，再对照对应 User-agent 段的最长匹配规则。 结果说明什么：命中 Disallow 表示抓取被限制；未命中表示可被抓取。注意 Allow 与 Disallow 同时存在时，要按具体实现的最长匹配判断，不要只看行序。 - 查什么：是否把抓取限制当成索引移除。 怎么查：确认目标 URL 是否已被索引、是否还需要 noindex 或移除请求。 结果说明什么：robots.txt 只限制抓取，不保证页面从索引消失。若页面已被索引，仅加 Disallow 可能让搜索引擎无法读取 noindex，反而延长处理周期。
- 查什么：Sitemap 是否被正确引用。 怎么查：检查 Sitemap 行是否为完整绝对地址，并实际请求该地址确认可访问。 结果说明什么：引用正确只说明发现了站点地图，不保证收录。收录还取决于内容质量、链接和抓取预算等因素。
- 查什么：线上与预发是否一致。 怎么查：分别请求两个环境的 robots.txt，对比 User-agent 段和 Disallow 路径。 结果说明什么：不一致时，要判断是环境差异还是发布遗漏。若预发禁止抓取、线上也禁止抓取，说明发布流程可能把测试规则带到了生产。
用一份结果记录表固定结论口径
清单要可复用，结果记录必须能横向比较。建议每次检查输出一张表，列为：检查项、环境、请求地址、状态码、关键行、判定、负责人、日期。判定只允许写“通过”“不通过”“待确认”三种，避免“应该没问题”这类模糊结论。待确认项必须写明还缺什么证据，例如需要确认某搜索引擎是否支持 Allow、需要确认 CDN 是否缓存了旧文件。这样下次复查时，能直接看出是规则变了还是环境变了。
多人协作时的执行与复查条件
清单适合在以下条件使用：有明确的站点根目录、有可访问的测试环境、改动 robots.txt 需要走发布流程。若站点由多个子域或 CDN 节点组成，每个子域应单独建一行，不能只查主域。复查时优先看三类高风险改动：新增 Disallow 根路径、修改 User-agent 段、替换 Sitemap 地址。任何一项不通过，先不要合并发布，先补齐证据再判断。若只是新增一条 Allow，且不影响既有 Disallow 的最长匹配，可按低风险流程处理，但仍要记录请求结果。
下一步：把上面清单复制到团队文档，先对当前线上 robots.txt 跑一遍，把每个“待确认”项补上请求记录和判定人，再把它设为下次改版前的必过检查。
