Job Posting Schema for Google for Jobs

Quick Answer

JobPosting schema only works when it exactly watches the visible details on a single, public job page. If your page validates but still isn't getting indexed, you don't need another schema field. You need to fix the URL structure, remove expired jobs faster, or ensure the visible data perfectly mirrors your JSON-LD.

Start With the Page, Not the Schema

Google for Jobs is a search engine for web pages, not just a reader for JSON snippets. If a job page is thin, hard to read, or duplicated across several URLs on your domain, perfectly formatted JSON-LD won't save it.

The golden rule: If a human candidate cannot instantly figure out the role, the employer, the location, and how to apply, Google won't figure it out either. Fix the page UX before you tweak the schema.

• One job, one URL: Every listing needs a single, definitive detail page to be indexed.
• Visible facts are mandatory: Title, employer, location, and the apply button must be obvious on load.
• Data must match: If the visible page says one thing and the JSON-LD says another, Google loses trust immediately.
• Clean up fast: Leaving schema on expired jobs is the #1 way to slowly destroy indexation quality over time.

Open image

Close

Structured data helps, but the page still needs to make sense to a human reader first.

A Quick Audit Before Changing Code

Before rewriting your JSON-LD, it's worth checking a live job page from a candidate's perspective. Many "schema problems" are actually just page structure issues.

1. Load a live job URL. Ensure it's a dedicated detail page, not a filtered search results page.
2. Check for clarity. Are the role, employer, location, and apply button immediately obvious?
3. Compare the page to the markup. If the title, location, or salary on the screen don't match the schema data, fix the mismatch first.
4. Verify indexability. Make sure the URL is public, canonical, and not blocked by a `noindex` tag or a `robots.txt` file.
5. Check for stale jobs. If a job is closed but the page still looks active, Google's trust in the site can drop.
6. Watch for duplicate pages. Search filters or partner integrations often create multiple URLs for the exact same job post.

The Fields That Actually Matter

You don't necessarily need to fill out every optional structured data field right away. The key is to start with a reliable baseline that stays accurate as jobs are added and removed.

A good rule of thumb: if a detail isn't visible on the webpage, don't try to cram it into the schema. This is especially true for salaries, remote policies, expiry dates, and employer names.

Handling Remote, Hybrid, and On-Site Jobs

Remote jobs often cause confusion with schema. If a role is fully remote, the jobLocationType should be TELECOMMUTE, and you should use applicantLocationRequirements to outline where the applicant is allowed to live.

Hybrid jobs are handled differently. If an employee is required to come to an office occasionally, the physical location still matters and should be treated like an on-site role in the schema.

• Fully remote: Use TELECOMMUTE and clearly define the allowed country or region.
• Hybrid: Use the real office location and explain the remote-work flexibility in the normal page text.
• On-site: Use the exact physical location, including the city, region, and country.

Avoid marking a job as TELECOMMUTE just because the employer offers a few work-from-home days. Google treats TELECOMMUTE as fully remote, and getting that wrong can lead to poor candidate experiences and reduced search visibility.

Expired Jobs and Duplicate URLs

Leaving active JobPosting schema on closed jobs is a quick way to lose Google's trust. Cleaning up expired jobs is just as important as publishing them.

• If the job is permanently gone, return a 404 or 410 status code.
• If you want to keep the page live for archival purposes, remove the JobPosting markup.
• If you know exactly when a job will close, use the validThrough property and make sure it has expired.

Duplicate URLs are another common gotcha. If the exact same listing is accessible via search parameters, category pages, or alternate domains, pick one definitive URL and set a canonical tag pointing to it.

A Simple JSON-LD Example

Here is a clean, minimal starting point. The goal isn't to stuff every possible property into the code, but to ensure the data perfectly mirrors what the visitor sees.

{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "Senior Climate Data Engineer",
  "description": "<p>Build data pipelines for climate risk products...</p>",
  "datePosted": "2026-04-28",
  "employmentType": "FULL_TIME",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "Example Climate Co",
    "sameAs": "https://example.com"
  },
  "jobLocationType": "TELECOMMUTE",
  "applicantLocationRequirements": {
    "@type": "Country",
    "name": "USA"
  }
}

Why Valid Pages Still Might Not Show Up

Sometimes a page passes the Rich Results Test with flying colors, but the job still doesn't appear. That usually means the issue lies outside the code snippet itself.

It helps to start by confirming the page quality and checking for duplicate URLs before spending time refining the schema syntax.

A Simple Validation Workflow

Rather than just checking for syntax errors, it's best to verify exactly what Google is seeing.

1. Test the live URL. Run the actual web page through the Rich Results Test, rather than just pasting code.
2. Check Search Console. Ensure Google isn't blocking or misinterpreting the page.
3. Compare text and schema. Ensure your titles, locations, and salaries match on both sides.
4. Check for duplicates. Ensure there isn't another version of the page competing for indexing.
5. Verify expired listings. Make sure closed roles don't still look active.
6. Use the Indexing API. Notify Google when a job opens, changes, or closes.

If you want to look at the bigger picture, you might find our Job Board SEO vs. General SEO comparison helpful.

Frequently Asked Questions