网页抓取手册真实被抓取站点的实测画像

一个只跑通过一次的采集器只证明了一件事：那一次请求，从某一个出口、在某一个时刻，取回了内容。它没有告诉你目标站点多久能应答一次、一次要花多长时间、一个页面要花多少钱、浏览器是否真的在做事，也没有告诉你失败集中在站点的哪一类 URL 形态上。这些数字决定了一条流水线是否值得搭建，而它们通常要等流水线建好之后才被发现。

Crawlbase Web Scraping Cookbook 会预先公布这些数字。它是每个站点一个页面，而且在动笔之前，每个页面都基于真实的 Crawlbase 流量测量过：成功率、中位应答时间、积分价格、成功流量中有多少使用了浏览器、成功的调用设置了哪个国家线路、哪些 URL 模式贡献了这些成功，以及失败究竟是什么。目前覆盖 已测量 17,739 个站点 和 356 个配方，基于2026年8月的数据，每月刷新。

一份配方测量了什么

每个页面都基于对该站点的实际观测流量构建，而不是为这个页面专门跑一次测试。这些测量正是一条流水线真正需要围绕其做规划的内容。

成功计数里有一个细节值得明说，因为它改变了成功率的含义。一个站点如果用 200 返回一个拦截页或同意墙，那它并没有返回内容，所以 Cookbook 把它计为失败而不是成功。在 Google 上，这一类是最大的单一失败桶，占 33.8%。

六个站点，六种不同的形态

要看清单个数字为什么不够，最快的办法是把六份真实配方并排放在一起。下面所有数据都是各页面公布的2026年8月测量值，其中的模式和失败数据取自2026年8月14日以来的请求日志。

Google：快、够便宜、不需要浏览器

google.com 配方 测得 97.0% 成功率，1.9 秒中位应答，以及 2 个积分 每页。普通令牌调用的成功率为 96.9%，承载了 99.8% 的流量，所以在这里浏览器纯粹是成本。搜索页占主导：/search 占成功请求的 98.3%，另有 6.3% 的调用请求 google-serp 采集器，以获取结构化 JSON 而不是 HTML。失败几乎平均分布在以 200 返回的拦截页或同意墙（33.8%）和在超时内始终没有应答的请求（33.5%）之间，限流占 23.5%。

LinkedIn：可靠、慢，而且是最贵的那个

linkedin.com 配方 测得 98.0% 成功率，14.7 秒中位应答，以及 20 个积分 每页，属于 Extreme II 价格档。普通令牌调用的成功率为 99.9%，占流量的 96.0%。成功集中在职位页（41.5%）、公司页（27.3%）和个人主页（18.5%）。失败主要来自站点自身的拒绝状态码 999，占 58.5%，另有 591 响应占 27.1%。

LinkedIn 最能说明为什么要读完整份画像。按成功率看，它是这组里第二可靠的站点。按每页成本看，它是 Target 的二十倍；按延迟看，它是 Google 的九倍。

Allegro：近乎完美，但一点也不着急

allegro.pl 配方 测得 99.7% 成功率，16.5 秒中位应答，以及 2 个积分 每页。全部成功流量都使用普通令牌。位于 /produkt/{slug} 下的商品页占成功的 77.3%。失败以超时为主（44.3%），其次是 403 拒绝（36.9%）和 400 响应（12.8%）。

Target：又便宜又快，但会被限流

target.com 配方 测得 96.4% 成功率，1.6 秒中位应答，以及 1 个积分 每页。普通令牌调用的成功率为 97.7%，承载 97.2% 的流量，两种商品 URL 形态合计覆盖了 99.3% 的成功。有意思的是它的失败画像：48.1% 是 429 限流，其次是 403 占 32.4%，超时占 13.3%。便宜又快，但站点会对调用节奏施压，这是调度问题而不是配置问题。

Trustpilot：渲染和国家都会起作用的那一个

