Implementing Job Posting Schema for Remote Jobs
Understanding Job Posting Schema
The job posting schema is a standardized format that helps search engines like Google and Bing understand and display job listings accurately. Both search engines have dedicated search features related to job postings that get triggered when a user inputs a query about a job search.
Implementing this schema is crucial for job boards because it ensures job postings appear correctly and prominently in search results, making it easier for potential candidates to find relevant jobs. Using this structured data, job boards can improve their visibility and gain more organic traffic by attracting more applicants.
The job posting schema is a simple JSON object with the most essential details about the job, such as title, location, description, salary, etc.
You can find the Google-defined Job Posting Schema requirements at this link.
Issues with Schema implementation for remote jobs
Implementing a job posting schema is essential for more organic visibility and attracting suitable candidates. Generally speaking, it is very straightforward – you must map your existing job data to the Google format and embed it on the page.
However, proper implementation, especially for remote roles, is quite tricky. This is one of the most common issues I see when I audit job boards and ATS platforms. It is a pity because when appropriately implemented, remote jobs gain a lot of visibility in Google jobs.
Here’s a detailed guide to ensure proper schema implementation.
Types of remote jobs
Before we start, we have to agree on the definition of what a remote job is:
In Google’s perspective, there are three types of jobs based on where the employee is:
1. Remote: Jobs that can be performed from any location.
2. Hybrid/Flexible: Jobs that can be performed both remotely and from a physical location. This category caters both too flexible jobs (employee chooses) but also hybrid (fixed days in the office, fixed days remote)
3. Fixed Location: Jobs must be performed at a specific location.
As you can imagine, this is a fundamental view of where a job location can be. How about field sales or consulting jobs, where the consultant travels between multiple sites?
Google does not give a lot of guidance on how to do that. However, Google monitors whether a job is remote; if you label a remote job as a non-remote one, you will most likely get a manual action quite fast. So, the rule to obey here is to use the remote setting ONLY if the job is remote.
Job location implementation in the schema
Google gives us three properties in the job posting schema that can be used to define the location:
1. jobLocationType: Specifies if a job is a work-from-home position.
2. applicantLocationRequirements: Defines geographic locations where employees can be located for remote jobs. At least one country is required. This is very important.
3. jobLocation: Indicates the physical location where the job can be performed, if applicable.
Confusing?
Let’s look at the most common issues I have seen, and things will become much more straightforward.
Common schema implementation issues
Missing applicantLocationRequirements
This is the most common issue I see. We have a remote job where the jobLocationType is correctly set to TELECOMMUTE, but the required element applicantLocationRequirements is not set. This will raise an error in your search console because Google expects some geographic restrictions on remote jobs.
These restrictions are handled with the applicantLocationRequirements field.
Wrongly implemented applicantLocationRequirements
Although the requirements on how this field should be constructed are pretty simple (type and name), I have seen all kinds of variations where either this is being ignored or implemented incorrectly.
Not marking remote jobs as such.
Some job boards I have worked on just chose not to add any remote schema parameters because they tried in the past and got errors.
Although this is a less risky approach, you will miss a lot of traffic.
No Schema Implementation
Some job boards and job board SaaS platforms decide not to put schema on remote jobs. This is a terrible idea, as your job will not be eligible to be seen on Google Jobs, and you will miss out on organic traffic.
The mistakes are always visible in the search console:
Proper Implementation for different job location types in the schema
So, let’s look at some examples of appropriate implementations for the three types of jobs: remote, hybrid and on-site.
Essential: when testing the schema, stick to the rich results test tool
The schema validator does not raise the same errors as Google.
On-site job posting schema
We start nice and easy with an on-site (physical location) job. This job has a fixed address where the applicant is based. This is the correct schema application:
{
"jobLocation": {
"@type": "Place",
"address": {
"@type": "PostalAddress",
"streetAddress": "555 Clancy St",
"addressLocality": "Detroit",
"addressRegion": "MI",
"postalCode": "48201",
"addressCountry": "US"
}
Notice that there is no need to add applicantLocationRequirements or jobLocationType.
As it is always with Google, providing as much information as possible about the location is highly beneficial. Important for indexing are specifically street and zip-code level location details.
Fully remote job posting schema
We are continuing with another relatively simple example. This is how the schema should look like for a job advertised as fully remote.
{
"applicantLocationRequirements": {
"@type": "Country",
"name": "USA"
},
"jobLocationType": "TELECOMMUTE"
}
Notice that both options, applicantLocationRequirements and jobLocationType, are present. On the other hand, job location is not present and is not required because this field should only be used for fixed locations.
A couple of things. Google does not validate the country field, so many people are typing “any” or “anywhere.” Using this will validate the field, and I am yet to see an impact on ranking. I guess that Google is not recognizing and ignoring this case, leading to this job being shown for all remote searches.
It is still a risky decision because this might change.
You can also provide more than one country. It can be done like this:
Of course, I have seen people listing 20 or 30 countries here. From what I have seen, this approach works, but it is still being determined how long Google will be happy with it. For now, it works.
When you do that, you have to think about the implications. Every country you list would be eligible to show the job in the remote search. Think about that – do your customers want applicants from any of these countries? Most likely, no.
Most employers require a remote worker to be physically in the country of operation due to legal and contractual obligations.
This is why, on my sites, I tend to stick to 1-3 countries max, in most cases, the country where the company is operationally based.
Now, a lot can go wrong here because you ALWAYS have to provide “@type” and “name” values; otherwise, the validation will fail.
For example, I have seen the following wrong implementations:
- Skipping the type variable
- Using a type that is not supported or providing the wrong type (in this case, Cairo is a city, not a state)*
- Listing multiple countries with a comma in the name field
- Using a type with a wrong value (type State with name which is a City)
- Using the jobLocation entity with “Anywhere”
Hybrid jobs - physical site or remote
In this case, you must use all three fields: jobLocation,applicantLocationRequirements, and jobLocationType.
The first example indicates the job can be done remotely from Canada or at a physical location in Detroit, MI.
{
"jobLocation": {
"@type": "Place",
"address": {
"@type": "PostalAddress",
"streetAddress": "555 Clancy St",
"addressLocality": "Detroit",
"addressRegion": "MI",
"postalCode": "48201",
"addressCountry": "US"
}
},
"applicantLocationRequirements": {
"@type": "Country",
"name": "Canada"
},
"jobLocationType": "TELECOMMUTE"
}
Let’s look at another example that allows the job to be performed at a physical location in Detroit or remotely within the states of Michigan or Texas.
{
"jobLocation": {
"@type": "Place",
"address": {
"@type": "PostalAddress",
"streetAddress": "555 Clancy St",
"addressLocality": "Detroit",
"addressRegion": "MI",
"postalCode": "48201",
"addressCountry": "US"
}
},
"applicantLocationRequirements": [{
"@type": "State",
"name": "Michigan, USA"
},{
"@type": "State",
"name": "Texas, USA"
}],
"jobLocationType": "TELECOMMUTE"
}
Notice how the applicantLocationRequirements has two values? This is the proper way of handling multiple entries.
Key Points for Implementation
To summarize, remote jobs generally get a lot of traffic, and jobs with incorrectly implemented location schemas will not be eligible for Google Jobs. Hence, it is essential to handle remote schema implementation properly to avoid losing this traffic.
Stick to these rules, and you should be on the safe side:
- Specify at least one country for remote eligibility using applicantLocationRequirements.
- Make sure that the remote requirements have the correct type and value
- Use jobLocationType to indicate the job is 100% remote with the value TELECOMMUTE
- Jobs marked as TELECOMMUTE must be fully remote.
- Validate implementations using the Rich Results Tool and don't trust the Schema validator.
*A funny question is why it does not pass the validation, but "Anywhere" does. I guess that Anywhere does not match against an existing location entity)
If you like my post, feel free to subscribe and be the first to get the latest blog posts in your inbox.
Some blog posts that might be relevant for you if you are interested in Google Jobs:
Is it OK to use the Indexing API for non-jobs?
Is Google Removing the Full Job Description from Google Jobs?