Sitemap or Indexing API? Getting jobs into Google for Jobs faster

"Can we send Google an XML feed?" is a common question at the start of job board and career site implementations. The answer is no, and it confuses people. With Indeed and most job boards you do deliver a feed, so why not here? Because Google for Jobs is not a job board but a part of the search engine: it gets filled by crawling, not by delivery.

There is no job feed to Google

With a job board like Indeed, you hand over an XML file and the board republishes your jobs on its own platform. Google for Jobs is not a job board in that sense. It is a layer on top of regular search results, and that layer is filled by crawling, like the rest of your site.

So Google takes everything from your own pages. It does that through JobPosting markup: structured data that tells Google your page is a job posting. That markup must sit on the same page as the job text the candidate reads, and that is where Google reads it too. Which fields are required is covered in the Google JobPosting documentation. A separate file with all your jobs simply does not exist in this model. There is an upside: there is only one truth, your website.

What you can influence is when those job pages get crawled. There are two channels for that, each with its own role.

The difference in plain terms

Channel one: the XML sitemap

A sitemap is a simple XML file that only says at which URL a job can be found, while a feed to Indeed carries the full job text along.

There are conditions. The most important one is lastmod: it must be as accurate as possible and reflect the real last change. Crawl budget is limited, and wrong timestamps lead to pointless recrawls of pages that never changed. Google reads the whole sitemap and recrawls the pages whose lastmod is newer than the previous crawl.

What counts as a real change for lastmod? An edited job text, a new salary, an extended closing date. What doesn't: a new date in the footer, a different banner, a regenerated page with identical content. A sitemap that stamps every URL with today's date on every deploy trains Google to ignore your lastmod, and then you have lost the very channel you wanted to steer with.

Beyond that, the same rules apply as for the markup itself: search result and list pages do not belong in the sitemap, and every URL in it must be the canonical page of that job. A sitemap full of filter pages costs crawl budget and returns nothing.

Channel two: the Indexing API

The Indexing API knows two signals: URL_UPDATED and URL_DELETED. Technically it is not complicated: you create a service account in Google Cloud, add that account as an owner in Search Console, and send a POST to the publish endpoint per job:

https://indexing.googleapis.com/v3/urlNotifications:publish

It gets harder when the system your job site runs on does not properly track when a change happens. Then you also don't know when to ring the doorbell.

Using the API is free. The default quota is 200 publish requests per day per project, meant for onboarding and testing. For more, you request approval through a form. Google can raise or lower that quota based on document quality, so poor job pages can literally cost you your quota.

Mind the scope too: the API may only be used for pages with JobPosting or BroadcastEvent markup. Abuse, such as setting up multiple accounts to dodge the quota, can get your access revoked.

What Google itself recommends

For job URLs, Google recommends the Indexing API over sitemaps, because Googlebot comes by faster. At the same time, they still advise submitting a sitemap for coverage of your whole site.

So it is not a choice between the two. You need both, with different roles: the sitemap for coverage, the API for speed.

That division of roles makes sense. Jobs are the shortest-lived content on your site: an average posting is live for three to six weeks. Waiting for the regular crawl cycle means a job sometimes only joins after a week, and by then a good chunk of its lifetime is gone. For your regular pages a week makes no difference, and there the sitemap is enough.

What the API does not do

Google accepts your submission, returns a 200 and puts the URL in a queue. That is all the 200 means. Validation only happens at crawl time, and the status endpoint only tells you when Google received your notification, not whether the page is indexed.

Faster crawling also repairs nothing about the content. A thin description stays a thin description, and a duplicate posting stays a duplicate. If your job still isn't in Google for Jobs after a successful submission, look at the eight causes from the previous chapter.

Expired jobs: the underrated half

For removing jobs, the advice is the same as for publishing: use the Indexing API with URL_DELETED, instead of quietly dropping the URL from the sitemap. A URL that disappears from the sitemap stays in the index until Google happens to pass by.

This is where most job sites drop the ball. They automate new postings, not the cleanup. The result is an index full of expired jobs, and that is exactly the pattern that can lead to a manual action.

What do you build in practice?

The order for a job site looks like this:

1. A sitemap, always, with a correct lastmod per job.
2. The Indexing API on top, as soon as you publish more than a handful of jobs per week.
3. The quota request before you hit the 200 per day, not after. Turnaround is days to weeks, and until then your submissions cap out.
4. A daily expiry job that pushes a URL_DELETED for every expired posting. Wire it to the same source as your sitemap, so sitemap and API always say the same thing.

With these four in place, the crawl side is covered. After that it comes down to the content itself, and for that there is the Google for Jobs checklist.