抓取的法律与条款：团队必须先做的决定

多数抓取项目从技术问题开始，直到有人问“来源为什么封了任务”，才发现还有授权问题。BotBrowser 为已获授权的工作记录浏览器自动化能力，并要求只在自己拥有、或已取得明确书面测试许可的系统上运行。它不判断一次收集是否合法，不授予收集许可，也不替代条款审阅或法律意见。

TL;DR

• 首次请求前写清四项决定：来源与适用条款、需要哪些数据、请求负载多大、数据保留多久。
• robots 规则、速率限制、登录状态和授权决定是四件事。通过其中一项，说明不了另外三项。
• 技术控制是行为证据，不是许可证、合同条款或法律依据。
• 记录来源条款的版本和阅读日期，让后续变更可查，而不是靠记忆。
• 当来源限制自动化访问、数据涉及个人信息、或答案取决于司法辖区时，交法务处理。不要用浏览器设置去回答这些问题。

目录

• 首次请求前的四项决定
• 逐条阅读条款
• 编写决策记录
• 把技术控制与许可分开
• 明确升级节点
• 实践结论

首次请求前的四项决定

第一项决定是数据来自哪个来源、适用哪份条款。服务条款、API 协议、开发者政策和公开数据许可可能各说各话，也可能随时变更。记录你读过的文档、它的版本或更新日期，以及关键条款。“这个站点看起来是公开的”不算决策记录。

第二项是任务真正需要哪些数据。一个页面可能包含价格、评价、头像、用户标识和时间戳，敏感度与保留需求各不相同。在抓取前确定字段，而不是在导出后补决定，因为宽泛的导出一旦存在就很难收窄。保留能回答业务问题的最小字段集。

第三项是请求负载。并发、重试策略、抓取时间窗和单来源速率都要写进记录，并附上来源公布的限额（如有）。429 是负载信号，技术上能重试不代表更高的速率可以接受。抓取速率限制与并发讲机制；本记录决定机制必须遵守的预算。

第四项是保留与删除。确定数据放在哪里、谁能读、保留多久、什么条件触发删除。没有保留决定的收集往往会意外变成永久保存。记录责任人和复核日期，因为无人复核的数据集会活得比批准它的项目更久。

决定	记录	错误捷径
来源与条款	文档名称、版本日期、相关条款、复核人	以为公开可访问就等于可无限制使用
数据范围	字段清单、个人信息标记、用途、最小化说明	先导出整页，之后再决定
请求负载	并发、速率、时间窗、重试上限、来源限额	一直重试到成功
保留	存储位置、访问名单、删除触发条件、复核日期	无限期保留一切

逐条阅读条款

条款页不是一句话。它通常包含访问授权、禁止行为清单、知识产权条款、责任限制和变更条款。约束自动化收集的条款可能藏在禁止行为清单、API 章节或单独的开发者协议里。读标题不等于读条款，别人写的摘要也不是原文。

按四点去读。第一，文档是否涉及自动化访问，是否使用 crawl、scrape、robot、自动化手段或速率这类词？第二，它是否把内容复用与访问分开限制，例如禁止再分发或禁止建立衍生数据库？第三，它是否要求账号、API key 或书面协议才能取得你要的数据？第四，它是否保留修改条款的权利，并说明如何通知变更？每个答案都要连同条款编号和版本日期写入记录。

公开数据许可与条款页是两种不同的工具。开放许可可能授予条款页没有授予的复用权，条款页也可能限制许可未提及的行为。两者同时存在时，两份都记录，并注明团队认为哪一份约束预期用途。当两份文件冲突时，这个判断属于法务问题；爬虫不能靠挑更宽松的读法来解决它。

API 也要用同样的纪律。API 协议可以允许其文档化的调用、禁止其他收集；文档中的速率限制是运营限制，不是关于合法复用的声明。记录 API 版本、端点、配额和允许该用途的条款。如果任务需要 API 不返回的字段，那是范围问题，不是绕过新决定、退回页面抓取的理由。

