Pre-rendering for job boards - expiry control, Google for Jobs hygiene, and canonical discipline

The first template to fail is almost always the canonical job page because it carries the structured data, expiry state, and intent Google for Jobs cares about most. If that page serves stale active HTML after a role is filled or expired, the board starts training crawlers not to trust its inventory.

The second failure point is browse sprawl. Employer pages, keyword pages, remote filters, and deep pagination all look useful in the product, but only a controlled subset deserves indexation. Without that boundary, the board spreads crawl attention across browse states while the canonical jobs themselves stay weaker than they should be.

Start with canonical active job URLs, then add employer pages that consistently surface live jobs, and only then consider a narrow subset of high-signal search pages. That order matches how search engines and users actually extract value from a board.

Do not try to render every keyword permutation, salary filter, remote toggle, or deep page in pagination. Those URLs may help onsite navigation, but they usually weaken SEO when they become an uncontrolled render surface. If the board also behaves like a seller or provider directory, compare the overlap with marketplaces.

Job boards win or lose on expiry discipline. `validThrough` should be in the first HTML, but that alone is not enough because jobs get filled or withdrawn before the planned expiry date all the time.

In practice, you need two layers working together: event-driven purge for filled or withdrawn roles, and a scheduled expiry sweep for anything that passes `validThrough`. That combination keeps crawler-facing HTML aligned with reality instead of waiting for one nightly job to catch everything after the damage is already done.

The structured data fields that matter most - title, hiring organization, location, employment type, date posted, and `validThrough` - need to land in the first HTML snapshot. If they appear only after hydration, the board is effectively asking Google to infer critical state from a partial render.

This is where pre-rendering helps most on job sites. It makes the canonical job URL stable and legible on the first crawl. The trick is not to stop there. Once the HTML is stable, the expiry workflow has to be equally disciplined or the board just becomes better at publishing stale jobs.

Employer pages can be useful crawl hubs because they group active roles, but they should support the canonical job URL rather than compete with it. The `JobPosting` schema belongs on the job page. Employer pages summarize and link; they should not blur the source-of-truth role URL.

Pagination is where boards quietly burn crawl budget. A bounded subset of page 1, and sometimes pages 2-3 for proven high-demand categories, can make sense. Deep pagination almost never deserves the same treatment. This is the same kind of crawl-discipline problem covered in crawl budget 80 percent.

They rely on `validThrough` without a real purge workflow. They keep expired roles live because product teams want a larger-looking catalogue. They let employer pages, filters, and keyword URLs compete with canonical jobs. And they treat 410, noindex, and redirect behaviour as interchangeable when they solve very different problems.

The result is predictable: stale listings linger, Google for Jobs visibility is unstable, and crawl budget gets spread across browse surfaces that do not deserve it. If freshness policy is already becoming hard to manage, pair this page with pre-render cache headers so TTL logic follows job state instead of one global default.