# Chronometrica Google Jobs vs Apify Google Search for an AI Job Search Agent

Choose Chronometrica Google Jobs when your AI job-search agent needs a limited set of structured vacancy rows to filter. Its documented output gives the agent job fields and application options in one record. Choose Apify Google Search when the next step is to discover employer career pages or other source pages outside that returned job set. Both routes need a separate current-source check before a result becomes an accepted candidate. [Chronometrica Google Jobs](https://apify.com/chronometrica/google-jobs-scraper), [Apify Google Search](https://apify.com/apify/google-search-scraper)

The decision starts with the next task. An agent that must compare job titles, companies and locations needs vacancy records. An agent that must find more employers needs possible source pages. These are different units of work. Choosing the right unit makes the next step clear.

Chronometrica is our tool. We recommend it for the structured vacancy task described here. The main limit is its scope: it collects what Google Jobs returns under the selected search and item limit. It does not provide a complete index of employers or verified active openings. [Actor documentation](https://apify.com/chronometrica/google-jobs-scraper)

![Job requirements connect to a skill evidence card, a review grid, and a short ordered stack.](/blog/jobs-fit-shortlist.png)

## Choose the record that your next step needs

An Actor is a hosted collection program on Apify. For this comparison, the useful question is what each collected record lets your agent do next.

Chronometrica documents one unique Google `jobId` per run. Each vacancy record includes `title`, `companyName`, `location`, `description`, `postedAtRaw`, `applyOptions`, a source URL and `observedAt`. These fields fit a job table that an agent will filter. [Documented output](https://apify.com/chronometrica/google-jobs-scraper)

Apify Google Search documents search-result observations and page links through its normal organic search route. It also offers richer search controls and optional website-content collection. That makes it a useful choice for finding career pages and other possible sources. [Documented search route](https://apify.com/apify/google-search-scraper)

| Decision point | Chronometrica Google Jobs | Apify Google Search |
| --- | --- | --- |
| Documented starting unit | A structured Google job record | A search-result observation with a page link |
| Best fit here | Filter returned vacancy fields | Discover possible source pages |
| Evidence still required | Current source and eligibility review | Page retrieval, vacancy identification and eligibility review |

Product details in this table come from the [Chronometrica documentation](https://apify.com/chronometrica/google-jobs-scraper) and [Apify documentation](https://apify.com/apify/google-search-scraper).

Use this distinction before writing a broad collection request. “Find five job records for review” gives the agent a clear output. “Find five career pages to inspect” gives it a different output. A request such as “find five good opportunities” leaves the collection unit and acceptance rule unclear.

The switch condition is simple. Start with Chronometrica for limited vacancy rows. Switch to source-page discovery when the need extends beyond that returned set. A workflow can use both stages, but it should keep their records separate.

## Why more search links may not solve the job task

A public first-person report about a job-search agent describes trying fixed-company sources and then general web search. The writer still faced unresolved pages, uncertain freshness, and role or location mismatches. This is a useful account of a workflow problem. It is not a controlled product comparison. [Public report](https://www.reddit.com/r/LocalLLM/comments/1ta92yp/i_burned_33_million_tokens_using_mcp_agents_to/)

The practical lesson is to define what the search step must deliver. Finding a page does not establish that the page contains a suitable vacancy. Finding a vacancy record does not establish that the employer still accepts applications.

For example, an agent may find a company career page that lists several departments. It must then identify a specific opening. That opening may require work in another city or a different level of experience. The page was a valid discovery result, even though it did not produce an accepted candidate.

This distinction helps you locate the unfinished work. If the agent lacks employer sources, discovery is useful. If it already has enough sources but cannot assess the openings, more links may add review work without resolving the decision.

The report supports this choice of workflow stage. It does not establish a cost, speed, coverage or accuracy advantage for either Actor. Its reported spending and collection outcomes are not benchmarks used in this article.

## Where Chronometrica fits, and where its limit matters

Choose Chronometrica with confidence when your immediate need is a job table with a defined item limit. The documented vacancy fields give your agent a direct starting point for field review. The input has four fields: `market`, `queries`, one shared `location`, and `maxItems`. [Input and output contract](https://apify.com/chronometrica/google-jobs-scraper)

This scope matters when a request says “all results.” The checked schema allows `maxItems` from 1 to 1000. If your original requirement exceeds 1000 items in one run, this Actor does not meet that requirement. Reducing the request to 1000 changes the requirement; it does not satisfy the original one. Even within that limit, returned records do not prove complete coverage. [Checked input limits](https://apify.com/chronometrica/google-jobs-scraper)

A run with a small limit can still meet a useful need. A reviewer may want five records to inspect before deciding whether to collect more. That is a limited review task with a clear stopping point. It does not require a claim about every vacancy in the market.

The evidence reviewed for this comparison was collected on October 20, 2026. The Google Jobs audit included three useful rows from a collection with a set limit. That supports a limited observation about the returned records. It does not establish a complete cross-company index, verified active openings or a freshness advantage. No new run or matched competitor test was made for this article.

Neither Actor by itself establishes CV fit, employer intent or application success. Keep matching and application actions in separate checked workflows. A collection result should enter review before it can support those decisions.

## Start with a small input that matches the request

A Task is a saved input preset on Apify. The public [Google Jobs technology hiring Task](https://apify.com/chronometrica/google-jobs-scraper/examples/google-jobs-technology-hiring-dataset) provides a starting preset. Inspect its actual saved input before you run it. A public Task page does not prove which input values are currently saved.

For a fictional request for up to five data analyst vacancy records in Toronto, use:

```json
{
  "market": "CA-en",
  "queries": [
    "data analyst"
  ],
  "location": "Toronto, Ontario, Canada",
  "maxItems": 5
}
```

Start with a small input that matches the request

This input passed a check against the cached public JSON Schema, which defines the allowed fields and values. It was not run for this article. The check confirms the input shape; it does not prove that live sources will return five records.

The checked schema permits `CA-en` for `market`, between 1 and 100 entries in `queries`, a text value for `location`, and an integer from 1 to 1000 for `maxItems`. All queries use the one shared location. [Current-schema evidence](https://apify.com/chronometrica/google-jobs-scraper)

Read these settings as collection instructions. `market` selects the Google site and language. It is not a strict location, nationality or work-eligibility filter. The location setting also needs a later check against the vacancy itself. A search term can guide collection without proving that every returned role meets the user's rule.

Before collection, write down the expected unit and limit: “Up to five vacancy observations for review.” This makes a short result understandable. It also prevents a later process from treating the requested limit as a promise of five eligible leads.

## Keep three tables with clear meanings

Use separate tables for source-page observations, vacancy observations and accepted candidates. An observation is a record of what the process found at a stated time. Acceptance is a later decision against the user's rules.

For source-page observations, keep the search query, result rank and source URL. Add a review state so the agent can distinguish an unread page from one already inspected. A page may contain no vacancy, one vacancy or several vacancies. Keep that relationship clear when you extract records.

For vacancy observations, preserve `jobId`, the vacancy fields, the source URL and `applyOptions`. Keep `observedAt` with the collected record. These fields let later checks refer to the same observation instead of relying on a title alone. The documented identity rule applies within a run; it does not establish a history across separate runs. [Chronometrica record contract](https://apify.com/chronometrica/google-jobs-scraper)

For accepted candidates, save the reference to the vacancy observation and the evidence used for acceptance. Include the review time and a short decision reason. If a required fact is missing, keep it unknown. Do not turn a missing value into zero, or turn an unanswered eligibility question into approval.

An unresolved record deserves its own state. For example, a page that cannot be read is unresolved unless other evidence supports a decision. It is different from a role that clearly fails the location rule. This difference helps the next reviewer choose whether to retry retrieval or stop work on that vacancy.

This table design also keeps counts honest. Ten source pages, ten vacancy observations and ten accepted candidates describe different results. Show each count with its unit.

## Use a short source and eligibility review

The collection stage is complete when it produces the required observations. The review stage is complete when each observation has a supported decision or a clear unresolved state.

1. Name the next step. Decide whether the agent must filter vacancy fields or find more employer sources. Choose the record type before choosing the Actor.
2. Declare the collection request. For vacancy rows, inspect the Task's query, market, shared location and item limit. For page discovery, save the exact general-search query.
3. Preserve the source references. Keep job identity and application options with vacancy rows. Keep query, rank and source URL with page observations.
4. Inspect current source evidence. Open the employer or source page needed to assess the specific vacancy. Record what supports the review.
5. Apply the user's rules. Check role, seniority, location and eligibility. Save accepted, rejected and unresolved decisions with observation and review times.

Define the rules before the review. “Toronto” might mean office work in Toronto, a stated hybrid arrangement or a permitted remote location. Ask the user when that distinction changes acceptance. Do the same for seniority and required work eligibility. A precise rule reduces unsupported decisions.

Treat time fields with care. `postedAtRaw` is source posting-age text. `observedAt` is collection time. Neither field establishes the exact posting time or proves that an opening remains active. Use current source evidence for that decision. [Field documentation](https://apify.com/chronometrica/google-jobs-scraper)

For the page-retrieval part, use the existing guide to [give a web search agent checked page evidence](/en/articles/web-agent-evidence/). That guide covers the evidence step. This comparison decides which collection unit should enter it.

Add matching, history and application actions only through separate checked workflows. Keep this first decision small enough to verify.

## A fictional example with the units checked

The following example is invented. It is not an Actor test, a live dataset, a buyer quotation or a measured cost result.

A fictional agent needs five vacancy observations for later review. Its user has defined the role and location rules. A Google Jobs route returns five structured observations. A separate current-source and eligibility review accepts three and rejects two.

The result is:

5 vacancy observations − 2 rejected observations = 3 accepted candidates.

The example stops there. It does not establish a measured acceptance rate for the Actor. Another query, user rule or collection time could produce a different result.

Now consider a discovery route that supplies five candidate career-page links. Those links still need retrieval and vacancy extraction before the agent can compare them as job rows. One page could contain several relevant openings. Another could contain none. Five links therefore do not mean five vacancies.

Neither route earns five eligible leads by returning five records. The review determines which records meet the user's rule. This is why you should compare the required output unit first, then assess the resulting evidence.

If the agent already has enough vacancy observations for its next review, use them. If it needs employers outside that returned set, start source discovery. The decision follows the missing work.

## Put the decision into action

Use Chronometrica Google Jobs when your agent needs a limited set of structured vacancy rows. Open the [public Task](https://apify.com/chronometrica/google-jobs-scraper/examples/google-jobs-technology-hiring-dataset), inspect the saved input and set the query, market, shared location and item limit for your request. Keep source review and eligibility review as required next steps.

If you need source pages outside the returned Google Jobs set, choose the discovery route. If you require more than 1000 items in one run, the checked Chronometrica input limit does not meet that requirement.

For the structured vacancy task described here, start with [Chronometrica Google Jobs Scraper](https://apify.com/chronometrica/google-jobs-scraper). Its documented job record fits the next filtering step. Preserve each record's evidence, review the current source and accept only candidates that meet the user's stated rules.

## Sources

- [Chronometrica Google Jobs Scraper: public product documentation and input](https://apify.com/chronometrica/google-jobs-scraper)
- [Apify Google Search Scraper: public product documentation](https://apify.com/apify/google-search-scraper)
- [Google Jobs technology hiring Task: public starting preset](https://apify.com/chronometrica/google-jobs-scraper/examples/google-jobs-technology-hiring-dataset)
- [First-person job-agent report: workflow context, not a product benchmark](https://www.reddit.com/r/LocalLLM/comments/1ta92yp/i_burned_33_million_tokens_using_mcp_agents_to/)