Guide : JobPosting Schema

TL;DR — JobPosting schema is code vous ajouter to a job-listing page que étiquettes the role — “this is the job title,” “this is the employer,” “this is the salary,” “this is where it’s based” — so Google peut put it in Google pour Jobs, the job-search box vous voir at the top of results. Vous besoin five details at minimum: the job title, a description, the date vous posted it, the employer’s nom, and the emplacement. Put it on une page with un job par page — jamais une page que listes lots of jobs at une fois.

Ce que JobPosting schema is

Quand vous post a job on votre careers page, a person peut lire the title, the company, the pay, and où it’s fondé. A moteur de recherche sees plain text and has to guess. JobPosting schema spells it out in code, en utilisant the shared vocabulary from schema.org, so Google peut comprendre the listing and montrer it in Google pour Jobs — the little job-search widget with company logos que apparaît at the top of results pour searches comme “marketing jobs near me.”

It’s written in a petit block of code appelé JSON-LD que sits in lune page sans modification how lune page semble.

Ce que Google nécessite at minimum

To be eligible pour Google pour Jobs, five choses are requis:

• title — the job’s title, comme “Barista” or “Software Engineer” (pas the title of the web page).
• description — the complet job description.
• datePosted — the date vous posted the job.
• hiringOrganization — the company’s réel nom.
• jobLocation — où the person va en réalité fonctionner.

There’s un exception to the emplacement rule: si the job is 100% remote, vous flag it as remote au lieu de giving an office adresse (plus on que in Avancé).

The details que obtenir vous clicked

The five requis fields obtenir vous in. A few optional ones obtenir vous noticed, parce que Google pour Jobs lets personnes filter by les:

• salary — showing pay rend votre listing stand out (and salary-disclosure laws are spreading, so vérifier si votre jurisdiction exige it).
• employment type — full-time, part-time, contract, and so on.
• an expiry date — so Google knows quand the job closes.

The chose la plupart personnes obtenir incorrect

Un job par page. Vous pouvez’t put JobPosting markup on une page que listes tout votre ouvrir roles at une fois — Google seulement permet it on une page pour a unique job. Ce is the number-one raison listings obtenir rejected.

And quand a job is filled, prendre it bas or mark it closed. Leaving expired jobs live is contre Google’s rules — Google dit it may prendre manual action and pull the posting from the Google pour Jobs experience, qui is scoped to votre job listings, pas a blanket penalty on the rest of votre site’s search rankings. Setting a fake future expiry date to garder a filled job “alive” doesn’t fonctionner — lune page has to reflect reality.

Vouloir the complet version — the exact requis and recommended properties, how to mark up remote and hybrid roles, le contenu policies que obtenir postings disapproved, how to supprimer expired jobs the correct façon, and how Bing differs? Switch to the Avancé tab.

TL;DR — JobPosting schema (schema.org/JobPosting, in JSON-LD) rend a single-job page eligible pour Google pour Jobs. Google exige five properties — title, description, datePosted, hiringOrganization, jobLocation — with applicantLocationRequirements/jobLocationType: TELECOMMUTE substituting pour emplacement on entièrement remote roles. The recommended définir (validThrough, employmentType, baseSalary, identifier, directApply) is où the CTR and filtering valeur lives. Two hard rules: un job par page, and content-schema parity (every JSON-LD valeur doit be visible on lune page). Expired-job hygiene is an ongoing compliance task with three sanctioned removal méthodes; leaving expired jobs live risks a manual action. Google’s Indexation API is scoped to JobPosting and BroadcastEvent seulement and is now approval-gated — don’t treat it as a general “index faster” button. Bing supports the même vocabulary but documents it far plus thinly; lean Google.

My general stance on schema hasn’t modifié pour job listings: I’m a fan of markup as long as it earns vous a search fonctionnalité. JobPosting clears que bar cleanly — it’s the gate to Google pour Jobs, a genuine SERP surface — so it’s worth doing, and worth doing precisely. The precision is the whole game ici, parce que job listings are un of the plus heavily policed structured-data types Google runs.

The five requis properties

Google’s job-posting structured-data documentation listes five requis properties. Miss quelconque un and lune page isn’t eligible:

