A website migration SEO checklist that keeps your rankings

Most traffic lost in a relaunch is lost in a spreadsheet nobody made: the list of every old URL and where it goes now. This website migration SEO checklist is the one we work through whenever a site changes platform, domain or structure, split into what to do before launch, on the day and in the month after. It is also the part of our technical SEO and performance work that clients most often ask us to take over, because a mistake here costs months of rankings and is quiet until it is too late.

01What counts as a website migration

Anything that changes the URLs Google already knows, or the pages behind them. The risk grows with how much changes at once:

Google's own advice is to change one thing at a time where you can, for example the domain first and the layout later. That is rarely what a rebrand looks like in practice, so when everything moves together the checklist below matters more, not less.

If you are still choosing where to move, our comparisons of Webflow and WordPress and of headless and traditional CMS setups cover the platform side. This post assumes the decision is made.

02Before launch: the website migration SEO checklist

Nearly all of the work happens before anything goes live. Start it when the new sitemap is agreed, not the week before launch.

Take a snapshot of what you have

You cannot protect traffic you have not measured. Record it now, because the old site will not be there to ask later.

• Export every URL Google knows: the current XML sitemap, a full crawl of the site, and the pages report in Search Console
• Add URLs that only show up elsewhere: analytics landing pages, server logs, old campaign links and PDFs
• Export the last 12 months of clicks and impressions per page from Search Console
• Note the pages that earn backlinks from other sites; those links will keep pointing at the old URLs for years
• Save each important page's title, meta description, H1 and structured data

Map every old URL to a new one

This is the core of the job. Every old URL gets one row and one decision.

• Redirect each old URL straight to its final new URL, with no hops in between
• Send pages to the closest equivalent, not to the home page; Google advises against redirecting many old URLs to one irrelevant page such as the home page
• Where several old pages are merged into one, redirect them all to that one page
• Let content with no replacement return a 404 or 410 rather than redirecting it somewhere unrelated
• Include images and files that get search traffic or links, not only pages
• Keep the URLs that earn the most traffic exactly as they are, if the new structure allows it

Carry the content and signals over

• Move titles, meta descriptions and headings for pages that rank, and rewrite them only on purpose
• Keep the text that ranks; cutting a long page down to a short one is a content change, not a design change
• Point canonical tags, hreflang and internal links at the new URLs, so the site does not rely on its own redirects
• Rebuild structured data on the new templates and test it
• Check the new templates against our Core Web Vitals checklist before launch, not after

Prepare the staging site

• Block the staging site from search with a password, not only with noindex
• Write down every noindex tag and robots.txt rule used during the build, so each one can be removed at launch
• Build the new XML sitemap from the new URLs
• Test the full redirect map on staging: every old URL should land on its new page in one step

03Launch day

Launch early in the week and at a quiet time, with people who can fix things on hand. Google suggests timing a move for low traffic periods if you can.

• Switch on the redirects as server side permanent redirects (301 or 308)
• Remove the staging password, every noindex tag and any robots.txt block
• Crawl the old URL list against the live site; every row should return one redirect and then a 200
• Submit the new XML sitemap in Search Console
• Inspect the home page and a handful of key pages with the URL Inspection tool
• Check analytics, tag manager and consent tools are firing on the new site
• Update the links you control: social profiles, email signatures, ad campaigns and directory listings

Use the right kind of redirect

Google's guide to redirects and Google Search separates two kinds. Permanent redirects (301 and 308) tell Google the new URL is the one to show in results. Temporary ones (302, 303 and 307) keep the old URL as the one shown. A migration is permanent, so use 301 or 308.

Set them up on the server or the platform, not in JavaScript. Google treats JavaScript redirects as a last resort, because it only sees them if the page renders.

If the domain changes, tell Google

A move to a new domain or subdomain is the one case for the Change of Address tool in Search Console. It does not apply to HTTP to HTTPS, www to non-www, or new paths on the same domain.

• Verify the old and new domains in Search Console with the same account, including every variant such as www and non-www
• Make sure the old home page and main pages already 301 to their new versions
• Submit the change of address for each verified variant of the old domain
• Keep the old domain registered; Google recommends at least a year

04The first 30 days

Expect movement. Google says rankings can fluctuate while it recrawls, and that a medium sized site can take a few weeks or more for the new URLs to replace the old ones in results. A dip in the first fortnight is normal. A slide that is still going in week four is a problem to find.

• Check the Page indexing report in Search Console every few days for new 404s and "redirect error" warnings
• Compare clicks per page against the snapshot you took, page by page, not only the site total
• Fix any old URL that 404s and still gets visits or links
• Keep the old sitemap submitted for a while, so you can watch its URLs drop out of the index
• Look for redirect chains created by older redirects pointing at URLs that now redirect again
• Ask the sites that link to you most to update their links to the new URLs

After the first month, these checks become part of a normal website maintenance routine rather than a launch task.

How long to keep the redirects

Google's site move guide says to keep redirects for at least a year, and that keeping them indefinitely is reasonable for visitors. For a domain change, the Change of Address tool forwards signals for 180 days. We keep them for good. A redirect costs nothing to leave in place, and backlinks to old URLs do not expire.

05When a migration goes wrong

When traffic falls and stays down after a launch, the cause is nearly always one of a short list:

• Redirects missing, temporary, or all pointed at the home page
• A noindex tag or robots.txt block left over from staging
• Ranking pages removed or cut down to a fraction of their text
• Titles and headings rewritten without the words people searched for
• Internal links still pointing at old URLs, so the site leans on its own redirects

Most of these can be fixed after the fact, but every week they stay broken costs traffic. That is why we treat the redirect map and the launch checks as part of the build, not an extra.

06Should you migrate at all?

A migration is a cost paid in risk, so it should buy something real: a platform your team can edit, a structure that matches how people search, or a site that is no longer slow by design. If the site only needs new pages and a fresh coat of paint, you may not need to move anything. We set out how to tell the two apart in how often you should redesign your website.

If a move is planned and you want a second pair of eyes on the redirect map or the launch plan, get in touch. It is easier to fix in the spreadsheet than in Search Console.