How It Works

Why pre-rendering exists for modern SPAs

Single-page apps are great for users, but crawlers often get only a shell before JavaScript runs. Pre-rendering solves that by serving crawler-readable HTML while preserving the normal browser SPA path.

Without pre-rendering

Crawlers can miss the final content rendered in the browser.

JavaScript SPA ships a minimal initial HTML shell.

Some crawler contexts do not execute full app rendering.

Result: weaker indexability and incomplete page understanding.

With pre-rendering

Crawlers receive rendered HTML, users keep the SPA experience.

Edge proxy classifies incoming requests.

Crawler/programmatic requests get rendered HTML output.

Browser navigation continues to your existing origin SPA.

DNS proxy or API: two integration paths

Both paths use the same rendering engine. The difference is how you trigger and control it.

DNS proxy

Best when you want site-wide behavior with minimal setup.

No-code setup for most teams.

Applies automatically across your site.

Good default if you do not need custom render orchestration.

API mode

Best when engineering teams need explicit control.

Programmatic render requests in your own workflows.

Integrates with jobs, queues, and custom release pipelines.

Useful when you want deterministic triggering and automation.

HOW THE RENDERING PROXY WORKS

The proxy makes one routing decision per request. Crawler or programmatic requests get rendered HTML. Human browser requests go straight to your origin SPA.

  1. 1

    Incoming request

    A request reaches the edge proxy for classification.

  2. 2

    Classify request intent

    The proxy determines whether it is crawler/programmatic or browser navigation.

  3. 3

    Return the right response

    Crawler/programmatic requests get rendered HTML, browsers continue to your origin SPA.

INCOMING REQUEST
LovableHTML
EDGE PROXYClassifies request type
Web crawler
Crawler / ProgrammaticOutcome: Rendered HTML
GooglebotGooglebotChatGPTChatGPTBingbotBingbotPerplexityPerplexityClaudeClaude
Browser NavigationProxy to Origin SPA
ChromeSafariFirefoxEdge
CloudflarePowered by Cloudflare Workers — 300+ edge locations worldwide

How DNS proxy works (light version)

DNS mode is designed to be straightforward: route traffic to the proxy, classify requests at the edge, and return crawler vs browser responses through the right path.

1

Point DNS records

Update your domain records so traffic reaches the proxy entrypoint.

2

Proxy classifies request

At the edge, each request is classified to decide crawler/programmatic vs browser navigation handling.

3

Serve correct response

Crawler/programmatic requests get rendered HTML. Human browser traffic continues to your origin SPA.

How API mode works (light version)

API mode gives you explicit control: request rendered output when your system decides, then plug the response into your own pipeline.

1

Call render endpoint

Send a request to the render API with the target URL and your API key.

2

Render and cache

The service renders when needed and reuses cached snapshots where available.

3

Consume HTML output

Your workflow receives rendered HTML for crawler-facing use cases, with optional cache management endpoints.

How to choose

Choose DNS proxy if...

You want the fastest path to site-wide crawler coverage.

Your team prefers no-code or low-ops integration.

You do not need custom orchestration from your backend.

Choose API mode if...

You need render control inside custom systems.

You want automation hooks around release or content events.

Your team is already operating programmatic workflows.

Common questions

Ready to pick a path?

Start with DNS proxy for the quickest rollout, or use API mode if you need tighter engineering control.