Website Migration Checklist: Moving to a New Host or Domain
Published October 15, 2026 · Last updated October 21, 2026 · By the WebSolutions LLC team
Moving a website is one of the few routine jobs that can undo years of work in an afternoon. Pages go missing, forms stop sending, email breaks because a DNS record was forgotten, and search traffic drops because old URLs return errors. None of this is inevitable. A website migration done in the right order, with a written plan and a rollback option, is usually uneventful.
This checklist covers the two most common moves: changing hosting provider while keeping the same URLs, and changing the domain or URL structure. It follows Google's own guidance on moving hosts without URL changes and site moves with URL changes. Website migration is part of our hosting and domain services if you would rather not do it alone. Still choosing where to move? Our guide to the types of web hosting compares shared, VPS, cloud and dedicated plans, and our guide on how to choose a domain name covers registration, renewals and registrar transfers if you are changing domain.
Step 1: Decide what kind of migration you are doing
- Host move, same URLs. Same domain, same page addresses, different server. This is the lowest-risk move; the main work is copying files and data and switching DNS.
- URL change. A new domain, a move from HTTP to HTTPS, a switch between www and non-www, or a new URL structure (for example after a redesign or a CMS change). Every old address needs a permanent redirect to its new equivalent.
- Both at once. Possible, but harder to troubleshoot. When you can, change hosts first, let things settle, then change URLs.
Step 2: Pre-migration checklist
- Take a full backup of files, databases and email (if email is hosted with the site). Store a copy away from both the old and the new server.
- Inventory every URL. Combine the XML sitemap, a site crawl, analytics landing pages, server logs and your CMS export. Include images, PDFs, CSS and JavaScript files, which Google's guide specifically calls out.
- Export your DNS zone. Record every A, AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC, verification) and SRV record. Forgotten MX and TXT records are the most common cause of broken email after a move.
- Lower the DNS TTL. Google suggests reducing the TTL to a low value, such as a few hours, at least a week before the move so ISPs pick up the change faster.
- Note software versions. PHP or runtime version, database version, required extensions, cron jobs and any server rules (for example
.htaccessredirects). Match or upgrade them deliberately on the new host. - Record a baseline. Save current traffic, top pages, indexed page counts in Search Console and page speed scores so you can compare after launch.
Step 3: Build and test on the new host
- Upload the full site and import the database. Update configuration files with new database credentials and paths.
- Test on a temporary hostname or by editing your local hosts file. Google recommends blocking the test copy from indexing (for example with a
noindextag) while it is public. - Check every template: home, service pages, contact, blog posts, checkout or booking flows. Submit every form and confirm the messages arrive.
- Install an SSL certificate on the new server before switching DNS, so visitors never see a certificate warning.
- Confirm the new server does not block Googlebot through a firewall or bot protection, and that your Search Console verification method (file, meta tag or DNS record) still works.
Step 4: Map and test redirects (URL changes only)
If any URL changes, build a redirect map: a simple two-column list of old URL and new URL. Then follow these rules from Google's documentation:
- Use server-side permanent redirects, HTTP 301 or 308. Google treats 302 and 307 as temporary and may keep the old URL as canonical (Google redirect guide).
- Redirect each old URL directly to its final destination and avoid chains; Google suggests no more than three hops at most.
- Do not send many unrelated old URLs to the homepage. Return a 404 or 410 for content you are deliberately retiring.
- Update internal links, canonical tags and hreflang annotations to point to the new URLs rather than relying on redirects.
- Test the full redirect map with a crawler before launch and again immediately after.
Step 5: Launch day
- Freeze content changes on the old site so nothing is lost between the final sync and the switch.
- Run a final database and file sync, then update DNS records (or nameservers) to the new host.
- Remove any temporary
noindextags or robots.txt blocks from the new site. This step is easy to forget and can remove a site from search results. - For a domain change, submit the new XML sitemap in Search Console and use the Change of Address tool. Google notes that the tool is not needed for HTTP to HTTPS moves, www changes or path changes on the same domain.
- Keep the old hosting account running until traffic on it has dropped to zero.
Step 6: Post-migration checks
- Watch server logs on both old and new servers; traffic should shift to the new one as DNS updates spread.
- Check Search Console daily for the first weeks: indexing, crawl errors and any security issues. Google says a temporary dip in crawl rate is normal and should recover over the following days, while ranking fluctuations after a URL change can last a few weeks or more on medium-sized sites.
- Crawl the live site for 404s and redirect chains and fix them quickly.
- Confirm email delivery, SSL renewal automation, backups and cron jobs on the new host.
- Keep redirects in place for at least one year, as Google recommends, and ask partners to update important links to your new URLs.
Common migration mistakes to avoid
Most failed migrations come down to the same handful of mistakes: forgetting MX records, leaving noindex on the new site, using temporary 302 redirects, cancelling the old hosting too early, and skipping a test restore of the backup. Before you start, add a regular maintenance plan for the new host using our website maintenance checklist, and review the access and update basics in our small business website security guide. Questions about your own move? See our FAQs or contact us.
Website Migration FAQs
Answers to common questions about changing hosts and domains.
Will moving my website to a new host affect SEO?
If the URLs stay the same and the new server is fast and reachable, a host move usually has little lasting effect. Google notes that crawl rate may dip briefly after the switch and then recover over the following days.
How long should I keep 301 redirects after a domain change?
Google recommends keeping redirects in place for at least one year. Many sites keep them indefinitely, because old links from other websites keep sending visitors for years.
Do I need the Change of Address tool in Search Console?
Only when you move to a different domain or subdomain. It is not needed for an HTTP to HTTPS switch, a www to non-www change, or a host move where the URLs stay the same.
How long does DNS propagation take?
It depends on the TTL set on your DNS records. Lowering the TTL to a few hours at least a week before the move, as Google suggests, helps resolvers pick up the new address faster on launch day.
Should I redirect all old pages to the homepage?
No. Redirect each old URL to the most relevant new page. Sending many unrelated URLs to the homepage is confusing for visitors, and Google advises against it.