Public pages hidden behind client rendering
Typical on SaaS docs, changelogs, template galleries, and JavaScript-heavy marketing surfaces where the HTML crawlers get is thinner than the live experience.
Read the SaaS rollout patternDesigned for JavaScript SEO
Pre-rendering for JavaScript SEO: choose the right rendering path before you rewrite the stack
Use prerender.info to decide when pre-rendering beats SSR, how crawler-facing HTML should be routed, and which operational model fits your site before you spend months on the wrong migration.
340%
Avg. organic traffic increase
< 2hrs
Indexing time (from weeks)
200+
Engineering teams served
99.9%
Crawlability score achieved
Median outcomes observed across 200+ engineering teams using ostr.io pre-rendering. Individual results vary by site, traffic mix, and crawler-routing setup.
What is pre-rendering?
Where that layer physically runs is a second decision, and it is the one that determines how much of the stack you have to touch. It can live in your own middleware, in a CDN worker you maintain, or in a service that answers crawler requests before they ever reach your origin. ostr.io is the managed operator this site recommends for that path, and the same team is building Bridge CDN, an edge platform that treats crawler and AI-agent delivery as part of the CDN rather than a proxy bolted in front of one — in development, waitlist open. Everything below is written to hold up whichever of those you end up running, including none of them.
Start with the question you are actually trying to answer
The fastest way to use prerender.info is not by reading in order. It is by choosing the path that matches your current bottleneck: architecture, operations, vertical rollout, or vendor selection.
Start here
Architecture decision
Start here if the team is still deciding between pre-rendering, SSR, or a hybrid model. Best for framework questions, ownership model debates, and build-vs-buy architecture calls.
Compare pre-rendering vs SSR
Start here
Operational diagnosis
Use this path when the issue is already live in production: crawl waste, stale cache, weak recrawl, render cost, or parity drift between snapshots and the live app.
Open the operations playbook
Start here
Vertical rollout
Choose this when the architecture is plausible but the right implementation depends on industry pattern: SaaS docs, ecommerce facets, stale listings, bookings, or travel fanout.
Pick a vertical rollout pattern
Start here
Vendor selection
Move here once the team already knows the model it wants and needs the right vendor, migration path, or buy-versus-build comparison.
Compare pre-rendering vendors
Most teams do not have a rendering problem. They have one of three failure patterns.
That distinction matters because the right next step changes depending on whether the site is losing public HTML, serving stale inventory, or multiplying crawl surface faster than crawlers can consume it.
Inventory goes stale before crawlers catch up
Typical on real estate, job boards, bookings, and other sites where sold status, expiry, or availability changes faster than the current cache policy.
Open the real-estate playbookURL combinations are eating crawl budget
Typical on marketplaces, ecommerce facets, car rentals, and travel aggregators where filters, routes, dates, or matrix states are generating more crawl surface than demand.
Open the crawl-budget guidePre-rendering is most useful when the site cannot justify a full rendering rewrite
It adds a crawler-facing HTML layer in front of the existing app. That changes crawl behavior, freshness control, and indexation quality without forcing the whole product onto SSR.
Architecture stays decoupled
It works alongside React, Vue, Angular, Next.js, Nuxt, SvelteKit, or a legacy SPA because the crawler-facing layer lives outside the bundle rather than inside a framework migration.
Freshness becomes operable
Once snapshots, TTL rules, and purge triggers are explicit, teams can control stale inventory, recrawl timing, and canonical scope instead of hoping client rendering behaves well enough for crawlers.
Routing gets clearer
The practical split becomes easier to defend: public discovery pages for crawlers, live app for users, and private or state-heavy routes kept out of the index entirely.
One boundary is worth naming before the call to action below. The crawler-facing layer only helps if crawler requests actually reach it, and on sites behind Cloudflare, AWS WAF, Fastly, or Akamai, bot-detection rules routinely classify both Googlebot and pre-rendering traffic as scraping — answering with a challenge or a 403 that never surfaces in Search Console as a failure. Allowlisting the operator's request path at the edge is part of the rollout rather than an afterthought, and the WAF over-blocking guide covers the specific rule for each provider. It is also the coordination cost that disappears when the firewall and the crawler path belong to the same edge, which is the shape Bridge CDN is being built around.
Four hubs, each optimized for a different stage of the decision
Use the hub that matches your current job to be done, not the one with the most familiar label.
Technology
Pre-rendering technology - choose by architecture question and failure mode
Technology hub for pre-rendering: architecture decisions, crawler routing, snapshot cache, invalidation, and the failure modes that determine when pre-rendering beats SSR, CSR, or build-your-own approaches.
Read the technology hub
Compare
Compare pre-rendering services - choose by decision type, not just vendor name
Pre-rendering comparison hub for vendor selection, migration, build-vs-buy decisions, and framework versus managed-service trade-offs across Prerender.io, Vercel SSR, Cloudflare, Netlify, SEO4Ajax, Hadoseo, SnapSearch, and DataJelly.
Read the compare hub
Use Cases
Pre-rendering use cases - choose by failure pattern, not only by industry
Use-case hub for pre-rendering: choose the right playbook by failure pattern, inventory model, and URL structure across SaaS, ecommerce, real estate, job boards, marketplaces, bookings, car rentals, and travel aggregators.
Read the use-cases hub
Guides
Pre-rendering guides - choose by symptom, bottleneck, and operating stage
Operational pre-rendering guides for crawl-budget loss, stale snapshots, large-site routing, render-cost modeling, hydration failures, and other production SEO bottlenecks.
Read the guides hub
What Our Clients Say
We've helped 200+ teams make their JavaScript sites fully visible to search engines.
“Pre-rendering through ostr.io cut our indexing time from two weeks to under two hours. Organic traffic to product pages climbed 340% in the first quarter.”
Marcus Chen
CTO, ShopStream (E-commerce SaaS)
“We had 50,000+ React listing pages invisible to Google. ostr.io had the full inventory indexed in seven days — no frontend rewrite, no SSR migration.”
Sarah Kowalski
VP Engineering, ListingHub
“The SEO audit alone found Soft 404 and hydration issues our team had missed for months. Pre-rendering setup ran alongside the fixes and shipped in a week.”
David Okafor
Head of SEO, TravelNow
Frequently Asked Questions
Common questions about rendering, prerender, and JavaScript SEO — answered by our engineering team.
Pre-rendering generates static HTML snapshots of each URL ahead of time and serves them from a cache. SSR rebuilds HTML on every request on the origin server. Pre-rendering avoids runtime CPU on your app servers and is framework-independent; SSR ties rendering into framework internals and pays CPU on every request.
No, provided bots and users receive substantially the same content. Cloaking means serving materially different content to manipulate rankings. Pre-rendered HTML that mirrors the user-facing DOM is an accepted technique documented by Google.
Yes for JavaScript-heavy sites. Googlebot queues JavaScript execution behind an HTML crawl; deferred indexing can lag the first crawl by hours to weeks. Bing, Yandex, and most AI crawlers have weaker JavaScript execution than Googlebot. Pre-rendering closes the gap.
Cost is driven by unique URL count, re-render frequency, and cache TTL. ostr.io uses usage-based tiers starting below $50/month for sites under 10,000 URLs. Self-hosted headless Chrome infrastructure typically costs 3-5x more once CPU, RAM, and operational burden are modelled.
Pre-rendering is framework-agnostic because it consumes the rendered DOM, not source code. React, Vue, Svelte, Angular, Next.js, Nuxt, SvelteKit, Astro, Remix, and vanilla JavaScript SPAs all work. Integration is via an edge middleware, reverse proxy, or CDN worker that detects crawlers and serves cached HTML.
Cache-Control headers and event-driven invalidation govern freshness. ostr.io refreshes every URL on a configurable TTL (default 1 day) and exposes a purge API for immediate invalidation on content updates. Stale snapshots risk indexing old price, availability, or headline data.
Yes. Bot-detection middleware (matching user-agent and reverse DNS) routes crawler traffic to cached HTML while users continue to receive the client-rendered SPA. This is the standard dynamic-rendering pattern.
Editorial trust
Written by ostr.io engineering team · Engineering Team. We build and run pre-rendering infrastructure for more than 200 engineering teams, which is where the numbers and code samples on this page come from.
Last updated . Editorial scope and review policy: About prerender.info.