Job posting schema for web extraction

A job posting schema captures the fields recruiters, job boards, and labor-market analysts care about: the role title, hiring company, location, whether it is remote, the salary range, employment type, and how to apply. People extract this to aggregate openings into a single board, track hiring trends across companies, benchmark compensation, or alert candidates when roles that match their criteria appear. A schema turns each posting into a clean, comparable record instead of free-form prose. Job listings vary a lot in wording, which is exactly where describing fields beats hand-tuning selectors per site. You define what a salary range or an employment type is, and the model reads it from the rendered page regardless of how that page lays it out. Fields that a posting omits, like a salary that the employer chose not to publish, come back as null rather than a fabricated number, so your compensation data stays trustworthy and you can clearly separate "not disclosed" from "not found".

Fields in a Job posting schema

The fields teams most often extract for a job posting, what type each one is, and whether it is usually present.

Field	Type	Required	Notes
title	string	yes	The job title as advertised, such as Senior Backend Engineer. This is the primary field for matching, search, and grouping, so it is required rather than optional.
company	string	yes	The name of the hiring organization as shown on the posting. Used to group openings by employer and to join postings against company records you already hold.
location	string	optional	Where the role is based, typically a city and region or country. Returned as written on the page, which preserves details like a specific office or a multi-city listing.
remote	boolean	optional	Whether the role is offered as remote, expressed as a true or false flag. Lets you filter for remote-friendly openings without parsing varied phrasing like hybrid or work from home.
salaryRange	string	optional	The advertised pay range, kept as text because postings phrase it many ways, like 90,000 to 120,000 USD per year. Returns null when no salary is disclosed rather than an estimate.
employmentType	string	optional	The contract shape, such as Full-time, Part-time, Contract, or Internship. Normalizing this helps you compare openings and filter by the kind of work arrangement on offer.
datePosted	string	optional	When the listing was published, ideally as an ISO 8601 date. Lets you sort by freshness and drop stale postings, which is important since old roles linger on many boards.
applyUrl	string	optional	The link to apply for or learn more about the role. Gives candidates a direct path and lets your aggregator send applicants straight to the source posting.

The schema

Copy this and send it with any URL.

{
  "title": "string",
  "company": "string",
  "location": "string",
  "remote": "boolean",
  "salaryRange": "string",
  "employmentType": "string",
  "datePosted": "string",
  "applyUrl": "string"
}

Example output

Validated JSON back, matching the schema.

{
  "title": "Senior Backend Engineer",
  "company": "Northwind Labs",
  "location": "Austin, TX",
  "remote": true,
  "salaryRange": "140,000 to 180,000 USD per year",
  "employmentType": "Full-time",
  "datePosted": "2026-05-30",
  "applyUrl": "https://example.com/careers/senior-backend-engineer"
}

Job posting schema: FAQ

What happens when a posting does not list a salary?

The salaryRange field returns null instead of a guessed or averaged figure. Because the output is validated against your schema before it is returned, a present salary is one that actually appeared on the page. That keeps compensation datasets honest and lets you separate roles that disclose pay from those that do not without manual checking.

Can Extracto read job postings behind a login or on heavily scripted boards?

Heavily scripted boards are fine: every request runs through a real headless browser with a managed anti-bot bypass layer and proxies handled for you, so JavaScript-rendered and anti-bot-protected listings render normally. Login-gated postings are the exception, since signing in needs session cookies, which is available on Enterprise. Always check each board's robots.txt and terms of service before extracting in volume.

How is the remote field decided?

You define remote as a boolean in your schema, and the model reads the posting to set it true or false based on the wording. This saves you from matching every phrasing employers use, like fully remote, hybrid, or work from anywhere. When a listing gives no clear signal about location flexibility, the field returns null so you can treat it as unknown.

Will the same schema work across different job boards?

Yes, that is the point of describing fields rather than writing selectors. Each board lays out a posting differently, but the meaning of a title, company, or employment type is the same everywhere, so one schema can run across many sources. Every request renders in a real headless browser with a managed bypass layer, so this holds on JavaScript-rendered and anti-bot-protected boards alike, with login-gated listings the only exception.

How do I try this on my own postings first?

The free plan gives you 100 pages with no credit card, which is enough to run this job posting schema against the listings you care about and confirm the fields come back clean. Paid plans start at 35 dollars per month when you need more volume. Testing the output shape before you commit is the recommended way to start.