Is there a Google Jobs API?

The short answer

If you are searching for a Google Jobs API, you are almost certainly after one of two things: a way to read the job listings that appear in Google for Jobs, or an API to add job search to your own product. Here is the situation before the detail.

There is no official, public API for Google for Jobs. It is a feature of Google Search, not a developer product, and Google does not expose its job index for querying. The one official Google product that had “job search” in its name, Cloud Talent Solution, was a different thing entirely and has been deprecated. The services that sell you a “Google Jobs API” are third-party scrapers of the search results page.

If your actual goal is job-postings data, the better path is to skip Google as a middleman and read postings from the sources Google itself aggregates from. The rest of this guide explains why the term is so confusing, what each option really is, and what to do depending on what you are building.

Three things called “Google Jobs API”

The phrase “Google Jobs API” gets attached to at least three unrelated things. Most of the confused answers online come from someone addressing one of them while the reader meant another.

Notice that none of these is what most people picture when they imagine a “Google Jobs API”: an official endpoint that returns the job postings Google knows about. That product does not exist. The sections below take each in turn.

Cloud Talent Solution, and why it's gone

Cloud Talent Solution, originally launched as Cloud Job Discovery, was a Google Cloud product aimed at companies running job boards, applicant tracking systems, and staffing platforms. It offered machine-learning job search: you loaded your own job postings into it, and it provided query understanding, synonym handling, commute-based search, and relevance ranking you could embed in your own product.

The key thing to understand is what it was not. It was never a way to read job postings out of Google. It was infrastructure for running search over your own jobs. A staffing company with 50,000 listings could use it so their candidates got Google-quality search on the staffing company’s site. The jobs going in were the customer’s jobs, not Google’s.

Google has since deprecated the product. The documentation that still ranks at the top of search results for “google jobs api” is legacy material. New work should not be built on Cloud Talent Solution, and if you find a tutorial pointing you to it, check the date - it is almost certainly outdated.

So if you arrived at Cloud Talent Solution hoping for a feed of job listings, it was the wrong product even when it was alive. And it is no longer a live option regardless.

Google for Jobs has no public API

Google for Jobs is the enriched job-search experience inside Google Search - the boxed widget of job listings that appears when someone searches for, say, “marketing jobs near me”. It launched in 2017. It is not a website of its own and not a separate product; it is a feature of the search results page.

It works by aggregating job postings from across the web. When an employer or job board publishes a posting with JobPosting structured data - the schema.org markup that describes a job in machine-readable form - Google can read it, fold it into the Google for Jobs index, and show it in that widget. Large job boards also feed Google through other arrangements.

What Google does not do is expose that index for querying. There is no jobs.googleapis.com that returns the listings. You cannot ask Google for “every software engineering job in Austin posted this week” through an API. The only supported way to interact with Google for Jobs as a data source is to look at it in a browser.

This is a deliberate product decision and unlikely to change. Google for Jobs sends traffic to employers and boards; it is not designed to be a wholesale data supplier. Which is exactly why a market of third-party scrapers exists to fill the gap.

The “Google Jobs API” products are SERP scrapers

Search for “Google Jobs API” and most results are commercial products from companies like SerpApi, Bright Data, Scrapingdog, and SearchApi. These are real, working products. They are also not what their name suggests.

Every one of them works the same way underneath: they send searches to Google, capture the Google for Jobs widget that appears in the results, parse the listings out of the page, and return them to you as structured JSON. They are SERP scrapers - search-engine-results-page scrapers - pointed at the jobs widget. The “API” is their API, wrapped around Google’s search page. It is not Google’s API.

That distinction has practical consequences:

• You get Google’s downstream view. Google has already aggregated, deduplicated, ranked, and filtered the postings. You receive that processed result, not the raw source data, and you inherit whatever Google chose to show or hide for that query.
• It is query-shaped, not feed-shaped. You get results for the specific search you ran, in the order Google ranked them, capped at what the widget displays. Comprehensive coverage of a market means running and paying for a very large number of queries.
• Terms of service. Scraping Google search results conflicts with Google’s terms. Using a third-party provider moves the activity off your infrastructure but does not resolve the underlying conflict.
• Fragility. When Google changes the layout of the jobs widget, scrapers break until the provider updates. You depend on a parser of a page Google can change at will.

None of this makes these products useless. For ad-hoc research, for checking how a given job ranks in Google for Jobs, or for light use, they are convenient. But to build a product on a steady supply of job-postings data, you would be building on Google’s downstream copy through an unofficial scrape.

The Indexing API: getting jobs in, not out

There is one official Google API that genuinely touches job postings: the Indexing API. It is worth knowing about precisely so you can rule it out for data retrieval.

The Indexing API lets a site notify Google directly that a page has been added or removed. Google supports it specifically for pages with JobPosting (and BroadcastEvent) structured data. If you run a careers site or a job board, you can call it to tell Google “this new posting exists, crawl it” or “this posting is filled, drop it” - which keeps your listings in Google for Jobs fresh.

The direction matters. The Indexing API moves data into Google. It is for publishers who want their own postings to show up in Google for Jobs promptly. It returns nothing useful to anyone trying to read job data. If your goal is to publish jobs and rank in Google for Jobs, it is relevant; if your goal is to consume job data, it is not.

What to actually do

Strip away the naming confusion and there are really two distinct goals behind “Google Jobs API”. Sort yourself into one.

If you want your jobs to appear in Google for Jobs

You are an employer or a job board, and you want your postings in that widget. There is no API call that does this directly. The path is: publish each posting with valid JobPosting structured data, make sure the pages are crawlable, and optionally use the Indexing API to speed up discovery and removal. This is an SEO and structured-data task, not a data-API task. Google’s own job-posting structured-data documentation is the reference.

If you want to read job-postings data

You want a supply of job postings to power a product - a search tool, an aggregator, a sourcing platform, a labor-market dataset. Scraping Google for Jobs is the option most people reach for first because of the name, and it is the wrong instinct. You would be reading Google’s downstream, filtered copy through an unofficial scrape.

The better path is to go upstream. Google for Jobs is built from job postings that already exist on company career pages and job boards. Those original sources are where the data is freshest and most complete - before Google aggregated it, ranked it, and trimmed it to a widget. Reading them directly means you are at the source, not three steps removed from it.

That is what a jobs-data API does. JobsPipe reads job postings directly from the ATS-hosted career pages and job boards that Google for Jobs itself aggregates from - Workday, Greenhouse, Lever, Ashby, and 30+ more - and returns them in one normalized schema. The same underlying postings Google for Jobs is built on, without Google as a middleman, with full fields and no SERP-scraping in the path.

Decision guide

Run through these in order.

1. Do you want your own job postings to show up in Google for Jobs? Publish valid JobPosting structured data and use the Indexing API. No data API is involved.
2. Do you need a one-off look at how jobs rank in Google for Jobs? A third-party SERP scraper (SerpApi, Bright Data, and similar) is a reasonable, convenient choice for ad-hoc use.
3. Are you building a product on a steady supply of job-postings data? Skip Google as a middleman. Read postings from their original sources through a jobs-data API. That is what JobsPipe is for.
4. Were you looking for Cloud Talent Solution to add search to your own site? It is deprecated. Evaluate a current search product, and bring your own job data to it.