Which international format is used for job posting data (schema.org JobPosting)?

The international format used for job posting data is schema.org JobPosting, a standardized vocabulary that defines how job listing information should be structured and marked up on the web. It is maintained by Schema.org, a collaborative community supported by Google, Microsoft, Yahoo, and Yandex. This format is recognized globally and forms the foundation for job posting rich results in search engines. The sections below unpack exactly what the schema requires, how search engines use it, and what can go wrong when implementing it, starting with a look at Openindex’s structured data expertise.

What fields does schema.org JobPosting require?

Schema.org JobPosting has a small set of required fields and a much larger set of recommended properties. The required fields are title, description, hiringOrganization, jobLocation, and datePosted. Without these five properties, search engines cannot reliably interpret or display the job listing as a rich result.

Beyond the required fields, Google strongly recommends including additional properties to improve how a listing appears and ranks in job search results. These recommended properties include:

• validThrough — the date the job posting expires
• employmentType — such as FULL_TIME, PART_TIME, CONTRACTOR, or INTERN
• baseSalary — the pay range or fixed amount
• identifier — a unique internal reference for the role
• directApply — indicates whether candidates can apply directly from search results
• jobLocationType — used to flag remote positions

The more complete the markup, the more information Google can surface in its job listing cards, which directly affects click-through rates. Leaving recommended fields empty does not break the schema, but it reduces the richness and visibility of the listing.

How does Google use JobPosting structured data in search?

Google uses JobPosting structured data to power its Google for Jobs experience, a rich results feature that surfaces job listings directly within search results pages. When Google crawls a page with valid JobPosting schema markup, it can extract the role details and display them in a dedicated jobs panel with filtering options for location, employment type, and date posted.

This is significant for employers and job boards because Google for Jobs aggregates listings from across the web rather than relying on a single platform. A well-marked-up job posting on a company’s own careers page can appear alongside listings from major job platforms, giving smaller organizations direct visibility in job searches without needing to pay for placement.

Google also uses the structured data to understand the freshness and relevance of a listing. The datePosted and validThrough fields signal when a role was published and when it expires, helping Google avoid surfacing outdated listings. Listings without a validThrough date may remain indexed longer but risk appearing stale in search results.

Which formats can be used to implement JobPosting schema?

JobPosting schema markup can be implemented in three formats: JSON-LD, Microdata, and RDFa. Google recommends JSON-LD as the preferred format because it is placed in a separate script block in the page’s head or body, keeping it cleanly separated from the visible HTML content.

JSON-LD

JSON-LD (JavaScript Object Notation for Linked Data) is the most widely adopted format for job posting structured data. It is written as a <script type="application/ld+json"> block and does not require any changes to the visible page markup. This makes it easy to add, update, and maintain, especially on dynamically generated pages or templated career sites.

Microdata and RDFa

Microdata and RDFa embed the structured data directly into the visible HTML elements of the page using special attributes. While both formats are technically valid, they are more complex to implement and harder to maintain because any change to the page layout can inadvertently break the markup. For most teams, JSON-LD is the practical choice unless a content management system enforces one of the other formats.

What salary and location standards apply to JobPosting data?

For salary data, schema.org JobPosting uses the MonetaryAmount type within the baseSalary property. This requires specifying a currency (using ISO 4217 codes such as EUR, USD, or GBP), a value or range, and a pay unit such as HOUR, DAY, WEEK, MONTH, or YEAR. Salary information must reflect the actual compensation offered and not be misleading or so approximate as to be uninformative.

For location, the jobLocation property uses the Place type with an embedded PostalAddress. This should include the street address, city, region, postal code, and country. For remote roles, the jobLocationType property should be set to TELECOMMUTE, and the applicantLocationRequirements property can be used to specify which countries or regions are eligible.

International job postings should pay close attention to country codes and address formats. Schema.org uses ISO 3166-1 alpha-2 country codes (such as NL for the Netherlands, DE for Germany, or US for the United States). Using inconsistent or informal location labels can reduce how accurately search engines match the listing to location-based job queries.

Why might a JobPosting not appear in Google for Jobs?

A JobPosting may not appear in Google for Jobs for several reasons, ranging from technical markup errors to policy violations. The most common causes include missing required fields, incorrect data types, and pages that are blocked from crawling or indexing.

The following issues are frequently responsible for listings being excluded:

• Missing required properties — omitting title, description, hiringOrganization, jobLocation, or datePosted will prevent eligibility
• Expired listings — if validThrough has passed, Google will stop showing the listing
• Blocked pages — if the job posting page is blocked by robots.txt or a noindex tag, Google cannot index the structured data
• Markup errors — syntax errors in JSON-LD or mismatched property types cause Google to ignore or partially parse the schema
• Content mismatch — structured data that does not match the visible content on the page violates Google’s guidelines and can result in manual actions
• Aggregator conflicts — if the same listing appears on a third-party platform with stronger authority, Google may prefer that source

Google’s Rich Results Test and the URL Inspection tool in Google Search Console are the most reliable ways to diagnose these issues. The Rich Results Test will flag missing fields and parsing errors, while Search Console shows whether a page has been indexed and whether any manual actions have been applied.

How Openindex helps with JobPosting structured data

Implementing job posting structured data correctly requires both technical precision and a clear understanding of how search engines interpret and validate schema markup. At Openindex, we help organizations get this right from the start. Whether you are running a job board, a corporate careers page, or an HR platform, we can support your structured data implementation with:

• Custom development of JSON-LD templates that generate valid JobPosting markup dynamically from your data sources
• Integration of structured data into existing CMS platforms, APIs, and application backends
• Validation and auditing of existing markup to identify missing fields, formatting errors, or policy violations
• Crawling and indexing solutions that ensure your job pages are discoverable and correctly parsed by search engines
• Ongoing support for schema updates as Google’s requirements and Schema.org specifications evolve

Our team has deep expertise in data structuring, crawling, and search technologies, which means we approach structured data not just as a markup task but as part of a broader data quality strategy. If you want your job listings to appear in Google for Jobs and reach candidates at the moment they are searching, we are ready to help. Get in touch with us to discuss your structured data needs.