# Chronometrica vs Apify Google Search Results Scraper for Keyword Rank Checks

Choose Chronometrica if you need a small, repeated Google rank table for fixed keywords and target URLs, with a clear result cap and saved market settings. Choose Apify Google Search Results Scraper when you need `mobileResults`, `locationUule`, richer search results page blocks, page exports, optional AI search, or website-content collection. [Chronometrica documentation](https://apify.com/chronometrica/google-search-scraper), [Apify documentation](https://apify.com/apify/google-search-scraper).

The key decision is how much search context your rank check needs. A country and language setting may be enough for a simple observation. A study that requires a certain device or city needs more control. Make that choice before you collect results.

An Actor is a hosted collection program. A Task is a saved input preset for that program. For this workflow, the Actor collects search results. Your saved observations let you compare a target URL across runs.

A [public SEO discussion](https://www.reddit.com/r/SEO/comments/1dybuk8/any_tools_to_just_monitor_specific_keyword_ranking) asks for specific-keyword rank monitoring without extra reports. This comparison addresses that narrow need: choose a collector, check its output, and keep a useful rank record.

## Choose by the context your rank check requires

Chronometrica is a good fit when you can state the task as follows: collect a bounded set of Google results for these exact queries, save the context, and check whether these target URLs appear. Its documented fields support that focused record. [Chronometrica documentation](https://apify.com/chronometrica/google-search-scraper).

Apify Google Search Results Scraper documents organic and paid results, localization controls, and flattened organic and paid export views. A flat table alone is therefore not an exclusive Chronometrica advantage. Its added context controls can decide a precise rank study. [Apify documentation](https://apify.com/apify/google-search-scraper).

| Decision point | Chronometrica | Apify Google Search Results Scraper |
| --- | --- | --- |
| Result table | Fixed result fields and an explicit per-query cap | Flattened organic and paid export views |
| Required context | Check whether the supplied market settings are sufficient | `mobileResults` and `locationUule` |
| Wider collection need | Choose for the bounded rank-observation workflow | Page exports and optional AI or website-content tools |

The table summarizes the checked [Chronometrica contract](https://apify.com/chronometrica/google-search-scraper) and [Apify contract](https://apify.com/apify/google-search-scraper).

For a small keyword list, choose Chronometrica with confidence when its scope matches your need. The reason is its clear collection contract: each result has fields that identify the query, engine, position, and observation time. You can build a compact rank table from those fields.

This article is published by Chronometrica. The recommendation rests on documented fit and evidence checked on 20 October 2026. The evidence provides no measured comparison of speed, cost, accuracy, or long-term reliability.

## Check the result cap before you choose

Chronometrica documents `maxResultsPerExecutedQuery` as an integer from 1 to 100. This limit applies to each executed query. The checked schema accepts between 1 and 100 items in `queries`. These are separate limits: one sets the number of queries; the other sets the maximum returned rows for each executed query. [Chronometrica input schema](https://apify.com/chronometrica/google-search-scraper/input-schema).

If your original requirement is every result for a query and that requires more than 100 rows, Chronometrica does not meet that requirement. Changing the request to the first 100 rows changes the task. It does not complete the original request.

For a bounded check, choose a cap that answers your actual question. A first-10 observation can show whether a target appeared in the saved range and what rank the returned row reports. It cannot give a numeric rank for a target outside that range.

Keep the configured cap separate from the number of rows returned. A cap of 10 sets a maximum. It does not establish that the run returned 10 useful rows. Save both values so that a later reader can see the scope of the evidence.

The same rule applies to a fixed keyword list. A valid input does not prove that every keyword produced usable results. Check the returned query values before you mark the observation as complete.

## Use a small method to make the choice

### 1. Define the rank question

Write down the exact keyword list and target URLs before you run the Actor. Keep the submitted keyword text so that you can compare it with `executedQuery` in the output.

Then record the required context:

- Search engine.
- Country and language.
- Whether sponsored results belong in the observation.
- Maximum results per executed query.
- Any required city or device context.

Decide whether you are checking one page or any page on a domain. Those questions can produce different answers. If the task asks about one article URL, a different page from the same site does not meet that target rule.

A broad market preference also differs from a precise search setting. A country value does not prove a certain city, device, or signed-in context. If your decision depends on one of those details, resolve the collection settings before you accept the tool.

### 2. Set a Google-only input

Open the [Keyword Rank Snapshot Task](https://apify.com/chronometrica/google-search-scraper/examples/keyword-rank-snapshot) and inspect its saved input. The Task has historically included several search engines. Its title does not prove the current engine selection.

Set `engines` to `["google"]` explicitly. Use this checked input shape as a starting point:

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

Use a small method to make the choice

These supplied fields and values passed a check against the cached public input schema. That check confirms the input shape. It does not prove that a live run will reach Google or return the requested number of results. [Chronometrica input schema](https://apify.com/chronometrica/google-search-scraper/input-schema).

Replace the sample query with your fixed keyword list. Inspect the full input again before saving it. In particular, confirm the engine selection and sponsored-result rule.

The checked schema permits `country: "US"`. Do not assume that this input supports another country. If you need a different market, confirm a supported setting before you choose the collector. The supplied `language` value is a string; its presence alone does not establish a precise local search context.

### 3. Check the returned fields

Chronometrica documents result fields including `engine`, `executedQuery`, `country`, `language`, `page`, `rankOnPage`, `rank`, `canonicalUrl`, and `observedAt`. Together, these identify a result and the context in which it was observed. [Chronometrica documentation](https://apify.com/chronometrica/google-search-scraper).

Inspect those fields before you calculate movement. Use the returned `rank` for the rank observation. Do not use the row's position in an exported file. Sorting or combining files can change row order.

Keep `page` and `rankOnPage` as supporting fields. They help you inspect the position record without having to reconstruct it from an export.

Also check that `engine` is Google for each row used in the comparison. If you find another engine, keep those rows separate and correct the saved input. A rank from one engine cannot serve as the earlier or later Google rank.

### 4. Declare how URLs match

Use `canonicalUrl` as the returned field for comparison with your target. Write one URL matching rule and apply it to both observations.

For an exact-page check, start with exact matching. If you choose to ignore a trailing slash or remove certain tracking parameters, name those changes in the rule. Do not remove all query parameters without review. A parameter can identify a different page.

Keep the original returned URL beside any adjusted value used for matching. This lets you inspect a match later. It also helps explain why a page was accepted as the target.

Apply the same rule to both runs. If you change the rule between observations, check the earlier data again before you report movement.

### 5. Compare only compatible observations

Match the engine, executed query, market settings, sponsored-result rule, and URL rule. Check the saved caps too. A target found in a wider later range does not gain a known earlier rank if the earlier range did not contain it.

Use `observedAt` to label the observation time. Keep the collection settings with that observation so that you can explain a difference later.

When required context is unresolved, keep it visible. For example, a record can state that city or device context was not established. That is more useful than a precise-looking rank with no explanation of its scope.

## Build one useful rank record per target and keyword

Your analysis table should have one record for each keyword and target URL at each observation time. This is your rank record. It differs from the Actor's result rows: the result rows contain candidates, while your record states whether the target matched one of them.

Keep these values in each record:

- Keyword and target URL.
- Engine and market settings.
- `observedAt`.
- Found: yes or no within the returned range.
- Configured cap and actual returned row count.
- Observed rank, or unknown.
- Any unresolved context.

Retain the source result rows so that you can check a match. The compact record supports comparison; the result rows explain how you reached it.

Treat an unknown rank as a distinct value. Do not replace it with zero. Do not use the cap plus one as a substitute. Those values would imply a measured position that the saved results do not provide.

Also distinguish an inspected result set with no target match from a collection that produced no usable evidence. Both can leave rank unknown, but they need different follow-up. The first may call for a wider supported range. The second calls for checking the collection before drawing a rank conclusion.

## A fictional example: rank 7 becomes rank 4

This example is fictional. It is not an Actor test, a live dataset, or a customer result.

An analyst follows one target URL for a fixed Google query. Both saved observations use the same query, US market setting, English language setting, sponsored-result rule, URL matching rule, and 10-row cap.

In the first observation, the target appears at organic rank 7. In the second, it appears at organic rank 4.

The analyst calculates:

`7 − 4 = 3 places upward`

The useful conclusion is narrow and clear: the target moved upward by three places between these matched saved observations. The records do not establish that every person searching that query saw the same position.

For a second keyword, the target does not appear in the saved first 10 rows. The analyst records found as no and rank as unknown. The analyst does not enter zero or 11, and does not claim that Google removed the page.

Suppose the analyst later increases the cap and finds that target. The new rank can be saved as an observation. It cannot supply the missing rank from the earlier run. Any movement calculation still needs two known ranks from compatible observations.

This example shows why the cap belongs in the rank record. Without it, a reader cannot tell whether an unknown value reflects a narrow saved range or a different collection issue.

## Check the fit before you repeat the work

Use a small first run to answer a few acceptance questions. Confirm that the returned engine is Google, the executed queries match the list, and the result fields support your URL rule. Then check whether the returned range is useful for your targets.

Inspect at least one target match directly in the saved rows before you rely on the summary table. For a missing target, confirm what rows were actually returned. This check can catch an input or matching problem before it enters your history.

The supplied evidence includes a Chronometrica Google control that returned three useful capped rows. That supports Google availability in the checked observation. It does not establish persistent access, complete coverage, or future collection success. No new run was made for this comparison.

Once the first output is acceptable, save the input with the observations. Change it only with a clear reason, and record the change. A changed cap or URL rule can affect which comparisons remain valid.

For the existing Bing analysis method, use [How to Keep Comparable Bing Keyword Rank Snapshots](/en/articles/web-rank-snapshots/). Keep Bing observations separate from Google observations. The earlier guide supports the comparison method; it does not establish Google collection results.

## Start with the bounded Google rank check

Use [Chronometrica Google Search Scraper](https://apify.com/chronometrica/google-search-scraper) when your task needs a small, repeated result table and the checked settings meet your context needs. Its explicit per-query cap and saved result fields give you a clear basis for that work.

Open the rank Task, inspect its current input, and set `engines` to `["google"]`. Add your keywords, declare your target URL rule, and check the first returned rows before you repeat the collection. Keep ranks outside the saved range unknown. If your required context or result range exceeds the checked fit, resolve that requirement before you commit to the workflow.

## Sources

- [Chronometrica Google Search Scraper: product documentation](https://apify.com/chronometrica/google-search-scraper)
- [Chronometrica Google Search Scraper: input schema](https://apify.com/chronometrica/google-search-scraper/input-schema)
- [Keyword Rank Snapshot Task](https://apify.com/chronometrica/google-search-scraper/examples/keyword-rank-snapshot)
- [Apify Google Search Results Scraper: product documentation](https://apify.com/apify/google-search-scraper)
- [Public discussion about specific-keyword rank monitoring](https://www.reddit.com/r/SEO/comments/1dybuk8/any_tools_to_just_monitor_specific_keyword_ranking)
- [How to Keep Comparable Bing Keyword Rank Snapshots](/en/articles/web-rank-snapshots/)