robots.txt 是放在网站根目录的一份纯文本文件,通过与搜索引擎爬虫约定“哪些能抓、哪些不能抓”,来引导爬虫把有限的抓取配额集中到关键页面上。配置正确,能明显提升新内容的收录速度;配置失误,则可能导致重要页面迟迟不被抓取,甚至无意中把整站拒之门外。只有把它的运行规则和常见误操作弄清楚,才能让这份文件真正为 SEO 目标服务。
必须首先明确,robots.txt 对爬虫来说只是一种“君子协定”,并不具备强制力。任何网络访客都可以在浏览器中输入“你的域名/robots.txt”直接查看文件全部内容。可以把它理解成一张园区示意图,标明了哪些区域欢迎参观,但存放核心数据或后台管理系统的区域,绝不能依赖这张图来防护。
这份文件只控制爬虫是否发出抓取请求,而一个页面最终是否进入搜索结果,并不完全由它决定。举例来说,某页面在 robots.txt 中被设置为禁止抓取,但若它拥有大量高质量外链,搜索引擎依然有可能把它加入索引,只是展示的快照可能来自缓存或页面描述。
同时要特别留意,协议的遵守完全取决于爬虫的自律。主流搜索引擎的蜘蛛一般都会执行约定,但市场上大量采集工具和恶意爬虫根本无视规则。凡是涉及用户隐私、订单支付、登录后台等敏感路径,务必配合登录验证、IP 白名单或防火墙等硬性防护措施,不要把全部安全指望都押在这份“君子协定”上。
robots.txt 的内容由多个规则块组成,每个块必须以 User-agent 行开头,用于声明该组规则的作用对象。所有指令都遵循“名称: 值”的格式,冒号必须使用英文半角符号,建议冒号后保留一个空格。虽然多数爬虫对空格和大小写有一定的容忍度,但养成规范书写习惯,能避免后续解析时出现难以排查的怪问题。
这一行决定了规则块的适用范围。若只想约束谷歌搜索蜘蛛,应写 User-agent: Googlebot;若希望所有搜索引擎一视同仁,则用通配符写 User-agent: *。通过拆分多个规则块,可以实现差异化策略,例如对谷歌完全放开,同时对必应施加更严格的抓取限制,从而优化不同来源的抓取效率。
Disallow 用于声明禁止访问的路径,Allow 则用于声明允许访问的路径,二者通常是搭配使用的。容易被忽略的是:当 Disallow 后面留空不填时,表示解除全部限制,爬虫可以自由抓取全站内容。当某条 URL 同时命中多条规则时,各搜索引擎普遍遵循“最长匹配优先”原则——路径写得越具体,优先级就越高。例如同时存在 Disallow: /api/ 和 Allow: /api/public/ 两条规则,由于后者匹配的路径更长、更详细,public 子目录下的内容会被正常放行。
Sitemap 指令用于声明站点地图的完整网址,帮助爬虫快速了解全站内容结构,通常置于文件末尾。Crawl-delay 指令则用于设定爬虫两次抓取之间的等待秒数,但要注意谷歌蜘蛛并不识别该参数,其抓取频率由自身算法决定。因此这条指令需谨慎使用,以免不必要地拖慢其他搜索引擎的抓取效率。
实际操作中,许多问题源于对语法细节的疏忽。以下几类错误最为多见,值得逐条对照自查。
文件路径区分大小写,比如 Disallow: /Photo/ 只阻止 /Photo/ 目录,而无法阻止 /photo/ 目录。配置前务必逐一核对服务器上的真实路径,必要时同一条路径的大小写变体都可以加上,避免因疏漏造成该封的没封住。
虽然部分搜索引擎支持 * 作为通配符,但各家的解析规则并不一致。为了跨引擎兼容性,建议优先使用明确的前缀路径,而不是依赖通配符表达复杂规则。特别是 $ 符号用于匹配路径结尾时,极易引发理解偏差,应避免在核心规则中使用。
Disallow: / 表示禁止抓取整站,这是全站封闭的写法;而 User-agent 行下方不写任何 Disallow 则等于全站开放。很多新手容易混淆“不写”和“写 /”的效果差异,一旦误写全站禁止,排查时往往要花较长时间才能发现。建议在文件关键位置添加注释,明确每个规则块的意图,便于后期维护。
下面给出一个典型的配置结构,供参考对照:
不能完全阻止。它只能阻止爬虫发出抓取请求,但若页面已有大量外部链接,搜索引擎依然可能将其收录进索引,只是展示的快照可能来自缓存。若想彻底阻止收录,应使用 noindex 标签配合 robots.txt 双重设置。
没有固定时间,爬虫再次访问并抓取该文件后即生效。一般情况下,主流搜索引擎会在几小时到几天内重新抓取。若急需生效,可以通过搜索引擎的站长工具主动提交更新后的 robots.txt 地址,以加速抓取。
不可以。按照协议标准,robots.txt 只能放在网站根目录的根路径下,例如 https://www.example.com/robots.txt,子目录中的同名文件不会被识别。若使用子域名,每个子域名需单独放置自己的 robots.txt 文件。
robots.txt 的配置看似简单,实则处处是细节。建议先明确划分站内敏感区域与可公开区域,再按规则块逐一书写,并严格遵循“最长匹配优先”的逻辑设计 Allow 与 Disallow 组合。每次变更后务必用工具验证并保留变更记录,同时牢记它只是引导协议,后台与用户数据的安全仍需依赖技术防护措施。