Chronometrica vs Axiom Works for Bing Search Result Exports

Start with the discovery decision

The reader's problem starts before page scraping. You need to find URLs that might lead to useful content. Choosing a search Actor means choosing which search records and result types will support that work.

A public question about finding URLs before scraping supports this discovery need. The supplied source is a search excerpt. It does not define a complete crawl requirement, endorse either product, or prove that search snippets contain the required page text.

Write one sentence that defines an acceptable destination for your project. In a fictional tutorial project, that rule could be: “Accept public pages that contain a complete machine learning lesson.” This gives you a content requirement to apply after discovery.

Next, decide which search result types you need to find those pages. Use the switch condition in the lead. A clear observation record fits the small discovery job described here. Additional discovery requirements can change the product choice.

Keep these decisions separate. The search Actor supplies candidates and search evidence. Your destination checks determine whether a candidate meets your content rule. A suitable search export does not make every returned page suitable.

Why Chronometrica fits a capped observation table

An observation is one saved search result in its query context. The same destination can produce several observations when it appears for several queries.

Chronometrica documents these fields for each observation:

• `runId`: the collection run associated with the observation.
• `engine`: the search engine used.
• `executedQuery`: the exact query used.
• `page`: the search result page.
• `rankOnPage`: the result position on that page.
• `rank`: the recorded result rank.
• `canonicalUrl`: the destination URL recorded by the Actor.
• `resultDomain`: the result's domain.
• `observedAt`: the observation time.

These fields define its documented record for each engine and query. The input also provides a cap for each executed query. Chronometrica output and input documentation

That structure helps you answer a practical question: why did this page enter the queue? You can trace it to the exact query, recorded rank, and observation time. You do not have to infer that history from a list of URLs.

Suppose a page appears for both queries in your discovery request. Keep both observations. They record two search appearances, even though you have only one distinct destination to check.

This is the supported reason to choose Chronometrica. Its documented observation record gives you a clear source record before you accept destinations. Its cap lets you define a small discovery pass that you can review.

A recorded rank remains a search position. It is not a score for page quality, accuracy, or suitability. Use rank to retain search context, then apply your content rule to the destination itself.

Check whether the cap meets your requirement

Chronometrica's `maxResultsPerExecutedQuery` sets a maximum for each executed query. The checked schema accepts integers from 1 through 100. Its `queries` array accepts 1 through 100 entries. Chronometrica input schema

A cap is a ceiling. It does not promise that the Actor will return that many observations. A setting of five permits up to five saved observations per executed query. It does not promise five distinct URLs or five acceptable pages.

This fits a small discovery job. You can review the candidates, assess the queries, and decide whether another search round is useful. Set the cap from the amount of evidence you need and can assess.

If your original requirement exceeds 100 saved results from one executed query, Chronometrica does not meet that requirement under the checked schema. It also does not meet a requirement to export every Bing result without a limit. Changing the queries does not satisfy an all-results requirement for the original query.

The supplied evidence includes small successful checks across the four documented engines. Those checks do not prove complete or lasting coverage. This comparison concerns Bing only, and the example input selects only Bing.

Write the required scope before collection. “Review up to five observations for each of two queries” is a clear, limited request. “Find every relevant page” requires evidence that this capped export does not provide.

Use the Bing Task with explicit input

The product name includes Google, but Chronometrica's public contract explicitly supports Bing. For this comparison, set `engines` to `["bing"]`. Chronometrica documentation

A Task is a saved input preset for an Actor. The public Bing Search Results Scraper Task provides a starting preset. Its recorded page check returned HTTP 200, a successful page response. That check does not prove its current saved input.

Inspect the preset and apply the settings you require before a run. The following fictional discovery request uses two queries and a five-observation cap:

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

This input passed a check against the cached public JSON Schema. A JSON Schema defines allowed input fields and values. All supplied field names exist in that schema. This was an input-shape check. No collection run was made for this comparison.

The checked schema permits only `US` for `country`. It accepts text for `language` and a true-or-false value for `includeSponsoredResults`. The `engines` array requires at least one entry. Chronometrica input schema

