Job Posting Structured Data, Explained From Scratch

What Structured Data Actually Is

A person reading one of your job pages can tell at a glance that Acme Corp is the employer, Austin is the location, and $150,000 is the salary. They work it out from layout, wording, and context without thinking about it.

A search engine is inferring all of that from raw text, and inference is unreliable. Is "Austin" the city, or the hiring manager's name? Is that figure a salary or a budget the role manages?

Structured data settles it. You attach a small block of code to the page that labels each fact explicitly: this string is the job title, this one is the employer, this is the city. It is not visible to visitors and it does not change how the page looks. It exists purely so machines stop guessing.

The Words People Use Interchangeably

Most of the difficulty here is vocabulary rather than technology. Six terms get used loosely, three of them mean the same thing, and nobody says which is which. Worth ten seconds:

So "add job posting markup", "implement JobPosting schema", and "put structured data on your job pages" are three ways of asking for one task. If you have been reading conflicting guides, that alone may be why they seemed to disagree.

Why Job Pages Specifically Need It

For most page types structured data is optional polish. For job postings it is closer to a prerequisite, because it is the entry condition for Google for Jobs, the job search box that appears above normal results for hiring queries.

Google populates that box from pages carrying valid JobPosting structured data. No markup means no consideration, regardless of how good the page is. That is the practical reason job boards and careers pages treat this as mandatory while a blog might never bother.

What It Looks Like

Here is a complete, valid example with nothing optional in it. If you copied this into a job page and changed the values, you would have working structured data.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "JobPosting",
  "title": "Senior Software Engineer",
  "description": "<p>We are hiring a senior engineer to...</p>",
  "datePosted": "2026-08-06",
  "hiringOrganization": {
    "@type": "Organization",
    "name": "Acme Corp"
  },
  "jobLocation": {
    "@type": "Place",
    "address": {
      "@type": "PostalAddress",
      "addressLocality": "Austin",
      "addressRegion": "TX",
      "addressCountry": "US"
    }
  }
}
</script>

Reading it: @context says which vocabulary you are using, always schema.org. @type says what kind of thing the page describes, here a JobPosting. Everything after that is a labelled fact. The nested objects exist because an employer and an address are things in their own right rather than plain strings, which is why hiringOrganization takes an object with a name rather than just the company name directly.

The Five Fields Google Requires

Google lists exactly five required properties on a JobPosting. Miss any and the listing is unlikely to appear at all. Everything else it publishes, including salary, employment type, and expiry date, is recommended, so leaving those out produces a warning rather than an error.

Two of these cause nearly all the trouble. description must be the full job description rather than a teaser, and it must match what the page shows. And title must be the actual job title, not the headline of your advert. Google's wording on that is blunt: the title of the job, not the title of the posting. If your listings carry titles like "Join Our Amazing Team", that is a real problem with a real cost, covered in job title schema markup.

Handling Remote Jobs

The one case where the five-field rule needs qualifying. A fully remote job has no physical jobLocation, so instead of an address you supply two properties saying it is remote and where applicants may be based:

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

Use TELECOMMUTE only for genuinely fully remote roles. A hybrid job that expects someone in the office two days a week is an on-site job as far as the markup is concerned, and should carry the real office address.

Build Yours

Rather than editing the example by hand, fill in the fields below. It builds the same structure, handles the remote and on-site branches for you, and runs entirely in your browser.

Checking That It Worked

Publish the page first, then run the live URL through Google's Rich Results Test. Testing the URL rather than pasting the snippet matters: it is the only way to confirm Googlebot can actually see the markup on the rendered page, which is exactly what fails when content is injected by JavaScript after load.

A pass tells you the syntax is correct and the required properties are present. Warnings about missing recommended properties are fine to leave for now. Errors are not, and each message maps to a specific cause in the Google for Jobs error reference.

When It Validates but Nothing Happens

This is where a lot of people get stuck, and it is worth knowing in advance that it is normal rather than a sign you did something wrong. Valid markup makes a job eligible for Google for Jobs. It does not oblige Google to show it.

Once your markup validates, the remaining questions are about the page rather than the code: whether each job has one canonical URL, whether closed jobs are being retired promptly, whether the visible page backs up every claim in the markup. That is a different problem from this one, and it has its own guide in why valid JobPosting schema still does not appear in Google for Jobs. Start there once the Rich Results Test is green.

Frequently Asked Questions