What Is JobPosting Schema?

The markup belongs on the most detailed page for a single job. It helps a search system distinguish the role from the careers site, hiring organization and location. The structured fields should come from the same recruiting source that powers the visible description and application flow.

JobPosting markup does not create a vacancy, authorize recruiting for another company or guarantee inclusion in a job-search experience. Fake roles, resume collection without an open position, expired listings and applicant fees remain unacceptable even when the JSON-LD validates.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Represent one genuine open role.
• Source fields from the recruiting system.
• Keep application and expiration status synchronized.

Primary specification: Schema.org definition for JobPosting.

JobPosting schema is a machine-readable record for one real, open and directly applicable role - not a recruiting advertisement template.

A crawler reads the rendered page and compares the structured job with visible information. Required fields such as title, description and datePosted establish the vacancy, while recommended fields improve filtering and candidate understanding. The hiring organization should reference the real authorized employer.

Syntax validity cannot prove a requisition is open, salary is approved or applicants are allowed from a stated location. The ATS, HR policy and application endpoint remain authoritative. Automation should remove or expire markup as soon as the position closes.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Approve and identify the requisition.
2. Publish one canonical detail page.
3. Map visible role and eligibility fields.
4. Test the complete application flow.
5. Expire the posting when hiring ends.

The graph works when one canonical job page mirrors the active requisition and its real employer, eligibility and application conditions.

A careers index can link to job detail pages but should not carry a JobPosting node for every listing. Each role needs its own readable description without requiring login. Multiple physical locations for the same approved requisition can be represented where the property supports them, but unrelated roles require separate pages.

Third-party boards may mark up authorized listings when their records are accurate and application paths work. A company must not publish jobs on behalf of another employer without authorization or use a vacancy as a lead-generation disguise.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Keep markup off list and search pages.
• Require a public complete description.
• Do not disguise lead collection as hiring.

The eligible surface is one accessible leaf page for one real role with a working application route.

The title must be the role title only. Do not add the company, salary, location, job code, “apply now” or keyword variants to manipulate discovery. The description should include responsibilities, qualifications, skills, hours, education and experience requirements that candidates can read on the page.

A requisition identifier can help deduplicate feeds and URLs. hiringOrganization can connect to the employer identity described through Organization schema. Optional fields should be omitted when the recruiting system cannot maintain them accurately.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Use the approved role title.
2. Publish the complete job description.
3. Preserve original posting and closing dates.
4. Identify employer and work location.
5. Add stable requisition and employment details.

Prioritize complete visible job facts and lifecycle controls before adding optional filters or promotional properties.

Remote does not automatically mean worldwide. Payroll registration, tax, employment authorization, time zones, security and team coverage may limit eligible states or countries. Represent only the geography approved by the employer and show those restrictions visibly.

A hybrid role is not a fully remote role merely because some days can be worked from home. Provide the actual office location and explain the on-site schedule in the description. Do not create fake city locations to capture regional searches.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Separate remote work from hiring geography.
• Model hybrid roles with real offices.
• Never manufacture regional locations.

Remote markup must reflect where the employee may work and where the employer can genuinely hire, not the geographic reach desired for SEO.

Do not place a salary in structured data while hiding it from candidates. A range should preserve minimum and maximum values from the approved compensation band. Hourly and annual amounts cannot be mixed without explicit conversion and policy. Bonuses, equity and commissions are not automatically base salary.

US pay-transparency duties vary by jurisdiction and change over time, so employers should obtain current legal guidance for the locations involved. Schema implementation should follow the approved public disclosure rather than attempt to decide what the law requires.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Confirm the approved public compensation.
2. Separate base salary from variable pay.
3. Set currency and time unit.
4. Match visible minimum and maximum values.
5. Review jurisdictional duties with qualified counsel.

Compensation markup must mirror the approved visible base salary and its unit without substituting legal judgment or marketing estimates.

The right page experience depends on recruiting and content policy. A closed role can explain that applications ended and link to current openings, but active structured markup must not remain. An apply button should not lead to a generic talent pool while the page claims a specific vacancy is open.

Lifecycle automation should react to ATS closure events rather than wait for a periodic SEO audit. Update discovery systems promptly and keep sitemap last-modified values accurate. Redirect only when a truly equivalent active role or useful destination exists; avoid sending every expired job to the careers homepage without context.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Use ATS closure as the trigger.
• Remove active apply claims immediately.
• Preserve only truthful useful closed-page experiences.

Closing the requisition must close the structured job and application path promptly, with a truthful user experience for any remaining URL.

ATS feeds and careers templates often drift. A role may close in one system while cached JSON-LD stays live. Location arrays can merge unrelated requisitions, and recurring jobs can refresh datePosted every day to appear new. These are content-truth failures even when syntax passes.

Applicant safety matters. Jobs should not require payment, impersonate organizations or collect resumes without an open position. Validate the end-to-end candidate journey, including mobile forms, accessibility and confirmation, rather than stopping at a rich-result test.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Reconcile every active requisition.
2. Inspect page scope, title and description.
3. Verify employer, location and salary.
4. Test expiration and cache behavior.
5. Complete the application as a candidate.

Job markup fails when the vacancy, employer, eligibility, compensation or application experience is false, stale or incomplete.