Back to blog

Prerendering cache freshness: when rendered pages update

A practical guide to Prerender Buddy cache freshness, invalidation, cache hits, fresh renders, stale responses, and render usage.

Operations
Jun 30, 2026
4 min read

Prerendering caches rendered HTML so every crawler request does not need to start a browser and rebuild the page.

That improves response time and controls rendering usage, but it also creates an operational question: when does a crawler receive the new version after the website changes?

Quick answer

If the server already sends complete HTML, you probably do not need Prerender Buddy. If visitors see a complete JavaScript page but bots receive thin HTML or an empty app shell, Prerender Buddy can help by serving rendered HTML to search engines and AI crawlers.

Cache states in Prerender Buddy

StateMeaningTypical action
HITA recent rendered version was served from cacheUsually no action required
MISSNo usable cached version existed, so a fresh render was requestedConfirm the result is correct; this counts as a fresh render
STALEAn older cached version was used as a fallbackCheck origin and renderer health if this persists
QUOTA_EXCEEDEDFresh rendering capacity was unavailable for the current planReview usage, route scope, and plan capacity

Cached crawler hits do not consume fresh-render allowance. Cache misses and forced refreshes do.

When to refresh a page

An explicit refresh is most useful after changing information that crawlers should receive promptly:

  • pricing, availability, or product descriptions
  • page title, description, canonical, or robots directive
  • public headings and body copy
  • JSON-LD or other structured data
  • internal links and navigation
  • a route that changed from available to missing, or the reverse
  • a hostname, redirect, or origin configuration

Do not clear the entire site cache for a one-page correction when an exact URL refresh is available.

Why a published change may not appear immediately

Several layers can retain old output:

  1. The builder or hosting platform has not deployed the latest version.
  2. The origin CDN still serves an older asset or HTML document.
  3. Prerender Buddy has a valid cached render.
  4. The external crawler or social platform has its own cache.

Before clearing repeatedly, open the origin URL directly and confirm the new content is actually live there.

A safe refresh sequence

  1. Publish the change at the origin.
  2. Open the separate origin URL and confirm the new page is visible.
  3. Refresh or clear the exact public URL in Prerender Buddy.
  4. Send a crawler-style request to the canonical hostname.
  5. Inspect x-prerender-cache, x-prerender-cache-ttl, and x-prerender-time.
  6. Confirm the new response appears in render logs.

Avoid unnecessary render growth

Fresh-render usage can grow unexpectedly when integrations include:

  • tracking-query variations
  • assets and API routes
  • internal search and filter combinations
  • nonexistent URLs and soft 404s
  • preview, admin, or authentication routes
  • very short refresh intervals for pages that rarely change

Use the narrow route guidance in Public vs private routes and review render usage limits before increasing refresh frequency.

Cache freshness is not the same as search-engine recrawling. Refreshing Prerender Buddy updates what a future supported crawler request can receive; it does not force an external crawler to revisit the URL immediately.

Who this is for

  • SaaS founders with already-shipped JavaScript websites
  • React, Vite, Vue, Lovable, Bolt, or Base44 users
  • SEO freelancers checking crawler-readable HTML
  • Agencies maintaining client sites without rebuilding them

You may not need Prerender Buddy if

  • Server HTML is already complete.
  • Static pages crawl correctly.
  • You are already rebuilding with SSR or static generation.
  • You only need an audit, not a rendering fix.

Final recap

Prerendering cache freshness comes down to what search engines and AI crawlers actually receive from your site.

Prerender Buddy does not guarantee rankings or AI citations. It helps with one specific technical problem: making sure crawlers receive readable rendered HTML instead of a thin JavaScript shell.

The first step is to check what bots see.

Check your website

Check what crawlers see to test whether the site sends readable HTML to search engines and AI crawlers.