Greenhouse jobs on WordPress: how to get found on Google

People looking for work start on Google. This guide covers what it takes for your Greenhouse jobs to show up there from your own WordPress site, and what a WordPress plugin for Greenhouse has to do to help.

Where Greenhouse already puts your jobs

Greenhouse publishes each job on your hosted job board, at an address such as job-boards.greenhouse.io/yourcompany, and prepares those pages for Google. In Greenhouse’s words, “Job posts on Greenhouse Recruiting automatically include basic metadata so Google can display your job posts in search results more easily.”

The same article suggests going further with your marketing or SEO team: “Mark up your job listings with job posting structured data”, and “Include a sitemap (or an RSS/Atom feed) with a <lastmod> date for each job listing.” That is the work this guide describes, done on your own domain.

Why your own domain? A job page on Greenhouse’s board earns its visits for Greenhouse’s address. A job page on your site brings candidates to your site, next to your About page, your product and your other openings.

What Google needs from a job page

Four things, in order of importance.

1. A real page and URL per job

Google ranks pages, not lists. Each job needs its own address on your site, such as yoursite.com/jobs/senior-designer-4012345/, that returns the full job as HTML.

If you use Greenhouse’s embedded job board, each job opens on your careers page, but the job text is served from Greenhouse inside a frame. A WordPress page per job puts the text in your own page’s HTML.

2. JobPosting structured data

JobPosting is a block of schema.org data in the page’s source. It tells Google, in fixed fields, what the job is: title, description, company, location, date posted and closing date.

This markup is what makes a page eligible for Google’s job search results, the panel that appears above ordinary links for searches like “marketing jobs in Berlin”. Google’s job posting guidelines list the required fields: title, description, datePosted, hiringOrganization and jobLocation.

3. A sitemap that lists every job

The XML sitemap tells Google which pages exist and when they last changed. New jobs should appear in it as soon as they are published, and closed jobs should leave it.

4. Closed jobs that actually close

A job that stays online after you fill it frustrates applicants. Google’s guidelines ask sites to take expired jobs down, for example by removing the page. When a job closes in Greenhouse, its page on your site should come down and drop out of the sitemap.

Pages per department and location

Beyond single jobs, archive pages such as “Engineering jobs” or “Jobs in Berlin” collect every open job in one group at a stable URL. People search that way, so these pages can match searches that no single job page would.

The Google Indexing API

Google normally finds new pages on its own schedule, which can take days. For job pages, Google offers a shortcut. Its job posting guide says: “For job posting URLs, we recommend using the Indexing API instead of sitemaps because the Indexing API prompts Googlebot to crawl your page sooner.” The Indexing API lets a site tell Google the moment a job is published, changed or removed.

It needs a Google Cloud service account with owner access to your site in Search Console. It asks Google to crawl; it does not guarantee indexing or a position in results.

When your page and Greenhouse’s describe the same job

Your job page and the job’s page on your Greenhouse board can both carry job data for the same role. When the same job appears in more than one place, Google decides which listing to show. No site or plugin controls that choice.

What you control is giving Google a complete, fast page on your own domain, linked from the rest of your site. Over time, visits and links to that page build up on your domain.

How Greenhouse Jobs for WordPress covers this

Greenhouse Jobs for WordPress syncs the jobs published on your Greenhouse job board into WordPress and handles each point above:

• A page per job on your domain, as plain HTML that follows your theme.
• JobPosting data on every job page: title, description, date posted, a valid-through date (the application deadline when you set one in Greenhouse), your company and the job’s location. A remote job is marked as remote when the countries applicants may live in are known, and a pay range you publish in Greenhouse becomes the salary when its pay period is clear.
• Department and location pages, such as /jobs/department/engineering/ and /jobs/location/emea/ireland/, on by default and listed in the sitemap. Locations follow your Greenhouse office tree, and employment type pages are added when your board has an employment type field.
• Sitemap entries for every job. Jobs are ordinary WordPress posts, so the WordPress sitemap lists them, or your SEO plugin’s sitemap if it replaces it.
• Closed jobs come down. Every sync, every 30 minutes by default, moves jobs that are no longer on your Greenhouse board to the trash.
• The Indexing API, optional. Off by default. Add a service account key and the plugin notifies Google when a job is published, changed or closed.
• Applications on the same page. With a Job Board API key, candidates use the on-site application form instead of leaving for Greenhouse.
• No clash with your SEO plugin. With Yoast, Rank Math, AIOSEO, SEOPress or Slim SEO active, the plugin leaves the description, canonical and social tags to it. The JobPosting data is printed either way; if your SEO plugin also adds job posting markup, turn one of them off.

What goes into the JobPosting data

The plugin fills the fields from what Greenhouse publishes, and leaves a field out rather than guess:

• Location comes from the address Greenhouse stores for each office, such as “Dublin, Ireland”. Office names are never used as places, because they are often internal groupings like “EMEA” or “Acme Global”. Without an office address, the job’s location text is used.
• Remote jobs get jobLocationType: TELECOMMUTE together with the countries applicants may live in, read from the location text (“Remote - Canada”) or from the job’s office addresses. A job whose location reads “Remote - Europe” names a region, not a country, so the plugin leaves the remote type out unless an office address gives a country. A developer can supply the countries with the ghjb_schema_applicant_countries filter:

add_filter( 'ghjb_schema_applicant_countries', function ( $countries, $job ) {
	if ( empty( $countries ) && false !== stripos( $job['location'], 'Remote - Europe' ) ) {
		foreach ( array( 'Germany', 'France', 'Spain' ) as $name ) {
			$countries[] = array( '@type' => 'Country', 'name' => $name );
		}
	}
	return $countries;
}, 10, 2 );

• Salary (baseSalary) comes from the job’s first pay range. The period is read from the range’s wording (“hourly”, “Annual Base Salary”). When the range names none, a year is assumed only for salary-sized amounts (15,000 or more) in USD, CAD, AUD, NZD, GBP or EUR; otherwise the salary is left out, while the page still shows the range. Untick Pay ranges under Greenhouse → Settings → Display and both the row and baseSalary go.
• Valid through is the application deadline you set in Greenhouse. Without one, it is a rolling date that stays in the future while the job is open, 30 days ahead by default (the Job validity setting; 0 leaves the date out).
• Direct apply (directApply: true) is added while the on-site application form is in use.

Setup is in the installation guide, and the sitemap and schema switches are covered in settings. Comparing setups first? See three ways to add Greenhouse jobs to WordPress, the FAQs and pricing.

How to check it in Search Console

Once your job pages are live:

1. Paste one job URL into Google’s Rich Results Test. It should find a valid Job posting.
2. In Search Console, submit your sitemap under Indexing → Sitemaps if it is not there already.
3. Use URL Inspection on a job page and click Request indexing for the first few.
4. After a few days, open the Job postings report under Enhancements. It lists valid job pages and any missing fields.

Warnings for missing optional fields, such as salary, do not stop a page from being eligible. Errors do: fix those first.