robots.txt 文件配置全指南：语法规则与常见误区解析
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /d86b7674681f.html
📄
robots.txt 是一份存放在站点根目录的纯文本文件，它向搜索引擎爬虫声明哪些路径可以访问、哪些应被拒绝。一份配置合理的 robots.txt 可以避免服务器资源被无效抓取消耗，同时确保核心内容顺利进入索引库；而配置不当，则可能造成整站无法收录或关键页面被误屏蔽。本文围绕文件的创建位置、语法要点及典型错误展开，提供一份可直接落地的配置参考。
1. 创建位置与语法基础
文件名称必须严格使用小写的 robots.txt，并通过 FTP 或文件管理器放置在域名根目录下，例如 https://example.com/robots.txt 应能直接访问到。文件内容由若干条记录组成，每条记录之间以空行隔开，便于爬虫区分不同的规则组。单条记录内包含指令行，基本书写格式为“字段名: 值”，比如 Disallow: /private/。字段名对大小写不敏感，但路径值通常是区分大小写的。以 # 开头的行被视为注释，可独立成行或放在某条指令后方，用于说明规则意图。
每条记录的逻辑顺序是：先声明 User-agent 指定爬虫对象，再排列若干条 Disallow 或 Allow 指令。一个 User-agent 声明后可以跟随多条禁止或允许规则，它们共同作用于该爬虫。值得注意的是，尽管多数主流搜索引擎支持 Allow 指令去覆盖同长度的 Disallow 规则，但对于路径长度不同的情况，不同爬虫的裁决方式略有差别，因此在多搜索引擎环境下需要额外审慎。
2. 常用指令写法及实例
2.1 用户代理与禁止规则
最典型的用法是屏蔽所有爬虫抓取网站的任意内容，配置如下：
User-agent: *
Disallow: /
如果只打算封闭特定目录，例如后台和缓存目录，可以借助多条 Disallow 来实现：
User-agent: *
Disallow: /backend/
Disallow: /cache/
此处务必要留意目录末尾的斜杠。写成 /backend/ 仅匹配该目录及其内部页面；若写 /backend 而无斜杠，则会波及所有以 backend 字符开头的地址，如 /backend-test、/backend-api，从而误伤无辜内容。建议在配置后逐一访问测试 URL 进行验证。
2.2 许规则与优先级判断
当你希望封禁一个目录但例外放行其中的某个子目录时，可用 Allow 实现。例如允许爬虫进入博客下的专题栏目，同时拒绝博客其余部分：
User-agent: *
Disallow: /blog/
Allow: /blog/featured/
规则匹配的优先级可以这样把握：当两条规则所匹配的路径字符数相同时，Allow 优先于 Disallow；若路径长短不一，则以字符数更多、更具体的规则为准。据此，上述例子能够保证 /blog/featured/ 正常被抓取，而 /blog/ 下其他内容依旧被屏蔽。
2.3 分爬虫设置与站点地图声明
针对性不同的搜索引擎爬虫制定策略是常见的需求。比如希望 Google 完全抓取、而对 Bing 暂时关闭，可以这样组织语句：
User-agent: bingbot
Disallow: /
User-agent: Googlebot
Disallow:
此处 Disallow 后面留空即为允许全部抓取。此外，Sitemap 指令不属于任何用户代理组，通常置于文件末尾，用于告知搜索引擎站点地图的具体位置，其格式为 Sitemap: https://example.com/sitemap.xml。注意此指令不会被 robots.txt 的规则所拦截，但站点地图文件本身若被 Disallow 屏蔽，仍会影响搜索引擎获取索引信息。
3. 高频配置误区与规避要点
实际运维中，不少站点因细节疏忽引发抓取异常。以下是几类高频问题：
- 误用通配符：部分站长以为 * 可以代表任意路径，但实际上多数爬虫仅支持 $ 符号匹配结尾，盲目使用通配符可能造成规则失效。
- 忽略大小写差异：虽然字段名不区分大小写，但路径部分在大多数服务器上是区分大小写的。若实际目录为 /Admin/ 而规则写为 /admin/，则无法生效。
- 空行误用与缺失：记录之间缺少空行时，爬虫可能把后续的 User-agent 当成上一组规则的一部分，导致规则错乱。
- 将 robots.txt 用于敏感信息保护：该文件是公开可读的，任何人均可通过浏览器访问。若目录含有隐私数据，应通过服务器权限或应用层鉴权来保护，而非单纯依赖 robots 规则。
建议在每次修改完成后，使用搜索引擎官方的抓取测试工具核对规则的实际效果，并观察站点日志中爬虫的访问频次变化，以判断是否出现意外拦截。
4. 配置验证与持续维护
撰写好文件后，不应该立刻宣告完成。先通过浏览器直接访问该文件的 URL，检查内容是否正常展示且无 BOM 头或乱码。随后可以利用各大搜索平台提供的 robots 测试工具，输入某条页面 URL 进行模拟抓取，观察匹配结果是否符合预期。若发现某条页面被意外拦截，根据上文优先级逻辑回溯对应的 Allow 与 Disallow 组合，逐条修正。
另外，站点结构并非一成不变。新增栏目、调整路径或迁移目录时，均应同步检查 robots.txt 是否需要更新。建议将其纳入站点日常维护清单，每个季度至少复查一次，确保规则与当前内容架构保持同步。
5. 常见问题
5.1 robots.txt 能阻止搜索引擎收录敏感页面吗？
不能。robots.txt 只是抓取层面的约定，并不提供访问控制。它无法阻止搜索引擎将 URL 列入索引，也不能防止其他网站引用或访问该链接。对于需要真正保密的内容，必须采用登录鉴权或服务器端访问控制。
5.2 Disallow 留空和完全不写有什么区别？
Disallow 留空表示该爬虫可以抓取全部页面，与不写任何 Disallow 指令的效果类似。但两者的书写意图不同：留空语句通常用来显式表达“对某个特定爬虫完全开放”，而省略该字段则可能隐含规则未定义。为了维护时的可读性，建议显式写出留空的 Disallow。
5.3 如何判断某条 URL 最终是被允许还是被禁止？
最直接的方法是使用搜索引擎官方的 robots 测试工具输入该 URL，查看匹配结果。如果没有工具可用，可以人工核对：先找到与 URL 匹配的最长路径规则，若该规则是 Disallow 则被禁止，若是 Allow 则被允许；若长度相同，则按 Allow 优先处理。手工核对时务必带上末尾斜杠进行完整路径比较。
6. 总结
正确配置 robots.txt 并不复杂，关键在于把握语法细节与优先级逻辑。创作时建议从全站放行开始，逐步按需添加 Disallow 规则，并借助 Allow 处理例外。每次改动后，用测试工具验证并观察日志中的爬虫行为，避免因一条斜杠或大小写问题导致整站抓取异常。将这份文件纳入定期的站点巡检流程，能有效维持搜索流量的稳定。
