Job posting schema
A job posting schema is the defined structure of a job record - the field names, types, and meanings - that lets job data from different sources be stored, searched, and exchanged consistently.
Also called: JobPosting schema, job data schema, job posting structured data.
Key points
- 'Job posting schema' means either schema.org's JobPosting type, or a product's internal canonical job record.
- A practical schema fixes the name, type, and meaning of core fields like title, company, location, salary, and dates.
- Salary and remote status are the hardest fields - inconsistent in the wild and easy to represent ambiguously.
- One consistent schema is what makes search, matching, analytics, and deduplication possible across sources.
Two things 'job posting schema' can mean
The phrase points at two related ideas. One is schema.org's JobPosting type - a standardized vocabulary, usually expressed as JSON-LD on a careers page, that tells search engines this is a job and here are its title, location, salary, and dates. The other is the internal schema a jobs-data product defines for its own records: the canonical shape every posting takes once it has been ingested, regardless of which ATS or board it came from.
Both exist to solve the same problem - job postings are wildly inconsistent in the wild - but they operate at different layers. schema.org JobPosting standardizes how a single employer publishes one job for crawlers. An internal job posting schema standardizes how a consuming system represents millions of jobs from thousands of sources.
Fields a job posting schema usually defines
A practical job posting schema converges on a core set of fields: a stable identifier, the source it came from, title, company, location, salary when disclosed, employment type, a remote indicator, the posted date, an expiry or last-seen date, an apply URL, and the description. The schema's job is to fix the name, type, and meaning of each, so that 'location' always means the same thing and salary is always represented the same way.
The fields that cause the most trouble are the optional and ambiguous ones. Salary is often missing, or a range, or hourly versus annual, or in different currencies. 'Remote' can mean fully remote, hybrid, or remote-within-a-country. A schema that does not decide how to represent these consistently pushes the ambiguity onto every downstream consumer.
Why a consistent schema is the whole point
The reason to normalize to one schema is that it makes job data composable. Search, filtering, matching, analytics, and deduplication all assume every record has the same fields with the same meaning. If a Workday job and a Greenhouse job arrive in different shapes, every one of those operations has to special-case the source - and that branching multiplies with every source added.
This is the core promise of a jobs-data API: not just that it collects postings, but that it returns every posting in one schema. A response where the field set depends on the source has only relocated the normalization work to you.
FAQ
What is schema.org JobPosting?+
It is a standardized vocabulary for marking up a job posting in a page's HTML, usually as JSON-LD. Employers add it so Google and other engines can read the job's structured details and show it in job-search results. It standardizes how one employer publishes one job; it does not, on its own, give you a feed of jobs across many companies.
Why not just use schema.org JobPosting as my internal schema?+
You can borrow its field names, and many products do. But schema.org JobPosting is permissive - most fields are optional and loosely typed - because it has to fit every publisher. An internal schema for a jobs-data product usually needs to be stricter: required identifiers, a fixed salary representation, a defined source field, consistent dates. Treat schema.org as a starting vocabulary, not a finished spec.
What makes salary hard to fit in a job posting schema?+
Salary is frequently undisclosed, so the field is often empty. When present it can be a single number or a range, hourly or annual, gross or net, and in any currency. A schema has to decide on a single representation - typically a minimum, a maximum, a period, and a currency - and accept that many records will only partly populate it.
JobsPipe is the jobs-data API behind this glossary - 30+ sources, one schema, 5,000 requests/month free.
Get a free API keyRelated