Bolt.new Custom Domain Not Working: Check Apex, www and SSL
Bolt uses different DNS shapes for a root domain, www, and other subdomains, so copying one record type everywhere can leave a deployment stuck or route only part of the traffic.
Publish the Bolt project first. For a root domain, Bolt currently documents an ALIAS, ANAME, or flattened CNAME pointing to site-dns.bolt.host; for www, use a CNAME to site-dns.bolt.host. Other subdomains can require both a CNAME and the project-specific TXT value shown in Bolt. Remove old records at the same hostname, confirm public DNS, and then test HTTPS and preferred-host redirects.
This guide explains why Bolt domain setup differs at the DNS apex and on subdomains. It covers provider support for CNAME flattening, www routing, project-specific TXT verification, publishing state, conflicting records, DNS proxy uncertainty, HTTPS validation, redirect consistency, and the SEO checks needed after the host works.
Quick Questions
Bolt currently documents site-dns.bolt.host through an ALIAS, ANAME, or flattened CNAME at the apex, depending on DNS-provider support.
Bolt’s current guide uses a CNAME for www pointing to site-dns.bolt.host.
Bolt can provide a project-specific TXT value to verify control of a subdomain. Copy the exact value from the project rather than a tutorial.
Choose the Bolt record by hostname
The record name determines the correct setup. Use the exact project instructions when they differ from this reviewed public pattern.
- example.com: ALIAS, ANAME, or flattened CNAME to site-dns.bolt.host
- www.example.com: CNAME to site-dns.bolt.host
- app.example.com: CNAME plus the project-specific verification TXT when Bolt requests it
- Any hostname: remove an old website route at that same name, but preserve unrelated email records
See which AI crawlers actually reach your website.
Track visits from GPTBot, ClaudeBot, PerplexityBot, search bots, and other discovery agents-then see which public pages attract their attention.
- Monitor leading AI and search crawlers
- Review which public pages receive visits
- Connect crawler activity to your visibility work
Main Explanation
Confirm the project is published before debugging DNS. Bolt’s domain connection flow applies to a published site. Open the current Bolt-hosted URL and test the relevant production routes directly. If the application itself is not available, repair the publish or build state first; a DNS record only changes how visitors reach the deployment.
Identify whether you are connecting the root domain or a subdomain. The apex is the bare name such as example.com. Bolt currently directs the apex to site-dns.bolt.host using an ALIAS, ANAME, or flattened CNAME because standard DNS does not allow an ordinary CNAME at the root when other required records exist. The label varies by provider, so search its documentation for CNAME flattening rather than inventing an A address.
For www, Bolt documents a normal CNAME to site-dns.bolt.host. A deeper subdomain can also use that target, but Bolt may require a second TXT record containing a unique verification value. Copy the TXT host and value exactly from the project connection screen. Do not reuse a token from another Bolt project or publish it at the apex when the screen requests a specific subdomain.
Remove conflicting routes at the same hostname. An old A record, parked-domain CNAME, or previous builder target can keep some requests away from Bolt. Preserve unrelated mail and verification records. DNS cleanup should be hostname-specific: deleting MX, SPF, DKIM, or unrelated TXT records can break email without improving the website.
Check what public DNS actually returns. The apex may appear as resolved A addresses even when your provider is correctly flattening the Bolt target; that is normal behavior for flattening. A public tool should therefore accept either the documented hostname signal or the working public route and should not claim that an apex CNAME must always be visible. Compare uncertain results with the provider configuration and Bolt dashboard.
If Cloudflare or another CDN proxy is enabled, validation may observe the proxy instead of the Bolt destination. Public DNS cannot always identify proxy state conclusively. Use DNS-only mode during initial connection when the platform or provider requires it, confirm the base route works, and add advanced proxy behavior only with platform-supported guidance.
After DNS is visible, request the site over HTTPS. Test the root, www, and any connected subdomain in a private browser and with a direct HTTP request. Choose one primary hostname and redirect alternatives to its HTTPS URL. If DNS matches but certificate provisioning remains pending, record the public evidence and read Bolt’s project status rather than repeatedly replacing correct records.
Finally, replace preview URLs in canonicals, sitemap.xml, internal links, OAuth callbacks, email templates, analytics, and Search Console. Use the Domain Launch Doctor to compare current public signals with the reviewed Bolt rules, then run a full crawl and content audit. A stable custom host removes launch friction, while rankings and AI citations still depend on crawlable, useful, connected pages and ongoing measurement.
Practical Steps
- Publish the Bolt project and test its current hosted URL.
- Classify the requested hostname as apex, www, or another subdomain.
- Add the documented Bolt target using the record type supported by the DNS provider.
- Copy any project-specific verification TXT exactly.
- Remove only conflicting website routes on the same hostname.
- Check public DNS and account for CNAME flattening or proxy behavior.
- Test HTTPS and redirect every alternate host to one preferred domain.
- Update canonicals, sitemap URLs, callbacks, analytics, and Search Console.
Stop guessing whether AI crawlers see your best pages.
Use crawler activity as an early discovery signal, identify pages that receive attention, and find important pages that may need a clearer path.
- Monitor leading AI and search crawlers
- Review which public pages receive visits
- Connect crawler activity to your visibility work
Turn AI crawler visits into a repeatable visibility workflow.
Monitor discovery over time, compare activity across important pages, and use the evidence to decide what deserves attention next.
- Monitor leading AI and search crawlers
- Review which public pages receive visits
- Connect crawler activity to your visibility work
FAQ
Can I use a normal CNAME at the root for Bolt?
Many DNS providers do not permit a standard apex CNAME. Bolt documents ALIAS, ANAME, or flattened CNAME behavior for the root domain.
Why can the apex work while www fails?
They are separate DNS hostnames. Add the documented www CNAME and include www in the Bolt project if you want that version to serve or redirect.
How long should I wait for Bolt DNS?
Propagation time varies by provider and cached TTL. First verify that the exact public records match the Bolt project; waiting does not repair a wrong record.
Sources and methodology
The guide translates Bolt’s current hostname-specific connection rules into a dependency-ordered diagnostic. Public documentation and the platform manifest were reviewed on 2026-08-16. Because project TXT values, provider flattening, and private provisioning state vary, dashboard evidence overrides examples and no result guarantees visibility or traffic.
These references support the changeable facts and study findings discussed above. Results depend on each source's sample, date, market, query set, and measurement method.