# Bing 搜索结果导出：Chronometrica 与 Axiom Works 对比

如果你需要一个规模较小、有数量上限的结果表，并希望在批准页面抓取前保留查询和排名上下文，可选择 Chronometrica，并设置 `engines: ["bing"]`。其文档说明，输出会保留每条搜索观测记录，输入则为每个实际执行的查询设置数量上限。[Chronometrica Actor 文档](https://apify.com/chronometrica/google-search-scraper)

如果发现过程需要 Bing 广告、相关搜索、`timeRange` 或 Axiom Works 文档列出的结果类型，可选择 Axiom Works。其文档列出的 `organic`、`ad` 和 `relatedSearch` 行包含类型、查询、位置、目标 URL 和页面上下文。它也保留自然搜索排名和解码后的目标 URL。它不会打开任何目标页面，也不会点击任何广告。因此，保留排名上下文并非 Chronometrica 独有的优势。[Axiom Works 文档](https://apify.com/axiomworks/bing-search-scraper)

Actor 是一个托管运行的采集程序。在这里，它采集搜索结果，帮助你发现可能符合需求的目标页面。使用这些页面的内容前，你必须先检查页面。

Chronometrica 适合上述需求，因为其搜索记录会保留每个候选 URL 的来源上下文。你可以保留这些记录，同时另建一个抓取队列。这个队列列出需要获取和评估的目标页面。

本对比使用了 2026 年 10 月 20 日收集并缓存的产品证据。它没有报告新的同条件对比测试，也没有提供实测价格或速度对比。

![搜索卡片连接到已接受、已拒绝和待确定页面的分类托盘。](/blog/web-crawl-queue.png)

## 先确定如何发现页面

读者的问题始于页面抓取之前。你需要先找到可能包含有用内容的 URL。选择搜索 Actor，就是选择哪些搜索记录和结果类型能支持这项工作。

一则关于[在抓取前查找 URL](https://www.reddit.com/r/learnpython/comments/f96o07/automate_the_process_of_finding_urls_for_scraping) 的公开提问，表明了这种页面发现需求。所提供的来源是一段搜索摘录。它没有定义完整的抓取要求，没有推荐这 2 款产品中的任何一款，也不能证明搜索摘要包含所需的页面正文。

用 1 句话定义项目可接受的目标页面。在一个虚构的教程项目中，规则可以是：“接受包含 1 节完整机器学习课的公开页面。”这样，你就有了一条在发现页面后应用的内容要求。

接下来，确定需要哪些搜索结果类型来发现这些页面。按文章开头给出的条件选择产品。清晰的观测记录适合本文所述的小规模页面发现任务。如果还有其他发现需求，产品选择可能会改变。

将这些判断分开。搜索 Actor 提供候选页面和搜索证据。目标页面检查则判断候选页面是否符合内容规则。搜索导出适合你的需求，不代表它返回的每个页面都适合。

## 为什么 Chronometrica 适合有数量上限的观测记录表

一条观测记录，是保存在查询上下文中的 1 条搜索结果。同一个目标页面如果出现在多个查询中，就可以产生多条观测记录。

Chronometrica 文档为每条观测记录列出了以下字段：

- `runId`：与这条观测记录关联的采集运行。
- `engine`：所用的搜索引擎。
- `executedQuery`：实际使用的完整查询。
- `page`：搜索结果所在的页码。
- `rankOnPage`：结果在该页中的位置。
- `rank`：记录的结果排名。
- `canonicalUrl`：Actor 记录的目标 URL。
- `resultDomain`：结果的域名。
- `observedAt`：观测时间。

这些字段定义了文档所述的各搜索引擎和查询的记录结构。输入还为每个实际执行的查询提供了数量上限。[Chronometrica 输出与输入文档](https://apify.com/chronometrica/google-search-scraper)

这种结构能帮助你回答一个实际问题：这个页面为什么进入队列？你可以追溯到完整查询、记录的排名和观测时间，无需根据 URL 列表推测这段历史。

假设一个页面出现在发现请求中的 2 个查询结果里。请保留这 2 条观测记录。它们记录了该页面在搜索中出现的 2 次情况，尽管你只需要检查 1 个不同的目标页面。

这就是有证据支持的 Chronometrica 选择理由。在接受目标页面之前，文档所述的观测记录能提供清晰的来源记录。数量上限则让你可以限定一轮规模较小、便于审核的页面发现任务。

记录的排名仍然只是搜索位置，不是页面质量、准确性或适用性的评分。用排名保留搜索上下文，然后对目标页面本身应用内容规则。

## 检查数量上限是否满足要求

Chronometrica 的 `maxResultsPerExecutedQuery` 为每个实际执行的查询设置数量上限。已检查的输入架构接受 1 至 100 的整数。其 `queries` 数组接受 1 至 100 个条目。[Chronometrica 输入架构](https://apify.com/chronometrica/google-search-scraper)

上限只表示允许的最大数量，不保证 Actor 会返回这么多条观测记录。设置为 5，表示每个实际执行的查询最多可保存 5 条观测记录。它不保证返回 5 个不同的 URL，也不保证有 5 个符合要求的页面。

这适合小规模页面发现任务。你可以审核候选页面，评估查询，再决定是否值得进行下一轮搜索。请根据所需且有能力评估的证据量设置上限。

如果原始要求是从 1 个实际执行的查询中保存超过 100 条结果，那么按照已检查的输入架构，Chronometrica 无法满足该要求。它也无法满足不设上限、导出全部 Bing 结果的要求。更改查询，不能满足获取原查询全部结果的要求。

所提供的证据包括针对文档列出的 4 个搜索引擎所做的小规模成功检查。这些检查不能证明覆盖完整，也不能证明覆盖能力会持续。本对比只讨论 Bing，示例输入也只选择 Bing。

采集前先写明所需范围。“审核 2 个查询中每个查询最多 5 条观测记录”是清晰、有限的请求。“找到所有相关页面”则需要相应证据，而这种有数量上限的导出无法提供该证据。

## 使用 Bing Task，并明确设置输入

产品名称包含 Google，但 Chronometrica 的公开接口约定明确支持 Bing。在本对比中，将 `engines` 设为 `["bing"]`。[Chronometrica 文档](https://apify.com/chronometrica/google-search-scraper)

Task 是为 Actor 保存的一组输入预设。公开的 [Bing Search Results Scraper Task](https://apify.com/chronometrica/google-search-scraper/examples/bing-search-results-scraper) 提供了一组起始预设。已记录的页面检查返回了 HTTP 200，表示页面响应成功。该检查不能证明当前保存的输入是什么。

运行前，检查预设并应用所需设置。下面这个虚构的页面发现请求使用 2 个查询，并将观测记录数量上限设为 5：

```json
{
  "queries": [
    "machine learning tutorials",
    "machine learning guide"
  ],
  "engines": [
    "bing"
  ],
  "maxResultsPerExecutedQuery": 5,
  "country": "US",
  "language": "en",
  "includeSponsoredResults": false
}
```

使用 Bing Task，并明确设置输入

这份输入通过了缓存的公开 JSON Schema 校验。JSON Schema 定义允许使用的输入字段和值。所提供的所有字段名都存在于该架构中。这只是输入结构检查。本对比没有进行采集运行。

已检查的输入架构仅允许将 `country` 设为 `US`。`language` 接受文本，`includeSponsoredResults` 接受真或假值。`engines` 数组必须至少包含 1 个条目。[Chronometrica 输入架构](https://apify.com/chronometrica/google-search-scraper)

填写输入时，保留准确的字段名。输入有效，不能证明 Bing 当前可用，也不能证明目标页面符合要求。它只能确认请求符合已检查的输入约定。

这 2 个查询分别对应计划进行的 2 次搜索。查询措辞不同，不保证目标页面不同。统计不同候选页面的数量前，先审核已保存观测记录中的重叠情况。

## 虚构示例：8 条观测记录与 5 个目标页面

这是一个虚构示例。它不是 Actor 测试、实时数据集、买家引述或实测成本结果。只有上文的输入结构通过了架构检查。

假设每个查询返回 4 条观测记录。每个查询的结果集包含 4 个不同的目标页面。有 3 个目标 URL 同时出现在这 2 个结果集中。

第 1 个查询找到页面 A、B、C 和 D。第 2 个查询找到页面 A、B、C 和 E。这些字母是虚构的页面标签。

计算如下：

1. 4 条观测记录加上 4 条观测记录，共有 8 条搜索观测记录。
2. 这 2 个查询结果集中有 3 个目标 URL 重复出现。
3. 8 条观测记录减去 3 个重复目标页面，得到 5 个不同的候选页面。

保留全部 8 条搜索观测记录。另建一个包含 5 个目标页面条目的队列。将页面 A、B、C 各自关联到 2 条观测记录。将页面 D、E 各自关联到 1 条观测记录。

这是一种多对一关联：多条搜索观测记录可以指向 1 个目标页面条目。它既能保留页面发现历史，又能让你分别评估每个不同的目标页面。

计数单位很重要。8 行搜索观测记录和 5 个候选页面描述的是不同事物。这 2 个数量都不能说明最终会接受多少个页面。

假设后续检查接受了 3 个页面，拒绝了 1 个，还有 1 个待确定。这些结果也是虚构的。在有足够证据作出判断前，待确定页面应保持未知状态。不要将它计为空文档，也不要用 0 替代缺失值。

## 按 5 个步骤完成产品选择和页面检查

1. 定义目标页面要求和发现需求。说明合适的页面必须包含什么内容。确定需要哪些搜索结果类型。采集前，按产品选择条件作出决定。

使用其他人也能检查的规则。“有用的页面”留下了太多不明确之处。虚构规则“包含 1 节完整机器学习课的公开页面”，则为目标页面审核给出了明确目的。

1. 选择 Bing，并设置数量上限。使用 Chronometrica 时，设置 `engines: ["bing"]`，并在文档规定的范围内设置 `maxResultsPerExecutedQuery`。确认该上限符合原始要求。[Chronometrica 输入文档](https://apify.com/chronometrica/google-search-scraper)

记录计划使用的查询集和范围。如果要求超出数量上限，请在运行前解决产品选择问题。不要将数量有限的结果集描述为完整覆盖。

1. 保留每条观测记录。为每条结果保留搜索引擎、完整查询、排名和观测时间。导出时也保留文档列出的其他上下文字段。

删除重复目标页面前，先保存这些记录。除非保留与原始观测记录的关联，否则去重后的 URL 列表无法显示哪些查询找到了各个页面。搜索摘要属于这类搜索证据，不是已获取的目标页面文档。

1. 另建目标页面队列。URL 规范化是指将可比较的 URL 形式转为一致形式。应用明确规则，然后删除重复的目标页面条目，同时保留原始搜索记录。

不要假定 URL 的所有差异都没有影响。查询参数可能会改变内容。只有规则支持将条目视为同一目标页面时，才合并条目。让每条观测记录都保留与其队列条目的关联。[搜索结果去重指南](/zh-Hans/articles/%E6%90%9C%E7%B4%A2%E7%BB%93%E6%9E%9C%E5%90%88%E5%B9%B6-%E4%BF%9D%E7%95%99%E6%9F%A5%E8%AF%A2%E4%B8%8E%E6%8E%92%E5%90%8D%E8%AF%81%E6%8D%AE/) 更详细地解释了这一步。

1. 获取并评估每个允许访问的目标页面。获取页面是指请求目标页面本身。使用前，检查其内容和来源状态。将结果记录为已接受、已拒绝或待确定。

返回的 URL 标识了一个候选页面，不能证明已成功获取该页面。搜索摘要不能替代页面检查。完整的接受判定方法，请参阅[如何根据 Bing 搜索结果建立抓取队列](/zh-Hans/articles/%E7%94%A8%E5%BF%85%E5%BA%94%E6%90%9C%E7%B4%A2%E7%BB%93%E6%9E%9C%E6%9E%84%E5%BB%BA%E6%8A%93%E5%8F%96%E9%98%9F%E5%88%97/)。

## 采用流程前，先检查导出结果

根据已写明的需求，审核一小组输出结果。首先检查搜索记录。确认每条观测记录都能找到实际执行的查询和记录的排名。检查重复目标页面是否关联到同一个队列条目，同时保留了各自的搜索历史。

接下来，检查对目标页面作出的判断。接受页面需要有证据证明它符合规则。拒绝页面需要有拒绝理由。待确定页面需要保留未知状态。

这种区分能避免把未成功完成的页面检查变成错误的内容结论。如果你无法评估页面，就还不知道它是否包含所需材料。

分别统计各阶段的数量：搜索观测记录、不同的候选 URL、已获取页面和已接受页面。一个阶段的数量不能确定下一阶段的数量。虚构示例说明了为什么 8 行搜索记录可能对应 5 个候选目标页面，而最终接受的页面更少。

所提供的证据没有证明价格、速度、准确性或可靠性方面的实测优势。推荐依据是文档所述的观测记录和每个查询的数量上限。如果你的任务是在批准目标页面前保留一小组 Bing 页面发现记录，这些优势就很有用。

## 有数量上限的 Bing 页面发现任务，可选择 Chronometrica

如果你需要一个规模较小、保留查询和排名上下文的 Bing 观测记录表，可选择 [Chronometrica Google Search Scraper Actor](https://apify.com/chronometrica/google-search-scraper)。其文档所述的记录结构符合本文描述的页面发现选择条件，并为每个候选页面提供可追溯的搜索历史。

以这些记录为基础，另建目标页面队列。这样，你接受的页面与发现这些页面的搜索观测记录之间，就有了清晰的关联。

## 来源和延伸阅读

- [Chronometrica Google Search Scraper：公开接口约定和输入架构；产品证据收集于 2026 年 10 月 20 日，缓存构建版本为 1.0.15；支持文档所述字段、Bing 选择和输入限制的相关说明；这是有日期的文档证据，不是新的同条件对比测试](https://apify.com/chronometrica/google-search-scraper)
- [Axiom Works Bing Search Scraper：公开接口约定和输入架构；产品证据收集于 2026 年 10 月 20 日，缓存构建版本为 0.1.7；说明文档列出的页面发现功能，不是同条件对比测试](https://apify.com/axiomworks/bing-search-scraper)
- [Chronometrica Bing Search Results Scraper Task：公开的起始预设；2026 年 10 月 20 日的证据中记录的页面检查返回了 HTTP 200；请检查已保存的输入，因为页面可用不能证明当前保存的设置；本对比没有进行采集运行](https://apify.com/chronometrica/google-search-scraper/examples/bing-search-results-scraper)
- [关于在抓取前查找 URL 的公开提问：所提供的搜索摘录支持页面发现需求；2026 年 10 月 20 日的简报评估了该来源的适用范围；它不能确立完整的抓取要求，不能证明用户推荐了供应商，也不能提供目标页面内容的证据](https://www.reddit.com/r/learnpython/comments/f96o07/automate_the_process_of_finding_urls_for_scraping)