Setup guide

Before changing DNS, adding middleware, or installing a plugin, check the HTML that a crawler-style request receives. A page that already returns meaningful HTML does not need a rendering proxy. A page that returns only an application shell may need one.

Use a public crawler check to compare the initial HTML with the browser-rendered page. Record the hostname, status code, canonical URL, headings, and the first meaningful text before making changes.

No-code DNS setup is appropriate when a hosted builder or static host cannot run server-side middleware. The public hostname is routed through a managed delivery layer while the existing host remains the origin.

Developer integration is appropriate when the application can run middleware, an Edge Function, a Worker, or server-side routing. It should route only eligible crawler requests and keep API credentials in server-side environment variables.

Only public, cacheable pages belong in a crawler-rendering path. Exclude account pages, dashboards, checkout, API endpoints, previews, password-protected content, and any route whose output depends on a session or cookie.

Never place an API key in browser JavaScript. Do not use a broad crawler user-agent match to expose content that ordinary visitors cannot access.

Test the exact production hostname with a normal request and a crawler-style request. Confirm that the crawler response has the expected status, canonical URL, important text, and render headers. Test both the apex and www hostname if both resolve.

A successful DNS record alone does not prove that crawler requests reach the rendering path. The response is the proof.