Moving a site to a new domain touches four things: DNS, the site's own internal URLs, redirects from the old domain, and email. Doing them out of order can break the site, drop SEO, or bounce mail. Here's the sequence that avoids all three.
Point the new domain at your hosting first, update the site's internal URLs second, set up redirects from the old domain third, and move email last, once you've confirmed the new domain is stable. Keep the old domain registered and pointed at something (a redirect, not a parked page) for at least six to twelve months so old links and bookmarks still resolve.
1. Point the new domain at your hosting
Add the new domain to your hosting account before you change anything else. If it's a domain registered with us, add it as an addon domain or alias from your service in the portal (Services > your hosting). If the domain lives at another registrar, you have two options: change its nameservers to ours, or leave it where it is and edit DNS records directly there. If instead you're pointing a domain or subdomain at a platform like Shopify or Wix rather than to us, see Pointing your domain or subdomain to Shopify, Wix, and other services.
If you're new to how this resolution chain works, What is DNS? Nameservers, records, and how the internet finds your site covers it. For the actual nameserver change at your specific registrar, see Changing nameservers at GoDaddy, Namecheap, and Cloudflare. Once the new domain resolves to your hosting account, you can preview the site there (via a browser hosts-file entry, or by visiting it once DNS has propagated) before you touch anything on the old domain.
Don't remove the old domain from your hosting yet. You need it live to build the redirect in step 3.
2. Update the site's internal URLs
Pointing DNS at your hosting doesn't change what the site itself thinks its address is. If you're running WordPress, the site URL is stored in the database, in the siteurl and home options, and referenced throughout post content, image paths, and any hardcoded links in the theme. Change it in one of two places:
- WordPress admin: Settings > General, update both WordPress Address (URL) and Site Address (URL) to the new domain, then save.
- Database search-and-replace: useful if the admin dashboard becomes unreachable mid-change because the old URL is baked into a redirect loop.
Either way, a straight URL rename in the settings screen only updates the two site-address options. It won't rewrite URLs stored inside post content, serialized widget data, or a page builder's saved layouts. For a full domain migration you generally need a proper search-and-replace pass across the database (there are WP-CLI commands and plugins built for exactly this) so that internal links, image src attributes, and any absolute URLs in content all point at the new domain instead of the old one. Skipping this step can leave a site that loads, but with some links and images silently pointing back at the old domain.
For a static site or anything without a database, this step is simpler: grep your source files for the old domain and replace it, then redeploy.
3. Redirect the old domain
Once the new domain is live and confirmed working, set up a redirect from the old domain to the new one. This preserves your SEO equity and keeps old bookmarks and inbound links working instead of dead-ending at an error page or someone else's parked-domain ad page.
The cleanest way to do this at the DNS/hosting level is a domain redirect on the old domain pointing every path to the equivalent path on the new domain (a full redirect, not just the homepage) so that olddomain.com/blog/post lands on newdomain.com/blog/post rather than dumping every visitor on the new homepage. Set this up from the old domain's hosting or DNS configuration once it's no longer serving the live site directly.
Leave this redirect running long-term. Search engines and other sites take months to fully re-index the new URLs, and old links out in the wild (forum posts, old backlinks, printed materials) never fully disappear. Keep the old domain's registration current specifically so this redirect doesn't lapse.
4. Move email last
Email is easy to get wrong if you change it too early. Don't touch MX records on the old domain until the new domain's site is confirmed working and you're ready to switch mail delivery, since a mid-migration mistake here can mean bounced or lost mail.
When you're ready: set up mailboxes on the new domain first (Services > your hosting > Email Accounts in the portal), confirm you can send and receive on the new addresses, then update MX records so mail starts routing to the new domain. If you want to keep receiving mail at the old addresses too, during the transition, a forwarder from the old mailbox to the new one is safer than trying to run both domains' mail live in parallel.
For the mechanics of individual record types, both MX and the TXT records SPF/DKIM depend on, see DNS record types explained: A, AAAA, CNAME, MX, TXT, SRV, CAA.
When to open a ticket
If you're not confident about the redirect setup, the database search-and-replace, or you want someone to double check DNS before you change nameservers on a domain with active mail, open a ticket from Support in the portal. It goes to a real person, not a bot, and catching a misconfigured MX record before it goes live avoids the hassle of recovering lost mail after.