The SEO-safe website migration checklist we use on every relaunch

A redesign or platform change is one of the riskiest things a business can do to its organic traffic. We regularly speak with companies who relaunched a beautiful new site and then watched search traffic fall by 30 to 60 percent over the following weeks. When we investigate, the causes are rarely mysterious: missing redirects, changed URLs with no mapping, content quietly removed, or a staging noindex tag that went live. Almost all of it is preventable with a disciplined process. This is the checklist we use on every migration, whether it is a WordPress redesign, a move to Shopify or a full replatform onto a headless stack.

Before you design anything: inventory what ranks

The most important migration work happens before a single template is built. You need a complete picture of what the current site is worth in search.

1. Crawl the existing site and export every indexable URL with its status code, canonical, title and word count.
2. Pull 16 months of Search Console data by page, so you capture seasonal pages that might look dead today.
3. Export backlink targets. Pages with external links pointing to them must keep their equity, even if they receive little traffic.
4. Collect URLs from other sources: XML sitemaps, analytics landing pages, paid campaign destinations and any URLs printed on packaging or sales material.
5. Flag the pages that matter most. Typically, 10 to 20 percent of URLs drive 80 to 90 percent of organic sessions and conversions. These get individual attention throughout the project.

Share this inventory with the design and content teams early. It changes decisions. When a designer learns that a seemingly minor guide page drives 12 percent of leads, it does not get merged into an FAQ.

Map every old URL to its best new home

The redirect map is the core artifact of a migration. Every URL from the inventory gets one of three outcomes:

• Kept, with the same URL. This is the safest option and worth fighting for on high-value pages.
• Redirected with a single 301 to the most relevant equivalent page, not the home page.
• Retired with a 410 or 404, only when there is genuinely no relevant replacement and the page has no meaningful links or traffic.

Rules that save pain later: avoid redirect chains by pointing old URLs directly at final destinations, update any existing redirects so they also land on the new URLs, and handle patterns such as trailing slashes, uppercase characters and old query parameters in bulk rules rather than one by one.

Redirecting hundreds of old pages to the home page is not a migration strategy. Search engines treat most of those as soft 404s, and the equity they carried is lost.

Pre-launch checks on staging

Staging should be crawlable by your tools but blocked from search engines, preferably with HTTP authentication rather than a noindex tag that might ship to production. Before launch we crawl staging and compare it against the old site:

• Titles, meta descriptions and H1s carried over or deliberately improved on key pages.
• Body content present and comparable, especially on the top pages. Designs that hide text behind tabs or drop long-form sections are a common source of ranking loss.
• Canonical tags pointing at production URLs, not staging.
• Structured data present and valid for products, articles, FAQs and organization details.
• Internal links pointing at new URLs directly rather than through redirects.
• Hreflang, pagination and faceted navigation handled consistently with the old site or intentionally changed.
• Core Web Vitals at least as good as the current site on key templates.

We also test the redirect map itself by running every old URL against staging with the redirect rules applied. Any old URL that does not end in a 200 on the intended destination is a bug.

Launch day and the first month

Launch day

1. Remove staging protection and confirm robots.txt and meta robots allow indexing.
2. Deploy redirects and re-run the full old-URL test against production.
3. Submit new XML sitemaps in Search Console, and keep the old sitemap available for a few weeks so crawlers find the redirects quickly.
4. If the domain changed, use the Change of Address tool.
5. Verify analytics and conversion tracking fire on the new templates.

The first four weeks

Some volatility is normal. Rankings for a well-executed migration usually wobble for two to four weeks and then settle at or above the previous level. We check daily in the first week and weekly after that, looking at crawl errors and 404s in Search Console and server logs, indexing coverage of the new URLs, and organic sessions and conversions for the flagged top pages compared against the same period last year. Most issues surface within ten days, and they are almost always a missing redirect, a template that dropped content, or an internal linking gap.

What migrations cost and where to spend

On a site with a few hundred URLs, the SEO work described here typically takes five to ten days spread across the project. On large catalogs with tens of thousands of URLs, most of the effort goes into pattern-based redirect rules and automated testing. The places where extra budget pays off are the redirect map, content parity on top pages and post-launch monitoring. The place teams most often cut corners, the pre-launch crawl comparison, is where the expensive mistakes are caught.

Our SEO-safe migrations service runs this process alongside your build team, or alongside ours if we are doing the build. For WordPress projects it pairs naturally with WordPress migration, and for store moves with store migration to Shopify.

Planning a relaunch?

Bring us in before the designs are final and we will give you a fixed price for the inventory, redirect map and launch monitoring. Get a migration quote.