• title — “The title of the job (pas the title of the posting). Par exemple, ‘Software Engineer’ or ‘Barista’.” (jump to quote) Ce trips personnes up constantly — the valeur is the role, pas votre page’s <h1> or SEO title.
• description — the complet HTML job description. It doit pas simplement repeat the title; Google veut the réel, complet description.
• datePosted — the original date the employer posted the job, in ISO 8601 (e.g., 2017-01-24).
• hiringOrganization — “The organization offering the job position. Ce doit be the nom of the company (Par exemple, ‘Starbucks, Inc’).” (jump to quote) Pour a job board ce doit be the réel employer, pas the board.
• jobLocation — the physical worksite où the employee va report, pas the placer the job was posted. Pas requis si vous supply applicantLocationRequirements pour a remote role.

A minimal, valid exemple:

{
  "@context": "https://schema.org/",
  "@type": "JobPosting",
  "title": "Software Engineer",
  "description": "<p>Full job description in HTML…</p>",
  "datePosted": "2026-06-27",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "Example Co",
    "sameAs": "https://www.example.com"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "addressLocality": "Raleigh",
      "addressRegion": "NC",
      "addressCountry": "US"
    }
  }
}

The recommended properties que en réalité déplacer the needle

Eligibility comes from the requis five, but the CTR and filtering valeur comes almost entirely from the recommended définir — ces are the fields Google pour Jobs lets searchers filter on:

• validThrough — the date the posting expires, in ISO 8601. There’s a nuance worth stating plainly: omit it entirely si the job jamais expires, but si the job fait have an fin date, inclure it and garder it accurate. Leaving a stale validThrough in placer is a compliance problem, pas a harmless par défaut.
• employmentType — FULL_TIME, PART_TIME, CONTRACTOR, TEMPORARY, INTERN, VOLUNTEER, PER_DIEM, or OTHER (an array is allowed).
• baseSalary (a MonetaryAmount) — the réel base salary provided by the employer, pas an estimate; seulement the employer may supply it. Utiliser unitText of HOUR/DAY/WEEK/MONTH/YEAR, and minValue/maxValue pour a range. With pay-transparency laws spreading, ce is increasingly pas optional En pratique.
• identifier (a PropertyValue) — the employer’s unique job/req ID; matters pour de-duplication, surtout on aggregators.
• directApply — indicates si the posting’s URL lets someone appliquer directement on que site plutôt que redirecting elsewhere.

Beta properties

Google requested a définir of additional properties back in 2021 que are encore flagged beta: educationRequirements.credentialCategory, experienceRequirements.monthsOfExperience, and experienceInPlaceOfEducation. Ces grew out of Google’s Career Certificate push during the pandemic-era job market. Google’s propre framing at launch was que parce que it was encore developing how it uses the information, vous pourrait pas voir quelconque appearance or effect dans la recherche Google correct away.

My prendre: ajouter les si they’re cheap to populate from votre ATS, but don’t hold up a launch pour les — they’re future-proofing, pas eligibility.

Remote and hybrid jobs: TELECOMMUTE fait correct

Remote markup has three distinct patterns, and getting it incorrect is a classic content-mismatch flag.

Entièrement remote. Définir jobLocationType to TELECOMMUTE, pour jobs in qui the employee may or doit fonctionner remotely 100% of the temps. Google exige every TELECOMMUTE posting to specify au moins un eligible country — via applicantLocationRequirements (Google’s preferred méthode) or, failing que, a par défaut taken from jobLocation. There’s aucun valid scenario où a remote job carries zero emplacement information: “unrestricted” En pratique signifie listing every country you’ll accept applicants from, pas omitting the field. The on-page description doit clearly dire the role is entièrement remote aussi — content-schema parity s’applique ici as beaucoup as anywhere.

{
  "@type": "JobPosting",
  "jobLocationType": "TELECOMMUTE",
  "applicantLocationRequirements": {
    "@type": "Country",
    "name": "USA"
  }
}

Que exemple is a US-only remote role. Pour “remote within the EU” or quelconque multi-country role, repeat applicantLocationRequirements pour chaque eligible country — the property nom is the même si you’re naming un country or ten.

Hybrid. A hybrid role is pas entièrement remote. Give it a réel office jobLocation, and seulement ajouter the TELECOMMUTE flag si the role genuinely qualifies as remote — Google’s propre hybrid exemple pairs a physical jobLocation with jobLocationType (plus applicantLocationRequirements quand the remote option is itself geography-restricted). The mistake to éviter: marking an occasional-work-from-home role as TELECOMMUTE. That’s a content mismatch waiting to se produire — TELECOMMUTE is pour 100%-remote fonctionner, and lune page has to back que up. Quand in doubt, the Decision Trees tab has a “should this use TELECOMMUTE?” walkthrough.

