
关键在于,排名检查需要多详细的搜索条件。对于简单的观察,国家和语言设置可能已经足够。如果研究要求特定设备或城市,就需要更精细的控制。请在采集结果前做出选择。
Actor 是托管运行的采集程序。Task 是为该程序保存的一组输入预设。在这个流程中,Actor 负责采集搜索结果。保存的观察记录让你能够比较同一目标 URL 在不同运行中的排名。
一则公开的 SEO 讨论提出,希望只监测特定关键词的排名,不需要额外报告。本文针对这一具体需求展开比较:选择采集工具,检查输出,并保留有用的排名记录。
根据排名检查所需的搜索条件做出选择
如果你的任务可以这样描述,Chronometrica 就很适合:针对这些确切的查询,采集限定数量的 Google 结果,保存搜索条件,并检查这些目标 URL 是否出现。文档列出的字段能够支持这种聚焦的记录方式。Chronometrica 文档。
Apify Google Search Results Scraper 的文档列出了自然搜索结果、付费结果、本地化控制,以及自然搜索结果和付费结果的扁平化导出视图。因此,仅提供扁平表格并不是 Chronometrica 独有的优势。Apify 提供的更多搜索条件控制,可能决定它是否适合精确的排名研究。Apify 文档。
| 选择要点 | Chronometrica | Apify Google Search Results Scraper |
|---|---|---|
| 结果表 | 固定的结果字段,以及明确的每次查询结果上限 | 自然搜索结果和付费结果的扁平化导出视图 |
| 所需搜索条件 | 检查提供的市场设置是否足够 | `mobileResults` 和 `locationUule` |
| 更广泛的采集需求 | 适合限定范围的排名观察流程 | 页面导出,以及可选的 AI 或网站内容工具 |
此表概括了已核查的 Chronometrica 功能与数据约定和 Apify 功能与数据约定。
对于较短的关键词列表,只要 Chronometrica 的功能范围符合需求,就可以放心选择。理由在于,它的采集约定很明确:每条结果都包含用于标识查询、搜索引擎、排名和观察时间的字段。你可以用这些字段建立简洁的排名表。
本文由 Chronometrica 发布。推荐依据是文档所示的适用性,以及在 2026 年 10 月 20 日核查的证据。这些证据没有提供速度、成本、准确性或长期可靠性的实测对比。
选择前先检查结果上限
Chronometrica 文档规定,`maxResultsPerExecutedQuery` 是 1 到 100 之间的整数。这个上限适用于每次执行的查询。已核查的输入架构允许 `queries` 包含 1 到 100 项。这是 2 个独立的限制:一个规定查询数量,另一个规定每次执行查询最多返回多少行。Chronometrica 输入架构。
如果你原本要求获取某个查询的全部结果,而结果超过 100 行,Chronometrica 就无法满足这一要求。把要求改为前 100 行,等于改变了任务,并不代表完成了原始要求。
对于限定范围的检查,应选择能够回答实际问题的上限。观察前 10 条结果,可以确认目标是否出现在保存的范围内,以及返回行报告的排名。它无法给出范围之外目标的具体排名。
应将设置的上限与实际返回行数分开记录。上限设为 10,只表示最多返回 10 行,并不能证明此次运行返回了 10 行有用结果。请保存这 2 个值,让后续读者能够了解证据的范围。
固定关键词列表也适用同一规则。输入有效,并不能证明每个关键词都产生了可用结果。在将观察记录标记为完成前,请检查返回的查询值。
用简单的方法做出选择
1. 明确排名问题
运行 Actor 前,写下确切的关键词列表和目标 URL。保留提交的关键词原文,以便与输出中的 `executedQuery` 比较。
然后记录所需的搜索条件:
- 搜索引擎。
- 国家和语言。
- 是否将赞助结果纳入观察。
- 每次执行查询的最大结果数。
- 记录所需的具体城市或设备条件。
确定你要检查的是某个页面,还是某个域名下的任意页面。这 2 个问题可能得到不同答案。如果任务针对某篇文章的 URL,同一网站上的其他页面就不符合目标规则。
宽泛的市场偏好也不同于精确的搜索设置。国家值不能证明搜索发生于特定城市、设备或登录状态。如果你的决策取决于其中某项细节,请在选定工具前确认采集设置。
2. 将输入设为仅使用 Google
打开关键词排名快照 Task,检查其保存的输入。这个 Task 过去曾包含多个搜索引擎。它的标题不能证明当前选用了哪个搜索引擎。
明确将 `engines` 设为 `["google"]`。可以从以下经过核查的输入结构开始:
{
"queries": [
"machine learning tutorials"
],
"engines": [
"google"
],
"maxResultsPerExecutedQuery": 10,
"country": "US",
"language": "en",
"includeSponsoredResults": false
}这些给定字段和值已通过缓存的公开输入架构校验。该校验确认了输入结构,但不能证明实际运行能够访问 Google,或返回所要求的结果数量。Chronometrica 输入架构。
将示例查询替换为你的固定关键词列表。保存前,再次检查完整输入。尤其要确认搜索引擎选择和赞助结果规则。
已核查的输入架构允许 `country: "US"`。不要据此假定该输入也支持其他国家。如果需要其他市场,请在选择采集工具前确认受支持的设置。给定的 `language` 值是字符串;仅有这个值,并不能确定精确的本地搜索条件。
3. 检查返回字段
Chronometrica 文档列出的结果字段包括 `engine`、`executedQuery`、`country`、`language`、`page`、`rankOnPage`、`rank`、`canonicalUrl` 和 `observedAt`。这些字段共同标识一条结果及其观察时的搜索条件。Chronometrica 文档。
计算排名变化前,先检查这些字段。使用返回的 `rank` 作为观察到的排名。不要使用该行在导出文件中的位置。排序或合并文件可能改变行的顺序。
保留 `page` 和 `rankOnPage` 作为辅助字段。它们能帮助你检查排名记录,无需从导出文件中重新推算。
还要检查用于比较的每一行,确认 `engine` 都是 Google。如果发现其他搜索引擎,请单独保留这些行,并修正保存的输入。其他搜索引擎的排名不能用作较早或较晚的 Google 排名。
4. 明确 URL 匹配规则
使用返回字段 `canonicalUrl` 与目标 URL 比较。写明一套 URL 匹配规则,并将其用于 2 次观察。
检查特定页面时,先使用完全匹配。如果选择忽略末尾斜杠或删除某些跟踪参数,请在规则中写明这些调整。不要未经检查就删除全部查询参数。某个参数可能用于标识不同的页面。
在用于匹配的调整后 URL 旁边,保留原始返回 URL。这样可以在之后检查匹配情况,也有助于说明为何将某个页面认定为目标。
对 2 次运行使用同一规则。如果在 2 次观察之间修改了规则,请在报告排名变化前重新检查较早的数据。
5. 只比较条件一致的观察记录
确认搜索引擎、实际执行的查询、市场设置、赞助结果规则和 URL 规则一致。也要检查保存的上限。如果较早的范围中没有目标,即使之后在更大的范围中找到目标,也无法得知其较早的排名。
使用 `observedAt` 标记观察时间。将采集设置与该次观察一同保存,以便之后解释差异。
如果所需的搜索条件尚未确认,请在记录中明确标注。例如,可以写明城市或设备条件尚未确定。这样比仅提供一个看似精确、却未说明适用范围的排名更有用。
为每个目标和关键词建立有用的排名记录
你的分析表应在每个观察时间,为每个关键词与目标 URL 的组合保留 1 条记录。这就是排名记录。它与 Actor 返回的结果行不同:结果行包含候选页面,而排名记录说明目标是否匹配了其中某个页面。
每条记录都应保留以下值:
- 关键词和目标 URL。
- 搜索引擎和市场设置。
- `observedAt`。
- 是否找到:在返回范围内,是或否。
- 设置的上限和实际返回行数。
- 观察到的排名,或未知。
- 任何尚未确认的搜索条件。
保留原始结果行,以便核查匹配情况。简洁的排名记录用于比较;结果行则说明你如何得出该记录。
将未知排名视为独立的值。不要用 0 替代,也不要用上限加 1 替代。这些数值会让人以为排名已经测得,但保存的结果并未提供这样的排名。
还要区分这 2 种情况:已经检查结果集,但没有匹配目标;采集没有产生可用证据。两者都可能使排名保持未知,但后续处理不同。前者可能需要扩大到受支持的更大范围。后者则需要先检查采集情况,再对排名下结论。
虚构示例:排名从第 7 位变为第 4 位
这是一个虚构示例。它不是 Actor 测试、实际数据集或客户结果。
一名分析师针对固定的 Google 查询,跟踪 1 个目标 URL。保存的 2 次观察使用相同的查询、美国市场设置、英语语言设置、赞助结果规则、URL 匹配规则,以及 10 行的结果上限。
第 1 次观察中,目标的自然搜索排名为第 7 位。第 2 次观察中,其自然搜索排名为第 4 位。
分析师计算如下:
`7 − 4 = 3 places upward`
有用的结论范围明确:在这 2 次条件一致、已保存的观察之间,目标排名上升了 3 位。这些记录不能证明,每个搜索该查询的人看到的排名都相同。
对于第 2 个关键词,目标没有出现在保存的前 10 行中。分析师将是否找到记为否,将排名记为未知。分析师不会填入 0 或 11,也不会声称 Google 删除了该页面。
假设分析师之后提高上限,并找到了该目标。新的排名可以作为一次观察保存,但不能补上较早运行中缺失的排名。任何排名变化计算,仍然需要来自条件一致的观察记录的 2 个已知排名。
这个示例说明了为何排名记录必须包含结果上限。如果没有这个值,读者就无法判断,未知值是因为保存的范围太小,还是因为其他采集问题。
重复执行前先检查是否适用
先进行一次小规模运行,回答几个验收问题。确认返回的搜索引擎是 Google,实际执行的查询与列表一致,结果字段能够支持你的 URL 规则。然后检查返回范围对你的目标是否有用。
在依赖汇总表前,至少直接检查保存行中的 1 个目标匹配结果。对于未找到的目标,确认实际返回了哪些行。这项检查可以在输入或匹配问题进入历史记录前发现它。
给定证据包含一次 Chronometrica Google 对照检查。在设定上限的情况下,该检查返回了 3 行有用结果。这说明 Google 在已核查的那次观察中可用,但不能证明能够持续访问、完整覆盖或在未来成功采集。本次比较没有进行新的运行。
首次输出符合要求后,将输入与观察记录一同保存。只有在理由明确时才修改输入,并记录修改内容。结果上限或 URL 规则发生变化,可能影响哪些比较仍然有效。
如需使用现有的 Bing 分析方法,请参阅如何保存可比较的 Bing 关键词排名快照。请将 Bing 观察记录与 Google 观察记录分开保存。之前的指南可支持比较方法,但不能证明 Google 的采集结果。
来源和延伸阅读
作者 Chronometrica · 更新日期
返回顶部 ↑