robots.txt 规则写法与实操避坑指南
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /17ed5903a88c.html
📄
robots.txt 是放在站点根目录下的一个纯文本文件，它的职责是与搜索引擎爬虫对话，告诉它们站内哪些区域可以抓取、哪些区域应当绕开。对于做 SEO 的人来说，它是控制抓取预算、保护敏感目录的基础工具。写对了，爬虫会把精力集中在优质页面上；写错了，轻则规则失效，重则误伤整站收录。
1. 理解指令块：从语法基础到匹配逻辑
一个完整的 robots.txt 由若干组指令块组成，每组指令块以 User-agent 开头，用来声明规则作用的对象。星号（*）表示匹配所有爬虫；如果你只想限制某一家，就写上对应的爬虫名称，比如 Googlebot 或 Baiduspider。
在指令组内，主要通过三个字段划定边界：
- Disallow：指明禁止抓取的路径或文件。例如 Disallow: /admin/ 表示整个 admin 目录都不允许访问。
- Allow：在禁止的大范围内，单独放行某个子路径。同一路径下，Allow 的优先级高于 Disallow，这是白名单逻辑，需要牢记。
- Sitemap：列出 sitemap 的绝对地址，帮助爬虫快速定位你的内容清单。
一个常见的写法示例如下：
User-agent: *
Disallow: /private/
Allow: /private/public/
Sitemap: https://www.example.com/sitemap.xml
书写时必须注意两点：一是路径区分大小写，/Admin/ 与 /admin/ 是两个完全不同的入口；二是所有符号必须用半角英文标点，全角冒号或空格都会让整行规则直接作废。
2. 按场景设计规则：从全站屏蔽到精细放行
不同的运营阶段和站点结构，对 robots.txt 的要求完全不同。以下按常见需求列举几类配置思路，你可根据现状直接套改。
2.1 全站禁止抓取，用于调试或临时维护
新站上线前调试，或站点需要临时维护时，屏蔽全站是稳妥选择。需要提醒的是，这只能阻止后续抓取，对搜索引擎已有的旧快照没有清理作用。要删除旧收录，仍需去站长平台提交索引清理。
User-agent: *
Disallow: /
2.2 全站开放，适合内容完全公开的站点
如果没有任何需要隐藏的资源，配置越简单越好。此时只需声明 Sitemap，不需要写 Disallow，让爬虫自由遍历全站。
User-agent: *
Allow: /
Sitemap: https://www.example.com/sitemap.xml
2.3 隐藏后台目录与用户敏感页面
企业站和内容站通常需要屏蔽后台登录页、会员中心以及临时上传目录，避免这些入口被搜索引擎收录，从而降低被针对扫描的风险。注意，这类操作只是增加一层防护，真正的权限控制仍要依靠程序层面的鉴权。
User-agent: *
Disallow: /admin/
Disallow: /user/
Disallow: /temp/
2.4 只拦不速之客，放行主要搜索引擎
有些爬虫会带来大量无效请求，挤占服务器资源。这时可以在不同的指令组里分别设置规则。
User-agent: SomeSpider
Disallow: /
User-agent: *
Allow: /
Sitemap: https://www.example.com/sitemap.xml
实际测试时要注意，规则匹配是按最长前缀执行的，且指令块之间自上而下生效，因此把特定爬虫放在前面更安全。
3. 常见误区与避险建议
robots.txt 的错误配置往往不会立刻暴露问题，但后续影响很难收场。以下几个坑值得留意：
- 误把 Disallow 当作删除手段：它只阻止抓取，不清除索引，处理旧收录必须走站长工具。
- 使用绝对 URL 写 Disallow：语法只接受路径部分，写成 Disallow: https://example.com/admin/ 会直接失效。
- 忽略了大小写与转义字符：路径中的特殊字符尽量保持原样，不确定时宁可不写也不要乱写。
- 文件编码错误：保存时务必使用 UTF-8 无 BOM 格式，某些编辑器默认的 BOM 头会让首行规则失效。
建议上线前在浏览器中直接访问 https://你的域名/robots.txt，确认内容展示无误；还可以借助搜索引擎官方的 robots 测试工具，检查每条规则的实际匹配效果。
4. 版本管理与验证流程
将 robots.txt 纳入版本管理是容易被忽略的细节。它和代码一样会迭代，建议放入 Git 仓库，并在每次改动后记录变更原因。团队协作时，约定好修改审批流程，避免多人同时改动导致规则冲突。
验证流程可以这样推进：先在测试环境模拟站点结构并配置相应规则，用爬虫模拟工具逐一检查核心 URL 的抓取权限；确认无误后再部署到线上，并持续观察服务器日志中爬虫请求的变化。若发现某个重要页面流量骤降，第一时间反查 robots 是否误伤了该路径。
5. 常见问题
5.1 Q1：robots.txt 文件必须放在网站根目录吗？
是的。搜索引擎只会去域名根路径寻找该文件，例如 https://www.example.com/robots.txt。放在其他目录下不会被识别。如果站点通过多级子目录部署，每个独立域名或子域都需要各自的 robots.txt，互不共享。
5.2 Q2：Allow 和 Disallow 同时存在时，到底听谁的？
在路径长度相同的前提下，Allow 的优先级更高。但更关键的是匹配规则：爬虫会按最长匹配前缀来判断。比如 Disallow: /a/ 和 Allow: /a/b/，那么 /a/b/file.html 被允许，而 /a/c/file.html 被禁止。理解这一点才能精确控制边界。
5.3 Q3：修改 robots.txt 后，需要多久才能看到效果？
没有固定时间表。爬虫会定期重新抓取该文件，短则数小时，长则数天，取决于搜索引擎的抓取频率。你可以主动在站长平台提交更新或申请快速抓取，来加速新规则的生效。
6. 总结
robots.txt 是一把双刃剑：用好了能引导爬虫聚焦核心页面、保护敏感资源；用错了则可能造成整站收录异常。写规则时务必保持简单明确，遵循半角字符、大小写敏感、最长匹配这几个基本原则。上线前多做验证，改动后持续观察数据，比追求完美规则更重要。建议每季度复查一次文件内容，及时清理过时的路径设定。
