Website migration without losing SEO: the checklist we use

A website migration loses rankings for boring, preventable reasons: old URLs that now return a 404, a noindex tag left on from staging, page titles that quietly changed. This is the website migration SEO checklist we use to stop that. In short: list every URL the old site has, record what ranks and what earns traffic, map each old URL to one new URL with a 301 redirect, keep titles, content and schema at least as good as before, launch behind a 503 maintenance page, then watch 404s, indexing and rankings for four to eight weeks.

We used this process on our own site when we rebuilt we-dev.uk in October 2026. Every old URL, several hundred of them, was mapped to a new address and tested. The Search Console verification file and the analytics tag were carried over, and visitors and crawlers got a 503 maintenance page during the switch instead of a half-built site. It is mostly spreadsheet work done in the right order.

What counts as a migration, and how risky each kind is

Google does not care that you have a new design. It cares about URLs, content and whether it can still crawl them. So the risk depends on how many of those three things change at once.

Our advice is to change as few things at once as the business can tolerate. If you are rebranding and rebuilding, launch the new site on the old domain first, let it settle for a month or two, then move the domain. You get two small wobbles you can diagnose instead of one large drop you cannot.

Before the migration: the work that decides the outcome

Crawl and export every old URL

You cannot redirect a page you do not know exists. No single source has the full list, so combine several and de-duplicate them in one spreadsheet:

• A crawl of the live site. Screaming Frog is free up to 500 URLs.
• The XML sitemap, which often lists pages nothing links to any more.
• Search Console. Export the Pages report and the Performance report by page for the last 16 months. This finds old landing pages that still get impressions.
• Analytics landing pages for the last 12 months.
• Pages with backlinks, from the Links report in Search Console or a tool such as Ahrefs.
• Everything that is not a page: PDFs, images that rank in image search, and any redirects already in place from the last rebuild.

Expect surprises: once tag archives, paginated blog pages, old campaign pages and PDFs are counted, a 60-page site can easily have 200 addresses.

Benchmark rankings and traffic

Record where you stand before anything changes, otherwise you will be arguing from memory in week three. Save organic clicks and impressions by page and by query from Search Console, organic sessions and conversions by landing page from analytics, positions for your 20 to 50 most valuable keywords, the number of indexed pages, and Core Web Vitals for the main templates. Mark the 10 to 20 pages that bring in most enquiries or sales.

Build the 301 redirect map

The redirect map is a spreadsheet with the old URL in column A and its new home in column B. Three rules matter more than any tool.

• One to one. Each old page goes to the closest equivalent new page. Sending everything to the homepage is the classic shortcut, and Google generally treats those redirects as soft 404s, so the old page’s value is lost anyway.
• No chains. If /services.html already redirects to /services/, and /services/ is about to become /what-we-do/, update the first rule to point straight at the final address.
• Exact final form. Redirect to the HTTPS version with the correct www or non-www host and the trailing slash your new site uses, so one hop lands on a page that returns 200.

Not every page deserves a new home. If a page has no successor, no traffic and no links, let it go honestly.

On a WordPress build with a few dozen redirects, a redirect plugin is fine. With several hundred, we put the map in the web server configuration so the rules run before WordPress loads. Whichever way you do it, test the whole list with a script on staging: request every old URL and confirm it reaches the right page in one hop.

Keep slugs where you can

The safest redirect is the one you never need. If /boiler-servicing/ ranks well, call it /boiler-servicing/ on the new site too. Change a slug only when there is a reason a customer would notice, such as merging duplicate pages or fixing addresses like /page-2-copy/.

Titles, meta descriptions and schema parity

A migration is a poor moment to rewrite everything. For the pages that already rank, carry the title tag, meta description, H1 and body copy across as they are, and improve them a month later when you can measure the effect. Check too that the new templates still output what the old ones did: canonical tags, structured data (Organization or LocalBusiness, Product, FAQ, breadcrumbs), Open Graph tags, image alt text and hreflang if you have more than one language. We run a second crawl on staging and compare it column by column with the first.

Keep staging out of Google

A staging copy that gets indexed competes with your real site as duplicate content. Put it behind a password (HTTP authentication is simplest) and add a noindex as a second line of defence. Then write “remove noindex” at the top of the launch list in capitals. A forgotten noindex, or the “Discourage search engines” box left ticked in WordPress, is the most damaging mistake in this whole process and also the easiest to make.

Launch day, step by step

Pick a quiet day early in the week. Never a Friday, and not the week before your busiest season. If the hosting is changing, lower the DNS TTL to five minutes a day or two beforehand so the switch takes effect quickly.

1. Freeze content on the old site and take a full backup of files and database.
2. Serve a 503 maintenance page with a Retry-After header for the duration of the switch. The 503 tells crawlers the outage is temporary, and Retry-After suggests when to come back. Keep the window to minutes or hours: Google’s guidance is that a 503 lasting more than a couple of days starts to look permanent.
3. Deploy the new site and the redirect rules together.
4. Remove the staging password and the noindex. Check robots.txt does not still say Disallow: /.
5. Take the 503 away and run the redirect test script against the live domain.
6. Check the money pages by hand on a phone: forms send, the checkout takes a test payment, phone links dial.
7. Submit the new XML sitemap in Search Console and use URL Inspection to request indexing of the homepage and top pages.
8. Crawl the live site once more to catch internal links that still point at old addresses. Fix them at source so they do not rely on the redirects.

