This is the core of the article. Everything below rests on Google Search Central's JobPosting documentation (confirmed August 9, 2026). Specifications change, so check the current version when you implement.
The properties Google supports fall into three tiers: required, recommended, and beta. Five properties are listed as required (datePosted, description, hiringOrganization, jobLocation, and title). There is an exception for jobLocation: it is not required for a 100% remote job that uses applicantLocationRequirements.
4-1. hiringOrganization — the company name, not the site name
This is the property where mistakes happen most often. The documentation states that it is the company that is offering the job position and that it has to be the name of the company. The contrast it draws is clear: a legal entity name such as "Starbucks, Inc" belongs here, and a hiring-location name such as "Starbucks on Main Street" does not.
"hiringOrganization": {
"@type": "Organization",
"name": "MagsRUs Wheel Company",
"sameAs": "http://www.magsruswheelcompany.com"
}
sameAs can point to the company's website. Where companies share or resemble each other's names, a name alone does not resolve to one entity, and using this as an aid to identification is reasonable. Google does not, however, guarantee that effect in the JobPosting documentation.
4-2. confidential — the official rule for anonymous postings
Here sits a rule many practitioners do not know. The documentation specifies that when an organization is hiring anonymously — the examples given are a staffing or recruitment services provider posting on behalf of an anonymous employer, and an employer posting anonymously directly on a platform — you set hiringOrganization.name to the value confidential, in lower case.
"hiringOrganization": {
"@type": "Organization",
"name": "confidential"
}
What matters is that even an anonymous posting has a prescribed way to declare that it is anonymous. When an employer wants to stay unnamed, practitioners sometimes enter the posting company's name or a made-up name, or drop the property altogether; the answer the specification gives is confidential. Misrepresenting the employer is clearly prohibited by Google's job posting content policies, which list impersonating another organization, listings that do not accurately represent the actual job, postings for jobs that do not exist, and posting on behalf of another company without authorization among the violations.
Note that "the company that actually employs the person" is not a synonym for the company where the work happens. Under Japanese law, a temporary staffing worker is legally employed by the dispatching agency, not by the client company where the work is performed — so do not read hiringOrganization as "the workplace." How "who is posting this job" becomes structurally hard to see in postings routed through recruitment agencies, staffing firms, and applicant tracking systems is a topic in its own right. A separate article in this series (employer attribution in the staffing and recruitment industry) is planned to cover it; here we keep to the specification.
4-3. jobLocation — where the work happens, not where it was posted
jobLocation means the physical location of the business where the employee actually reports to work. The documentation states explicitly that this is not the location where the job was posted. addressCountry is required. Where there are multiple work locations, they are written as an array, and Google is described as selecting a location suitable for display.
4-4. jobLocationType and applicantLocationRequirements — expressing fully remote work
Fully remote jobs have their own dedicated expression. You set jobLocationType to TELECOMMUTE and state in the job description that the role is 100% remote. The requirement is strict: the documentation defines a TELECOMMUTE job as one that has to be completely remote, and prohibits this markup for arrangements that are not 100% remote, such as jobs where occasional work from home is permitted or where remote work is a negotiable benefit.
applicantLocationRequirements specifies the geographic area in which an applicant may be located. For a 100% remote job with no physical work location, this property specifies where applicants may apply from, and it needs to indicate a scope of at least one country. Where both a physical work location and remote work are permitted, one configuration uses the country given in jobLocation as the default scope.
"applicantLocationRequirements": {
"@type": "Country",
"name": "USA"
},
"jobLocationType": "TELECOMMUTE"
4-5. directApply — a property whose effect is stated to be still in development
directApply is a boolean indicating whether an applicant can apply directly from the job URL. The specification itself carries a caveat worth noticing: how this information will be used is still under development, and you may not see any immediate display or effect in Google Search.
By Google's definition, a direct apply experience is one that offers a short and simple application process without unnecessary intermediate steps; if the applicant is asked to click apply, fill out forms, or sign in multiple times, it is not a direct apply.
This property demonstrates the theme of this article from inside the specification. Implementing something does not necessarily produce a display or an effect — and here Google says so itself.
4-6. validThrough and handling closed postings — where manual action risk lives
validThrough is the date and time at which a job posting expires. It is described as required for jobs that have an expiry date, and as something not to specify for jobs where no expiry is known.
What matters is the handling when a posting closes. The documentation states that jobs no longer accepting applications have to be closed out by prescribed methods, and that failing to deal with expired postings in a timely manner may result in manual action. There are three methods — set validThrough to a past date and time, remove the page itself and return a 404 or 410, or strip the JobPosting structured data from the page. Google recommends removing expired postings from the site as the ideal, and describes setting validThrough to a past date and time as what to do when the page is not removed.
In practice this is the part most often overlooked. Job pages fail more readily at the close than at the launch. When integrating with an applicant tracking system, the closing flow needs to be designed with the same precision as the publishing flow.
4-7. Other recommended properties and beta properties
The recommended properties include baseSalary (the actual base salary the employer is offering, with unitText as one of HOUR through YEAR, and ranges given via minValue and maxValue), employmentType (FULL_TIME, PART_TIME, CONTRACTOR and others, eight values in total, multiple values permitted), and identifier (the employer's own job identifier). The four beta properties covering education and experience carry the same caveat as directApply.
The documentation also states that title takes the job title itself, and that job codes, addresses, dates, salaries, and company names do not belong in it.
4-8. Markup has to match the visible text
Separate from any individual property, one principle covers the whole. All information contained in the markup has to be present visibly on the job posting page.
The documentation gives as a violation the case where a salary appears in the markup but is not displayed on the page. This principle matches the recommendation in the guide on generative AI features. Structured data is not a place to make additional claims that the page does not make.
