The Hidden Costs of Prerendering (That Teams Ignore)
The site didn't go down. It just stopped working. Traffic dropped ~40% over two weeks. No deploys. No outages. Status pages green. The issue was prerendering — Google indexing stale HTML snapshots that no longer matched the live app. We see this constantly.
On This Page
What's Actually Happening
Prerendering creates cached HTML snapshots and serves them to bots. The moment you turn it on, you have two systems:
- 1Live app — JS-driven, always current
- 2Snapshot cache — static HTML, updated on triggers you don't fully control
These two systems drift. Always. The only question is how fast and how much.
Real example we saw last month:
- • Pricing page still showed $19/month after it changed to $29
- • New blog posts existed in the UI but never appeared in HTML
- • Product pages lost reviews and FAQs in the snapshot
The app worked. The HTML bots saw did not.
Stale Content (The Observable Failure)
Snapshots are routinely small and incomplete. Here's an actual diff from a real site:
Browser-rendered DOM: ~1,200 words ~35KB HTML (after JS)
Prerender HTML: <150 words 4-6KB HTML
Missing in snapshot:
- Product descriptions
- Reviews
- Internal links to related pages
- JSON-LD structured dataBots index the smaller version. Your "real" page never makes it into the index. This is how a site that looks healthy ends up ranking for nothing.
Cache Invalidation Failures
Invalidation is where prerendering actually breaks. It depends on events you don't fully control.
This breaks in production when:
API data changes
no rebuild is triggered → snapshot stays stale
CMS updates
don't map to all affected routes → some pages refresh, others don't
Incremental builds
skip dependent pages → updates partially propagate
/pricing → updates correctly
/pricing/enterprise → does NOT update (different route, missed trigger)
/blog/page/2 → never updates (paginated routes ignored)No errors. No alerts. Just inconsistent HTML across your site. We dig into this exact pattern in Why Script-Based Prerendering Breaks on Real Apps.
Personalization Mismatch
Snapshots are static. Your app isn't. The mismatch shows up immediately:
- Logged-out version is cached. Logged-in UI is never visible to bots.
- Geo content defaults to one region. Other regions silently disappear from the index.
- A/B test variants never make it into snapshots, or worse, only one variant does.
Homepage snapshot (cached):
Generic marketing copy, ~300 words, "Sign up free"
Real users see:
Account dashboard, recent activity, billing status
Bots index a page your users never see.Snapshot Drift (Time-Based Failure)
Prerendering degrades over time. We see this constantly:
Real production audit:
Total routes: 1,200
Valid snapshots: 700
Fallback shell HTML: 500 (3-5KB, effectively empty)
→ ~42% of the site is invisible to botsNo one noticed for months. Status checks all green. Traffic just kept dropping.
What Most Guides Get Wrong
Most prerendering guides optimize for setup, not reality. Typical advice:
"Enable incremental static regeneration"
ISR only fires when traffic hits a stale page. Low-traffic routes stay stale forever.
"Cache aggressively"
Aggressive caching is the problem. The snapshot was already wrong — caching it longer makes it worse.
"Use a sitemap"
Sitemaps tell bots which URLs exist. They don't verify the HTML at those URLs is complete.
What's missing from every guide:
- No verification that snapshot HTML is complete
- No monitoring of snapshot freshness over time
- No detection of route coverage gaps
They assume content changes are predictable, routes are static, and one invalidation trigger is enough. None of that holds for SPAs with API-driven data.
What We See in Production
Four patterns. We see them constantly. Probably yours too.
Partial indexing
Symptom: Some blog posts indexed, others not. Indexed pages missing key sections.
Root cause: Prerender queue incomplete. Pagination routes never rendered. New posts wait days for inclusion.
Thin HTML
Symptom: Page renders fine in a browser. Raw HTML is <5KB, <100 words.
Root cause: Snapshot generation failed silently and fell back to the shell. Same problem we cover in Your HTML Is Only 4KB.
Stale pricing
Symptom: SERP shows outdated pricing for weeks after a change. Conversion drops because users see one price in search and another on the page.
Root cause: No invalidation trigger tied to your pricing system. The snapshot was generated once and never refreshed.
Broken internal linking
Symptom: Crawlers don't discover deep pages. Crawl depth limited to 1–2 levels.
Root cause: Snapshot is missing dynamic links rendered via JS. Bots can't follow what isn't in the HTML.
Quick Test: Is Your Prerender Drifting?
Stop guessing. Fetch your page as a bot and look at what comes back. If your snapshot is broken, this will show it in 30 seconds.
Quick Test: What Do Bots Actually See?
Most people guess. Don't.
Run this test and look at the actual response your site returns to bots.
Fetch your page as Googlebot
Use your terminal:
curl -A "Googlebot" https://yourdomain.comLook for:
- Real visible text (not just
<div id="root">) - Meaningful content in the HTML
- Page size (should not be tiny)
Compare bot vs browser
Now test what a real browser gets:
curl -A "Mozilla/5.0" https://yourdomain.comIf these responses are different, Google is indexing a different page than your users see.
Stop guessing — measure it.
Real example: 253 words vs 13,547
We see this constantly. Here's a real example from production: Googlebot saw 253 words and 2 KB of HTML. A browser saw 13,547 words and 77.5 KB. Same URL — completely different content.
If your HTML doesn't contain the content, Google doesn't either.
Compare Googlebot vs browser on your site → HTTP Debug ToolCheck for common failure signals
We see this all the time in production:
- HTML under ~1KB → usually empty shell
- Visible text under ~200 characters → thin or missing content
- Missing <title> or <h1> → weak or broken page
- Large difference between bot vs browser HTML → rendering issue
Use the DataJelly Visibility Test (Recommended)
You can run this without touching curl. It shows you:
- Raw HTML returned to bots (Googlebot, Bing, GPTBot, etc.)
- Fully rendered browser version
- Side-by-side differences in word count, HTML size, links, and content
What this test tells you (no guessing)
After running this, you'll know:
- Whether your HTML is actually indexable
- Whether bots are seeing partial content
- Whether rendering is breaking in production
This is the difference between "I think SEO is set up" and "I know what Google is indexing."
If you don't understand why this happens, read: Why Google Can't See Your SPA
If this test fails
You have three real options:
SSR
Works if you can keep it stable in production
Prerendering
Breaks with dynamic content and scale
Edge Rendering
Reflects real production output without app changes
If you do nothing, you will not rank consistently. Learn how Edge Rendering works →
This issue doesn't show up in Lighthouse. It shows up in rankings.
Solutions Compared: Prerender vs SSR vs Edge
Three real approaches. Each has tradeoffs.
| Approach | Works when | Breaks when |
|---|---|---|
| Prerendering | Content rarely changes, routes known upfront, <100 pages | Data is dynamic, route count grows, invalidation isn't perfect |
| SSR | You can absorb the latency cost and run rendering infra | Higher TTFB, infra complexity, hot path scales with traffic |
| Edge (DataJelly) | You want bots to see live HTML without changing your app | No long-lived snapshot cache → no drift, no stale pricing |
For deeper context, see Prerender vs SSR vs Edge Rendering and the Prerender Alternatives guide.
How Edge avoids the drift problem
- • Generates or validates HTML at request time for bots — no long-lived cache
- • HTML stays aligned with live data (no stale pricing, no missing routes)
- • AI crawlers get clean Markdown — no JS execution required
- • Works with React, Vite, and Lovable SPAs without rewriting your app
Practical Checklist (Run These Today)
If you have prerendering in production, run all six. If even one fails, your snapshots are drifting.
Measure HTML size
<5KB → broken. 5–15KB → likely incomplete. 20KB+ → usually healthy.
Count words in raw HTML
<200 words = thin. Compare against the rendered page.
Compare live page vs raw HTML
Look for missing sections, links, or structured data.
Test freshness
Change content → check HTML. Delayed or missing update = broken invalidation.
Audit route coverage
Sample 50+ routes. Missing HTML = invisible page. We routinely find 30–40% gaps.
Track drift weekly
Snapshot HTML today. Snapshot again in 7 days. Differences without code changes = system failure.
Want this automated? The Page Validator and HTTP Bot Comparison tool do most of these checks for you.
Prerendering is not a performance optimization. It's a second system with its own bugs.
It fails silently. No crashes. No alerts. Just worse HTML over time. Healthy app. Broken HTML. Falling traffic. If you're not actively monitoring HTML size, content completeness, route coverage, and freshness — you're not actually monitoring your prerendering.
What DataJelly Does About This
DataJelly Edge removes the long-lived snapshot problem. Instead of caching HTML for days, the edge proxy generates or validates HTML when bots request it — ensuring full content (not 4KB shells) and keeping HTML aligned with live data. AI crawlers get clean Markdown.
Works with React, Vite, and Lovable SPAs. No app rewrite required. The goal is simple: bots see the same complete, current page your users see.