Google for Jobs structured data: the five required fields, and what breaks the rest

Google for Jobs structured data needs five properties, not fifty: datePosted, description, hiringOrganization, jobLocation and title. The rest of the work is plumbing - one role per URL, no markup on your jobs list page, no login wall, and a push to the Indexing API so Google crawls the page sooner than a sitemap would get it crawled.

In our view the plumbing, not the schema, is what defeats most small teams. Google's job posting structured data documentation was last updated on September 8, 2026, and the five required fields are short enough to hand-write in an afternoon. When we searched the phrase on October 23, 2026, the pages ranking for it were mostly applicant-tracking-system help articles and agency posts dated 2017 to 2021. We read the current Google documentation on October 23, 2026; everything below is what it says today.

What Google for Jobs structured data requires in 2026

Five properties are required. Google's docs describe each one narrowly, and much of what they warn about is markup that is present but wrong rather than missing.

Two of those have escape hatches worth knowing. hiringOrganization taking "confidential" means a company recruiting quietly does not have to choose between markup and discretion. And jobLocation is not required for a fully remote role as long as applicantLocationRequirements is there instead - which is the fix for the empty-address errors that remote-first companies hit.

The recommended fields that change who can find the role

Google lists the rest as recommended, which reads like "optional". These are the fields that carry employment type, pay and remote status, so in our view skipping them costs you reach among candidates filtering on exactly those things.

• validThrough - the expiry date. Google's advice is to omit it when the posting has no known end date, not to invent one.
• employmentType - FULL_TIME, PART_TIME, CONTRACTOR, INTERN and others. Multiple values are allowed.
• baseSalary - the real base pay. Google is explicit that "Only employers can provide baseSalary", so a board republishing your role should not be filling it in.
• identifier - your own job ID, which keeps duplicates straight when the same role is syndicated.
• jobLocationType - set it to TELECOMMUTE only for fully remote roles. Google's guidance is to leave it off a job that merely allows occasional remote work.
• directApply - whether the URL lets a candidate apply directly, without a detour.

Three more - educationRequirements, experienceRequirements and experienceInPlaceOfEducation - are marked beta in the docs, with effects that may not show in Search yet. In our view they are still worth filling in while you have the page open: the cost is a line of JSON, and a beta property in Google's docs is more likely to graduate than to disappear.

For remote roles, Google's wording on applicantLocationRequirements is firm: "At least one country is required" for work-from-home postings. "Remote (worldwide)" in the visible text with no country in the markup does not satisfy that.

One job per URL is the rule that breaks most careers pages

If your careers page is a single page listing every open role, markup on it is a guidelines violation, not a shortcut. Google's rule: "The JobPosting markup must only be used on pages that contain a single job posting." Search-results and list pages are called out by name.

Four more policies decide eligibility, and each maps to a real failure:

1. The markup must sit on the page with the visible description. If the description loads in an iframe pulled from your applicant tracking system, the crawler can end up with markup on a page whose text it never sees.
2. No login wall. Google's content policies say users "must be able to see the job posting details without the need to login."
3. No payment to apply. A posting that charges the applicant is not eligible.
4. Every posting needs a way to apply. A role with no apply path is not a job posting as Google defines it.

One thing to check before you write any JSON: Google's setup steps say "Be sure that your page is accessible to Google and not blocked by a robots.txt file, the noindex tag, or login requirements." In our view the quiet version of this is a careers subdomain stood up as a staging site and never unblocked.

How to add job posting structured data to a careers page

The order matters, because steps 4 to 6 are the only way to find out whether steps 1 to 3 worked.

1. Give every role its own crawlable URL. One role, one page, with the full description in the HTML a crawler receives.
2. Add a JSON-LD block with the five required properties plus validThrough, employmentType and identifier. JSON-LD is the format Google's own examples use.
3. Check access - robots.txt, the noindex tag, and any login or geo gate in front of the careers section.
4. Run the Rich Results Test on the live URL. It parses the markup the way Google does and names what is missing.
5. Inspect the URL in Search Console. Google's docs point to the URL Inspection tool to confirm the page is reachable, then to the rich result status report for errors across the site.
6. Submit the URL. Either a sitemap with an accurate lastmod value per job URL, or the Indexing API, which Google recommends specifically for job pages because it "prompts Googlebot to crawl your page sooner" than a sitemap does.

