How updates arrive

Astro has no equivalent of Next.js’s tag revalidation, so how a publish reaches your readers depends entirely on how your site is built. This is worth settling before you write any of the routes.

Your build	When a publish shows up
Server-rendered (output: "server", or prerender = false on the route)	On the next request. Astro has no data cache, so each render reads the current content. Only the list of published products is kept, for 30 seconds
Fully static (output: "static")	On your next build. Geoffy content is read at build time, so nothing changes until you rebuild

On a server-rendered site, a newly published product shows up within those 30 seconds, because the helper checks the list before it asks for the product.

There is no deploy hook, and no static acceleration

If you have read an older version of this guide

Earlier documentation described a Fully static build-mode setting and a deploy hook field that would trigger a rebuild on publish. Both were removed. There is no build credential to give us and no field to fill in.

A fully static site’s content appears at its next build. That is simply the truth about a static site, and holding a build credential on your behalf would not change it so much as move it — so the honest shape is to say it plainly rather than to offer an acceleration that is really just “we press your deploy button”.

What this means for your architecture

If your catalogue changes at all often, on-demand rendering is the shape that fits. Two reasons, and the second is the one people miss:

1. Your content refreshes within the hour instead of at your next deploy.
2. A fully static build cannot serve the Geoffy namespace at all — that route requires on-demand rendering. Without it your product twins, buying guides and Geoffy sitemap stay on api.geoffy.ai, and the citations they earn go to us rather than to you.

So the choice is not only about freshness. Going fully static costs you the namespace, which is the thing that puts your content on your own domain.

Tuning the window

In Astro there is no fetch cache to tune: revalidateSeconds is accepted on the options object and has no effect. Two things can still hold an old answer:

• The list of published products, kept in memory for 30 seconds.
• The text files (llms.txt and the others) answer with Cache-Control: max-age=300, so a browser or CDN in front of your site can keep them for 5 minutes.

If an answer looks stale while you integrate, see testing locally — a stale cache is the single most common cause of “I fixed it and nothing changed”.