robots 规则同样需要精确阅读。RFC 9309 为愿意参与的爬虫定义了协调机制，它不产生许可证、合同或法律依据，也不覆盖条款页。Disallow 可以告诉已声明的爬虫不要进入某条路径；Allow 可以说明该路径未被禁止。两者都不能判定收集是否被允许，所以 robots 决定和许可决定要放在不同的行里。

编写决策记录

有用的记录要短到能复核、具体到能审计。一项决定一行，一个具名责任人，一个日期。记录应写明决定了什么、依据是什么、还有什么未决。未决项不是失败；未记录的假设才是。

project=price-watch
source=https://shop.example.test
terms_version=2026-11-02
terms_clause=sections 4 and 9
fields=sku,list_price,currency,observed_at
personal_data=false
load=2 concurrent, 1 request/second, window 02:00-04:00 UTC
retention=90 days, owner=data-platform, review=2027-02-01
counsel_review=not_required (no personal data, no access restriction)

记录是对决定的陈述，不是决定正确的证明。若来源后来新增条款，或任务开始收集未批准的字段，记录就过期了，任务应暂停直到修订。

带未决项的记录，比带自信猜测的记录更有用。标出未决项，写明谁来回答，并设定任务继续或停止的日期。未决期间启动的任务应限于合成夹具或团队已拥有的数据，避免未决问题变成生产收集。

团队已有 schema 时，让记录保持机器可读。下面的字段名对小项目够用，也可以在不变更既有含义的前提下扩展。

字段	类型	用途
source	URL	任务可请求的确切来源与路径范围
termsVersion	date	所读文档的版本或更新日期
termsClause	string	约束自动化访问或复用的条款
fields	list	已批准的字段集，而不是整页
personalData	boolean	已批准字段是否可能关联到个人
load	object	并发、速率、时间窗与重试上限
retentionDays	integer	收集的数据可保留多久
owner	string	负责角色，而不是共享邮箱
reviewDate	date	何时必须重新阅读记录
counselStatus	enum	not-required、requested、answered 或 stop

counselStatus 是最常被跳过的字段。没有它，任务会从“我们问过一次”漂移成“我们以为没问题”，而没人察觉。记录提出的问题和得到的答复，包括“停止”的答复。停止是有效结果，应当结束任务，而不是触发另一个技术绕行。

把技术控制与许可分开

工程师常把技术信号当成许可问题的答案，但它不是。请求成功只说明服务器返回了响应；robots 评估通过只说明已声明 token 对应的公开规则；登录只说明账号完成了认证。这些都不是许可证、合同权利或法律依据，而且它们可以同时成立，收集却仍然不合适。

反过来也成立。请求被拦截不能证明收集被禁止，速率限制也不等于法定上限。技术结果和许可问题需要不同的责任人、不同的证据。robots.txt 决策记录讲爬虫规则一侧，招聘网站抓取边界则展示同一拆分如何落到具体来源，它明确把许可与 HTTP 交付分成两个决定，这里也是同一个道理。

BotBrowser 文档说明了已获授权工作的浏览器自动化能力，并支持在自有或取得书面测试许可的系统上运行；它不能替代条款审阅或法律意见。

BotBrowser 的负责任使用政策要求只在自己拥有或已获书面测试许可的系统上运行；法律免责声明把遵守适用法律和服务条款的责任放在用户身上。这些是产品政策边界，不是对某个来源的法律意见；读过它们也不会产生任务的许可。

技术控制还可能制造虚假的尽职感。加代理、加延迟或轮换 profile 改变的是请求的样子，不是团队被允许做什么。如果任务需要这些控制来规避来源明示的限制，要解决的是限制，而不是调控制。代理配置总览说明路由能改什么、不能改什么；这些改动没有一项是许可。

记录里要分开三组证据。技术组放响应码、速率观察和夹具结果；合同组放条款版本、条款和任何书面批准；法律组放法务答复（如已请求）。复核者应能看出哪组证据支撑哪项决定，任何一组都不该去填另一组的空白。200 响应填不了缺失的条款，条款也证明不了请求成功。