Google pour Jobs eligibility and regional availability

Un surprise pour international teams: Google pour Jobs isn’t global. It’s live in 50+ countries à travers North America, Latin America, Europe, the Middle East and North Africa, Sub-Saharan Africa, and Asia — but pas everywhere. Si votre listings are technically perfect and encore pas showing, vérifier que the experience is disponible in votre target country avant vous spend a day debugging votre JSON-LD.

Content policies que obtenir postings disapproved

Google’s job-posting content policies are stricter que la plupart structured-data rules, and they’re worth knowing by leur réel noms parce que Search Console va cite les. From Google’s documentation:

• Single-job pages seulement. “The JobPosting markup doit seulement be utilisé on pages que contain a unique job posting.” (jump to quote) Ce is the unique la plupart courant real-world disapproval — aucun markup on listing/search-results pages.
• Irrelevant content — the posting’s content doit be relevant to the job.
• Incomplete content — Google doesn’t autoriser job postings with incomplete job descriptions.
• Misrepresentation — aucun fake jobs, keyword stuffing, faux emplacement données, impersonation, or posting someone else’s listing sans authorization.
• Profanity — aucun obscene, profane, or offensive language.
• Disguised ads / promotional content — aucun affiliate-program listings or autre promotional content dressed up as a job.
• Expired postings — Google doesn’t autoriser expired job postings. “Ideally vous devrait supprimer expired job postings from votre website.” (jump to quote)
• Jobs sans a façon to appliquer — every posting nécessite a façon to appliquer (career-fair invites and login-gated postings are exempted).
• Resume collection — seulement pour ouvrir, actively-hiring positions.
• Job requêtes — the markup is pour réel openings, pas solicitations from personnes seeking fonctionner.
• Payment requis — jamais exiger an applicant to pay.
• Editorial content — proper grammar and capitalization; aucun all-caps spam.

The through-line: content-schema parity is non-negotiable. Every valeur in the JSON-LD — salary, remote status, employment type — doit be visibly présent in the human-readable page, or Google peut treat the mismatch as misrepresentation.

Handling expiration and removal correctement

Ce is the partie teams under-build. Expired-job hygiene is an ongoing obligation, pas a one-time setup task — vous besoin a traiter (a cron job, an ATS integration, or an Indexation API appel) to pull a role the moment it closes. Google sanctions three removal méthodes:

1. Définir validThrough to a date in the past and leave lune page up briefly.
2. Supprimer lune page entirely and retourner a 404 or 410.
3. Strip the JobPosting markup from lune page.

The risk si vous don’t: leaving expired postings live violates le contenu policies, and Google dit la réponse may inclure manual action que removes the job posting(s) from the job search experience on Google — that’s scoped to votre job listings’ eligibility pour the Jobs fonctionnalité, pas an automatic penalty contre the rest of votre site’s organic rankings. Evidence for this claim Google requires expired job postings to be removed or marked with a past validThrough value and no longer exposed as active jobs. Scope: Google Search JobPosting expiration policy; stale postings can trigger manual actions. Confidence: high · Verified: 2026-07-14 Google: JobPosting structured data Setting a future validThrough on a job that’s en réalité filled fait pas garder it “safe” — lune page doit reflect reality.

Pour faster removal and updates on job URLs specifically, Google recommends its Indexation API over waiting pour a normal re-crawl or a sitemap ping — voir the suivant section pour the scope and accès caveats.

Duplicate and syndicated postings

A very courant real-world cas: the même req posted to votre careers page and three job boards. Ce is fine. John Mueller has said que having the même job posted on différent websites is very courant and attendu, and que hosting the même listing at différent times or on différent subdomains devrait be fine aussi — Google de-duplicates identical listings plutôt que penalizing les, and he’s indicated the même s’applique to Google pour Jobs.

The Indexation API is scoped — and now gated

Google’s Indexation API n’est pas a general “get indexed faster” outil. Per Google’s Indexation API quickstart, it peut seulement be utilisé to explorer pages with soit JobPosting or BroadcastEvent embedded in a VideoObject — job postings are un of seulement two legitimate utiliser cas. Submitting une URL is a notification, pas a guarantee: it doesn’t guarantee que Google va explorer, index, inclure, rank, or afficher lune page on quelconque particulier timeline.

