Key Takeaways
- A website migration should begin with a complete record of the current site, not with the new design.
- Keep valuable URLs where you can. Where a URL must change, map it to the closest useful replacement and use a server-side permanent redirect.
- Preserve page content, metadata, analytics, consent settings and conversion tracking unless there is a clear reason to change them.
- Test the new site behind a protected staging environment, but remove any accidental crawl blocks before launch.
- Expect some short-term movement in search performance. Monitor Search Console, analytics, enquiries and server errors after launch.
A website migration can cover a change of domain, platform, hosting, URL structure or all four. The safe approach is the same: record what currently works, change as little as necessary at one time, test the replacement and monitor the results. You cannot promise that rankings will never move. Google says temporary fluctuations are normal while it recrawls and reindexes changed URLs. You can, however, remove most avoidable causes of permanent loss.
This checklist is for a UK business moving an established website, rather than launching a first site with no search history. It focuses on protecting organic visibility, genuine enquiries and the data needed to judge the migration afterwards.
First, Decide What Is Actually Moving
Write down the parts of the website that will change. A visual redesign with identical URLs is different from moving from WordPress to a headless CMS. A hosting change with the same domain is different from merging two domains into one.
The risk rises when several major changes happen together. Google’s official site migration guidance recommends changing one thing at a time where practical. If you change the domain, page structure, copy, CMS and analytics setup on the same day, it becomes difficult to identify the cause of a problem.
Create a short migration brief covering:
- the current and future domain;
- the current and future CMS or framework;
- whether page URLs will change;
- whether content will be rewritten, merged or removed;
- forms, payments, bookings and other business-critical functions;
- analytics, advertising and consent tools;
- who can approve the launch and who can roll it back.
If the project is still being scoped, a website audit and consultation gives you a useful starting record. A more substantial rebuild can be planned through the website redesign service.
Before the Build: Create a Reliable Baseline
Crawl and export the current website
Create a list of every discoverable URL before development starts. Include pages, posts, products, categories, images, PDFs and any campaign landing pages. Record the response code, title, meta description, canonical URL, headings and indexability of each page.
Do not rely only on the XML sitemap. A sitemap may omit older pages that still receive visits or links. Combine crawl data with Search Console landing pages, analytics data, backlink information and important URLs known to the team.
Record search and conversion performance
Export at least several months of landing-page and query data from Google Search Console. Record organic sessions and genuine business outcomes in analytics: submitted forms, calls, purchases, bookings or account registrations. Google’s Search Console introduction explains which reports help with indexing, page experience and search performance.
This baseline is not just for an SEO report. It tells you which pages need the most careful checking and whether the new site still produces the actions that matter to the business.
Back up the site and its settings
Keep a restorable copy of the website, database, media library, DNS records and important configuration. Save the existing robots.txt, XML sitemaps, redirect rules, structured data and analytics settings. Take screenshots of important forms and journeys so the new version can be compared properly.
During the Build: Protect Search Intent and Functionality
Keep strong URLs where possible
An attractive new URL is rarely worth breaking a well-performing old one. If a page about commercial office refurbishment already ranks and earns enquiries, keep its address unless there is a genuine structural reason to change it.
When a URL must change, add it to a redirect map with four columns: old URL, new URL, action and test result. Each useful old page should lead to the closest equivalent new page. Do not send every removed URL to the home page. That is unhelpful to visitors and can be treated as a soft 404.
For a permanent move, use a server-side 301 or 308 redirect. Google states that permanent redirects do not cause a loss of PageRank, but redirects still need to point to genuinely relevant destinations. Avoid chains such as old page to temporary page to new page.
Preserve the parts of each page that earn its visibility
A rebuild is a chance to improve weak content, but do not remove useful sections without understanding why the page performs. Preserve the main topic, important headings, helpful copy, title, description, image context and internal links until there is evidence for a better version.
Where several thin pages are being consolidated, make the new destination genuinely cover the combined subject. Link and redirect each old page to that destination, then update internal links so the site points directly to the final URL.
Our earlier guide to redesigning a website without losing SEO goes further into protecting individual page content during a design change. For platform-specific planning, see the WordPress to Next.js rebuild guide.
Rebuild tracking and consent deliberately
List every analytics property, tag, event and advertising conversion before launch. Test form submissions, telephone links, email links, purchases and booking confirmations in a non-production property where possible. Check that internal staff traffic and payment-provider referrals are handled as intended.
A migration should not quietly restore old marketing cookies before consent or remove the consent controls the business relies on. Include the privacy notice, cookie controls and tag behaviour in acceptance testing, not as an afterthought.
Build for real users, not just a test score
Check navigation, content hierarchy, forms, keyboard use, zoom, colour contrast and error messages. Measure speed on representative mobile connections and devices. Google defines Core Web Vitals around loading, responsiveness and visual stability; its current Core Web Vitals guidance provides the thresholds and reporting options.
If the new build needs deeper performance work, use the website speed optimisation service rather than removing valuable content simply to improve a score.
Pre-Launch Website Migration SEO Checklist
Search and crawl controls
- The production robots.txt allows the pages that should be indexed.
- Temporary noindex rules, password protection and staging headers will not reach production.
- Canonical tags use the final HTTPS domain and point to the correct page.
- The new XML sitemap contains final, indexable URLs only.
- Structured data describes visible content and passes the relevant tests.
- Pagination, language annotations and mobile behaviour have been checked where applicable.
Redirects and links
- Every priority old URL has a tested destination.
- Redirects work for uppercase, trailing-slash and common parameter variants where needed.
- There are no redirect loops or unnecessary chains.
- Internal navigation, body links, breadcrumbs and canonical tags point directly to final URLs.
- Important PDF, image and campaign URLs have not been forgotten.
- High-value external profiles and advertising destinations are ready to update.
Business functions
- Contact, quote and booking forms deliver to the correct people.
- Confirmation messages and emails work.
- Payments, account access and password resets have been tested if relevant.
- Telephone numbers, addresses, opening hours and company information are accurate.
- Analytics events and advertising conversions fire once, not twice.
- Consent choices are respected before and after a return visit.
Quality and operations
- The site has been tested on current phones, tablets and desktop browsers.
- A developer has checked server logs and error handling.
- The old site and database have a restorable backup.
- DNS access, hosting access and Search Console ownership are confirmed.
- The launch window, named owners and rollback decision are written down.
Launch Day: Keep the Change Controlled
Take a fresh backup and crawl immediately before the switch. Deploy during a quieter, staffed period rather than late on a Friday when nobody can investigate. Apply redirects at the same time as the new URLs go live.
Once DNS or the deployment has changed, run a focused set of checks from outside the development environment. Test the home page, top organic landing pages, forms, checkout, login, robots.txt and sitemap. Confirm that old priority URLs return one permanent redirect to the expected destination.
For a domain move, verify the relevant old and new properties in Search Console and use the Change of Address process where it applies. Submit the new sitemap. Google recommends keeping redirects for at least a year and says keeping them indefinitely can be useful for visitors and old links.
After Launch: Monitor Leads as Closely as Rankings
Check the first hours for server errors, broken forms and missing tracking. Check daily during the first week, then weekly while Google processes the move. Compare like with like: weekday with weekday, branded with non-branded search, and seasonal periods with the same period where possible.
Monitor:
- successful enquiries, calls, bookings and sales;
- organic landing-page clicks and impressions;
- indexed and excluded URLs;
- new 404 errors and redirect failures;
- Core Web Vitals and real-user performance;
- analytics events and channel attribution;
- paid campaigns or profiles still using old URLs.
Do not remove redirects after a few quiet weeks. Old bookmarks, directory listings and links may keep sending visitors for years. Also avoid reacting to one day of volatility by changing titles and content across the whole site. Investigate patterns, compare the affected URLs with the migration map and correct clear technical faults first.
Frequently Asked Questions
Will a website migration always reduce Google rankings?
No. Temporary movement is common while Google recrawls changed URLs, but a properly planned migration does not have to cause a lasting loss. Accurate redirects, equivalent content, crawlable pages and patient monitoring reduce the risk.
How long should website migration redirects stay in place?
Google recommends keeping permanent redirects for at least one year. Keeping useful redirects indefinitely is often sensible because people and external websites may continue using old links.
Should every old page redirect to the home page?
No. Redirect each valuable old URL to the closest relevant replacement. If there is no equivalent and the content has genuinely gone, a correct 404 or 410 can be better than an irrelevant home-page redirect.
When should we launch a website migration?
Choose a quieter period when the developer, marketing owner and decision-maker are available. Avoid an important sales campaign, seasonal peak or an unstaffed Friday evening.
What should we measure after the new site launches?
Measure enquiries, sales or bookings alongside organic clicks, indexing, errors, Core Web Vitals and analytics accuracy. Rankings alone cannot tell you whether the new website is working for the business.
Plan the Move Before You Rebuild
A successful migration is mostly preparation: a trustworthy inventory, a clear URL map, working measurement and named people who can make decisions. If your current website has valuable traffic or a complicated platform, start with a documented audit rather than a design mock-up. You can contact MattDarm to discuss the migration scope and decide whether you need an audit, a redesign or a WordPress to Next.js migration.
