GoDaddy setup
Confirm GoDaddy DNS authority, apply the connected site's exact records, and check forwarding effects and the final crawler-readable response.
On this page
Start with the public response
Check the returned HTML of an important public page before changing DNS. A website that already sends meaningful content may not need rendering. Use setup to choose a connection only when the evidence establishes a delivery gap.
Keep the website's chosen canonical hostname. The domain registrar, DNS provider, host and email provider can be different services.
Confirm the active DNS provider and origin
Check the domain's nameservers in Domain Portfolio. If another provider is authoritative, edit that provider's zone instead of GoDaddy's saved records.
For managed routing, verify a stable, publicly reachable HTTPS origin that serves the production content and important routes. It must not require a login or redirect back into the public hostname being connected. A hosting preview is not automatically a production origin; follow origin guidance.
Apply the site-specific DNS records
In the intended domain's DNS area, copy the exact records from PB's authenticated setup. GoDaddy's CNAME guide describes adding the record and entering its prefix in Name.
For www.example.com, the Name is www; the Value must be the exact target shown for the connected site. This is a field-format example, not an instruction to prefer www or put a CNAME at @.
Use the site's supported apex path for a root-domain canonical. Keep a copy of the current zone and correct only confirmed conflicts for the intended hostname.
Add current TXT ownership/certificate-validation records using the required host format. Preserve nameservers, mail records and unrelated verification values unless a separate reviewed migration requires changing them.
Review forwarding before enabling it
GoDaddy's forwarding guide describes its DNS → Forwarding controls and permanent forwarding. It also notes that forwarding can update the root A record and change nameservers to GoDaddy.
Review those effects before enabling forwarding; do not unintentionally move an externally managed DNS zone. Keep the PB-connected hostname's record intact rather than blindly following a generic instruction to point www at @.
The alternate hostname should redirect to the selected canonical over HTTPS, preserving the deep path and query string. GoDaddy documents HTTPS forwarding, but that alone does not establish path/query behavior for your configuration.
Test the actual result. If the panel setup drops the path or query, use a suitable host/server/edge redirect at a request layer you control instead of accepting homepage-only forwarding.
Verify the final response
DNS and validation timing varies. Compare the current records and dated response evidence before another edit or setup reset.
Run Verify Installation and inspect the tested URL, final hostname, status code, readable content and available delivery evidence. A Pending label or missing individual cache header does not establish the entire cause of a disagreement.
Compare a normal response and a crawler-profile response on a representative page. Simulated user-agent requests do not authenticate the crawler or prove indexing.
Continue with the relevant workflow
Use root and www guidance and troubleshooting for setup disagreements. Monitor important URLs with Health and Monitoring.
This guide covers rendering delivery. PB's AI Visibility, full article generation and reviewed publishing have separate prerequisites; follow How PB Works.
Instructions for your connected site
Open account setup for domain-specific values, diagnostics and copy-ready configuration. These stay private to your workspace.