DigitalOcean setup

DigitalOcean may manage only the DNS zone, host the application on App Platform, or run the website on a Droplet. Those are different setups.

Check the public HTML before adding rendering. A complete server response may already be sufficient. If a delivery gap remains, choose managed routing with a verified separate origin or a server-side integration at a request layer you control. Start with the setup guide.

Confirm that the domain's active nameservers actually use DigitalOcean. Hosting a website there does not automatically make it the authoritative DNS provider.

Open Networking → Domains and select the intended domain. DigitalOcean's record management guide explains the record fields.

Copy the exact records from your connected site's authenticated PB setup. For a CNAME, match PB's host label to Hostname and its generated target to Is an alias of. Do not substitute a universal target or copy a www record to the root domain.

Keep a record of the existing zone. Correct only confirmed conflicts for the connected hostname. Preserve nameservers, email records and unrelated TXT values.

After deployment, App Platform provides an ondigitalocean.app starter domain. Its domain guide also documents redirecting that starter address to a custom domain.

A provider address that redirects back to the public hostname is unsuitable as PB's managed-routing origin. Verify a stable HTTPS response, intended production content, important routes and assets before choosing it. Read origin requirements.

For a server component that can intercept public page requests, use the applicable PB integration rather than putting crawler detection in browser code. A static frontend has different capabilities; choose its supported setup path.

Store a rendering key only in the server component's protected runtime configuration. App Platform supports an Encrypt option for sensitive variables; follow its environment-variable guide. An encrypted variable can still be exposed if code copies it into a public frontend bundle. Avoid public environment prefixes and client-side references.

For an application server or reverse proxy you operate, use the appropriate PB server-side instructions. Route only eligible GET requests for public, cacheable pages; exclude APIs, static assets, authentication, checkout, dashboards, previews and personalized responses.

Keep credentials in server-side secrets. Validate the configuration, retain a rollback copy and check that ordinary visitors still receive the intended website.

If you instead choose managed routing, first establish a separate HTTPS origin that points to the Droplet and does not redirect into the PB-connected public hostname. A Droplet IP or origin label alone does not establish a working HTTPS origin.

Keep the site's chosen canonical hostname. Redirect the alternate root or www hostname with the full path and query string preserved. Use the site's exact supported records; root and www setup explains the distinction.

After deployment, run Verify Installation and inspect the tested URL, final URL, response status, readable content and available delivery evidence. A Pending label or one absent cache header does not establish the cause of a disagreement. Use troubleshooting before another routing change.

These are crawler-profile diagnostics, not proof of real bot visits or indexing.

Use Health and Monitoring for important public pages. Rendering is one part of PB's connected workflow; AI Visibility, full articles and reviewed publishing have separate prerequisites. See How PB Works and Integrations.