Keep the exact field names when you enter the input. A valid input does not prove live Bing availability or destination suitability. It establishes that the request follows the checked input contract.

The two queries express two intended searches. Their wording does not guarantee different destinations. Review the overlap in the saved observations before you count distinct candidate pages.

Fictional example: eight observations and five destinations

This example is invented. It is not an Actor test, a live dataset, a buyer quote, or a measured cost result. Only the input shape above was checked against the schema.

Suppose each query returns four observations. Each query set contains four distinct destinations. Three destination URLs appear in both sets.

The first query finds pages A, B, C, and D. The second finds pages A, B, C, and E. These letters are fictional page labels.

The arithmetic is:

1. Four observations plus four observations give eight search observations.
2. Three destination URLs repeat across the two query sets.
3. Eight observations minus three repeated destinations give five distinct candidate pages.

Keep all eight search observations. Create a separate queue with five destination entries. Link pages A, B, and C to two observations each. Link pages D and E to one observation each.

This is a many-to-one link: several search observations can point to one destination entry. It preserves discovery history while allowing you to assess each distinct destination separately.

The units matter. Eight observed search rows and five candidate pages describe different things. Neither count tells you how many pages you will accept.

Suppose later checks accept three pages, reject one, and leave one unresolved. These outcomes are also fictional. The unresolved page stays unknown until you have enough evidence to decide. Do not count it as an empty document or replace a missing value with zero.

Follow five steps from product choice to page checks

1. Define the destination and discovery needs. State what a suitable page must contain. Decide which search result types are required. Apply the product switch condition before collection.

Use a rule that another person can check. “A useful page” leaves too much unclear. The fictional rule “a public page with a complete machine learning lesson” gives the destination review a defined purpose.

1. Select Bing and set the cap. For Chronometrica, use `engines: ["bing"]` and set `maxResultsPerExecutedQuery` within the documented range. Confirm that the limit meets the original requirement. Chronometrica input documentation

Record the intended query set and scope. If the requirement exceeds the cap, resolve that product choice before the run. Do not describe a limited result set as complete coverage.

1. Preserve each observation. Keep the engine, exact query, rank, and observation time with each result. Retain the other documented context fields in the export.

Save these records before you remove duplicate destinations. A unique URL list cannot show which queries found each page unless you retain the links to the original observations. Search snippets belong with this search evidence. They are not fetched destination documents.

1. Build a separate destination queue. To normalize URLs means to put comparable URL forms into a consistent form. Apply clear rules, then remove duplicate destination entries without deleting the original search records.

Do not assume that every URL difference is harmless. A query parameter can change content. Merge entries only when your rules support treating them as the same destination. Keep each observation linked to its queue entry. The search result deduplication guide explains this step in more detail.

1. Fetch and assess each allowed destination. To fetch a page means to request the destination page itself. Check its content and source status before you use it. Record an accepted, rejected, or unresolved outcome.

A returned URL identifies a candidate. It does not prove successful retrieval. A snippet does not replace the page check. Use How to Build a Crawl Queue From Bing Search Results for the full acceptance method.

Check the export before you adopt the process

Review a small output set against your stated need. First, inspect the search records. Confirm that you can identify the executed query and recorded rank for each observation. Check that repeated destinations link to one queue entry without losing their search history.

Next, inspect the destination decisions. An accepted page needs evidence that it meets your rule. A rejected page needs a reason for rejection. An unresolved page needs to retain its unknown status.

This distinction prevents a failed page check from becoming a false content claim. If you could not assess a page, you do not yet know whether it contains the required material.

Keep counts for each stage separate: search observations, distinct candidate URLs, fetched pages, and accepted pages. A count from one stage does not establish the count at the next stage. The fictional example shows why eight search rows can lead to five candidate destinations and fewer accepted pages.

The supplied evidence does not establish a measured price, speed, accuracy, or reliability advantage. The recommendation rests on the documented observation record and per-query cap. These are useful strengths when your job is to preserve a small Bing discovery set before destination approval.