Moving a website is one of those jobs that looks simple until something breaks. Email stops arriving, contact forms go quiet, and three weeks later traffic from Google is half what it was. Almost every one of these problems is avoidable with a plan.
This is the checklist I use when I move a site to a new host or platform. It works whether you are leaving a slow shared host, moving off Wix or Squarespace, or rescuing a site from a developer who is no longer around. It concentrates on the mechanics of the move: ownership, DNS, email, testing, and the switch itself. If you are also redesigning the site, my article on protecting search visibility during a redesign covers the content and ranking decisions that sit on top of this.
Decide what is actually changing
Before any checklist, name the type of move, because the risk differs. Moving the same site to a new host with identical URLs is the lowest-risk case. Changing platform, which usually alters templates, URL patterns, and metadata, is riskier. Changing domain is riskier again.
Google’s guidance on site moves makes a point I follow closely: change one thing at a time. A hosting move, a new platform, a new design, and new URLs in the same weekend means that if traffic falls, you cannot tell which change caused it. If the business can afford to stage the work, do the move first and the redesign later. If it cannot, accept that diagnosis will be harder and keep better records.
Before the move
Confirm ownership. Make sure the domain is registered in your name and you can log in to the registrar. If you cannot, fix that first. Nothing else is safe until you control the domain.
Take full backups. Download the files, export the database and save a copy somewhere that is not the current host. Then check the backup opens. A backup you have never tested is a hope, not a backup. WordPress’s own upgrade documentation makes the same point: verify that backups are usable.
List every URL. Crawl the current site with a tool such as Screaming Frog and export every page, image and document address. Add the URLs from Search Console that get traffic, because crawlers sometimes miss old pages that still rank.
Record your DNS. Write down every DNS record, especially MX, SPF, DKIM and DMARC for email. Moving web hosting should never touch email, but a careless nameserver change can wipe these records. If your DNS is currently managed by the old host, that is a dependency to resolve before you leave, since cancelling the account can take the records with it.
Note what connects to the site. Forms, payment providers, booking tools, analytics, pixels and any API keys. Each one will need testing after the move. Include less obvious items such as embedded maps, newsletter sign-up connections, and any firewall rules that allow a service to reach the site.
Capture a baseline. Save a few weeks of Search Console performance data, analytics figures, and page speed results before you touch anything. Without a baseline, “traffic dropped” is an impression rather than a finding.
Plan the redirects
Map old URLs to new ones. If any address changes, every old URL needs a permanent redirect to its closest new equivalent. Google recommends server-side permanent redirects (301 or 308) straight to the final destination, and advises against sending many old URLs to an unrelated page such as the new homepage. Send each one to the page that answers the same question.
Keep what you can. The safest migration keeps URLs exactly as they are. Change them only when there is a good reason, and accept that rankings may wobble for a few weeks when you do. Tidy URLs are rarely a good enough reason on their own.
Plan how long the redirects stay. Google advises keeping redirects in place for at least a year so its systems can transfer signals to the new addresses. Visitors and other websites may rely on old links for far longer. I would treat redirects as permanent unless there is a specific reason to remove them, and update your own internal links to the new addresses so visitors are not sent through unnecessary hops.
Beware of chains. A redirect that points to another redirect adds delay and risk. During a platform change it is easy to stack a new rule on top of an old one without noticing. Test from the original address, not from the previous hop.
Build and test on a copy
Set up the new site on a staging address. Block it from search engines while you work so the copy does not compete with the live site. A noindex setting or password protection both do this, and I would use the second where the content is sensitive, since a noindex tag only asks engines not to list the pages.
Compare page by page. Check titles, descriptions, headings, images and structured data against the original. Missing meta data is one of the most common causes of lost rankings. A platform change often drops canonical tags, alternative text, or custom fields without any visible sign on the page.
Test the forms and integrations. Send a real enquiry through every form and check where it lands. Confirm that the sender address passes your email authentication, otherwise messages from the form may go to spam.
Check speed. The new host should be faster. If it is not, find out why before you switch. A hypothetical example: a site moves to a larger plan but keeps an uncompressed image library, and nothing improves. The host was never the main constraint.
Check that search crawlers can reach the new server. Google recommends confirming that firewall or protection settings at the new host are not blocking its crawler. A security rule that works well against abusive traffic can also stop legitimate indexing.
The switch
Lower the DNS TTL early. The TTL is how long resolvers keep an old answer. Google’s guidance for moves without URL changes suggests reducing it to a few hours at least a week before the move. A day is better than nothing, but it depends on what the existing value is, because a record set to a long TTL will be cached for that long regardless.
Pick a quiet time. Choose the low point in your own traffic, which may be late evening, a weekend, or a seasonal lull. For a business that takes orders, avoid the days before a campaign or a holiday peak.
Switch, then remove the staging block. Make sure the live site can be indexed. A forgotten “noindex” setting or a robots.txt disallow rule left over from testing has sunk more than one migration. Check the page source and the robots.txt file on the live address, not on the copy.
Test the redirects. Run your URL list through a redirect checker. Every old address should land on the right new page in one hop.
Remember that DNS changes spread unevenly. For a period, some visitors will reach the old server and some the new one. If your site accepts orders, comments, or form entries, plan for submissions to land in either place, and consider pausing changes on the old site during the overlap.
After the move
Submit the new sitemap in Search Console and watch the coverage and performance reports for the next four to six weeks. Google notes that after a move the crawl rate may dip briefly and then recover, and that for medium-sized sites the new URLs can take weeks or more to replace the old ones, so a short-term fluctuation is not by itself a reason to panic. A persistent drop on specific sections is a reason to investigate.
Use the Change of Address tool only if the domain changes. Google says it applies to moves between domains or subdomains, not to HTTPS moves, www changes, or path changes within the same domain.
Keep the old host until it stops receiving traffic. I used to think of this as a fixed month. Google’s advice is more precise: keep the old server until its logs show that neither visitors nor crawlers are still arriving. For a small site without detailed logs, a month is a reasonable minimum, in case you need to recover something.
Check email deliverability, including messages sent by your forms. Send test messages to more than one provider, and read your DMARC reports if you collect them.
Write down what lives where. A short document listing your registrar, host, DNS, logins and who has access will save the next person hours.
When to get help
If you have lost access to the site, the domain is not in your name, or the site has been hacked, start with a recovery plan rather than a move. My website migration and rescue service covers both: getting control back and moving the site safely. If you are on WordPress, a care plan afterwards keeps it healthy.
A careful migration is mostly preparation. The switch itself should be the least eventful part.