robots.txt规则，哪些常见误解会导致误操作
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3903236a2b26.html
📄
robots.txt规则，哪些常见误解会导致误操作
最常见的误操作是把robots.txt当成“删除网页”或“禁止收录”的总开关：它只表达抓取偏好，不保证页面从索引消失，也不保证搜索引擎一定遵守。真正要定位问题时，应先确认规则写的是什么、谁在抓、抓取结果如何，再决定改文件还是用其他移除手段。
先查：Disallow 是否被当成“删除指令”
要查的是文件里是否写了类似 Disallow: /private/，以及你是否期待这些页面从搜索结果中消失。查法：在浏览器打开 https://你的域名/robots.txt，逐行看路径和通配符。结果说明：如果只是屏蔽抓取，页面仍可能因外链、历史记录等原因出现在索引里；要移除索引，需要按具体搜索引擎提供的移除工具或页面级 noindex 处理，而且 noindex 页面必须允许抓取才能被读到。适用条件：你希望“不展示在搜索结果”而不是“不允许爬虫下载”。
再查：通配符和路径匹配是否被想当然
要查的是 *、$ 和目录结尾斜杠的写法。查法：把规则逐条对照实际 URL，例如 Disallow: /*.pdf$ 与 Disallow: /pdf 覆盖范围完全不同。结果说明：前者只挡以 .pdf 结尾的地址，后者会挡 /pdf 开头的整段路径；如果误写 Disallow: /，可能挡住全站抓取。适用条件：站点有动态参数、分页或文件下载目录时，必须用真实 URL 做匹配测试，而不是凭感觉判断。
还要查：User-agent 分组是否互相干扰
要查的是不同 User-agent 段之间是否空行分隔，以及某一段是否只写了部分规则。查法：把文件按空行切分成组，确认每组开头是 User-agent，组内规则只对该代理生效。结果说明：若把 User-agent: * 和 User-agent: Googlebot 写在同一组，规则归属会混乱；若只给某个代理写 Disallow，其他代理仍可能抓取。适用条件：你只针对特定爬虫做限制，或需要全站统一限制时，分组写法不同。
可执行清单：每项都给出判断结果
- 查文件可访问性：用浏览器或
curl -I请求/robots.txt，看返回状态。结果说明：返回 200 才能被读取；返回 404 通常视为无限制，返回 5xx 可能导致抓取暂时受限。 - 查是否误挡 CSS、JS：看规则是否包含
Disallow: /*.css或Disallow: /js/。结果说明：挡住渲染资源可能影响搜索引擎理解页面，但不等于页面一定不收录，需要结合抓取日志和渲染结果判断。 - 查站点地图声明：看是否写了
Sitemap:完整地址。结果说明：站点地图是发现 URL 的辅助线索，不保证收录；写错地址或返回错误状态会降低其参考价值。 - 查改前改后差异：保存旧文件，修改后对比规则变化。结果说明：如果只是放宽或收紧抓取，索引变化需要时间；若误操作挡住全站，应尽快恢复并观察抓取错误。
- 查是否用 robots.txt 处理敏感信息：看是否把后台、用户数据路径只靠
Disallow保护。结果说明：robots.txt 是公开文件，不能替代登录验证、权限控制或页面级 noindex。
一个短例子：误把“禁止抓取”当成“禁止收录”
假设某站把 /old-page/ 写进 Disallow，同时希望该页从搜索结果消失。结果可能是：爬虫不再抓取，但页面仍因历史索引或外链出现在结果里。正确顺序是：若页面可公开，先允许抓取并加 noindex；若页面必须隐藏，则用登录或权限控制，而不是只写 robots.txt。这个例子只说明规则边界，不表示任何固定生效时间。
下一步：用真实抓取结果验证，而不是只改文件
改完规则后，下一步是收集证据：查看服务器访问日志中目标爬虫的请求路径，确认它是否仍在抓取被挡目录；再在搜索结果中抽查目标 URL 是否仍出现。若抓取被挡但索引仍在，优先检查页面级 noindex 和移除工具；若抓取正常但未收录，则转向内容质量、内链和站点地图等方向，不要继续在 robots.txt 上反复加规则。
