Back to blog

Public vs private routes: what should a prerendering integration include?

A route-selection and security checklist for deciding which JavaScript pages should receive crawler-rendered HTML.

Jul 10, 2026
4 min read

A prerendering integration should not send every request through a browser renderer.

The safe default is narrow: public, indexable page routes requested with GET or HEAD by supported crawlers.

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.

Routes that commonly belong in the render path

  • homepage and public marketing pages
  • pricing and feature pages
  • public documentation and FAQ pages
  • public articles, guides, categories, and listings
  • public product, location, or directory detail pages
  • other canonical pages intended for crawler discovery

Routes that should normally be excluded

  • login, signup callbacks, password reset, and account recovery
  • dashboards, profiles, settings, and admin pages
  • checkout, cart, billing portals, and payment callbacks
  • APIs, GraphQL endpoints, RPC routes, and webhooks
  • health checks and internal service endpoints
  • JavaScript, CSS, fonts, images, source maps, and other assets
  • preview routes containing unpublished content
  • pages whose output depends on cookies, sessions, roles, or private user data
  • non-idempotent methods such as POST, PUT, PATCH, and DELETE

Why broad routing is risky

Broad crawler routing can:

  • expose content that should require authentication
  • trigger actions or expensive API behavior
  • consume rendering capacity on assets and irrelevant URLs
  • cache one user's personalized response for another request
  • create duplicate renders from query parameters
  • turn private error states into public crawler HTML

Robots.txt is not an access-control system. Private routes still need server-side authentication and authorization.

Query parameters need a policy

Decide which parameters change the canonical public page.

Tracking parameters such as utm_source usually should not create separate cached pages. Search, filtering, locale, pagination, or product-variant parameters may need route-specific handling.

Do not drop parameters blindly. Normalize only parameters that do not change meaningful public content, and keep canonical tags consistent with the chosen policy.

Route review checklist

For every included route pattern, ask:

  1. Is this content public without a session?
  2. Is the page intended for discovery?
  3. Is a safe crawler request read-only?
  4. Can the response be shared across visitors without exposing private state?
  5. Does the route have a stable canonical URL?
  6. Does the origin return the correct status when the item is missing?

Start with a small allowlist of public route families. Expand after verification rather than rendering the entire application by default.

For implementation, use the setup integration guidelines, API key safety guidance, and self-hosted setup.

Prerendering should make existing public content readable. It should never be used to bypass authentication or expose private application state.

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

Public vs private routes 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.