What Google for Jobs is
Google aggregates open roles into job experiences inside Search and Discover. Listings show title, employer, location, posting date and—when provided—compensation and employment type. Clicks land on your canonical job URL, ATS page or partner board depending on source.
Organic job visibility complements paid recruiting: costs sit in implementation and maintenance, not per impression from Google itself.
How listings qualify
- Crawl: URLs must allow Googlebot; live jobs must not carry noindex.
- Render: JobPosting JSON-LD should be present in HTML or SSR output—pure client lists risk empty crawls.
- Validate: Rich Results Test and Search Console highlight property-level errors.
- Dedup: One canonical URL per vacancy—avoid identical JobPosting across ATS subdomain and marketing domain without canonical strategy.
Required vs recommended properties
Follow Google’s current JobPosting documentation—missing required fields disqualify rich results. Always include realistic validThrough or remove jobs promptly when filled.
Salary, employmentType, identifier, industry and occupationalCategory improve filtering and CTR when policy allows disclosure.
Remote, hybrid, multi-location
Align schema with visible copy: remote roles need compliant TELECOMMUTE modelling plus any geographic eligibility constraints; multi-site roles need coherent location arrays or separate URLs per site—avoid contradictory geography on mirrored postings.
Application URLs and tracking
Use stable URLs; UTM parameters are fine if pages stay indexable and not soft-404. Mobile apply flows and GDPR-aligned consent copy must match the rest of your careers experience. Pair with website lead generation best practices and recruiting KPI measurement for attribution.
ATS vs owned site
Feeds are efficient but risk duplicates, lagging syncs and thin descriptions. Best practice: designate one public canonical source on your primary domain, generate JobPosting there and syndicate or link elsewhere. If the ATS cannot comply, a lightweight Next.js rendering layer can render compliant HTML and schema.
Technical pitfalls
1 JS-only job grids
Prefer SSR/SSG for listings when many roles exist.
2 Session parameters
Unstable query strings create duplicate URLs.
3 Accidental noindex
Template-level meta robots mistakes hide entire career sections.
4 Expired schema
Remove or update JobPosting when roles close—stale jobs erode trust.
5 Multilingual postings
Separate URLs per language with hreflang; keep JSON-LD language consistent with visible copy.
Content quality
Explain role, team, location/modality and next steps in opening paragraphs; separate must-have vs nice-to-have skills; avoid internal jargon titles—use phrases candidates actually search.
This reinforces careers page SEO and search visibility beyond structured data alone.
Pre-launch checklist
- Canonical URL strategy documented
- JobPosting validates cleanly
- Dates ISO-formatted; expiry workflow defined
- Location/remote modelling matches legal and HR policy
- Salary included when allowed
- Mobile apply tested end-to-end with measurable events
- Search Console property verified; job sitemap submitted
- HR ↔ marketing process for opening/closing reqs
Paid + organic
Organic jobs anchor always-on visibility; paid social performance recruiting reaches passive talent—use consistent URLs and messaging for clean reporting.
FAQ
Must we hand-code JSON-LD?
No—if CMS/ATS output is valid and deduplicated, you are done.
Rich test passes but no listing?
Indexing lag, quality filters or duplicate suppression—check coverage reports and canonical domain.
Same job on board and site?
Allowed with a single canonical JobPosting source.
Conclusion
Google for Jobs rewards disciplined schema, stable URLs, fresh data and human-readable postings. Maintain the plumbing and the copy together—then layer paid channels where labour markets are tight.
Get a free Google for Jobs and careers page audit covering schema, UX and paid recruiting campaigns as one programme.
