robots.txt完全指南：从语法解析到爬虫合规工程实践-代码聚汇网

robots.txt完全指南：从语法解析到爬虫合规工程实践

云海天狼·2026-09-03·阅读 21 GEO检测（免费）

robots.txt网络爬虫User-Agent

|难度：普通|阅读约 32 分钟

1. 一个不把robots.txt当回事的爬虫项目，是怎么被迫下线的

我做过很多种采集任务，从资讯站的列表页到行业网站的 PDF 文件，从单机脚本到分布式调度。早期我觉得 robots.txt 就是个摆设，无非是运维写给搜索引擎看的一份声明，我自己的 User-Agent 换个不常见的名字，谁会真的来查。直到有一次，我负责的一个采集任务上线不到半天，对方运维就带着完整请求日志找上门来。日志里时间戳、请求路径、响应码全都在，User-Agent 一行一行写得清清楚楚。那一刻我才意识到，网络爬虫库与 robots.txt规则之间从来不是“技术能不能实现”的关系，而是“这套数据你能不能用得安心”的关系。

这篇内容我想结合自己的实际经历，把 robots.txt 的语法细节、主流爬虫库对它的支持方式、如何把它写进请求链路，以及最近大家在热搜里提到的“怎么让 AI 绕过 robots.txt”这类问题一次性讲透。如果你是刚接触爬虫的小白，可以直接收获一套可落地的判断方法；如果你已经写了不少采集脚本，这几个容易踩的细节也许能帮你省下跟站点方扯皮的功夫。

先说我当年的教训。那个项目要做的是定时同步一个垂直网站的公告数据，量不大，但使用了并发请求，每个页面还顺手把静态资源也拉到了本地。起初只盯着页面能不能打开、会不会被封 IP，完全没有去看那台服务器的 robots.txt 到底写了什么。结果对方的运维人员通过访问日志识别出我们的爬虫后，先是一封措辞客气的提醒邮件，随后直接加了访问限制。等我们再去核对时才发现，robots.txt 里对一个二级目录明确写了 Disallow，而我的任务清单里恰好包含了那个目录下的几十个文件。

robots.txt 全称是 Robots Exclusion Protocol，2022 年已经有了 RFC 9309 这样的正式参考文档。它的作用是在站点运行方和自动访问程序之间建立一种公开约定：哪些路径允许被抓、哪些不允许、希望用多快的频率访问。但请注意，它本质上不是防火墙，也没有办法从技术上阻止任何请求。它更像家门口贴着的一张“非请勿入”的纸条，正人君子路过会尊重，心存侥幸的人依然可以无视。问题是，现实中很多数据纠纷、账号封禁甚至服务协议违约，最初的源头都是这一份看起来不起眼的文本文件。

所以我的建议是，把 robots.txt 当成采集项目的基础设施来对待，而不是可有可无的“道德约束”。它决定了你能在多大尺度上使用这批数据，也决定了当对方问起来时，你能不能坦然说出“我们是严格按照你的规则抓的”。在这个前提下，再来谈爬虫库、并发数、解析效率，才有意义。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. robots.txt语法拆解：别让 Allow、Disallow 的匹配逻辑坑了你

robots.txt 的核心语法并不复杂，但实际使用中特别容易在路径匹配上产生误解。先看一个标准的示例文件：

code复制User-agent: MyCrawler
Disallow: /admin/
Disallow: /api/v1/private
Allow: /public/
Crawl-delay: 5
Sitemap: https://example.com/sitemap.xml

这里 User-agent 行声明的是给哪个爬虫看的规则，MyCrawler 是爬虫在产品标识中使用的名称。接下来 Disallow 表示禁止访问的路径前缀，Allow 表示允许访问的路径前缀。Crawl-delay 是部分爬虫支持的访问间隔建议，单位是秒。Sitemap 则是给爬虫提供全站链接清单的入口，它不归属到具体某个 User-Agent 的规则组里。

2.1 User-Agent 的匹配方式

UA 匹配遵循几个原则：大小写不敏感，而且只要当前爬虫的 UA 中包含某个 token，就会认为该规则适用于它。例如我的请求头是：

