Chronometrica vs ScraperLink: Why One Google Results Page Can Look Duplicated

Start with the unit you are counting

A dataset item is one saved object. It does not always represent one search result. A page object can hold several results inside a list. A list stored inside another object is a nested array.

Before you count results, identify what each saved item represents. Two objects can present two views of the same observations. If your import expands both views, its total can exceed the number of observations you intended to use.

The public ScraperLink issue records a reader concern about duplicated results. It is historical and closed. It supports the reader question, but it does not establish a current bug or outage. Historical duplicate-results issue

The public product contracts used here were checked on October 20, 2026. No matched collection run or live result check was made. This comparison explains documented inputs and output formats.

Three counts answer different questions:

• Dataset items: How many objects were saved?
• Result observations: How many result entries belong to the selected searches?
• Unique destinations: How many distinct target pages appear in those entries?

Choose your count before you inspect the total. A correct count of saved objects can still give the wrong answer about search results.

Apply the direct fix to your current request

Use this ScraperLink input for the supplied example:

{
  "keyword": "Nike",
  "limit": "10",
  "page": 1,
  "include_merged": false
}

The current public input contract supports these settings. Keep `limit` as the string shown here. The example requests one bounded page with merged output disabled. ScraperLink default build and input schema

Replace `Nike` with your intended query. Inspect the output before you send it to another program.

Find the nested result list in the selected page item. Count its entries. Then check which object your import reads and which list it expands. The import should use the intended representation once.

Do not multiply the list length by the number of saved objects. First establish whether those objects contain separate observations or different views of the same observations.

Keep this first request small. Its purpose is to check the output format and your counting rule. If the page item already works with your next step, you have addressed the immediate need. Consider a tool change only after you define a separate requirement that the current process does not meet.

Compare the output your next step needs

An acceptance rule is a condition that output must meet before you use it. Use the table to write that rule. The input row lists settings for these examples; it does not claim that every field is mandatory.

The product columns use the current documented contracts. ScraperLink Actor, Chronometrica Actor, Chronometrica input schema

Expansion means turning each entry in a nested list into a separate row. During expansion, retain the search context that belongs to each entry.

A working expansion step can remain part of your process. The choice depends on the receiving system. If it accepts page objects, a change of output format may add no useful value. If it requires individual observations, decide whether to keep your expansion step or receive that row format directly.

A fictional example: two objects do not prove twenty results

This example is fictional. It is not a product test, measured result, or customer case.

An analyst requests one page. In this invented example, the raw page contains 10 nested result observations. An optional merged object repeats those same 10 observations.

The analyst sees two saved objects. Their import expands both:

10 observations from the raw page
+ 10 repeated observations from the merged object
= 20 imported sightings

The arithmetic is correct: 10 + 10 = 20. The interpretation is wrong. The intended count for this one page is 10 observations. The spreadsheet contains two copies of each observation because the import used both representations.

The analyst disables merged output. They then read the raw page’s result list once and check its length. In this fictional example, that prevents the double expansion.

This example does not show that an Actor fetched a page twice or charged twice. Saved-object counts alone do not establish either event.

The analyst faces a later choice when another API requires each submitted item to represent one observation. They can keep the expansion step or choose an Actor whose documented output already matches that requirement.

Chronometrica fits that later row requirement. The invented total provides no evidence of a collection performance advantage.

When Chronometrica is the useful fit

Chronometrica documents one search-result observation per dataset row, with engine, query, rank, and context. It also documents `maxResultsPerExecutedQuery`, which sets a result-row cap for each executed engine and query. Chronometrica Actor

Use this supplied input example as a starting point:

{
  "queries": [
    "Nike"
  ],
  "engines": [
    "google"
  ],
  "maxResultsPerExecutedQuery": 10,
  "country": "US",
  "language": "en"
}

The keys, required fields, allowed values, list bounds, and number bounds were checked against the current public schema. This example was not run. Chronometrica default build and input schema

The cap is an upper bound. It is not proof that a request will return exactly 10 observations. Check the actual output before you report its count.

This format fits a spreadsheet that stores one observation on each row. It also fits an API that expects one observation in each submitted item. The saved unit matches the unit that the next step needs.

That match removes the need to expand a nested result list first. You still need to select the fields your system uses, preserve unknown values, and check the output. You may also need a separate list of unique destinations.

Choose Chronometrica for this checked fit. The available evidence does not establish a speed, reliability, accuracy, or cost advantage. Confirm any other required feature from current documentation before you move.

Use five checks before you change tools

1. Read the current merged-output setting. Identify which output representation your process needs. Keep the immediate counting problem separate from the later choice of row format.
2. **Request one bounded page with `include_merged:false`.** Record the exact input. This lets you connect the output to the query and page you requested.
3. Count nested result entries. Inspect the selected raw page’s result list. Check that your import reads that list once. Compare the number of entries with the number of rows created by expansion.
4. Define the unit required by the next step. Write one sentence, such as: “Each imported row must represent one result under one exact query.” Use that sentence as your acceptance rule.
5. Keep search context before making a unique destination list. Retain the engine, exact query, rank, and available time information. Label any time recorded by your own process as your recorded time.

These checks create two decisions. First, decide whether you can count the current output correctly. Then decide whether its saved unit suits the next system.

For a manual spreadsheet, an expansion step may be easy to inspect. For a repeated import, direct result rows may better match the receiving system. Check the work your process requires before you assume a time saving.

If you later compare costs, define the billing unit separately. A saved object, a result observation, and a billed search are different concepts. A merged-output total does not establish the number of billed searches or a price advantage.

Check the import before using its totals

Make the acceptance rule specific enough to inspect. “The output looks right” gives you little help when totals differ. A useful rule names the source list, the unit being counted, and the context that each imported row must retain.

Start with the selected output before expansion. Count its intended observations. Then inspect the rows created from that output. If those totals differ, check which objects and lists the import reads before you remove rows.

A rule that deletes repeated URLs can hide the cause of a counting error. It can also remove valid observations from separate queries. Correct the selection of output representations first. Build a unique destination list only when you need that separate count.

Record the result of the check in plain terms. State whether you counted page objects, observations, or destinations. This makes the total useful to someone who did not inspect the original output.

Keep observations separate from unique destinations

The same destination can appear under different queries. Those appearances can be separate observations even when they point to the same page.

A unique destination list answers which pages appeared. Observation records answer where a page appeared for each query and rank. Keep both outputs when you need both answers.

Build the destination list from the observation records. Retain those records so that you can trace a destination back to its search context. Do not delete an observation solely because its URL also appeared under another query.

The distinction also helps when two people report different totals. One may have counted observations while the other counted destinations. State the unit before you treat their totals as conflicting results.

For the later task of combining exports across runs, see How to Merge Bing Search Exports Without Losing Query and Rank Evidence. That guide concerns cross-run merging. This comparison starts earlier, with the choice between output representations and saved units.

Preserve unknown values during import

An absent value does not mean zero. A missing rank should not become rank zero. An unknown count should not become a confirmed count of zero.

Keep an unknown value empty or use the missing-value form your receiving system supports. Document that choice so later calculations do not treat missing data as a measured result.

Apply the same rule to time. Do not invent a source timestamp. If you know only when your own process received the data, store that time with a clear label.

Check these rules with either output format. Separate rows can be easier for a receiving system to accept, but they still need correct interpretation. A valid row count does not prove that every field is present or that each value means what your report assumes.