来源发布机器可读政策时，把它当输入，而不是替代品。robots 文件、API 配额响应头或文档化的抓取时间窗说明来源在运营上期望什么。这些输入属于负载计划和 robots 决定，既不能免除读条款，也不能回答个人信息问题。

明确升级节点

有些问题属于法务，假装不是只会浪费工程时间并制造风险。当来源条款限制自动化访问或复用、数据涉及个人信息、收集跨越登录或访问控制、或答案取决于适用司法辖区时，就升级。这些不是浏览器 profile、代理或重试策略能做的决定。

交给法务一个窄问题和已收集的证据：来源、条款版本与条款、字段清单、负载计划、保留计划和业务目的。精确的问题才能得到有用的答案；“我们能不能抓这个”只会换来一段泛泛的警告。把答复和日期写进同一份决策记录。

升级不只针对首次请求。新字段、新来源、更长的保留期或条款变更，都可能重新打开已经关闭的决定。把记录当作有复核日期的活文档，关键输入变化时暂停收集。

用例子讲升级更容易。下表列出触发条件、需要携带的证据，以及仍由法务作出的决定。它是路由辅助，不是法律测试，团队应随情况补充自己的案例。

触发条件	需要携带的证据	谁来决定
条款禁止自动化访问	条款、版本日期、预期用途	法务与产品负责人
已批准字段可能识别个人	字段清单、用途、保留计划	法务与隐私负责人
任务需要登录或访问控制	账号角色、权限范围、来源条款	法务与账号负责人
来源涉及多个司法辖区	来源、团队与数据主体所在地	法务
来源为同一数据提供 API	API 条款、配额、缺失字段	产品负责人；条款冲突时交法务

团队可以在没有律师的情况下准备以上全部内容，却仍然走到只有律师才能回答的那一步。这正是预期边界。工程要做的是把问题问准、收集证据、在答案未定时停任务；法律要做的是确定适用依据。两者混在一起，结果要么是未经授权的收集，要么是永远得不到明确答案的停滞项目。

还有一个常被忽略的升级触发点：来源发生变化。新条款、新登录墙、新 API 版本或返回数据变化，都可能让上季度正确的决定失效。把复核日期写进记录，并在该日期之后把记录视为过期，直到有人重读来源。记录过期不是继续运行的理由，而是暂停的理由。

实践结论

首次请求前，写下来源及其条款版本、字段与敏感度、请求预算和保留规则，并为每一项指定责任人。把技术证据与许可证据分开保存；涉及法律或合同的问题，连同记录一起交法务。这个做法本身不会让收集变得合法，也不是法律意见，但它把隐含假设变成了团队可以复核的决定。

常见问题

页面公开是否意味着数据可以自由收集？

不是。公开可访问描述的是谁能看到页面，不是团队可以对内容做什么。服务条款、数据库权利、个人信息规则和合同限制可能各自独立适用。阅读适用文档，并记录约束预期用途的那条条款。

robots.txt 的 Allow 规则能否当作许可？

不能。robots 规则是针对已声明产品 token 的爬虫协调指令，不授予许可证、数据使用权或法律依据，也不涉及个人信息。把规则决定和许可决定放在记录的不同字段里。

站点返回 403 时停下来就够了吗？

停下来是正确的运营反应，但不是许可分析。403 只说明服务器拒绝了这次请求，既不说明原因，也不说明另一条路径是否合适。先诊断拒绝，再回到许可决定，而不是不断换做法直到某一次成功。

团队什么时候应该找律师？

当条款限制自动化访问或复用、涉及个人信息、收集跨越登录或访问控制、或适用司法辖区不明确时。带上决策记录和一个具体问题；泛泛地请求批准，很少能得到可用的答复。

来源

• RFC 9309：robots 排除协议
• Google Search Central：robots.txt 简介
• BotBrowser 负责任使用
• BotBrowser 法律免责声明