Nginx reverse proxy setup

Use this guide when Nginx receives the public website's requests and you can edit its active configuration. First compare the returned HTML with the completed browser page. If the public response already contains the important content, a rendering integration may not be needed.

This is a website-delivery integration, not running PB's rendering engine yourself. Read the self-hosted website guide for connection choices, or operate PB Engine for the separate engine deployment.

Add or select the website in PB, choose the developer integration and its Nginx option. Use the generated instructions for that exact site and request layer, rather than a generic crawler regular expression copied from another website.

Keep the existing canonical hostname and upstream behavior. Setup explains the general connection; root and www explains alternate-host redirects.

Save a rollback copy of the active configuration. Store any rendering key in restricted server-side configuration or secrets. Never put it in browser code, public repositories, response headers or shared debug output.

Render only eligible GET requests for public, cacheable pages. Exclude APIs, webhooks, static assets, authentication, admin/account routes, checkout, previews, health checks and personalized or session-dependent content.

A crawler user-agent is a routing signal, not authorization to access private content. Ordinary visitors must continue to receive the intended upstream website.

Pass the original public URL through the setup-specific render contract. Do not replace it with an internal admin or private-service address. A website render connection is separate from the scoped Developer API and its article/publishing actions.

Nginx's command-line reference documents configuration testing and reload signals.

For a typical operator-managed installation, test the relevant configuration:

sudo nginx -t

Use the configuration path/container and permissions appropriate to the actual deployment. If testing fails, correct the configuration before reloading.

After a successful test, reload using the deployment's normal control method. For an applicable running Nginx installation, nginx -s reload is a supported signal; a service manager or container deployment may use a different control path. Check the service's result and logs without sharing secrets.

A HEAD request is not a substitute for testing a GET-only rendering path. The following diagnostic examples save both headers and bodies; replace the URL with an intended public page:

curl -sS -L -D visitor.headers -o visitor.html https://example.com/page
curl -sS -L -A "Googlebot" -D crawler.headers -o crawler.html https://example.com/page

Review redirects, final URL, status, important headings, content, links and canonical metadata. Confirm that normal visitors still get the intended page. Use matching recent delivery/log evidence where available.

A missing individual cache header is not conclusive. Simulated user-agent tests do not authenticate crawler identity or prove indexing. If the result regresses, restore the known working configuration and investigate with troubleshooting.

Use Health and Monitoring for important public URLs. Rendering addresses delivery when needed; it does not guarantee rankings or AI citations. Follow How PB Works for AI Visibility, complete articles, reviewed publication and monitoring.