An SEO migration checklist for launch week

// In this article+

An SEO migration checklist for launch week has seven categories, run in a dependency order: redirects, indexability, internal links, metadata, structured data, sitemaps, and analytics. Google's own crawling and indexing documentation ↗︎ treats each as a distinct concern with its own rules. The order is not a style preference.

Redirects have to exist before anyone can check whether they resolve. Indexability checks assume the redirects are already live. Internal links, metadata, and schema depend on the new templates being crawlable. Sitemaps and analytics come last: their only job is to confirm the list worked.

What should be on an SEO migration checklist for launch week?

Search Engine Land's own migration checklist by Ludwig Makhyan ↗︎ tells a reader to "refer to this list to ensure that all existing redirects are in place". Shopify's site migration checklist ↗︎ runs to twelve steps, starting with backing up the old site and its metrics, and CrawlRaven's migration checklist template ↗︎ adds only a line to "ensure all structured data is carried over to new pages". None of the three assigns a name to a step. A checklist without an owner is a wish list.

In her guide to SEO for web migrations ↗︎, Aleyda Solis calls the right scope a "minimum viable" set of checks before and after a move, not an exhaustive audit. The seven categories below are that minimum, in the order a migration breaks them:

• Redirects: every old URL resolves to its correct new destination.
• Indexability: nothing that should be crawlable is blocked or noindexed.
• Internal links: no orphan pages, no links pointing at dead URLs.
• Metadata: titles, descriptions, and Open Graph tags carried over per template.
• Structured data: schema validates against the new markup, not just the old.
• Sitemaps: the new URL set is submitted and within format limits.
• Analytics: Google Analytics 4 (GA4) and conversion tracking fire correctly on the new domain or templates.

Each category depends on the one before it. Work the list in order.

What redirect work has to be locked before launch, and who signs it off?

A redirect map is a table matching every old URL to its new destination, built before any redirect code ships. Makhyan's Search Engine Land checklist ↗︎ pulls the map from five places: the CMS export, CDN or server logs, Search Console's indexed URLs, analytics' top landing pages, and a backlink tool's most-linked pages. No single source captures every URL that still carries ranking value: a CMS export misses old indexed pages, Search Console misses pages that lost crawl budget, and backlink data misses internally linked pages with no external links. Pull all five, dedupe, and map each surviving URL to its specific successor, never to the homepage.

Google's own redirects documentation ↗︎ sets the rule for the mechanism itself: "If you need to change the URL of a page as it is shown in search engine results, we recommend that you use a permanent server-side redirect whenever possible". Server-side means the redirect fires at the server or CDN layer, before a browser or crawler renders anything. A JavaScript or meta-refresh redirect requires the page to load first, so a crawler with a shallow rendering budget may record the old page's content, or nothing, instead of following it.

Sign-off runs in two directions for redirects, and indexability adds a third gate with its own owner:

The two redirect signatures are the backbone of a website migration SEO engagement.

What indexability checks catch a migration before it costs rankings?

Two blockers, a staging noindex tag and a robots.txt file with Disallow: /, sit on almost every staging site to keep it out of search results. The formal standard behind robots.txt ↗︎, RFC 9309, specifies that "the most specific match found MUST be used" when a crawler evaluates multiple rules. That precision matters at launch: a robots.txt file left pointing at a staging rule, or a server error that returns a disallow-everything response instead of the real file, produces a full crawl block that behaves identically to an intentional one. Remove the noindex tag, then remove or replace the staging robots.txt, then re-crawl to confirm both are gone.

Soft 404s are the quieter failure. A soft 404 is a page that returns an HTTP 200 status, telling a crawler it loaded successfully, while showing no meaningful content: an empty category page, a broken template, or an error message rendered as a real page. Google's crawlers treat these as low-value pages rather than errors, so they get crawled repeatedly and never indexed, burning crawl budget the rest of a migrated site needs. Mikael Araújo's account of one migration's aftermath ↗︎ in Search Engine Land is the clearest documented case of what that costs: 513,369 crawled-but-not-indexed pages turned up in Brazil alone, soft 404 errors affecting 90,400 pages on the main site, and a roughly 90% traffic collapse on the Brazilian domain, part of an indexing crisis that touched all 13 country domains.

Redirect duration is where two guidance sources disagree. Search Console's Change of Address help page ↗︎ states the baseline: maintain the redirects for at least 180 days, "longer if you still see any traffic to them from Google Search". TechWyse's report on Google's domain migration rules ↗︎ said in June 2026 that Google's own site-move guidance has moved further: for domain moves covering multiple www and subdomain variants, Google now recommends keeping redirects active for at least one year, alongside filing a Change of Address request for every variant. Treat 180 days as the floor and a year as the working target for anything beyond a single clean domain swap.

What has to move with the site: internal links, metadata, and schema?

A migration usually changes the template before it changes the content, and that is where internal links break first. An orphan page has no internal links pointing to it from anywhere else on the site, and it is easy to miss because the URL itself still resolves correctly. Screaming Frog's migration and staging-crawl guidance ↗︎ names the fix: crawl the staging site the way a search engine would, compare the internal-link graph against the pre-migration crawl, and flag any URL that dropped out of the link structure. Run that comparison before launch, then again after, since a new template can quietly drop a footer or related-content module that carried real internal link equity.