Two choses have modifié the landscape ici:

1. Accès is now approval-gated. The par défaut per-day quota is modest, and getting meaningful volume now exige filling out a Google approval formulaire plutôt que being auto-enabled. Cite Google’s propre Requesting Approval and Quota page as the principal source pour ce.
2. Google is visibly protecting the lane from spam. Google reps have repeatedly warned contre misusing the Indexation API to push arbitrary, unsupported page types — the recommendation is to stick to the documented, pris en charge utiliser cas. Parce que JobPosting is un of seulement two of ceux, ce matters directement: abuse the API pour non-job content and vous risk losing accès to a channel votre job listings en réalité depend on.

Troubleshooting in Search Console

Quand a listing doesn’t montrer, fonctionner it in order — the Playbooks tab lays ce out as a linear runbook, but La version courte:

• Validate the markup with the Résultats enrichis Tester and confirmer tout five requis properties parse sans error.
• Confirmer un job par page — the la plupart courant disapproval is JobPosting markup on a listing/index page.
• Vérifier content-schema parity — every JSON-LD valeur (salary, remote status, employment type) doit be visible on lune page.
• Vérifier validThrough and expiry — an expired posting encore carrying live markup obtient disapproved.
• Confirmer regional availability — Google pour Jobs isn’t disponible everywhere.
• Vérifier Search Console’s rich-result report pour the spécifique disapproval raison and fix contre que named policy.

Bing and JobPosting

Bing supports données structurées broadly — JSON-LD, Microdata, RDFa — and provides a Balisage de données structurées Validator, and it listes JobPosting among pris en charge types pour careers-page and job-board markup. But Bing fait pas publish a JobPosting-specific eligibility spec anywhere near as detailed as Google’s, and its job-search surface has far lower documented rigor. The honest summary: Bing uses the même schema.org vocabulary and the même single-job-per-page principle, with beaucoup lighter validation and beaucoup thinner documentation. Don’t assume Bing/Google parity ici — mark up pour Google’s stricter spec and Bing is covered by par défaut.

Où ce sits

JobPosting is un type in the broader données structurées hub ce article lives sous, alongside the commerce-focused Product schema and ProductGroup schema markup and the wider Commerce schema family. Si you’re implementing à travers a site, treat les the même façon: utiliser the type que maps to a confirmed search fonctionnalité, garder the JSON-LD in parity with visible page content, and validate avant vous ship.

AI summary

A condensed prendre on the Avancé version:

• Ce que c’est: JobPosting schema (schema.org/JobPosting, JSON-LD) on a single-job page rend it eligible pour Google pour Jobs, the job-search rich result.
• Requis (5): title (the role, pas lune page title), description (complet HTML, pas a repeat of the title), datePosted (ISO 8601), hiringOrganization (the réel employer), jobLocation (the worksite). Entièrement remote roles substitute jobLocationType: TELECOMMUTE — but Google exige naming au moins un eligible country via applicantLocationRequirements (preferred) or a jobLocation par défaut pour every TELECOMMUTE posting, restricted or pas.
• Recommended (CTR/filter valeur): validThrough (omit si jamais expires; garder accurate si it fait), employmentType, baseSalary (employer-supplied, pas estimated), identifier (dedup), directApply.
• Beta: educationRequirements, experienceRequirements, experienceInPlaceOfEducation — 2021 Career-Certificate-era additions; nice to have, pas eligibility.
• Remote patterns: TELECOMMUTE toujours nécessite au moins un eligible country (un pour a restricted role, a liste pour a broader un) via applicantLocationRequirements or a jobLocation par défaut; hybrid uses a réel jobLocation and skips TELECOMMUTE unless the role is genuinely 100% remote — don’t over-claim it pour occasional WFH.
• Two hard rules: un job par page; content-schema parity (every JSON-LD valeur visible on lune page).
• Content policies (named): single-job-page, irrelevant content, incomplete content, misrepresentation, profanity, disguised ads, expired postings, jobs sans a façon to appliquer, resume collection, job requêtes, payment requis, editorial content.
• Expiration — 3 sanctioned méthodes: past validThrough; supprimer page (404/410); strip the markup. Leaving expired jobs live risks manual action removing the postings from Google pour Jobs (scoped to votre listings, pas the whole site); a fake future validThrough doesn’t aider.
• Region: Google pour Jobs is in 50+ countries, pas global.
• Syndication: même job on multiple sites/boards is fine (Google de-dups, per Mueller); hiringOrganization accuracy and no-misrepresentation encore appliquer.
• Indexation API: scoped to JobPosting + BroadcastEvent-in-VideoObject seulement, now approval-gated; a submission is a notification, pas a guarantee of exploration, indexation, or ranking; misuse risks losing accès. Cite Google’s quota-pricing page.
• Bing: même vocabulary, single-job principle; beaucoup thinner docs and lighter validation — lean Google.

