Nginx reverse proxy setup

Use this path when Nginx already receives requests for the public website and you can edit and reload its configuration.

Recommended workflow

1. Add the site in Prerender Buddy.
2. Choose the developer or middleware setup path.
3. Generate the Nginx integration for the exact hostname.
4. Store the Prerender Buddy API key in a server-readable configuration or secret with restricted permissions.
5. Add the generated routing inside the correct HTTPS server block.
6. Validate Nginx before reloading it.

1sudo nginx -t
2sudo systemctl reload nginx

Use the dashboard-generated configuration as the source of truth. It contains the current crawler matching and render endpoint details.

Routing rules that must remain narrow

Rendered routing should apply only to public crawler GET requests. Skip:

• JavaScript, CSS, images, fonts, source maps, and other static assets
• API and webhook routes
• POST, PUT, PATCH, and DELETE requests
• admin, account, checkout, and authenticated pages
• health checks and internal service endpoints

Normal visitors must continue to reach the existing upstream application.

Security

• Never expose the render API key in client code or response headers.
• Restrict access to any Nginx file containing the key.
• Rotate the key if it appears in logs, shell history, or a repository.
• Pass the original public URL to the render endpoint, not an internal admin or private URL.

Test after reload

1curl -I https://www.example.com/
2curl -I -A "Googlebot" https://www.example.com/
3curl -s -A "Googlebot" https://www.example.com/ | head

The visitor request should still use the normal app path. The crawler request should return readable HTML and appear in Prerender Buddy render logs.

If Nginx fails validation, restore the last working server block and compare it with the generated snippet before retrying.