The SEO Site-Migration Playbook (Don't Lose Your Rankings)

Most ranking disasters are self-inflicted. Algorithm updates get the headlines, but the single most reliable way to erase years of earned authority in a matter of weeks is to migrate your site without a plan. URL structures change, redirects get missed, a staging noindex tag survives into production, and by the time traffic falls off a cliff in Search Console the damage is already done.

Migrations are not inherently dangerous. Done carefully — with a baseline, a tested redirect map, a parity checklist, and post-launch monitoring — sites move cleanly and rankings hold. The playbook is straightforward. What's missing in most failed migrations is the discipline to follow it.

Types of migration

Not all migrations carry the same risk profile. Understanding which type you're running changes which parts of the checklist matter most.

Domain migration. Moving from one root domain to another (old-brand.com → new-brand.com, or acquiring a competitor's domain). This is the highest-stakes migration type. Every URL changes, all accumulated domain authority starts fresh on the new domain, and consolidation depends entirely on the quality and completeness of the redirect map. Domain migrations can take months to fully consolidate even when executed perfectly — the monitoring section below covers what to watch as it recovers.

Platform or replatform migration. Moving from one CMS to another (Magento to Shopify, WordPress to a headless stack, Drupal to anything). The domain often stays the same, but URL structures, canonical logic, pagination, faceted navigation, and metadata handling can all change underneath you. Platform defaults don't always match what your previous platform was doing — especially around trailing slashes, index pages, and dynamic parameters.

HTTPS migration. Moving from HTTP to HTTPS. This is almost always a domain-level migration in terms of redirect scope — every single URL changes protocol — but it's operationally simpler because the content, structure, and authority signals transfer cleanly if the redirect map is complete. For any site still on HTTP — increasingly rare now — this is the migration with the clearest benefit-to-risk ratio.

Redesign or IA restructure. The domain stays, the platform may stay, but the information architecture changes. Sections are renamed, categories are merged, content is reorganized. URL structures shift at the section level rather than across the entire site. The risk is proportional to how many existing URLs are moved or eliminated — a full IA overhaul on a large content site touches thousands of URLs.

URL structure change. A subset of IA restructuring: changing URL patterns without necessarily reorganizing content. Removing date-based prefixes (/2019/06/post-title → /post-title), changing category paths, removing query strings. The content and page value is the same — only the address changes.

Why migrations go wrong

Every category of migration failure traces back to the same handful of root causes.

Broken or missing redirects. The most common cause of ranking loss. A URL that had backlinks, internal links, and crawl history suddenly returns 404. That page's authority doesn't consolidate anywhere — it vanishes. On a large site, generating a complete redirect map is difficult, and it's easy to miss URL patterns: paginated pages, filtered category URLs, seasonal content, user-generated content. Even a 90% redirect coverage rate means 10% of your URL inventory — potentially thousands of pages — is abandoned.

Lost content. During a replatform, content is migrated from one system to another. In practice this process has edge cases: unusual characters in titles, embedded media that doesn't transfer, content that lives in the old CMS under a database flag that the migration script doesn't handle. A page that existed before the migration and doesn't exist after it is an unrecoverable loss if no one noticed.

Changed internal links. Redirects handle external links and direct access. But internal links — navigation, in-content links, breadcrumbs, sitemap entries — should all point at the final URL, not the redirect. If your migration sets up a perfect redirect map but doesn't update internal links, your crawl budget is partly wasted on redirect hops, and link equity flows through an indirect path rather than directly. The mechanics of this are covered in depth in the 301 redirect audit.

Staging configuration carried to production. The most avoidable migration failure. A staging environment is — correctly — configured to block indexing: a Disallow: / in robots.txt, a noindex on every page, or both. The migration involves deploying that staging environment to production. If the staging configuration isn't cleanly removed or overridden before launch, the live site tells search engines not to index it. Google can fully deindex a site in a matter of days. This failure mode is almost always caught immediately in terms of cause, but the recovery — getting pages recrawled and re-indexed — takes weeks. Check robots.txt and a sample of page headers within the first five minutes of going live.

Sitemaps not updated. If your new URL structure is live but your sitemap still points at old URLs (which now 301 to the new structure), you're asking search engines to re-learn your URL inventory from scratch rather than updating it. Sitemaps should be regenerated to reflect the new URL structure before launch, not after.

Before: baseline everything

You cannot verify a successful migration without knowing what you had before you started. This sounds obvious, but many teams skip the baseline step and then have no reference point to determine whether a post-migration traffic change is noise or signal.

A complete pre-migration baseline includes three things.

Full crawl and URL inventory. Run a complete crawl of the current site and export every URL — pages, images, PDFs, sitemaps, everything. This is the source of truth for your redirect map. Every URL in this inventory that isn't going to exist at the same address after the migration needs an explicit redirect entry. Don't build the redirect map from a spreadsheet someone assembled last year; build it from a fresh crawl of what's actually live now.

Current rankings and traffic snapshot. Pull your ranking positions and organic traffic data from Google Search Console — by page, not just by query. You want page-level data so you can compare post-migration traffic per URL to pre-migration traffic per URL. A site-wide traffic comparison masks page-level losses. Export Search Console's coverage report as well; the pre-migration baseline tells you how many pages were indexed.

Page-level metadata. For each URL in your inventory, record the title tag, meta description, canonical tag, hreflang (if relevant), and whether it's noindexed. This is your parity checklist source. If a page had a canonical pointing at itself and post-migration it has a canonical pointing at a different URL, that's a regression to catch.

Without these three baselines — crawl inventory, ranking/traffic snapshot, metadata export — your post-migration verification is guesswork.

The redirect map

The redirect map is the single most important technical artifact in a domain or URL-structure migration. It is a complete list of old URL → new URL pairs, one redirect per row, configured to resolve in a single hop.

Every redirect in the map should be a direct connection from the original URL to the final destination. Chaining — old URL → intermediate URL → final URL — multiplies crawl overhead and introduces failure points. Build the map as a flat list.

# redirect-map.csv — old URL, new URL (one hop each)
/blog/old-slug,/blog/new-slug
/category/widgets?sort=new,/widgets
/2019/06/post-title,/post-title

A few things to include that teams commonly miss:

Query-string variants. If your old site had filtered category pages or sort parameters in the URL (/products?category=shoes&sort=price), those URLs accumulated links and crawl history too. Decide whether to redirect parameterized URLs to their canonical equivalents or to the category root, and make that decision explicit in the map rather than relying on a catch-all.

Case variants and trailing slashes. If your old server was case-insensitive and your new server is case-sensitive, /Blog/Post-Title and /blog/post-title are different URLs on the new server. Check for case variation in your URL inventory and cover it in the map. Same for trailing slashes: /about and /about/ should consistently resolve to one canonical form.

Paginated pages. /blog/page/2, /blog/page/3, and so on. If the pagination structure changes in the migration (which it often does when platforms change), these need explicit redirects to either the new pagination structure or the first page of the section.

The homepage. The old homepage should redirect to the new homepage. This sounds so obvious it's easy to overlook in the mechanics of building the map.

Test the redirect map in staging before launch. Run a subset of old URLs through the staging environment and verify that each one returns the correct status code and resolves to the expected destination in one hop, not two or three.

Parity checklist

After the redirect map is built and tested, the second verification pass is content and metadata parity — confirming that the new version of each page is technically equivalent to the old version.

Title tags. Compare title tags on key pages between old and new. Platforms often have different title templating defaults — a WordPress plugin might have been generating "Post Title — Site Name" while the new platform defaults to "Site Name | Post Title" or generates titles from a different field. Titles that change on migration can change rankings.

Canonical tags. Every page should self-canonicalize unless there's a specific reason not to. Check that the new platform is generating canonical tags that point at the new URL, not the old one. A canonical that still points at the old domain is a significant signal problem.

Structured data. If pages had schema markup on the old platform — Article, Product, BreadcrumbList, FAQPage — verify it's present and correct on the new platform. Schema that silently disappears during a migration can affect rich results. The technical SEO checklist covers the full structured-data validation workflow.

Robots/noindex status. Every page should match the old site's indexability state unless you're intentionally changing it. A page that was indexed on the old platform should not have a noindex tag added by the new platform's default template.

Internal links. After migration, internal links should point at new URLs, not old URLs that happen to redirect. Redirected internal links waste crawl budget and route link equity through an extra hop. Update them.

XML sitemaps. Regenerate sitemaps from the new URL structure. Remove all entries that redirect or return non-200 status codes.

Launch day

Go live with the redirect map in place and the parity checklist confirmed. The first ten minutes after flipping to production are the most important.

Spot-check redirects immediately. Request a sample of old URLs from the production server — not staging — and confirm they return 301 with the correct destination. At least a few from each major section of the site. Redirect rules sometimes behave differently in production than in staging because of CDN layer differences, server configuration, or environment-specific configuration files.

Check robots.txt. Request yourdomain.com/robots.txt from the live server and confirm it doesn't contain Disallow: /. Check a sample of page response headers for X-Robots-Tag: noindex. This is the staging-config-in-production check. Do it before doing anything else.

Submit updated sitemaps. In Google Search Console, submit the new sitemaps. This signals to Google that the URL inventory has changed and invites re-crawling of the new structure.

Request indexing on key URLs. In Search Console, use URL Inspection to request indexing on your highest-priority pages — homepage, top-traffic pages, core product or category pages. This doesn't guarantee immediate recrawling, but it puts those URLs into the priority queue.

Monitor Search Console for crawl errors. GSC's coverage report will start showing errors from the new structure within hours to days. Check it the same day. Early errors on URLs that should be redirecting cleanly are a signal that part of the redirect map isn't working as expected.

After: monitor

The work doesn't end at launch. Search engines take time to recrawl a migrated site, process the redirects, and consolidate signals to the new URLs. Monitoring in the weeks after migration is how you catch problems before they become ranking losses.

Re-crawl the site. Within a day of launch, run a full crawl of the new site. Compare crawl errors between the pre-migration crawl and the post-migration crawl. New 404s in the post-migration crawl indicate URLs in the new site that are broken — either content that didn't migrate cleanly or internal links pointing at non-existent URLs. New redirect errors indicate chains or loops in the redirect configuration.

Watch GSC coverage week by week. Track the count of indexed pages in Search Console. After a migration, indexed page count often dips temporarily as Google recrawls and re-evaluates the new URLs. A dip that persists beyond two to three weeks — or a dip that doesn't start recovering — indicates a deeper problem: redirects that aren't consolidating, canonical confusion, or content that Google is choosing not to index.

Track rankings per page. Match the page-level ranking data from your pre-migration baseline to post-migration data for the same queries. Significant ranking drops on specific pages that don't recover over four to six weeks suggest those pages either didn't have their signals consolidated cleanly (redirect or canonical problem) or had content or structural changes that changed how Google evaluates them.

Check inbound link equity. Ahrefs, Majestic, or any link data source will show links pointing at old URLs. Over time, a successful migration sees those links' equity consolidating to the new URLs as Google processes the redirects. Old-URL link counts don't decline in link data because the sources don't change — but in practice the ranking effect should shift to the new URLs within a few weeks to a few months.

The monitoring window for a large migration — domain change or full IA restructure — should be at minimum six weeks, and ideally three months. Traffic recoveries after major migrations are rarely linear; there are often dips at the two-week and six-week marks as Google's various systems process updates at different rates.

How CrawlX de-risks it

The playbook above is centered on three crawl moments: the pre-migration baseline, the post-migration verification, and the ongoing monitoring. CrawlX is built to support all three.

Before migration, a full baseline crawl exports your complete URL inventory, status codes, metadata, and internal link graph. That inventory becomes the source for your redirect map and parity checklist — built from what's actually live, not from a stale spreadsheet.

After migration, a verification crawl detects broken internal links pointing at redirected or 404 URLs, chains in the redirect configuration, canonical tags pointing at wrong destinations, noindex flags on pages that should be indexed, and structured-data losses. The comparison between the pre and post crawl surfaces exactly what changed.

During monitoring, scheduled crawls at weekly intervals produce a running record of crawl errors as a second reference, index coverage, and redirect status. If something goes wrong two weeks after launch — a redirect rule gets overwritten by a platform update, a CDN configuration change breaks a section of the map — the next scheduled crawl surfaces it automatically.

Migrations succeed when the redirect map is complete, the parity checklist passes, and monitoring catches regressions before they compound. The technical work is straightforward. The discipline to baseline before, verify after, and watch for weeks is what separates migrations that hold rankings from the ones that don't.