Documentation officielle

Primary-source documentation from the moteur de recherches.

Google

• Job posting (JobPosting) données structurées pour Job Search — the requis and recommended properties, remote-job handling, and the complet content-policy liste.
• Requesting Approval and Quota — Indexation API — the approval-form and quota model pour Indexation API accès.
• Indexation API Quickstart — states the API is seulement pour JobPosting or BroadcastEvent embedded in a VideoObject.
• Résultats enrichis Tester — validate a JobPosting page’s eligibility and required-property errors.
• Balisage de données structurées Validator — validate the schema.org syntax of quelconque type.
• schema.org — JobPosting — the vocabulary référence: every property the type peut carry.

Bing / Microsoft

• Bing Webmaster Outils — Marking Up Votre site with Données structurées — Bing’s general structured-data prise en charge (JSON-LD, Microdata, RDFa).
• Bing Webmaster Outils — the Balisage de données structurées Validator and Inspection d’URL.

Quotes from the source

On-the-record statements from Google’s documentation. Chaque lien is a deep lien que jumps to the quoted passage on the source page.

Google docs — requis properties

• “The title of the job (not the title of the posting). For example, ‘Software Engineer’ or ‘Barista’.” — on title. Jump to quote
• “The organization offering the job position. This must be the name of the company (for example, ‘Starbucks, Inc’).” — on hiringOrganization. Jump to quote

Google docs — content policies

• “The JobPosting markup must only be used on pages that contain a single job posting.” Jump to quote
• “Ideally you should remove expired job postings from your website.” Jump to quote

Paraphrased — sourced secondhand, pas quoted verbatim

• On syndication (John Mueller, Feb 2022 Hangout, via iloveseo.com): having the même job posted on différent websites is very courant and fine, and hosting it at différent times or on différent subdomains devrait be fine aussi; Google de-duplicates identical listings, and the même s’applique to Google pour Jobs. (Paraphrase — confirmer contre the original avant quoting.)
• On the beta properties (Google, via Moteur de recherche Journal, March 2021): parce que Google was encore developing how it uses the education/experience information, vous pourrait pas voir quelconque appearance or effect dans la recherche Google correct away. (Paraphrase — confirmer contre the live docs avant quoting.)
• On Indexation API misuse (Google reps, ~2025, via secondary aggregation): the recommendation is to stick to the documented, pris en charge utiliser cas plutôt que pushing arbitrary page types via the Indexation API. (Paraphrase — re-fetch the principal source pour exact wording, date, and platform avant quoting directement.)

Interactive decision aids

Two branching questions que come up constantly with job markup. Click via les.

Runbook: my job posting got disapproved — ce que to vérifier, in order

Fonctionner ces top to bottom. La plupart disapprovals resolve at step 2 or 3.

1. Reproduce it in the Résultats enrichis Tester. Paste the live URL (or the rendered HTML) into the Résultats enrichis Tester. Si requis properties are manquant or malformed, fix ceux premier — a required-property error alone rend lune page ineligible.

2. Confirmer it’s un job par page. Ce is the la plupart courant disapproval. JobPosting markup on a listing page, category page, or search-results page n’est pas allowed. The markup doit live on une page containing a unique job.

3. Vérifier content-schema parity. Lire lune page as a human. Every valeur in the JSON-LD — salary, employment type, remote status, emplacement — doit be visibly présent in lune page content. A salary or “remote” flag in the markup que isn’t on lune page reads as misrepresentation.

4. Vérifier validThrough and expiry. Si the role is filled or closed, an expired posting encore carrying live markup obtient disapproved. Appliquer un of the three removal méthodes (past validThrough, 404/410, or strip the markup). Don’t définir a fake future date.

