What is partial prerendering, exactly?

It's an experimental Next.js App Router feature (gated behind the experimental.ppr flag through Next.js 14 and 15) that lets you mix a static prerendered shell with dynamic regions streamed at request time in the same route. The static parts are served instantly from a CDN; the dynamic parts arrive over HTTP streaming. The pitch is fast LCP without giving up per-request data.

Does it solve the SEO problem on Next.js sites?

Partially. The static shell is in the initial HTML, which is fine for crawlers that read only that. The dynamic regions stream in afterwards, which most non-Google crawlers won't wait for. So if your H1, your meta description, your structured data, or your primary content lives in a dynamic region, partial prerendering doesn't fix bot visibility - it just makes the static parts faster.

Why might I want to skip implementing it?

Three reasons typically. One: you're not on Next.js App Router, and migrating is a multi-month project. Two: you are on App Router but you don't want to mark up every Suspense boundary correctly across hundreds of components. Three: your problem is bot visibility, not LCP - in which case PageGlass solves it directly without touching your code.

Does PageGlass do something similar?

PageGlass takes a different shape. We detect bot user-agents at the edge, run your full app in a headless browser, and serve the resolved HTML to crawlers. Human visitors get the original dynamic experience unchanged. So the bot sees a fully-rendered page (better than partial prerendering's streamed result for non-streaming crawlers), and the user sees what you built.

What about LCP for human visitors? Does PageGlass help with that?

PageGlass is built around bot visibility, not human-side LCP. If your goal is faster perceived load times for users, partial prerendering, ISR, or SSR with streaming are the right tools. If your goal is bot indexing, AI crawler visibility, and social previews working reliably, PageGlass is faster to roll out and works on whatever framework you have.

Can I use both - partial prerendering for users and PageGlass for bots?

Yes, and several teams do exactly this. PageGlass operates at the edge with a CNAME, so it's transparent to your application. You can keep optimising your user-side rendering strategy (PPR, streaming, ISR, whatever Next.js ships next) while PageGlass handles the bot-side concern. The two don't conflict.

Partial prerendering: when you'd rather not implement it yourself

Partial prerendering combines a static shell with dynamic content streamed at request time. It's a clean primitive, it lives behind an experimental flag in Next.js, and rolling it out across an existing app is a real engineering project.

This is a known problem, and the fix is simpler than you think.

100+ bots supportedPre-rendered by PageGlassFive-minute setupBuilt on Cloudflare's edge

Curious how a Next.js or SPA URL appears to bots today? Paste any public URL - yours, a competitor's, or any site at all - to see the static shell vs the hydrated DOM.

Don't want an external tool? We understand.

Partial prerendering done well is a clean primitive. It also means migrating to App Router, marking every dynamic boundary correctly, debugging streaming behaviour in production, and accepting that your rendering strategy is now coupled to one framework's decisions. PageGlass takes a different angle - render the whole page for bots from the outside, leave your application code alone.

Fix this in three steps

Run a free JavaScript scan. Confirm the bot visibility gap caused by the dynamic parts of your route that bypass the static shell - the scan takes ten seconds and needs no signup. You get exactly what Googlebot, Bingbot, and the AI crawlers see when they hit your URLs today, side by side with what your users see.
Add one CNAME record. Point your JavaScript site's domain through PageGlass in your DNS provider. The change takes thirty seconds and is fully reversible. Zero code changes, no deploy, no impact on the bundle your real users download.
JavaScript content is now indexable. Bot traffic now receives fully-rendered HTML for every URL on your JavaScript site, while human visitors keep getting the exact same dynamic experience as before. Come back to PageGlass and run the scan again to confirm the fix.

What partial prerendering is for

Partial prerendering targets a specific problem: pages that have stable shell content (navigation, layout, hero copy) and dynamic regions (recommended products, signed-in user state, real-time prices). Before PPR, the answer was either Static Site Generation (which serves stale data) or Server-Side Rendering (which makes every request hit the server). PPR streams the static shell from a CDN and the dynamic regions over HTTP, giving you the best of both for human users.

This is a genuinely good primitive when your bottleneck is LCP and user-perceived speed. The catch is that it's tightly coupled to Next.js App Router and requires explicit Suspense boundaries around every dynamic region. Mistakes are subtle - put a boundary in the wrong place and a region that should be dynamic gets baked into the static shell, or vice versa.

Where it doesn't help with SEO

Non-streaming crawlers. Bingbot, GPTBot, ClaudeBot, PerplexityBot, and most social card fetchers read the initial HTML response and stop. Whatever's in the static shell, they see; whatever streams afterwards, they don't.
Dynamic-region content that matters for ranking. If your H1, structured data, or primary product description lives in a dynamic region, PPR makes the user-side faster but leaves the bot-side unchanged.
Personalised meta tags. Per-user titles or descriptions that depend on auth or session can't go in the static shell, so they only resolve in the dynamic stream that crawlers don't read.

The simpler path when SEO is the real goal

If the actual problem you're trying to solve is "bots and AI crawlers don't see my content," PageGlass is a five-minute alternative to a multi-month framework migration. We render every URL for bots in a headless browser - dynamic regions included - and serve the resolved HTML at the edge. Human visitors keep the dynamic experience exactly as built. Stack it with partial prerendering if you want, or skip the PPR work entirely if SEO is the only outcome you needed.