Check this page with an assistantOpens a chat asking it to summarise this article and name the evidence behind each claim.
Claude opens with the prompt on your clipboard: Anthropic does not support prefilled prompts on the web, and we would rather copy it than ship a button that drops it.
Google Pulls, You Do Not Push
There is no endpoint to submit jobs to. Google discontinued its Jobs API, and the model is now entirely pull-based: it discovers your job pages the same way it discovers any page, reads the structured data on them, and decides whether the listing is eligible. Your job is to be readable, not to notify anyone.
That changes where effort belongs. Teams still look for an integration, a feed, or a partner that can push listings in, and those conversations are about products layered on top of the same underlying requirement. If your job pages carry correct markup and are crawlable, you are eligible; if they do not, no integration fixes it.
It also means the ordinary discovery mechanics apply. New roles are found through your sitemap and internal links, and a careers section that generates job pages only via JavaScript, or hides them behind a search interface, has a discovery problem before it has a markup problem. That sequence is in how Google Search works.
One URL Per Role, Always
The most common failure is putting JobPosting markup on a page that lists many jobs. It does not work, it has never worked, and it is why careers sites with apparently valid markup never appear. Each role needs its own page, its own URL, and its own markup block.
This is not arbitrary. A rich result for a specific role has to link somewhere that describes that role, and a listing page describes fifty. The requirement follows from what the feature does, which is also why it will not be relaxed.
Many applicant tracking systems handle this correctly by default, and some do not. Check by opening a single job page and confirming the markup is present in the served HTML, then confirm that page appears in your sitemap. Where the ATS hosts jobs on its own domain, decide deliberately whether you want the listings ranking under your brand or theirs, because that choice determines who accumulates the visibility.
The Fields, and Which Ones Actually Decide Things
Meeting the minimum makes you eligible. Completing the optional fields is what makes a listing competitive, because candidates filter on exactly the fields most employers leave empty.
| Field | Status | Why it matters beyond eligibility |
|---|---|---|
| title | Required | Use the role, not an internal grade. "Engineer II" is not searched |
| description | Required | Full HTML description; thin descriptions convert badly |
| datePosted, validThrough | Required | Drives freshness and clean expiry |
| hiringOrganization | Required | Should resolve to your actual entity, named consistently |
| jobLocation | Required | Real address; remote roles use the remote-specific properties |
| baseSalary | Recommended, often legally required | Candidates filter on it; omitting it removes you from results |
| employmentType | Recommended | Another common filter candidates apply |
| identifier | Recommended | Stable reference that survives reposting |
The title row deserves emphasis because it is a hiring problem disguised as a markup one. Internal titles, grades, and invented job names are not what candidates search. If nobody searches your job title, perfect markup makes an invisible listing eligible to remain invisible.
Salary Is No Longer Optional in Practice
Google treats salary as recommended. A growing number of jurisdictions treat it as mandatory, including several US states, and the direction of travel is consistent. Separately, candidates filter on it, so an omitted band removes you from the shortlist before anyone reads your description.
The usual objection is that publishing bands creates internal problems with existing staff. That is a real concern and it is not an SEO one: the compression it exposes exists whether or not you publish it, and jurisdictions requiring disclosure will force the conversation anyway. Deciding deliberately is better than being overtaken.
If you publish a band, publish it in the markup and on the visible page, matching each other. Structured data describing something the page does not show is the general failure mode covered in structured data in 2026, and it applies here as much as anywhere.
Expiry Is the Part Everyone Neglects
A careers section full of roles filled six months ago is the most common state of employer job pages, and it costs on both sides: candidates lose trust immediately, and repeatedly serving stale listings undermines how your postings are treated.
- Set validThrough on every posting.
An honest closing date rather than a distant placeholder. This is what allows a listing to expire cleanly instead of lingering as apparently open.
- Decide one policy for closed roles.
Either remove the page and return 410 Gone, which states deliberate removal, or keep it and mark it closed clearly. Both are defensible; leaving it live and unmarked is not.
- Do not redirect closed roles to the careers page.
Someone arriving from a search for a specific role wants that role, and a redirect to a generic list is a worse experience than an honest closed notice with related openings.
- Never repost the same role at a new URL.
It looks like churn to candidates and creates duplicates. Reuse the original URL with an updated posting date if the role genuinely reopens.
- Audit quarterly.
Crawl your careers section and list every page with a validThrough in the past. On most employer sites the first run is uncomfortable, which is the point of running it.
Questions People Ask About Job Posting Markup
- How do I get my jobs into Google for Jobs?
Put JobPosting structured data on each individual job page and make sure those pages are discoverable through your sitemap. There is no submission endpoint: Google discontinued its Jobs API, so the model is entirely pull-based. If the markup is valid and the page is crawlable, the listing becomes eligible.
- Can I put JobPosting markup on my careers page?
No. The markup belongs on the page for a single role, and a listing page showing many jobs is not eligible. Every open role needs its own URL with its own JobPosting block. This is the single most common implementation mistake and it is why some careers sites never appear despite having valid-looking markup.
- What fields are required?
Title, description, datePosted, validThrough, hiringOrganization, and jobLocation are the core. Beyond the required minimum, include employmentType, an identifier, and baseSalary, because incomplete listings compete badly against complete ones even when both are technically eligible.
- Do I have to include salary?
Google does not require it, and an increasing number of jurisdictions do. Several US states including New York, California, Washington, and Colorado have pay transparency requirements, and similar rules are spreading. Beyond compliance, listings without a salary band get filtered out by candidates who use salary filters, so omitting it costs you applicants directly.
- What happens when a role is filled?
Set validThrough to the closing date so the listing expires cleanly, and when a role closes either remove the page and return a 410, or keep it and mark it closed. Leaving filled roles live is the fastest way to lose trust with candidates, and repeated stale listings damage how your postings are treated.
