Getting your jobs found by answer engines

• A job gets quoted by a search or answer engine when the facts on the page are readable without interpretation. That means JobPosting structured data, in JSON-LD, on the individual job page, carrying at minimum the five properties Google lists as required: datePosted, description, hiringOrganization, jobLocation and title.

• Those five make a posting eligible. The recommended properties and the page architecture around them decide whether it gets shown.

The five required properties

• The last row catches people. "Senior Backend Engineer" is a job title. "We're hiring! Join our growing team" is a posting title. The property wants the first.

• The description property is stricter than it looks. It has to be complete. A page that shows two paragraphs and hides the rest behind an expand control, or one that puts the real detail in a linked PDF, fails the completeness expectation even when the markup validates.

The recommended properties that decide how good the result looks

• Google's general guidelines put it directly: the more recommended properties you provide, the higher quality the result is to users. The ones worth adding first are baseSalary, employmentType, identifier, validThrough, applicantLocationRequirements, jobLocationType and directApply.

• Those map to the questions a person actually asks an answer engine. What does it pay, is it full time, is it remote, can someone in my country apply, and is it still open. A posting that answers them in machine-readable fields can be quoted. One that leaves them in prose has to be inferred, and inference loses to a competitor's explicit field.

• schema.org defines a wider set on the same type, including salaryCurrency, estimatedSalary, workHours, jobStartDate, jobImmediateStart and applicationContact. Adding properties beyond Google's recommended list costs nothing and gives other consumers of the markup more to work with.

Eligibility rules that quietly disqualify a careers site

• Four rules do most of the damage, and all four are architecture decisions rather than markup decisions.

• One job per page. The page has to contain a single job posting. A careers index listing twenty roles with markup for all twenty is outside the rules, and the markup belongs on each individual job page instead.

• A way to apply without a login. If a candidate has to create an account before they can apply, the page is not eligible. That rule doubles as conversion advice, which we cover in [your careers page is a conversion problem](/spaces/careers-page-conversion-problem).

• Markup on the same page as the description. Structured data describing a job has to live on the page that shows that job.

• A crawlable site. Googlebot has to be able to crawl the site efficiently. A careers section rendered entirely client side behind a search filter is a common way to fail this without anyone noticing.

Removing expired jobs, and the manual action

• Google gives three ways to retire a posting: set validThrough to a date in the past, return a 404 or 410 for the URL, or remove the JobPosting markup. The documentation warns that failure to take timely action on expired jobs may result in a manual action.

• A structured data manual action removes the page's eligibility to appear as a rich result. Ordinary search ranking is unaffected. That is a narrower penalty than most people assume, and it still costs you the presentation candidates click.

• The practical fix is to make expiry automatic. Every requisition has a close date somewhere in your hiring system. Wire that field to validThrough and to the page's HTTP status, so a role closing on a Friday retires itself without anyone remembering.

The general guidelines apply too

• Three rules from Google's general structured data guidelines catch job pages regularly.

• Mark up only content visible to readers of the page. A salary range in the markup that appears nowhere on the page is a violation, however well intentioned.

• Keep the structured data relevant to what the page is. A JobPosting type on a general "work with us" culture page describes something the page does not contain.

• Where the same job exists at several URLs, apply identical structured data to all of them rather than only to the canonical version.

Why answer engines want the same things

• An answer engine assembling a reply about open roles has the same constraints as a search crawler. It needs one job per URL so it can attribute a fact to a source, a complete description in HTML so the text it reads is the text a candidate sees, and explicit fields for salary, location and closing date so it can answer without guessing.

• Correct JobPosting markup is therefore the same work twice. The properties that make a posting eligible for a rich result are the properties that let any engine quote it accurately.

• Where you publish in more than one language, give each language its own job page rather than switching content on one URL, so the one-posting-per-page rule holds in both. That case is covered in [hiring in Arabic and English](/spaces/hiring-in-arabic-and-english).

Before you publish a job page

1. All five required properties present, with title holding the job title.
2. The full description in the markup, matching what the page displays.
3. baseSalary, employmentType, validThrough and identifier added.
4. jobLocationType and applicantLocationRequirements set where the role is remote.
5. One posting on the page, and no JobPosting markup on any listing page.
6. An apply route that works without an account.
7. validThrough wired to the requisition close date, with a 404 or 410 after it.

• Run the result through Google's Rich Results Test before the page goes live, then check the Search Console report a week later for items that validated locally and failed in the wild. Whether any of it converts is a separate measurement, covered in [how to measure candidate experience](/spaces/measure-candidate-experience).