How incremental static regeneration works
The site is built as static HTML, exactly as it would be with static site generation, but each page is given a freshness window. While the window is open, visitors are handed the stored file with no server work at all. Once it has expired, the next visitor still receives the stored file straight away, and the framework quietly rebuilds that page in the background. The visitor after them gets the new version.
Most implementations also allow an on-demand refresh: the CMS calls a webhook when an editor publishes, and only the affected pages are regenerated. So a site can behave like a static one — fast, cheap, served from the edge — while still updating itself page by page instead of all at once.
Why incremental static regeneration matters
It solves the problem that makes static generation painful at scale. A catalogue or a large content library does not have to be rebuilt in full every time a single item changes, which turns a long, nerve-racking deploy into a background task nobody notices. New pages can also be created on first request rather than waiting for the next build.
For search, the important part is that crawlers still receive complete HTML from a file. There is no rendering queue and no script that has to succeed, so titles, canonical tags, body copy and internal links are all present on the first request, and the page tends to be quick to arrive because it is served from cache.
Where incremental static regeneration goes wrong
Someone always gets the old copy, and it might be Googlebot. On a page that gets few visits, the stored HTML can sit unrefreshed for a long stretch, because regeneration is triggered by a request. A crawler arriving during that quiet period sees whatever was true when the page was last built, which is how outdated prices, retired offers and old titles end up in the index.
Deletions are the sharper edge. If an item is removed from the CMS but its stored page is never invalidated, the URL can keep answering with a normal page and a success status instead of the gone-or-redirected response it should give. Stacked caches make all of this harder to reason about: a CDN in front of the regeneration layer means the window you configured is not the one visitors actually experience, and two people testing the same URL can honestly report different results.
What to do about it
Set each window by how quickly that content genuinely goes stale, not by one site-wide habit. Editorial pages suit a long window with an on-demand rebuild fired from the CMS, so publishing feels instant. Pages carrying prices or stock deserve a short window, or should be left to server-side rendering instead.
Handle removals explicitly rather than hoping the window closes in time — a deleted item needs its stored page invalidated and its URL answering with a proper redirect or gone status. Keep one caching layer authoritative and document what the others do. Then verify rather than assume: the URL Inspection tool in Search Console shows the HTML Google is actually holding, and comparing that against the live page is the only reliable way to catch a page that quietly stopped refreshing.