Careers Pages: Give Each Open Vacancy Its Own Accurate Job Detail

A careers page needs more than an attractive list of titles and a general contact form. Before commissioning it, decide which genuine vacancy each page represents, where an applicant can apply for that role and how the public information changes when recruitment closes. The useful deliverable is a reliable route from an advertised position to the correct application, not a promise of Google visibility.

This guide concerns a company's own vacancy pages. It does not establish employment-law requirements, permitted hiring criteria or mandatory salary disclosures. Have the responsible HR and legal advisers approve the job content and application policy.

Separate the vacancy list from the actual job

A fictional business is hiring a workshop coordinator and a customer support specialist. Its careers overview can help visitors compare the openings, but each role needs a clear destination with its own description and application route. A shared headline such as “Join our team” does not identify which position someone has selected.

Google's official JobPosting documentation places job structured data on the detailed page for a single job, not on a search result or list of vacancies. It also requires the structured data and readable job description to be on the same page. These are requirements for Google's job-search feature, not a rule that every careers site must implement structured data.

Ask the developer to keep the careers overview and vacancy template distinct. If the first release has no individual job pages, do not attach a collection of JobPosting objects to the overview as a shortcut.

Give the content owner one role record to maintain

Prepare an approved example containing the actual title, employer, duties, requirements, working arrangement and application destination. Establish who can change it. Do not let a developer invent missing facts simply to fill a template or satisfy a validator.

Require the visible page and machine-readable values to draw from the same approved information wherever practical. Google explicitly treats mismatches as a problem, including salary information present in markup but absent from the readable page. A technically valid block of JSON is not permission to advertise terms that applicants cannot inspect.

A change to the workplace should therefore trigger a review of both the displayed location and associated markup. Do not label an office-based position as remote to attract more visitors. If remote hiring is genuinely offered, scope its location requirements separately with the content owner rather than assuming “remote” means worldwide.

Google defines datePosted as the original date the employer posted the job. Keep that meaning separate from the date someone rebuilt the website or corrected punctuation. Moving the site to a new template should not automatically make every existing vacancy look newly advertised.

Make the application destination role-specific

Choose whether applicants use an on-site form or continue to an approved recruitment service. In either case, show the role they are applying for at the destination. Carry a stable vacancy reference, not just a title that staff may rename later.

Google's policy requires a way to apply and says visitors must be able to read the job details without logging in. That does not establish a universal prohibition on accounts anywhere in an application process. Define any account requirement honestly and test the actual handover instead of assuming the presence of an Apply button proves it works.

A general expression-of-interest mailbox is a different proposition from an open job. Google does not permit fictional vacancies or job postings whose primary purpose is collecting applicant information rather than hiring. Keep an ongoing talent-interest page separate from the active-vacancy feed and do not dress it up as an opening that does not exist.

Close the vacancy without pretending every applicant was rejected

Decide who marks a role filled, cancelled or closed to further applications. Those events concern the vacancy; they do not by themselves determine the outcome of every application already received. Staff may still need to finish conversations or retain access under their approved policy.

For Google job-search eligibility, the documentation gives several ways to expire an unavailable job: set validThrough in the past, remove the page with an appropriate 404 or 410 response, or remove its JobPosting data. Agree which path your website uses. Merely removing the card from the careers overview does not demonstrate that the detailed page and its markup have changed.

If a closed page stays online, request a clear closed notice and an application route consistent with that state. Handle an already open application form according to the agreed cutoff policy. Do not silently attach a late submission to a different vacancy.

Accept the whole journey, not only the markup

Include two fictional vacancies in your website acceptance criteria. Open each detail page from the overview, inspect the readable facts, compare its structured data and follow Apply to the intended destination. Change one role's title and workplace, then verify that the other role remains unchanged.

Close one opening while its detail page is still open in another browser tab. Check the public notice, application handling, listing and chosen markup-expiry method. Ask for a structured-data test as well, but remember that Google says its Rich Results Test cannot identify every content-policy problem and that structured data does not guarantee a search feature will appear.

For a careers website discussion, bring one approved open vacancy and one closed example. Those give the developer a much clearer contract than “make our jobs show up on Google.”