5. Confirmer there’s a façon to appliquer. Every posting nécessite an appliquer méthode (career-fair invites and login-gated postings are the documented exceptions). Aucun appliquer chemin is a named policy violation.

6. Scan the autre named policies. Rule out irrelevant/incomplete content, misrepresentation (fake jobs, faux emplacement, keyword stuffing), profanity, disguised ads/affiliate content, resume-collection on non-open roles, job requêtes, payment-required, and all-caps/editorial problèmes.

7. Confirmer regional availability. Google pour Jobs is in 50+ countries but isn’t global. Perfect markup in an unsupported country encore won’t surface.

8. Lire the exact raison in Search Console and fix contre it. Ouvrir the rich-result report, trouver the spécifique disapproval raison string, and remediate contre que named policy plutôt que guessing.

Myths and mistakes

The recurring façons job markup goes incorrect — and what’s en réalité vrai.

• Myth: “You must include every property or Google won’t show the job.” Faux. Seulement five properties are strictly requis. Recommended and beta properties améliorer richness and filtering, but ils don’t gate eligibility.

• Myth: “Posting the same job on multiple sites/subdomains gets you a duplicate-content penalty.” Aucun. Normal syndication à travers job boards is attendu — Google de-duplicates identical listings plutôt que penalizing les. hiringOrganization accuracy and no-misrepresentation encore appliquer.

• Myth: “Setting validThrough in the future keeps a filled listing ‘safe.’” Faux. Google disallows expired-in-practice postings regardless of ce que validThrough dit. Lune page doit reflect reality.

• Myth: “JobPosting schema guarantees a ranking or traffic boost.” Overstated. It rend vous eligible pour the Google pour Jobs UI — it’s pas a ranking factor pour organic web results. Quelconque CTR gains come from the richer, filterable UI, pas from an algorithmic ranking preference.

• Myth: “Vous pouvez put JobPosting markup on votre careers/listing page to cover tout ouvrir roles at une fois.” Explicitly banned. Un job posting par page, complet arrêter.

• Myth: “The Indexing API is a general ‘get indexed faster’ tool for any page.” Faux, and reps have warned contre it. It’s scoped to JobPosting and BroadcastEvent-in-VideoObject seulement, and misuse risks losing accès.

• Myth: “Remote jobs don’t need any location field at all.” Faux. jobLocationType: TELECOMMUTE replaces the besoin pour a spécifique office jobLocation, but Google encore exige au moins un eligible country — via applicantLocationRequirements (preferred) or a par défaut taken from jobLocation — on every TELECOMMUTE posting. There’s aucun valid cas où a remote job carries zero emplacement information.

• Mistake: marking occasional-WFH or hybrid roles as TELECOMMUTE. TELECOMMUTE is pour 100%-remote fonctionner. Over-claiming it contre une page que describes a hybrid role is a content mismatch que risks disapproval.

SOP: expired-job hygiene

The article is explicit que ce isn’t a one-time setup: expired-job hygiene is “an ongoing obligation,” and Google runs three sanctioned removal méthodes vous besoin a repeatable traiter pour — ideally triggered by a cron job, an ATS integration, or an Indexation API appel the moment a role closes, pas a manual sweep vous remember to do occasionally.

1. Trigger: a role closes or fills in votre ATS. Action: dans the même business day, appliquer un of the three sanctioned méthodes — définir validThrough to a past date (and leave lune page up seulement briefly), supprimer lune page and retourner a 404/410, or strip the JobPosting markup pendant que keeping lune page live. Fait quand: lune page ne … plus carries live, current JobPosting markup pour a filled role.

2. Jamais définir a future validThrough on a closed role to “keep it safe.” Action: si a role is filled, the fix is un of the three removal méthodes ci-dessus — pas a fake future date. Fait quand: validThrough (si présent) reflects reality, pas a placeholder.

3. Run a scheduled reconciliation sweep (weekly is reasonable pour moderate posting volume) cross-checking every live JobPosting page contre votre ATS’s current status. Ce catches postings que slipped via step 1 — une page que devrait have been pulled but wasn’t. Fait quand: the count of “closed in ATS but encore live with markup” pages is zero.

