Connect a self-hosted website to Prerender Buddy

This guide connects a website you operate to Prerender Buddy's managed rendering service. It does not install the PB rendering engine in your infrastructure.

If you want to run the open-source renderer itself, use Self-host Prerender Buddy Engine. That deployment has separate operator responsibilities and does not include the hosted AI Visibility, article publishing or account platform.

Compare an important public page's returned HTML with the completed browser page. Complete server HTML may already be sufficient. A self-hosted website does not automatically need a rendering proxy.

When a delivery gap is established, choose from the request layers and origin options you actually control. Use the setup guide for the shared workflow.

Managed routing requires a separate public HTTPS origin that keeps serving the production website after the public hostname is connected. Check its important routes, assets and redirects without a login or browser-only challenge. A temporary preview or raw server IP is not automatically a working HTTPS origin.

Configure the origin in your authenticated PB setup, then copy the exact records shown for the connected hostname. Keep the existing canonical host. Redirect its alternate root or www hostname with the full path and query preserved.

Preserve unrelated DNS and mail records. Complete the required ownership/certificate validation and inspect the final public response. See origin requirements and root/www configuration.

Use the applicable developer integration when the application server or reverse proxy can handle requests before HTML is returned. DNS can remain on the existing path.

Render only eligible public GET page requests. Keep API routes, webhooks, static assets, authenticated pages, checkout, previews and personalized content outside this path. Keep credentials server-side and retain the normal visitor response.

Use the current account-generated instructions for the selected site. The Nginx guide covers configuration testing and GET-response verification when Nginx is your request layer.

The existing server-side rendering contract uses the website's public URL and protected rendering credentials:

GET https://api.prerenderbuddy.com/render?url=https://example.com/page
X-Prerender-Token: <SERVER_SIDE_KEY>
X-Prerender-User-Agent: <ORIGINAL_CRAWLER_USER_AGENT>

These are placeholders. Keep the actual key out of browser JavaScript, public examples and logs. Use the setup-specific contract and URL encoding from your account instructions.

The versioned Developer API uses bearer authorization and operation-specific scopes. Its evidence, article review, delivery and schedule actions are separate from this rendering snippet.

Test normal and crawler-style GET responses on the intended public URL. Check the final hostname, response status, content, links, canonical and available delivery evidence. A setup label alone does not establish that a crawler received the expected page.

If no stable managed origin or supported server-side request layer is available, resolve the hosting requirement before changing routing. Do not make a private page public merely to pass a rendering check.

Use troubleshooting for disagreements and Health and Monitoring for important URLs. These diagnostic profiles do not prove bot identity or indexing. Follow How PB Works for the broader AI Visibility, full article and reviewed publishing workflow.