robots.txt与服务器访问控制分别适用于哪些场景?

很多站长把这两个东西混着用，觉得反正都是“不让爬虫访问”，写在哪里不是写。这种理解恰恰是麻烦的开始。robots.txt和服务器访问控制在技术性质上完全是两回事：前者是一份公开的书面声明，告诉爬虫“我希望你不要来”，但它没有任何强制力;后者是一道实体的门，由服务器在请求到达时直接决定放行还是拒绝。分不清这两者的边界，轻则配置无效白忙一场，重则误封搜索引擎导致收录断崖式下跌，或者把本应被拦截的恶意流量放进来消耗资源。

robots.txt的本质：一份靠自觉执行的君子协定

robots.txt的定位需要先说清楚。它放在网站根目录下，用纯文本规则告诉爬虫哪些路径可以抓、哪些不要抓。Google的官方文档写得很直白：如果抓取某些内容会给服务器带来压力，比如无限加载的日历脚本或者搜索结果页，用robots.txt来限制是合适的。它适合处理的是那些“遵守规则的爬虫”和“你愿意与之沟通的对象”。

搜索引擎爬虫基本都会读robots.txt。Googlebot在访问网站前会先请求这个文件，按照里面的Disallow规则决定抓取范围。所以如果你的目的是告诉Google“别把搜索参数页当成正常页面收录”，或者让Bing知道“后台目录不用费劲爬了”，robots.txt是正确且首选的工具。它成本极低，改一行文本就能生效，而且不会对真实用户造成任何影响。

但它的局限同样明显。robots.txt只是一份请求，不是命令。恶意爬虫、漏洞扫描器、采集脚本根本不看这个文件，它们不会因为你在里面写了Disallow就停下。更隐蔽的一点是，robots.txt本身是公开可读的。你在里面写了不要抓取哪个目录，等于在告诉所有人“这个路径可能有点意思”，对于安全防护来说反而是帮倒忙。此外，Google明确提醒过，robots.txt的Disallow并不能保证页面不出现在搜索结果中，因为其他网站的外链仍然可能让Google判定其相关，正确的隐藏方式是使用noindex标记而不是robots.txt屏蔽。

服务器访问控制的本质：请求到达时直接决定生死

服务器访问控制是实打实的拦截。Nginx的deny指令、limit_req限流、基于User-Agent的403返回、甚至防火墙层的IP封禁，都属于这个范畴。它的特点是请求在到达应用逻辑之前就被处理掉了，要么被拒绝，要么被限速，要么被直接关闭连接，PHP和数据库完全不参与。

这个工具适用的场景和robots.txt有清晰的分界。当某个爬虫已经被确认在恶意消耗资源时，robots.txt对它无效，必须用服务器层面的拦截。有一个高校机构仓储的案例很典型：该站点使用DSpace系统，遭遇AI训练爬虫的大规模抓取，这些爬虫完全无视robots.txt中已有的规则，导致服务频繁不稳定。最终的解决方案是在Nginx层面做IP封禁和限速，同时在搜索页和浏览页上部署验证码，才把服务稳住。这个案例说明的问题是，当对方不打算跟你讲规矩时，写在纸上的规矩没有任何意义。

服务器访问控制也适合处理高频请求对资源的冲击。Nginx的limit_req模块可以按IP限制请求速率，超出的请求返回429状态码。对于那种单IP每秒几十次请求的采集脚本，限流比封禁更灵活，因为它不会一刀切地拒绝所有来自该IP的正常访问，而是在频率维度上做约束。但这里有一个需要留意的副作用：如果网站前面有CDN或者反向代理，日志里记录的IP是代理节点的地址，直接按这个IP限流会误伤所有经过该节点的用户。配置时需要正确处理X-Forwarded-For头，把限流键设在真实客户端IP上。

用错场景的代价

把robots.txt当访问控制用，最常见的后果是“写了等于没写”。你在robots.txt里禁止某个AI爬虫，它照来不误，服务器该扛的压力一点没少。更糟糕的情况是依赖robots.txt来阻止搜索引擎收录不该出现的页面，比如后台入口或者测试页面。Google的文档说得很清楚，Disallow只是阻止抓取，不阻止索引，如果其他网站链接了那个URL，它仍然可能出现在搜索结果里。

反过来，把服务器访问控制当robots.txt用，代价可能更大。有站长为了阻止搜索框生成的垃圾页面被收录，在robots.txt里加了Disallow，但同时又在一个专门的Googlebot规则段里写了别的内容。由于robots.txt的规则匹配逻辑是“最具体的用户代理优先”，Googlebot只读取了针对它的那个规则段，忽略了一般的Disallow规则，结果垃圾页面照样被索引。这个案例虽然不是直接的访问控制误用，但它揭示了一个共通的道理：不理解规则的执行层级和优先级，配置写得再多也可能起反效果。

另一个常见的误操作是在服务器层面用User-Agent字符串做一刀切拦截。把所有包含“bot”的UA都返回403，听起来很解气，但Googlebot、Bingbot、Baiduspider的UA里都带着bot这个词。百度官方的建议是，在做UA过滤时务必把Baiduspider加入白名单，否则蜘蛛被挡在门外，收录和排名会直接受影响。正确的做法是用map指令做精确匹配，而不是用正则模糊拦截。

一套务实的分层策略

把这两个工具放在一起看，合理的用法是分层，而不是二选一。第一层用robots.txt做沟通和声明，告诉守规矩的爬虫哪些路径不需要抓，比如搜索参数页、后台目录、临时文件目录。这一步成本最低，对搜索引擎友好，也符合Google官方推荐的用途。第二层用服务器日志做观察，看实际流量里哪些来源在越界。robots.txt声明过不该来的地方如果还有高频请求，那些来源就是需要处理的對象。第三层对确认越界的来源执行服务器层面的拦截，用Nginx的deny或limit_req处理，必要时配合CDN或WAF在边缘就挡掉。最后，对于搜索引擎的合法爬虫，在服务器层面做反向DNS验证，确保放行的是真正的Googlebot而不是改了UA的冒牌货。

总结来说，robots.txt适合做“告知”，服务器访问控制适合做“执行”。告知的对象是愿意配合的搜索引擎，执行的对象是不打算配合的自动化程序。把告知当执行用，等于把规矩写在纸上指望小偷自觉;把执行当告知用，则可能误伤本该放行的流量。两个工具各司其职，边界清晰了，配置才不会白做。

纵横云服务器租赁，欢迎随时联系，客服联系方式：QQ3494196421，手机微信19906048601。