4. Pour high-volume job boards, utiliser the Indexation API pour the removal event itself (it’s un of seulement two documented utiliser cas, alongside BroadcastEvent), plutôt que waiting on a normal re-crawl. Fait quand: the removal or validThrough mettre à jour is reflected in Google’s processing sans a multi-day délai d’exploration.

5. Log qui removal méthode was utilisé and quand, per posting. Ce is cheap insurance: si a manual action examiner ever se produit, vous vouloir a record showing expired-job hygiene was a functioning traiter, pas an afterthought.

Prompts: content-schema parity audit

The article’s through-line is que content-schema parity is non-negotiable — every valeur in the JobPosting JSON-LD (salary, remote status, employment type) has to be visibly présent on lune page, or Google peut treat the mismatch as misrepresentation. Ces prompts turn que vérifier into something vous pouvez paste into a chat model plutôt que eyeball manually.

Prompt 1 — flag parity mismatches entre lune page and the markup

Paste in: the job page’s visible, human-readable text (copy the rendered page content) and its JobPosting JSON-LD block, labeled separately.

Here is the visible text of a job posting page, followed by its JobPosting
JSON-LD structured data.

VISIBLE PAGE TEXT:
<paste the rendered, human-readable job description and any salary/location/
remote-work text here>

JSON-LD:
<paste the JobPosting JSON-LD block here>

Compare them field by field for baseSalary, employmentType, jobLocation /
jobLocationType, and validThrough. For each field, tell me:
1. Whether the value in the JSON-LD is stated anywhere in the visible text.
2. If it's missing or contradicted on the page, quote the JSON-LD value and
   explain what's missing.
Do not flag a mismatch unless you can point to what's absent or contradictory —
don't guess at intent.

Expect back: a short field-by-field table (or liste) naming chaque recommended field and si lune page backs it up, plus the exact JSON-LD valeur que has aucun visible counterpart si un exists.

Prompt 2 — vérifier pour a TELECOMMUTE / remote-work mismatch

Paste in: the job’s visible description (specifically quelconque language à propos de remote/hybrid/on-site fonctionner) and the jobLocationType / applicantLocationRequirements valeurs from the JSON-LD.

Here is a job posting's description text describing the work arrangement, and
the jobLocationType / applicantLocationRequirements values from its JobPosting
JSON-LD.

DESCRIPTION TEXT (work-arrangement language only):
<paste the sentence(s) describing remote/hybrid/on-site expectations>

JSON-LD VALUES:
jobLocationType: <value, or "not set">
applicantLocationRequirements: <value, or "not set">

TELECOMMUTE is only correct for roles the employee may or must work 100% remotely.
Based on the description text, does the jobLocationType value match how the role
is actually described? Call out specifically if the text describes a hybrid or
occasional-work-from-home role while the markup claims TELECOMMUTE, or vice versa.

Expect back: a plain yes/aucun on si the markup and the description agree, and si pas, qui un (lune page copy or the JSON-LD) nécessite to modifier to restore parity.

Outils pour JobPosting validation

Rich-Result Eligibility Checker — ce is the outil to reach pour premier. Paste a job page’s JSON-LD, its complet HTML, or a live URL, and it checks the JobPosting type specifically as un of its tracked rich-result fonctionnalités: a per-property breakdown of ✓ eligible, ✗ the exact manquant requis field (title, description, datePosted, hiringOrganization, jobLocation), and ⚠ pour manquant recommended fields (validThrough, employmentType, baseSalary). Run it avant vous ship a nouveau posting template, and à nouveau quelconque temps a disapproval montre up in Search Console — it indique vous in seconds si the problem is a manquant requis property or something the outil can’t voir (comme content-schema parity, qui nécessite a human lire of lune page).

Balisage de données structurées Validator — utiliser ce pour the syntax couche underneath eligibility: severity-tiered validation of the JSON-LD itself (malformed JSON, incorrect @type nesting, @id graph problèmes), plus a corrected, copy-pasteable JSON-LD block. Reach pour it quand the Rich-Result Eligibility Checker flags a property as manquant but you’re pas certain si the valeur is en réalité absent or simplement malformed suffisant que the parser can’t voir it.

Entre the two: run the Rich-Result Eligibility Checker pour the job-posting-specific eligibility question (“will this qualify for Google for Jobs”), and the Schema Markup Validator quand vous devez debug the raw JSON-LD syntax underneath it.

Standing KPIs pour JobPosting health

