JobPosting Schema

What JobPosting schema is and where it shows up

JobPosting is the schema.org type that describes a single open role: what the job is, who is hiring, where it is, what it pays, and when the listing expires. Google reads it to populate its job search experience, the prominent jobs module that appears when someone searches "marketing manager jobs near me" or similar. That interface aggregates listings from career sites, ATS platforms, and job boards, and the entry ticket is valid JobPosting markup on an indexable page.

Here is the part that stings if you run a careers section without it: the jobs module sits above classic organic results for hiring queries. Your beautifully written job page can rank number one organically and still sit below a stack of Indeed and LinkedIn entries pulled into that module, because they have the markup and you do not. I have seen mid-size companies get more qualified applicants from fixing schema on 40 job pages than from a quarter of paid job board spend. Not a promise, but a pattern.

One structural rule people miss: the markup belongs on the individual job detail page, one JobPosting per canonical URL. Google explicitly does not want the schema on list pages that show multiple postings, and marking up a category page with an array of jobs gets you nothing.

The properties that actually matter

Google's documentation splits properties into required and recommended, and the difference has teeth. Miss a required property and the page is ineligible. Skimp on recommended ones, especially salary and remote attributes, and you lose filters and placement inside the jobs interface.

How a job page gets into the jobs experience

How to detect the gap

• Rich Results Test: paste a live job URL. It reports whether JobPosting was detected and lists every missing or invalid property with severity.
• Search Console: the Job postings enhancement report under Enhancements shows valid, warning, and error counts across the site, plus which URLs share each problem. If the report does not exist, Google has not detected any markup at all, which is your answer.
• Screaming Frog: enable structured data extraction and validation in the crawl config, crawl the careers section, and filter the Structured Data tab for missing JobPosting on URLs matching your job page pattern. This catches template-level gaps at scale.
• Server logs: if Googlebot rarely hits new job URLs before they expire, markup alone will not save you. Crawl frequency is the other half of this problem.

How to implement it properly

1. Generate JSON-LD server-side per job page from the same database record that renders the visible content. Hand-written schema drifts out of sync with reality within a month; templated schema cannot.
2. Cover the required set first: title, description, datePosted, hiringOrganization, and jobLocation (or TELECOMMUTE plus applicantLocationRequirements for remote roles).
3. Add validThrough and baseSalary. Salary ranges are fine using minValue and maxValue. If your ATS does not expose salary, escalate it; the listing competes against ones that show pay.
4. Wire up expiration handling. The moment a role is filled or expired: either return 404 or 410, or keep the page and ensure validThrough is in the past. Advertising dead jobs violates the guidelines and Google has issued manual actions for exactly this.
5. Use the Indexing API for job URLs. This is one of the two official use cases (job postings and livestream events). Ping URL_UPDATED on publish and URL_DELETED on close, so short-lived postings actually spend their lifespan indexed.
6. Validate, then monitor. Rich Results Test on the template, then watch the Search Console enhancement report weekly. ATS template updates have a talent for silently breaking one property.

DO and DON'T

FAQ