robots.txt写法_哪些常见误解会导致误操作
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dfe187320cd9.html
📄
robots.txt写法_哪些常见误解会导致误操作
最常见的误操作来自把 robots.txt 当成“删除网页”或“控制收录”的总开关。它实际只表达一件事：告诉遵守该协议的爬虫，哪些路径不要抓取。抓不到不等于已收录页面会消失，也不等于页面一定不会出现在搜索结果里。多人协作时，最容易出问题的不是语法，而是对这条边界的理解不一致。
假设场景：一次把测试目录写进正式文件
假设某团队上线新站，开发在正式 robots.txt 中写了 Disallow: /tmp/，本意是屏蔽临时目录。后来运营把活动页放在 /tmp/spring/ 下并对外投放，爬虫按规则不抓取该路径，页面自然难以进入索引。这里的问题不是“搜索引擎不收录”，而是规则把可抓取范围切掉了。排查时应先确认该路径是否真的需要被抓，再决定保留、改写还是移除规则。
误解一：写了 Disallow 就等于页面被删除
Disallow 只限制抓取，不发出删除指令。已经被抓取并建立索引的网址，可能仍会出现在结果中，只是描述信息可能变旧或缺失。若目标是让页面从索引中消失，应使用页面级的不索引标记，或在确认可访问后提交移除请求。涉及具体搜索引擎时，需分别查看其官方说明，不能把一家平台的工具行为套到另一家。
误解二：Allow 和 Disallow 的顺序决定一切
不少写法把 Allow 放在 Disallow 后面，以为后写的规则会覆盖前面。实际判断通常按路径匹配的具体程度和规则组来处理，而不是简单按行号先后。协作交付时，建议把同一路径组的规则集中书写，并逐条标注用途。例如：
User-agent: *下的规则只对未单独声明的爬虫生效。- 针对特定爬虫的规则组应单独成段，不要和通配组混在一起。
- 每条规则后写一行注释，说明是临时屏蔽、历史遗留还是业务要求。
检查时可以用“路径 + 规则”的方式逐条核对，而不是只看文件整体是否报错。
误解三：站点地图写在 robots.txt 里就能保证收录
在 robots.txt 中声明站点地图，只是提供发现入口，不构成收录承诺。页面能否被索引，还取决于可访问性、内容质量、重复情况以及各搜索引擎自身的处理。若站点地图中的网址恰好被 Disallow 挡住，爬虫可能读到地址却无法抓取内容。交付前应同时检查两处：站点地图是否包含目标网址，目标网址是否被规则误伤。
误解四：HTTPS 或语法正确就代表安全无误
语法正确只说明文件能被解析，不代表规则符合业务意图。HTTPS 也不等于没有抓取或索引问题。多人协作时，建议把 robots.txt 纳入上线检查清单：确认正式环境与测试环境使用不同文件，确认没有把整站写成 Disallow: /，确认规则变更后有人复核。若无法确定某条规则的影响，可先在非正式环境验证，再决定是否发布。
可执行的交付检查步骤
- 列出本次要屏蔽和要放行的路径，写成对照表。
- 逐条检查规则是否误伤活动页、商品页、文章页等需要被抓取的内容。
- 确认站点地图中的网址没有被同一文件中的规则挡住。
- 由第二个人按对照表复核，重点看通配符和目录层级。
- 发布后记录变更时间和负责人，便于下次排查。
下一步，把你当前 robots.txt 中的每条规则后面补一句“这条规则是为了什么”，再让同事按这句话判断是否应该保留。