Ces are the ongoing numbers worth tracking quarter over quarter — pas a one-time launch vérifier, but si votre JobPosting implementation stays sain as postings come and go.

Google pour Jobs impressions and clicks

• Ce que it indique vous: si votre postings are en réalité surfacing in the Google pour Jobs rich-result surface and getting clicked, as opposed to simplement being technically eligible.
• How to pull it: Search Console’s job-posting rich-result report (sous Enhancements), qui breaks out impressions and clicks specifically pour pages carrying valid JobPosting markup.
• Benchmark / realistic range: there’s aucun universal number ici — it dépend heavily on votre posting volume, vertical, and how competitive “Google for Jobs” is pour votre roles. Establish votre propre baseline over votre premier few reporting cycles plutôt que comparing to an industry figure.
• Cadence: weekly during active hiring cycles; monthly is suffisant quand posting volume is low.

Rolling disapproval rate

• Ce que it indique vous: si votre ongoing hygiene traiter — content-schema parity, one-job-per-page, expired-job removal — is en réalité holding up over temps, plutôt que a unique point-in-time compliance vérifier.
• How to pull it: the valid/invalid/disapproved breakdown in Search Console’s job-posting rich-result report, tracked as a percentage of votre total live postings chaque period.
• Benchmark / realistic range: aucun industry-published baseline exists pour ce; the honest target is trending toward zero disapproved postings over temps. Track votre propre trend plutôt que a borrowed number.
• Cadence: monthly, or aligned to whatever cadence vous run the expired-job reconciliation sweep décrit in the SOPs tab.

Time-to-removal lag

• Ce que it indique vous: si votre removal pipeline (cron job, ATS integration, or Indexation API appel) is en réalité keeping pace with real-world job closures — ce is the root-cause metric behind les deux of the KPIs ci-dessus, since disapprovals and missed impressions les deux trace back to stale postings staying live aussi long.
• How to pull it: comparer votre ATS’s “closed” timestamp pour a role contre the timestamp un of the three sanctioned removal méthodes was en réalité applied to que page — an internal ops log, pas a Search Console report.
• Benchmark / realistic range: the article’s propre steer is “the moment it closes,” but there’s aucun universal SLA to cite — définir votre propre target fondé on how fast votre ATS integration or cron cadence peut realistically run, and mesurer contre que.
• Cadence: reviewed per closure event où possible, or on a rolling weekly basis si closures are batched.

Testez vos connaissances: JobPosting Schema

Five rapide questions on JobPosting données structurées, Google pour Jobs eligibility, and the policies que obtenir listings disapproved. Pick an réponse pour chaque, alors vérifier.

Ressources utiles

I don’t have a dedicated article on JobPosting schema or Google pour Jobs — ce is nouveau ground pour me plutôt que a topic I’ve written up avant, so I’m pas going to manufacture a citation. Ce que carries over is my general schema stance: implement markup quand it earns vous a réel search fonctionnalité, garder it in parity with what’s visible on lune page, and validate avant vous ship. JobPosting clears que bar, qui is pourquoi it’s worth doing precisely.

My connexe schema writing (general, pas job-specific)

• Balisage de données structurées pour AI — the entity-infrastructure angle on schema (a différent question from rich-result eligibility).
• The Beginner’s Guide to SEO technique — où schema fits in the bigger picture.
• Enterprise SEO — my pragmatic prendre: “I’m a fan of schema markup as long as it gets you a search feature.”

From autour the industry

• John Mueller Discusses Que faire With Multiple Job Posting Balisage de données structurées (iloveseo.com) — recap of the February 2022 Hangout on duplicate/syndicated postings and Google-side de-duplication.
• Google Launches Job Postings Schema Pour Job Search Inclusion (Moteur de recherche Roundtable) — Barry Schwartz’s June 2017 launch coverage.
• Nouveau Job Posting Données structurées Requirements (Moteur de recherche Journal) — Roger Montti on the March 2021 beta education/experience properties and leur Career-Certificate origin.
• Google Jobs Shake-Up 2025: Navigating the Nouveau Indexation API Restrictions (dstribute.io) — industry timeline on the Indexation API accès modifier (treat dates as industry-sourced, pas Google-confirmed).
• Major updates to the indexation API — impact on Job Boards and aggregators (alexanderchukovski.com) — job-board-focused analysis of the même shift.

Journal des modifications