The website migration SEO checklist, from inventory to launch day

A website migration keeps its rankings when four things happen in order: you inventory every URL on the old site, map each one to its new home with a 301 redirect, check the staging site before it goes live, and verify the live site on launch day. Skip one and the damage usually shows up weeks later, after the project team has moved on and the cause is harder to trace.

This checklist works for a redesign that changes URLs, a move between platforms such as WordPress and Webflow, a domain change, or two sites merging into one. Google's guide to site moves with URL changes is worth reading alongside it.

Before any of it, agree who owns the search side of the project. In a redesign, the designers own the look and the developers own the build. Nobody owns the URLs unless someone is named, so put a name next to the inventory, the redirect map and the launch-day checks.

Step 1: inventory every URL

You can't protect what you haven't counted. Build one list of every URL the current site has, and pull it from several sources, because no single source has them all:

• A full crawl of the current site
• The XML sitemap
• Search Console's performance report, exported by page, for every URL with clicks or impressions
• Landing pages from your analytics
• URLs with backlinks, from a backlink tool
• Redirects already in place from earlier redesigns
• PDFs and images that get traffic or links

For each URL, record its title, meta description, main heading, canonical, clicks, impressions and backlinks. Then give it a decision:

• Keep. The page moves across with its content intact.
• Merge. The page joins a stronger one on the same topic, and redirects there.
• Retire. The page has no traffic, no links and no useful equivalent. It can return a 404 or 410.

Be slow to retire. A page with little traffic can still have links from other sites that are worth keeping, so check the backlink data before you let it go. When in doubt, redirect it to the closest relevant page.

Save a full crawl of the old site before it's switched off. After launch, it's the only record of what used to be there.

Step 2: build the redirect map

The redirect map is a two-column list: old URL, new URL. Every kept or merged page gets a row. Google explains how it treats each kind of redirect in its redirects documentation. For a permanent move, use a 301.

The rules I follow:

• Map to the closest equivalent. An old service page goes to the new service page, not to the services index.
• Don't send everything to the home page. It's a poor experience, and search engines tend to treat an irrelevant redirect like a missing page, so the old page's standing doesn't carry over.
• One hop only. Update old redirects so they point straight to the final URL instead of chaining through another redirect.
• Watch the URL patterns. Platforms differ on trailing slashes and folders. A WordPress post at the root of the domain usually ends up under a collection path like /blog/ on Webflow, so every post needs its own redirect.
• Include files. PDFs and images with links pointing at them need redirects too.
• Update internal links so they point straight to new URLs instead of leaning on the redirects.
• Keep them for the long term. Google's site move guide recommends keeping redirects for as long as possible, and generally for at least a year.

In my experience, this is the step that goes wrong most often. After Kitchen & Bath World moved from WordPress to Webflow, some old post URLs that still had search traffic were returning errors or landing on the home page. I checked every old URL with search traffic against the new site and mapped 301 redirects for the ones that no longer resolved, starting with the most-clicked posts.

Where the redirects live

On Webflow, 301 redirects go in the site settings, and a pattern rule can move a whole folder at once. On WordPress, a redirect plugin or the server configuration does the job. Wherever they live, keep the map as a spreadsheet as well. It's the document you'll test against on launch day and check against in the weeks after.

Step 3: check the staging site before launch

Staging is where you catch problems while they're still cheap to fix. Two things need handling before anything else.

Keep staging out of search, and make sure the block doesn't ship

A staging site can end up in search results if nothing stops it. Password protection is the safest block, and a noindex tag also works. A robots.txt disallow on its own doesn't: Google's robots.txt introduction explains that a blocked URL can still be indexed if other pages link to it. Whatever you use, put its removal on the launch checklist, because a noindex tag that follows the site into production can take it out of search.

Compare staging with the inventory

• Every kept page exists on staging, and every redirect destination returns a 200.
• Titles, meta descriptions and headings carried over, or were changed on purpose.
• The main content survived the redesign. Sections that earned rankings shouldn't vanish because they didn't fit the new layout.
• Canonical tags point at the page itself on the live domain, not the staging domain. Google's canonicalization guide covers the details.
• Schema is present on every template, with IDs on the live domain.
• Internal links point at the new URLs, and none point at the staging host.
• Images kept their alt text.
• Analytics and Search Console verification are in place.

Before launch, I run my Playwright QA toolkit against the staging site, alongside a crawl that I compare with the old inventory. Automated checks run the same way every time, including in launch week, when everyone is rushed.

Staging URLs are the easiest thing to miss, because the pages look fine. On one recent launch for a local service business, the canonical tags still pointed at the staging domain after the site went live, and URLs from the old site had no redirects. I fixed the canonicals, added redirects for 24 legacy URLs and put LocalBusiness schema in place.

Step 4: verify on launch day

1. Remove staging blocks. Check that the password is off, the noindex tags are gone and robots.txt allows crawling.
2. Test every redirect. Run the full list of old URLs and confirm each one returns a single 301 to the intended page, and that the page returns a 200.
3. Crawl the live site. Look for broken links, redirect chains, stray noindex tags and canonicals pointing anywhere unexpected.
4. Submit the new XML sitemap in Search Console. Google's sitemaps overview covers the format.
5. Use the Change of Address tool in Search Console if the domain itself has changed.
6. Inspect key pages with Search Console's URL Inspection tool to confirm Google can fetch them.
7. Test forms, calls to action and tracking on the live domain.
8. Update the links you control: your Google Business Profile, social profiles, ad destinations and email signatures.

The weeks after launch

Some movement in rankings after a migration is normal while search engines recrawl the site and process the redirects. The goal is to keep it small and short-lived. In the first few weeks:

• Check Search Console's page indexing report for new 404s and pages that have dropped out.
• Compare clicks by page against the inventory, and look hard at any page that lost traffic.
• Add redirects for old URLs that turn up in reports or server logs.
• Ask sites that link to you, starting with your own profiles and partners, to update their links.
• Leave the redirects in place.

If traffic has already dropped after a launch, the same inventory works in reverse. Rebuild the list of old URLs from Search Console and backlink data, then check each one against the new site. A technical SEO audit is the right tool when you don't yet know what broke.

Where to start

If your migration is still being planned, start the inventory now, before URLs and templates are final. It's the cheapest point to protect what the old site earned. If you're moving to Webflow, the CMS structure decides your new URLs, so plan it alongside the build.

I run migrations as their own project, next to whoever is building the site: the inventory, the redirect map, the staging checks and launch-day verification. Read how my SEO-safe website migrations work, or get in touch with your old and new URLs and your launch date.