code复制User-Agent: MyCrawler/1.0 (+https://example.com/contact)

那么 robots.txt 里的 User-Agent: mycrawler 可以命中它。如果站点没有为 MyCrawler 单独设置规则组，爬虫通常会落到 User-Agent: * 这个通配组上。也就是说，所有没有被单独点名的爬虫，都默认参考星号组的配置。

这里有个细节值得注意：某个爬虫到底使用哪一组规则，主流做法是匹配“最具体”的 UA token。如果站点里同时存在 Googlebot 和 * 两组规则，Googlebot 就按 Googlebot 那组执行；我自己叫 MyCrawler，就按 * 那组执行。所以编写机器人时，一定要给自己一个稳定、可识别的 UA，不要随手用浏览器 UA 去伪装。

2.2 路径匹配优先级

路径匹配最容易出错的地方在于：Disallow 后面的路径是一个“前缀”，而不是一个必须完整相等的目录。举个例子：

robots.txt 规则	页面 URL	是否禁止
`Disallow: /private`	`https://example.com/private2.html`	禁止，因为 `/private` 匹配前缀
`Disallow: /private/`	`https://example.com/private2.html`	不禁止，因为路径前缀要求包含斜杠后的目录结构
`Disallow: /admin`	`https://example.com/administrator.html`	禁止，因为 `/admin` 是前缀
`Disallow: /admin$`	`https://example.com/admin/`	需要看解析器是否支持 `$`，很多老实现不支持

看到问题了吗？/private 和 /private/ 的含义完全不同。想屏蔽一个目录，最稳妥的写法是保留末尾斜杠，比如 Disallow: /private/，这样 https://example.com/private2 不会被误伤。如果只想屏蔽特定后缀，现代解析器支持 $ 代表结束符，但这并非所有爬虫库都支持，所以正经站点的 robots.txt 通常不会写太花哨。

还有一个例子是 Allow 作为特例开放。很多站点会先全站禁止，再放行某个目录：

code复制User-agent: *
Disallow: /
Allow: /public/

这样配置后，/public/index.html 是可以被抓的，但根目录其他路径依然被禁止。它的核心逻辑是：Allow 和 Disallow 同时匹配时，按更具体的规则执行。也就是说，/public/ 比 / 更长、更具体，所以优先采用 Allow。

我在写采集脚本时养成了一个习惯：见到 Disallow: /private 这类不带结尾斜杠的写法，会主动多看一眼，因为它的影响范围往往比表面看起来更大。遇到复杂路径规则时，不要靠肉眼猜，直接用一个解析库去跑一遍 URL 列表，结果会比你想象中可靠得多。

3. 主流网络爬虫库与robots.txt的真实支持情况：从urllib到Scrapy

不同语言的爬虫库对 robots.txt 的支持差异很大。有些提供了现成开关，有些需要自己手动解析，还有些压根没把这当回事。选型之前先摸清它们的行为，能省掉很多不必要的返工。

3.1 Python 标准库 urllib.robotparser

如果你用的是 Python，标准库里其实已经内置了一个非常轻量的解析器，叫 urllib.robotparser。它没有第三方依赖，核心用法非常直白：

python复制from urllib.robotparser import RobotFileParser

rp = RobotFileParser()
rp.set_url("https://example.com/robots.txt")
rp.read()

url = "https://example.com/public/page.html"
allowed = rp.can_fetch("MyCrawler/1.0", url)
print(allowed)  # True 或 False

它还能读取站点声明的 Crawl-delay 和 sitemap：

python复制delay = rp.crawl_delay("MyCrawler/1.0")
rate = rp.request_rate("MyCrawler/1.0")
sitemaps = rp.sitemaps()

这段代码适合小规模的单机脚本。它的缺点是实现相对朴素，对 Allow/Disallow 交错排列、通配符、结束符这类扩展语法支持有限。如果你的目标站点 robots.txt 写得比较简单，用它做预检完全够用；如果站点规则很复杂，或者你需要高并发的批量判断，我更建议换一个更完整的解析工具。

3.2 Scrapy 的 ROBOTSTXT_OBEY

Scrapy 是我个人比较常用的抓取框架，它对 robots.txt 的支持是内建的。在配置中开启 ROBOTSTXT_OBEY = True 后，Scrapy 会为每个新域名先获取一次 robots.txt，然后通过中间件对所有请求做是否允许的判断。它的完整版本会使用更强大的解析器，支持 Google 扩展的 Allow 和通配符语法。

设置里通常这样写：

python复制ROBOTSTXT_OBEY = True
USER_AGENT = "MyCrawler/1.0 (+https://example.com/contact)"

你可能会想，设置一个 True 不就行了吗？实际操作中还是有几个坑。第一，如果你的 USER_AGENT 和 robots.txt 里针对的 token 不一致，中间件判断出来的结果会和你预期差很多。第二，一旦开启，Scrapy 在访问每个新域名的第一批请求中会多出一次 robots.txt 请求，如果站点响应慢，队列可能出现等待。第三，如果站点对 robots.txt 返回非 200，有些情况下处理策略会变得保守，这需要你在测试环境里先跑通再上线。

我见过不少开发者因为调试时总觉得“为什么这个页面抓不到”，最后才发现是 ROBOTSTXT_OBEY 一直没关。所以我建议用 Scrapy 做项目时，开发环境可以关掉它，但部署前一定要打开，并且用模拟数据验证一遍哪些 URL 被过滤了。

3.3 其他语言生态的参考情况

Python 生态之外，不少语言也有自己的处理方式。Go 的 colly 爬虫库提供了 RobotsTxt 选项，启用后会在访问域名时读取并遵守 robots 规则。Node.js 生态里有各类 robots-parser 库，但还需要你自己和请求库配合，不像 Scrapy 那样做到中间件级别。

整体来看，各语言库的成熟度差异很大。选型时不要只看 GitHub Star，要问清楚这几个问题：它是否会在每个新域名上自动请求 robots.txt？它用的是标准解析器还是自定义的简化版？它能区分 Allow 和 Disallow 的优先级吗？如果答案都是否定，那就要自己在请求层补一套判断逻辑。

4. 把robots规则真正串进抓取链路：预检、TTL缓存和异常策略

有了解析库之后，还需要一套代码层面的机制，让 robots.txt 的判断进入每一个请求。最朴素的方案是每次请求前都调用一次解析器，但这样效率太低，还会频繁请求 robots.txt，给站点造成压力。更合理的设计是把解析结果缓存起来，并在合适的时机刷新。

4.1 写一个带缓存的 RobotsPolicy 类

下面这段代码是我在单机爬虫中常用的骨架，参考了 urllib.robotparser 的用法：

python复制import threading
import urllib.robotparser
from urllib.parse import urlparse
from datetime import datetime, timedelta

class RobotsPolicy:
    def __init__(self, ttl_seconds=3600 * 24):
        self._cache = {}
        self._lock = threading.Lock()
        self._ttl = timedelta(seconds=ttl_seconds)

    def _get_parser(self, base_url: str):
        now = datetime.now()
        with self._lock:
            cache = self._cache.get(base_url)
            if cache:
                parser, fetch_time = cache
                if now - fetch_time < self._ttl:
                    return parser
                return parser

            parser = urllib.robotparser.RobotFileParser()
            parser.set_url(base_url.rstrip("/") + "/robots.txt")
            try:
                parser.read()
            except Exception:
                # 在未知状态下，我选择保守处理：不直接放行
                parser = None
            self._cache[base_url] = (parser, now)
            return parser

    def can_fetch(self, user_agent: str, url: str) -> bool:
        parsed = urlparse(url)
        base = f"{parsed.scheme}://{parsed.netloc}"
        parser = self._get_parser(base)
        if parser is None:
            return False
        return parser.can_fetch(user_agent, url)

这个类做的事情很简单：对同一个域名只拉取一次 robots.txt，并在 TTL 内复用解析结果。TTL 到期后，通过 now - fetch_time 的比较判断是否需要重新拉取。之所以要做 TTL，是因为长任务可能运行几天，站点的 robots.txt 可能在此期间发生变化。如果不刷新，你前几天是守规矩的，后几天可能已经在访问被新规则禁止的路径了。

4.2 网络异常时的策略：保守优先

我见过不少人在解析失败时直接返回 True，也就是“读不到就当允许”。这或许能让任务继续跑，但从风险控制角度看并不稳妥。robots.txt 请求失败可能是网络抖动，也可能是对方已经明确把你拒之门外。

在这种未知状态下，我的默认策略是暂时不放行这个域名的请求，并且把异常信息记录到日志里，等运维或者开发人员确认原因后再继续。宁可让任务慢一点，也不要让整个采集行为变成对方眼中的失控访问。如果你维护的是每天几百万页面的大规模集群，这种保守策略尤其重要。

4.3 把 UA、规则和业务逻辑对齐

解析器里的 user_agent 参数，必须和实际请求头里的 User-Agent 保持一致。很多库在解析 robots 时接受一个 token，比如 MyCrawler，但如果真正发请求时你又自定义了一个不同的浏览器 UA，规则就完全不适用了。服务器端看到的是一个身份，robots.txt 判断时用的却是另一个身份，这在语义上已经站不住脚。

建议把 UA 做成项目级配置，在启动时加载，并统一传给请求库、解析器和日志模块。这样后续做数据溯源时，也能清楚地知道某条数据是谁、在什么时间、以什么身份抓来的。

上传到生产环境之前，我通常会先用 curl 验证一下目标域的 robots 文件是否能正常返回：

bash复制curl -sA "MyCrawler/1.0 (+https://example.com/contact)" https://example.com/robots.txt

返回内容包含 User-agent、Disallow 等行，说明没有网络层拦截。如果返回的是登录页或验证码页面，那就说明站点对 robots.txt 做了特殊处理，这时就不应该继续用普通预检逻辑去推断抓取规则。

5. 当热搜叫嚣让AI绕过robots.txt时，爬虫开发者应该怎样应对

最近总能刷到类似“怎么让 AI 绕过 robots.txt”的提问，甚至有人把它包装成技术攻略。我想先给一个明确结论：这类思路我不仅不建议你写进代码，也不建议你在业务上抱有任何侥幸心理。

5.1 技术能实现，但代价会远远超出你的预期

绕过 robots.txt 很难吗？老实说不难，因为你只需要忽略解析结果，直接发 HTTP 请求就行了。很多爬虫库默认甚至都不开启 robots 支持，闭着眼睛写都能绕开。可是从项目长期运营来看，这里有几个更现实的问题：

第一，robots.txt 是对站点运营方意图的公开表达。无视它，相当于和对方公开对着干。站点方一旦通过日志识别出你这个爬虫的身份，可以做的事情很多：封 IP、封 UA、加验证码、修改条款、发律师函。到那时，你的爬虫代码写得再漂亮，也没有用武之地。

第二，数据采集不是“抓下来就算成功”，下游使用才决定价值。如果你抓到的数据最终要做成产品、训练模型或者对外提供，来源是否合规往往会成为合作方关注的重点。面对一份连 robots.txt 都不遵守的数据源，很难拿出让人信服的说辞。

第三，搜索热词里出现“让 AI 绕过”，背后其实是很多人想拿公开网页内容做模型训练。但 AI 训练场景对数据来源的合法性更敏感，因为这涉及到著作权、服务条款和平台对自动化访问的授权边界。与其研究怎么绕过，不如先把授权路径走通。

5.2 遇到禁止抓取时，正确的替代方案是什么

当 robots.txt 明确禁止你的 UA 访问某个路径时，我绝不会继续硬闯，而是会启动下面这套替代流程：

查看站点是否提供官方 API。很多网站虽然有爬虫禁止策略，但对 API 是友好开放的，申请一个 Key 往往就能拿到更规整、更完整的数据。
在 robots.txt 的 Sitemap 或页面联系方式中寻找线索，直接给站点运营方发邮件，说明你的采集目的、采集频率和最终用途。不要小看一封诚恳的邮件，我靠这种方式拿到了好几个原本禁止访问的数据源授权。
检查数据是否有第三方转售或开放数据集。很多行业数据已经被整理成规范的数据包，下载即可使用，比自己写爬虫更省成本。
如果以上都不行，就换一个数据源。项目延期总比项目被迫下架要好。

这里也分享一下我给自己定的底线：不爬需要登录才有权限看的数据；不伪装成普通浏览器用户去绕过站点的访问限制；不对 robots.txt 中明确禁止的路径做“换 UA 再试一次”的操作。这条底线不是胆小，而是我在几次被迫删除数据的教训之后总结出来的工程经验。

5.3 作为站长，该如何应对 AI 爬虫

如果你经营着自己的内容站点，也希望在 robots.txt 里明确表达对 AI 类爬虫的态度，现在很多主流 AI 爬虫都有自己的 UA 名称，例如某些大模型训练机器人、AI 搜索引擎机器人。你可以在 robots.txt 里单独为它们设置规则：

code复制User-agent: *
Allow: /

User-agent: SomeAIBot
Disallow: /

这等于告诉普通搜索引擎和普通用户“站点允许抓取”，但明确告诉 AI 训练机器人“请离开”。需要说明的是，这类设置更多是行业自律层面的表达，并不能从技术上阻止所有人都遵守；但作为站点方，你已经把授权边界写清楚了。这就给后续可能产生的数据使用纠纷留下了一个最基本的技术凭据。

6. 作为站点方反被robots.txt坑掉的七个配置细节

这个部分写给另一个方向的人看：如果你是站点方的技术人员，正在配置 robots.txt，下面几个细节是真的会让规则失效的。

第一，不要漏掉结尾斜杠。/private 会屏蔽所有以 /private 开头的 URL，包括 /private2 和 /private-notes.html。如果你确实只想屏蔽一个目录，请写 /private/。否则，某些“看似无关”的页面可能已经被你误伤。

第二，路径是大小写敏感的。URL 里的 /Admin/ 和 /admin/ 是两个不同路径。如果你的内容系统不区分大小写，那更要小心，最好在 robots.txt 里把可能出现的几种大小写都列出来，或者统一约定 URL 规范。

第三，不要把 Disallow: 留空，以为能“屏蔽所有页面”。在多数解释器中，空值代表没有限制，也就是允许抓取全部页面。如果你想全站禁止，应该写 Disallow: /，而不是留着空。

第四，注意规则组顺序带来的误判。虽然现代解析器会优先匹配具体 UA 组，但有些人习惯把 User-agent: * 放在最前面，然后在下面给具体爬虫放开权限。这种写法可能会被部分解析器误读，建议按下面这种分组互不干扰的格式来写：

code复制User-agent: *
Disallow: /

User-agent: GoodBot
Allow: /

第五，不要把安全敏感路径交给 robots.txt 保护。robots.txt 是一个公开文件，任何一个人打开浏览器都能看到里面写了 Disallow: /admin/、Disallow: /backup/，这等于直接告诉攻击者“这里有值得保护的内容”。真正需要权限保护的目录，应该用身份验证、IP 白名单或者更细粒度的授权机制来实现，而不是靠 robots 规则。

第六，修改 robots.txt 后要注意缓存问题。很多爬虫会缓存规则，站点方可能改了半小时，爬虫还在按旧规则抓取。不要用 CDN 对 robots.txt 设置过长的缓存时间，最好让它能够实时更新。

第七，不要只用 Crawl-delay 来限流。这个指令很多爬虫都不支持，搜索引擎也未必遵守。如果你真的担心某个爬虫把站点抓垮，应该在服务端做更具体的限流控制，同时根据日志建立一个可追溯的访问监控体系。

7. 上线前过一遍的robots自查清单（含我常用的代码骨架）

最后分享一份我每次上线采集任务前都会过的自查清单。它不是形式主义，而是踩过坑之后形成的肌肉记忆。

第一，我有没有一个稳定的 UA？这个 UA 是否能在官网或联系方式中让人找到我？如果你的 UA 是 python-requests/2.31.0，站点方只能识别出这是一个通用库，完全不知道你是谁。建议统一改成 项目名/版本号 (+联系方式) 的格式。

第二，是否已经在正式抓取前拉取过目标域的 robots.txt？拉取失败的默认策略是放行还是保守处理？我推荐的代码骨架已经在第 4 节给出，目标是让每个域名只解析一次，并对未知状态保持谨慎。

第三，是否有跨进程共享的缓存机制？如果爬虫跑在多台机器上，每一台各自缓存一份 robots.txt 会造成重复请求，浪费不说，还可能触发对方告警。单机可以接受内存缓存，分布式集群建议把 robots 解析结果放到 Redis 中，用域名作为 key 并设置 TTL。

第四，是否对“允许抓取”的路径仍然设置了合理的抓取频率？robots.txt 允许不代表你可以用尽带宽去抓。我一般会在任务调度层加一个令牌桶，将并发数和每秒请求数都限制在可控范围内，而不是等服务器返回 429 再做熔断。

第五，是否保留采集日志中的来源记录？完整记录 URL、UA、robots.txt 内容哈希、抓取时间和最终的 allow/deny 判断结果，对将来的数据溯源会非常有帮助。一旦业务方问你“这批数据是哪来的”，你能在几分钟内给出答案，而不是靠记忆和猜。

第六，所有要抓的数据，是否都对应了合法的用途？如果数据要用于训练模型、对外输出或商业化产品，我会额外走一道授权确认流程，把 robots.txt 作为其中一项参考依据，而不是唯一的依据。

以上这些经验，不是说遵守了 robots.txt 就万事大吉，而是说你要在技术上做一个可解释、可追溯、可沟通的爬虫系统。真到了需要跟站点方打交道的那一天，一份基于规则的采集日志，比任何技术辩护都更有说服力。