Getting a Client's Job Postings Ranked in Google Jobs Within a Month

The client was publishing job openings on their own site and getting almost nothing back from search. Their listings existed as ordinary web pages — readable by a person, but invisible to Google Jobs, the dedicated results panel that sits above conventional listings for employment queries. Candidates searching for roles in their region were being shown competitors' postings sourced from job boards, while the client's own openings sat unindexed on their domain.

The business cost was straightforward. Every hire that came through a third-party job board carried a placement fee or a listing cost, and every week a role stayed open was a week of unfilled capacity. The client had already invested in writing and maintaining their careers pages; that investment was returning no organic candidate flow.

The underlying problem was technical rather than editorial. Google Jobs does not infer job data from page copy — it requires structured data conforming to the JobPosting schema, served in a form the crawler can parse reliably. Without that markup, no amount of content improvement would surface the roles. The client had no way to diagnose this themselves, and no clear picture of whether their pages were being crawled at all.

I built a purpose-made job posting engine on Next.js using the App Router, structured in four layers — presentation, application logic, data access, and persistence — so that job data has a single source of truth and the markup Google reads can never drift from what the page displays.

The core of the work is JSON-LD structured data generated directly from the database record for each role. Every posting emits a JobPosting schema block containing the fields Google requires and rewards: title, description, hiring organisation, employment type, location, and validity dates. Because the markup is derived from the same record that renders the page, adding or editing a role updates both simultaneously — there is no separate SEO step for the client to forget.

Data is modelled with Drizzle ORM against a Supabase Postgres database, giving type-safe queries and a schema that can be migrated without hand-written SQL. The application is deployed on Vercel, which serves the posting pages from edge infrastructure and rebuilds them on content change. DNS was configured on XServer to point the client's existing domain at the deployment, so the postings live on their own brand rather than a subdomain.

I also ran a security review of the application before launch, covering input handling, access control on the admin surfaces, and environment secret management.

Within a month of launch, the client's job postings were ranking in Google Jobs — appearing in the dedicated employment results panel for relevant searches, on their own domain rather than through a third-party board.

The client reported being very satisfied with the outcome. Structured performance metrics were not instrumented at launch, so this write-up does not claim traffic or conversion figures; what changed measurably is indexation status — postings that were previously absent from Google Jobs entirely are now present and discoverable there.

Operationally, publishing a role is now a single action. The engine handles schema generation, deployment, and indexing signals automatically, removing the manual SEO work that would otherwise sit between writing a job description and having it appear in search.