Then wait, and do not panic early: the documentation says to "Remember that it may take several days after publishing a page for Google to find and crawl it."

The Indexing API has a 200-a-day quota and a narrow job

The Indexing API is the fastest route from "we published a role" to "Google has seen it", and it is deliberately limited. Google's quickstart says it "can only be used to crawl pages with either JobPosting or BroadcastEvent embedded in a VideoObject" - job pages and livestream pages, nothing else. Pushing your blog posts through it is outside what the API covers.

The limits, from Google's Indexing API quota page as of October 16, 2026: publish requests default to 200 per day per project, covering both URL_UPDATED and URL_DELETED calls, resetting at midnight Pacific Time. Metadata lookups default to 180 per minute. For a company hiring for a dozen roles, 200 a day is not a limit you will ever feel - which is a reason to spend it on removals as well as new roles.

Setup, per the Indexing API quickstart: enable the API, create a service account, verify ownership of the site in Search Console, and get an access token. That is a one-time job for whoever owns your domain, and in our view verification is the step most likely to stall a team whose careers site sits on a subdomain nobody has claimed.

Expired roles are not optional housekeeping

Google's position is blunt: "We don't allow expired job postings." Three ways to retire one, all from the docs:

• Set validThrough to a date in the past.
• Remove the page so the URL returns a 404 or 410 status code.
• Strip the JobPosting structured data from the page.

Google also recommends using the Indexing API to request removal, which is the fast version of all three. The consequence of skipping this is not just a stale listing. Greenhouse's help article on Google for Jobs visibility, last updated March 2, 2026, warns that Google may remove job posts without notice and that "Google will not send an alert to the customer" - and names evergreen postings, with titles like "General Application" and "Join our Talent Community", as the kind that get flagged. If you keep a permanent talent-pool page, we would not put JobPosting markup on it at all.

Do you need an ATS for Google for Jobs?

No - but if you already have one, check what it emits before you write a line of JSON. Two vendor positions, both taken from their own pages, show why checking beats assuming.

Greenhouse says "Job posts on Greenhouse Recruiting automatically include basic metadata so Google can display your job posts in search results more easily", and lists the fields it does not add: address locality, street address, address region, postal code, employment type, valid through and base salary. Greenhouse's own position is that "Excluding these optional metadata fields does not impact whether the jobs show up on Google." We would read that narrowly: it is a claim about appearing at all, not about appearing to a candidate who filtered on pay, contract type or remote status.

Workable states on its Google for Jobs page that jobs posted through Workable in the US and the UK "plus a number of other countries" are automatically recognized, and that "The jobs you post will then be indexed by Google's search engine and appear in search results automatically." That page's metadata shows a last-modified date of September 26, 2023, and it does not name the other countries - which is why we would verify against a live job URL rather than the help article.

The check takes a minute: put one of your live ATS job URLs into the Rich Results Test and read what it found. That tells you whether to do nothing, ask your vendor for the missing fields, or move the canonical job page onto your own domain.

Upfynd lists 129 hiring and recruiting tools as of October 2026, and 452 products under HR and hiring more broadly. Paid distribution is the other half of this decision: if you are weighing a free careers page against job boards, our breakdown of what Indeed's free employer tier covers sets out what the three-post limit includes.

Where this still will not work

Google's jobs experience is not everywhere. The documentation describes it as available across Latin America, North America and Sub-Saharan Africa, and in selected countries in Asia, Europe, and the Middle East and North Africa. If you hire into a country outside that set, correct markup is still worth having - it is plain schema.org data that other search and aggregation tools read - but it will not produce a jobs widget in local results.

The other limit is what markup can do at all. Correct structured data makes a page eligible for the jobs experience. Whether Google shows it, and to whom, is Google's call, and no field in your JSON settles that.

Next step: take one open role, give it its own URL with the five required properties, and run the Rich Results Test on it before you touch the other nine. If you make hiring software, you can list it free on Upfynd for the people choosing tools.