A prerendered route still serves last week's title and preview text after the data changed, though its body updates on load. Why?

## What prerendering actually stores Producing a route ahead of time means running the route once during a build — data step, head computation, body render — and storing the resulting HTML. At serve time there is no rendering left: the request is answered from that stored artifact, possibly by a cache that never even asks the origin. The point people miss is that **the head is inside the artifact**. It is not assembled per request and pasted onto a stored body; the whole document, head included, was serialised at build time. So every computed head entry holds the value its inputs had at build time, and keeps it until the artifact is produced again. ## Why the body looks fresh and the head does not The body appears current because the page repairs itself in the browser: after hydration a client fetch pulls the present state and re-renders. That repair happens in **one browser's live document**. It does not rewrite the stored file, and it does not run at all for a consumer that never executes scripts. | consumer | executes the page's scripts | what it sees | |---|---|---| | a person in a browser | yes | stored head, then a repaired body | | a link-preview fetcher | usually no | the stored head, unchanged | | a crawler or archiver that does not run scripts | no | the stored head, unchanged | | a plain HTTP client | no | exactly the stored bytes | That table is also the diagnosis procedure. Fetch the URL as a plain request and read the head in the returned bytes; comparing against the browser's rendered document proves nothing, because the client has already repaired it there. ## The repair options 1. **Rebuild the page.** The direct fix: run the route again so a new artifact replaces the old one. A full build is the blunt version and can be slow on a large site — and do not assume a redeploy alone rebuilds everything, since build caching may reuse artifacts whose inputs it believes unchanged. 2. **A regeneration window.** The stored page is marked stale after some interval; the next request makes it eligible to be produced again, typically serving the existing copy while the new one is made. Freshness is bounded by the window, and the first request after expiry may still receive the old head. 3. **On-demand invalidation.** The system that changed the record tells the framework to drop the affected page. The fix is prompt, but every mutation path has to fire the trigger, and a path that forgets leaves a page stale indefinitely. 4. **Render per request.** If the head is genuinely volatile, stop storing the page. You pay render time on every request and gain a head that is always current. 5. **Narrow the head's dependencies.** Often the strongest option: keep in the head only facts that change on the same cadence as the page is produced, and let the volatile numbers live in the body where the client repair is legitimate. | option | freshness | cost | |---|---|---| | rebuild | as often as you build | build time, all pages | | regeneration window | bounded by the window | one stale response per expiry, per page | | on-demand invalidation | near-immediate | wiring every mutation path | | per-request rendering | always current | render on every request | | narrower head | not needed | a product conversation about what belongs in the head | ## Everything in front holds a copy Regenerating the artifact is not the end of it. A cache in front of the origin keeps its own copy of the document and will keep serving the old head until it is invalidated or its lifetime expires. A generated preview image is worse: the consumer that fetched it caches it under **its** URL, on a schedule you do not control, so a corrected head can still unfurl with a stale image. The remedy is to key such a URL to the content — a hash or version in the path or query — so that a change produces a new URL the consumer has never seen. ## The design rule this suggests Before a head entry is allowed to carry volatile data, decide what will produce the page again when that data changes, and how quickly. If the honest answer is "nothing until the next release", the entry does not belong in the head of a prerendered route. That decision is cheaper made once, as a rule about what the head may contain, than repeatedly as a bug report about a preview that is out of date.