First-hand · verified against the real thing
Custom domains: the DNS order that avoids downtime
In one line: Apex, www, CNAME flattening and verification order — the sequence that works, learned while moving a live site.
Moving a site to a custom domain is simple in principle and annoying in practice because the steps have an order, and doing them out of order produces hours of "why is this still showing the old site".
The order
1. Buy the domain at a registrar with honest pricing (at-cost resellers like Cloudflare or Porkbun), and keep DNS hosted there. Free WHOIS privacy comes standard now; pay for it nowhere.
2. Add the domain in your host's dashboard first. Render (and most hosts) gives you the exact DNS records to create — an apex record and a www record. Adding the domain before the records exist means verification completes the moment DNS propagates.
3. Create the records exactly as given. Apex domains usually get ALIAS/ANAME or A records; www gets a CNAME. If your registrar supports CNAME flattening at the apex, flattening to the host's target is the clean path.
4. Change the site's canonical URLs in config, not in pages. Every canonical link, sitemap entry and Open Graph URL should come from one configuration value. Ours is a single SITE_URL in one config file feeding every builder; grep your codebase for the old hostname and the only hit should be the changelog.
5. Verify with the registry, not your browser. Browser caches lie about DNS for hours. Check with dig/nslookup, and confirm the old domain 301s to the new one at the host level.
The mistake that costs a week
Hard-coding the staging hostname into canonicals, then migrating. Search engines index what your canonicals say; if every page declares the staging URL canonical, the new domain can sit unindexed for weeks. Centralise the hostname before you migrate — the five minutes of config refactor is the whole game.
Next