trustpilot.com 配方 测得 90.9% 成功率，32.0 秒中位应答，以及 1 个积分 每页，2 个积分，也就是本配方所需的 JavaScript 令牌下的价格。在这组站点里，它是配置既改变结果也改变账单的那一个。JavaScript 令牌调用的成功率为 94.0%，普通令牌为 29.5%，而 94.0% 的调用使用了它。国家路由同样会改变结果：46.2% 的成功调用设置了 US 出口，成功率为 92.4%，而不设置国家时为 88.2%。位于 /review/{slug} 下的评价页占成功的 97.5%。失败以 403 为主，占 45.9%。

这就是配方推荐的调用方式，也是值得照抄的那一个，因为它同时承载了两个决策：

curl "https://api.crawlbase.com/?token=YOUR_JS_TOKEN&country=US&url=https%3A%2F%2Fwww.trustpilot.com%2Freview%2Fsd.se"

QQ.com：几乎完美，但仍然需要浏览器

qq.com 配方 测得 99.9% 成功率，6.1 秒中位应答，以及 1 个积分 每页，2 个积分，也就是本配方所需的 JavaScript 令牌下的价格。它是这组里最可靠的站点，却仍然需要渲染：JavaScript 令牌调用的成功率为 100%，普通令牌为 86.8%，而 98.9% 的调用使用了它。标签页占成功的 99.8%。大部分失败是站点自身的 5xx 响应，合计 72.4%。

QQ.com 和 Trustpilot 从两端说明了同一个道理。摆在表面的成功率并不能告诉你是否需要浏览器，因为这个成功率本身已经反映了调用方正在使用浏览器这一事实。

六个站点并排对比

在写采集器之前先读配方

这份画像的实际用处，是免去集成开始时的那一轮猜测，而大部分被浪费的精力正是花在那里。

从已经奏效的配置开始

每份配方都列出了成功流量所使用的令牌和国家，所以第一次调用是有依据的，而不是一次试探。对于 Google 这类使用普通令牌的站点，这就是全部配置：

from crawlbase import CrawlingAPI

api = CrawlingAPI({'token': 'YOUR_TOKEN'})
r = api.get('https://www.google.com/search')
html = r['body']

只在测量结果要求时才加上浏览器

渲染是最常见的条件反射，也是最常见的浪费。在观测到的流量中，Google、LinkedIn、Allegro 和 Target 都是用普通令牌完成的，在这些站点上加浏览器，只会给一次本来就成功的调用增加成本和延迟。Trustpilot 和 QQ.com 则是相反的情形，在它们身上，渲染就是 94.0% 与 29.5% 之间、或者 100% 与 86.8% 之间的差别。在 Crawling API 上，你可以用两种方式请求渲染：使用 JavaScript 令牌，或者使用普通令牌并加上 javascript=true，它会在抓取前切换到你的 JavaScript 密钥，因此一个密钥就能覆盖所有情况。借助 Smart AI Proxy，同样的开关是 javascript=true，放在 CrawlbaseAPI-Parameters 请求头里。两种方式都按 JavaScript 请求计费，这正是那两个站点积分价格翻倍的原因。

让失败类别决定重试方式

失败分布是上线之后才见效的部分，因为每一类都需要不同的应对。立刻重试 429 只会再次触发它。不换出口就重试 403，同样只会再次触发。

• 429 表示站点在为你限速。把调用间隔拉开，或者把它们交给 Crawler，由它替你控制节奏。Target 的失败有一半属于这一类。
• 403 表示出口被拒绝。设置成功调用所使用的国家，然后重试一次；第二次仍被拒绝，通常意味着 URL 本身受到保护。
• 5xx 表示是站点出了问题，而不是抓取出了问题。等一等再重试。在 QQ.com 上，这几乎占全部失败的四分之三。
• 超时 表示页面没有在限制时间内完成。把客户端超时设得高于该站点的中位应答时间，这正是配方公布这个数字的原因。
• 带着拦截页或同意墙的 200 是披着成功状态码的失败。它不计费，也正是应当检查内容而不是状态码的原因。

从配方到流水线

这份画像适用于搭建的早期阶段，此时消除未知的代价最低。

