robots.txt规则：检查前需要准备哪些信息
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /297c2df252d6.html
📄
robots.txt规则：检查前需要准备哪些信息
检查 robots.txt 规则前，至少要准备四类信息：站点使用的域名与协议、当前 robots.txt 的完整内容、需要放行或屏蔽的具体路径清单，以及各搜索引擎的抓取记录。缺少其中任何一项，都容易把“规则写错”和“抓取行为不符合预期”混在一起，导致多人协作时反复返工。最关键的一步是先确认 robots.txt 实际可访问且返回正常状态，再对照路径清单逐条核对，而不是先改文件。
准备域名、协议与文件位置
robots.txt 只对同一主机名和协议生效。检查前先写清楚本次要处理的是哪个主机名，例如 https://www.example.com 与 https://example.com 在抓取层面可能被当作不同来源。需要准备的信息包括：
- 目标主机名与协议，是否同时存在 http 与 https 版本。
- 是否存在多个子域，例如博客、商城、帮助中心各自独立。
- 文件是否放在该主机名的根目录，路径为
/robots.txt。 - 谁有权修改服务器根目录文件，以及发布流程是否需要审批。
这些信息决定了后续检查范围。如果只改了一个子域的规则，却期望另一个子域同步生效，就会产生协作误解。
整理当前规则与目标路径清单
把现有 robots.txt 的完整内容复制到共享文档，不要只截图片段。然后准备一份路径清单，标明每条路径希望被允许抓取还是禁止抓取，并写清原因。例如：
/search/结果页：希望禁止抓取，避免大量低价值页面被消耗抓取配额。/assets/静态资源：希望允许抓取，避免渲染检查时资源被拦截。/admin/后台路径：希望禁止抓取，但不应依赖它做安全防护。
清单要具体到目录或文件，不要只写“后台”“搜索页”这类模糊描述。多人协作时，路径清单就是验收依据：改完后逐条对照，能减少口头沟通造成的偏差。
区分抓取限制与索引移除
检查前要明确一个判断：robots.txt 的抓取限制不等于可靠的索引移除。如果某个 URL 已经被收录，仅靠禁止抓取通常不能保证它从搜索结果中消失，因为搜索引擎可能仍保留已有信息。需要移除索引时，应准备单独的移除需求与对应页面清单，而不是把它混进 robots.txt 规则里。站点地图也不保证收录，它只是提交候选 URL 的方式之一；HTTPS 同样不保证安全无漏洞或排名。把这些目标分开记录，能避免检查时用错工具。
实施与验证：先小范围再全量
准备完成后，按以下顺序执行：
- 在测试环境或副本中修改 robots.txt，保留修改前版本。
- 用浏览器直接访问目标主机名的
/robots.txt，确认返回内容与预期一致。 - 逐条核对路径清单，检查
Allow与Disallow的先后顺序和前缀匹配是否符合预期。 - 使用各搜索引擎提供的抓取测试工具分别核查，因为不同搜索引擎对规则的支持情况需要分别确认。
- 发布后再次访问线上文件，确认没有缓存或发布遗漏。
假设某团队要禁止抓取 /tmp/ 目录，但线上文件写成了 Disallow: /tmp。前者只匹配以 /tmp/ 开头的路径，后者还会匹配 /tmpfile 这类路径。这类差异必须在验证阶段用具体 URL 测试，而不是凭感觉判断。
维护与交付记录
每次修改后记录修改人、时间、变更内容和验证结果。维护时重点检查三类情况：新增目录是否被意外屏蔽、旧规则是否仍然必要、多个子域之间是否出现规则冲突。交付给协作者时，附上目标主机名、路径清单、修改前后文件、验证截图或日志，让对方能独立复核。这样即使人员变动，也能快速判断某条规则为什么存在。
下一步，先建立一份包含主机名、路径清单和验证记录的 robots.txt 变更表，再开始修改规则。