Keep the Search Console verification and the analytics tag

Two small things go missing in nearly every rebuild. The first is Search Console verification. If the property was verified with an HTML file in the site root or a meta tag in the old theme, the new site will not have it, and you lose access to your data on the one day you need it most. Copy the file or tag across, or better, verify at DNS level with a Domain property, which survives any rebuild.

The second is the analytics tag. Keep the same GA4 measurement ID so your history runs unbroken across the launch, and check it still fires only after consent. Our GA4 setup guide covers the configuration; do that work before or after the migration, not on the same day.

After launch: what to monitor for four to eight weeks

• 404s, daily in week one. Check server logs and the “Not found” list in the Search Console Pages report. Every 404 for an address that used to exist is a row missing from the redirect map.
• Indexing coverage, weekly. “Page with redirect” should rise as old URLs are processed, and indexed pages should climb back towards your benchmark. A spike in “Excluded by noindex tag” means something is still blocked.
• Rankings and clicks, weekly. Compare the benchmark keywords and the top landing pages against the pre-launch numbers, and against the same weeks last year to allow for seasonality.
• Conversions. Traffic can hold steady while enquiries fall because a form broke. Send a test enquiry every week for the first month.
• Links you control. Update your Google Business Profile, social profiles, directory listings, email signatures and advert landing pages to the new URLs.

Leave the redirects in place. Google advises at least a year; we keep them for good, because other people’s links and bookmarks never get updated.

What a normal traffic dip looks like

Google’s own documentation says to expect temporary fluctuation while a moved site is recrawled and reindexed, and that larger sites take longer. In our experience the pattern depends on how much changed:

• Same URLs, new design: often no visible change, sometimes a few days of movement.
• URLs changed, clean redirects: positions bounce for two to four weeks, then settle.
• New domain: a deeper and longer dip, commonly a couple of months before things settle, even when everything is done properly.

A dip is abnormal when it is sudden and sitewide, when it is still falling after three or four weeks, or when one important page disappears while the rest are fine. In that order, check for a leftover noindex or robots.txt block, a missing or wrong redirect, content that was cut from the page, and a changed title tag. The cause is usually on that list.

A realistic migration timeline

Common mistakes we are asked to fix

• Launching with noindex still on, or robots.txt blocking the whole site.
• Redirecting every old URL to the homepage.
• Rewriting all the copy and changing all the URLs in the same release, so nobody can tell which change caused the drop.
• Dropping pages that looked unimportant in the menu but brought in a large share of the organic traffic.
• Losing Search Console access or starting a fresh analytics property with no history.
• Cancelling the old hosting before checking the new site has everything, including email if it lived on the same server.

If you are still deciding whether a full move is necessary, our article on rebuilding versus refreshing a website is the place to start. For platform-specific export quirks, see moving from Wix or Squarespace to WordPress.

What the SEO side of a migration costs: a worked example

This is the migration work only, separate from designing and building the new site. Take a Bristol engineering firm with an 80-page WordPress site and around 250 URLs in total once PDFs and archives are counted. We charge WordPress development at £50 an hour through hourly hire.

20 hours × £50 = £1,000. Booking 20 hours earns a 15 % volume discount, so £1,000 − £150 = £850. Add VAT at 20 % (£170) and the total is £1,020. A 15-page site for a Leeds physiotherapist with 40-odd URLs is closer to 10 hours: 10 × £50 = £500, less 5 % is £475, plus £95 VAT comes to £570.

The website migration SEO checklist, printable version

Before

• Full crawl of the old site exported
• URL list combined from crawl, sitemap, Search Console, analytics and backlink data
• Benchmarks saved: clicks, impressions, rankings, indexed pages, conversions, Core Web Vitals
• Redirect map complete: one to one, no chains, final HTTPS form
• Retired pages listed and set to 410
• Titles, meta descriptions, H1s, canonicals, schema and alt text matched on staging
• Staging password-protected and noindexed
• Redirects tested by script on staging

Launch day

• Old site backed up, rollback plan agreed
• 503 maintenance page with Retry-After live during the switch
• New site and redirects deployed
• Noindex, staging password and robots.txt block removed
• Search Console verification and analytics tag present
• Redirect test passed on the live domain
• Forms, checkout and phone links tested
• XML sitemap submitted; key pages requested for indexing

After

• 404s checked daily in week one and fixed
• Indexing, rankings, clicks and conversions reviewed weekly for four to eight weeks
• Business Profile, social, directory and advert links updated
• Redirects left in place permanently

Doing it yourself or handing it over

A careful owner can migrate a small site with this list, a free crawler and a spare weekend. Hand it over when the site earns real money from search, when there are more than a couple of hundred URLs, or when the platform is changing and the old URL patterns do not match the new ones.

We are based in London and migrate sites for businesses across the UK, usually as part of a rebuild through our web development or CMS development services. If you have a move coming up, send us the current address and a rough page count and we will tell you how many hours the migration work is likely to take.

Photo: Dina Badamshina via Unsplash