对于一个在选基础设施而不是在写抓取代码的团队来说，同样这些数字回答的是另一个问题。可靠性、延迟和价格是每个目标站点各自的属性，而不是平台的属性，所以“你们能采集这个站点吗”远不如“这个站点要花多少钱、有多慢、拒绝时会怎么做”有用。上面六个站点在同一个平台上，每页从 1 到 20 个积分，耗时从 1.6 到 32.0 秒不等。成本测算要从目标站点的价格开始：

100,000 pages x  1 credit  =   100,000 credits   (target.com)
100,000 pages x 20 credits = 2,000,000 credits   (linkedin.com)

价格估算器 会把这些积分换算成月度金额。重点在于，这个倍数在流水线建成之前就能知道，而不是等到第一张账单之后。

这些数字没有宣称什么

一份配方描述的是某个声明窗口内的实测流量。它不是对明天的承诺，也不是宣称站点上的每个页面都和样本里的页面表现一致。站点会更换防护、轮换基础设施、重新调整限流阈值，所以每个页面都标明了测量所在的月份和最后测试日期，整套数据也按月刷新，而不是任其陈旧。当一个站点不再应答时，它的配方会被移除，而不是留作一份记录已经失效内容的文档。

这些模式和失败类别来自2026年8月14日以来的请求日志，因此它们描述的是 Crawlbase 账户实际抓取的页面形态。没有人请求过的 URL 形态不会出现在其中，即使站点确实提供该页面。

结论

大多数采集决策都会做两遍：一遍基于假设，另一遍在流量显示出站点的真实行为之后。Cookbook 把第二遍提前了。在写解析器之前，你就能看到目标站点多久应答一次、一次要花多长时间、一个页面要花多少钱、浏览器是否真的在做事、成功的调用使用了哪个出口、哪些 URL 形态承载了成功，以及拒绝时返回了什么。

在 Cookbook 里找到你的目标站点，从测量结果支持的调用方式开始，并 创建一个免费账户，用它跑一跑你自己的工作负载。

常见问题（FAQ）

Cookbook 的数字从哪里来？

来自发往该站点的 Crawlbase 流量：成功率取自所述月份内所有账户的每一次请求，模式、国家和失败类别取自2026年8月14日以来的请求日志。它们是该窗口内观测流量的测量结果，而不是对未来表现的保证，数据中任何地方都不会标识出客户或账户。

“需要浏览器”是否意味着我必须自己跑一个浏览器？

不是。它的意思是目标站点需要 JavaScript 渲染，而渲染由 Crawlbase 完成。使用 Crawling API 和 Crawler 时，你可以通过 JavaScript 令牌，也可以用你的普通 令牌，再加上 javascript=true，它会在抓取前切换令牌；使用 Smart AI Proxy 时，你传入 javascript=true，放在 CrawlbaseAPI-Parameters 请求头里。两者在计费上都算作一次 JavaScript 请求。

我能在动手之前估算一个目标站点的花费吗？

可以，而且这正是重点所在。配方公布了该站点一个页面的积分价格，它由该站点的 域名复杂度决定，所以页数乘以价格就得到积分数字，而 估算器 会把它换算过来。换算时注意浏览器那一列：需要渲染的站点按翻倍后的 JavaScript 价格计费，这就是 Trustpilot 和 QQ.com 每页 2 个积分而不是 1 个积分的原因。实际消耗仍然取决于你的配置，以及你把流量发往哪个产品。

为什么 200 响应有时会被计为失败？

因为以 200 返回的拦截页或同意墙并不是你想要的内容。把它计为成功会抬高该站点的所有比率，并掩盖现代目标站点最常见的拒绝方式。这类响应同样不计费。

配方多久刷新一次？

每月一次。每个页面都注明了其测量数据所属的月份和最后测试的日期，因此过期的画像是可见的，而不是悄无声息的。对于不再应答的站点，其配方会被移除，而不是留在原处。

NZ

Neil Zamora

高级架构师 · Crawlbase

Crawlbase 高级架构师，专注大规模爬取背后的系统：代理轮换、反机器人韧性，以及隐藏这些复杂性的 API。