Skip to content
Sulayman Bowles / Project Delta

JobPosting Structured Data: Fields and Validation

JobPosting is recorded as supported in the pinned Atlas schema registry for job posting rich results.

JobPosting schema reference for job posting rich results, covering required and recommended fields, visible-content alignment, implementation, and validation.

01

What JobPosting schema describes

JobPosting markup describes job posting rich results in the pinned Atlas registry. Its recorded status is supported, which is a documentation and validation boundary rather than a promise of a particular search presentation.

Use JobPosting schema only when the visible page actually contains and owns the entity or content being described. The reviewed page contexts are job, other. A type can be valid vocabulary while remaining irrelevant, ineligible, misleading, or unsupported for a specific page.

Structured data should make an existing page easier to interpret. It should not introduce hidden reviews, ratings, products, people, events, jobs, services, questions, steps, or other facts that users cannot verify in the visible content.

02

Required and recommended fields

The Atlas record lists these required fields for JobPosting: title, datePosted, hiringOrganization, jobLocation. Required means the registry expects the property for the reviewed feature or vocabulary contract; it does not override stricter current documentation or page-specific policy.

Recommended fields are description, validThrough, employmentType. Add them only when the page owns accurate values. Visibility requirements are title, and the broader rule remains that material structured claims must match visible content.

  • Confirm the page purpose is one of the reviewed contexts: job, other.
  • Inventory the required properties: title, datePosted, hiringOrganization, jobLocation.
  • Compare visibility requirements with the page: title.
Decision and validation matrixEach row keeps the signal, inspection step, and pass condition together.
SignalInspectPass condition
StatussupportedThe implementation and claims respect this registry boundary.
Requiredtitle, datePosted, hiringOrganization, jobLocationEvery applicable required property has a page-owned value.
Recommendeddescription, validThrough, employmentTypeOptional values are present only when supported.
VisibletitleMaterial values agree with visible content.

03

Implementation pattern

Implement JobPosting schema from the same content record that renders the page whenever possible. That ownership prevents a detached JSON-LD template from retaining an old title, entity, price, date, author, rating, location, or availability after visible content changes.

Use stable canonical identifiers for recurring entities, absolute URLs for public references, and correctly shaped values for dates, numbers, lists, and nested objects. Keep route-specific markup out of global shells that can duplicate it across unrelated pages.

  • Add page-owned values for the required JobPosting properties before optional enrichment.
  • Review recommended properties without inventing absent facts: description, validThrough, employmentType.
  • Keep JSON-LD values consistent with the visible page and the current primary documentation.
Implementation specimenAdapt values to the visible canonical page; do not paste placeholders into production.
{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "Visible title value",
  "datePosted": "2026-07-20",
  "hiringOrganization": "Visible hiringOrganization value",
  "jobLocation": "Visible jobLocation value",
  "description": "Visible description value",
  "validThrough": "2026-07-20"
}

04

Validation workflow

Validate JobPosting schema in the final deployed HTML. First parse the JSON, then check Schema.org vocabulary shape, then review feature-specific required properties and policy, and finally compare every material value with what a user can see on the canonical page.

The source record was reviewed on 2026-06-23. Recheck the primary documentation before a release when the feature, status, or Search presentation could have changed since that date.

  • Parse the final deployed JSON-LD rather than a detached editor snippet.
  • Review the JobPosting record against its official documentation and Atlas status supported.
  • Check that no hidden, misleading, expired, or unsupported values survive the render path.

05

Failure modes and claim limit

A parser success does not establish feature eligibility or rich-result selection.

JobPosting can be valid Schema.org vocabulary while having limited or no special Google Search presentation.

Do not mark a reference page like this one as JobPosting merely because it discusses the type. This page is an Article about JobPosting schema; its JSON-LD must describe the visible article, not impersonate the subject of the guide.

Claim boundary: Valid JobPosting markup can establish technical eligibility only. It does not guarantee crawling, indexing, a rich result, ranking, impressions, or clicks.

06

Primary references and related routes

  1. JobPosting structured data documentationGoogle Search Central / checked 2026-06-23

    Primary documentation referenced by the Atlas JobPosting registry record.