Metadata carryover is the more mechanical check: titles, descriptions, and Open Graph tags mapped from old URL to new URL, template by template. The instruction in CrawlRaven's migration checklist ↗︎ to "ensure all structured data is carried over to new pages" is the right idea applied to the wrong stage. Carrying schema over is necessary but not sufficient, because a new template can serve syntactically valid markup that no longer matches what is on the page, or breaks silently for URLs a spot check never touched.

Structured data needs two checks. Google's own introduction to structured data ↗︎ describes what the markup does: "a standardized format for providing information about a page and classifying the page content". Test it before launch with the Rich Results Test on a representative sample of every template type, not just the homepage. Monitor it after launch with the Rich result status report in Search Console, since markup that validates on staging can still break in production once the new templating engine serves it under real traffic and real caching. Canonical tags, which tell a search engine which of several similar URLs is the authoritative one, sit next to this same risk: the HTTP Archive's 2025 crawl, reported in its Web Almanac SEO chapter ↗︎, found 68% of desktop pages and 67% of mobile pages already implementing them, so a migration rarely introduces canonicals from scratch, it just has to carry the existing pairing over without breaking it. When a canonical tag actually wins that argument is a longer discussion; see Technical SEO: what the work actually covers.

What sitemap and analytics steps confirm the migration actually worked?

A new sitemap has to respect the same format limits. The sitemaps.org protocol ↗︎ caps "each Sitemap file... no more than 50,000 URLs and... no larger than 50MB (52,428,800 bytes)". A site with more URLs than that needs a sitemap index file pointing to multiple sitemaps. Build the new sitemap from the same canonical, indexable URL set the redirect map confirmed, submit it in Search Console, and drop the old sitemap reference from robots.txt once the new one is live.

The Change of Address tool applies to a narrower case than most checklists imply. Search Console's Change of Address help page ↗︎ is specific: the tool exists for a change in domain or subdomain, and its redirect-duration guidance is written for exactly that scenario. A redesign that keeps the same domain, an HTTPS upgrade, or a switch between www and non-www does not need it. Those are handled through the redirect map and normal recrawling.

Once redirects are live, push the changed URL list through IndexNow rather than waiting for a crawler to rediscover it on its own schedule. IndexNow's documentation ↗︎ describes the mechanism plainly: it lets a site "automate submission of URLs as soon as the content is added, updated, or deleted". Submit the full redirect list, old URLs included, since a 301 is itself a change worth reporting.

Analytics confirmation closes the loop. Shopify's migration guidance ↗︎ sets a realistic window: expect traffic and rankings to take 4 to 6 weeks to normalize after a migration, and annotate the launch date and time in GA4, so any dip in the following weeks reads against a marked baseline. Confirm conversion events and any ecommerce tracking fire on the new domain or template set before calling analytics done, since a broken tag can sit unnoticed for weeks if nobody checks it.

What to do this week

1. Pull the redirect map from the CMS export, CDN or server logs, Search Console's indexed URLs, analytics' top landing pages, and a backlink tool's most-linked pages, before any redirect code ships.
2. Crawl staging in Screaming Frog's list mode ↗︎ against the finished redirect map, confirming every entry resolves and flagging any orphan page the new template dropped.
3. On launch day, remove the staging noindex tag and the robots.txt block, in that order, then re-crawl to confirm both are gone.
4. Submit the new sitemap within the 50,000-URL and 50MB limits ↗︎, and file a Change of Address request ↗︎ only if the domain or subdomain itself changed.
5. Validate structured data with the Rich Results Test after deployment, not only on staging, since a template can serve broken markup under production conditions that never showed up before launch.
6. Push the full list of changed URLs through IndexNow, then check the soft-404 count and the indexed-pages number in Search Console daily for the first 2 weeks after launch.

FAQ

How long should old URLs keep redirecting after a migration?

Search Console's Change of Address help page sets 180 days as the minimum, "longer if you still see any traffic to them from Google Search". Google's own site-move guidance, reported by TechWyse in June 2026, now recommends at least a year for domain moves that cover multiple www and subdomain variants. Treat 180 days as the floor and a year as the working target for anything beyond a single clean domain swap, and keep checking Search Console traffic to the old URLs rather than picking a date in advance.

Do I need the Change of Address tool for a redesign that keeps the same domain?

No. The tool is built for a domain or subdomain change specifically, and Search Console's own help page frames its guidance that way, not for an HTTPS upgrade, a www to non-www switch, or a template redesign that leaves the domain untouched. Those changes still need a complete redirect map and a recrawl. They do not need the formal address-change filing.

What's a soft 404, and why does it matter during a migration?

A soft 404 is a page that returns an HTTP 200 status, signaling success, while showing no meaningful content: an empty template, a broken module, or an error message rendered as a normal page. Google's crawlers keep revisiting these pages without indexing them, burning crawl budget the rest of a migrated site needs. Mikael Araújo's Search Engine Land account of one migration shows the scale that can reach: 513,369 crawled-but-not-indexed pages and a roughly 90% traffic collapse on the Brazilian domain, part of an indexing crisis that touched all 13 country domains.