Moving a site to a new domain while switching hosts

A rebrand on a new server is really two migrations: a server move, which is about DNS and infrastructure, and a domain move, which is about URLs, redirects and search engines. Doing them together saves a second cutover, but when something breaks it is harder to tell which change caused it.

If you can, move hosts first with the old domain, let it settle for a week or two, then change the domain. If you must do both together, the steps below keep the risk manageable by testing everything before any DNS change.

List every URL on the old site that matters: pages from the sitemap, pages with search traffic or backlinks, files people link to such as PDFs. Map each to its new address. Where paths stay the same, one domain-wide rule covers everything; where they change, you need specific rules.

Use permanent redirects (301 or 308) from each old URL straight to its final new URL, in one hop. Avoid sending everything to the new home page: search engines treat that like a missing page, and visitors lose their place.

server {
    listen 443 ssl;
    server_name old-brand.com www.old-brand.com;
    # ssl_certificate ... (the old domain still needs a valid certificate)

    location = /about-us { return 301 https://new-brand.com/company; }
    location / { return 301 https://new-brand.com$request_uri; }
}

1. 1

   Step 1: Map old URLs to new URLs

   Export the old site’s URLs from its sitemap and analytics, and write the redirect map: same-path rule plus specific rules for changed paths.

2. 2

   Step 2: Build the site on the new server under the new domain

   Install and configure the site with the new domain as its address. Replace the old domain in the database and templates.

3. 3

   Step 3: Preview the new domain on the new server

   Create a preview link with the new domain and the new server IP. The new domain does not need to point anywhere yet: DNSPeek connects to the IP you enter.

4. 4

   Step 4: Compare against the old site

   Set the link’s old site address to the old domain and use Live compare to go through key pages side by side. Run a QA report for broken pages and leftover links to the old domain.

5. 5

   Step 5: Prepare redirects and certificates for the old domain

   Configure the old domain’s redirects on the new server or at your CDN, with a valid certificate for the old domain too.

6. 6

   Step 6: Switch DNS for both domains

   Point the new domain at the new server, then point the old domain at whatever serves its redirects. Lower both TTLs a day ahead.

7. 7

   Step 7: Test the redirects and notify search engines

   Check a sample of old URLs with the redirect checker, then submit the change of address and the new sitemap.

8. 8

   Step 8: Keep the old domain redirecting

   Keep the old domain registered and the redirects running for at least a year, longer if it has valuable backlinks.

Side-by-side comparison is the best way to catch what got lost in a rebuild: a missing section, an old logo, a broken layout. Usually DNSPeek compares the preview with the live site on the same domain. When the domain changes, the old server only answers on the old domain, so the “current server” side would show nothing useful.

For this case a DNSPeek link has an old site address. Create the preview link for the new domain and the new server IP, then fill in Old site for comparison in the link settings: the old domain, and optionally the old server’s IP if the old domain no longer points there. Live compare then opens the old site on the left and the new one on the right, scrolls both together and follows navigation by path. On paid plans, screenshot compares and client share links use the old address too. Details: The domain changed during the migration.

• Verify both domains in Google Search Console and Bing Webmaster Tools before the switch.
• After the redirects are live, use Search Console’s Change of Address tool on the old domain property.
• Submit the new sitemap. Canonical tags, hreflang and structured data on the new site must use the new domain.
• Update internal links to the new domain instead of relying on redirects, and ask the most valuable linking sites to update their links.
• Expect rankings to fluctuate for a few weeks while search engines process the move.

• Sign-in and payment callbacks: OAuth apps, payment providers and SSO register return URLs per domain. Add the new domain before the switch.
• Email: addresses on the old domain should keep receiving mail, or forward, for a long time. Do not drop the old domain’s MX records.
• Logins: cookies belong to a domain, so every visitor is signed out once. Warn members or customers.
• Analytics and ads: update the property URL, conversion settings and ad destination URLs.
• Certificates for both domains: the old domain needs a valid certificate to redirect HTTPS requests without a browser warning.
• Renewal: keep the old domain registered. If it lapses, someone else can buy it and inherit your links.

Check the redirect chain of the old domain with the redirect checker and the new certificate with the SSL checker right after the switch.