SEO Migration Consulting

Which migrations carry SEO risk

Not every website change is equally risky. The risk depends on how many search signals change at once. In rough order of complexity:

• Design refresh on the same URLs: lower risk, but templates can still drop content, headings, internal links or structured data
• Content restructure or URL cleanup: every changed URL needs a redirect, and merged pages need careful mapping
• CMS or platform change: new templates, new URL patterns, new rendering behavior and often new tracking
• Domain change or rebrand: all signals move at once, and external links, profiles and listings need updating
• Merging several sites into one: overlapping topics, conflicting pages and large redirect maps

The most dangerous projects combine several of these at the same time, such as a rebrand, new domain and new platform launched together. Where possible, I recommend separating changes so each one can be verified on its own. Where the timeline does not allow that, the testing and monitoring plan gets more thorough. If the site already has unresolved technical problems, a technical SEO audit before the migration avoids carrying them into the new build.

Building and testing the redirect map

The redirect map is the single most important artifact in an SEO migration. It decides whether the signals earned by each old page pass to the right new page or are lost. I build it in stages:

1. Inventory. Combine URLs from crawls, XML sitemaps, Search Console, analytics landing pages, backlink data and old campaign links, so pages that are no longer linked internally are not missed.
2. Prioritize. Flag the URLs that carry traffic, inquiries, links or rankings, because those need individual attention.
3. Map. Match each old URL to its closest equivalent on the new site. Pattern rules handle large groups, and retired pages go to the most relevant parent rather than the homepage.
4. Review. Walk through the map with the people who own the content, because they know which pages were merged or replaced.
5. Test. Run the full map against staging, then again on production at launch, checking status codes, final destinations and chains.

This mirrors the way I handle ERP data migration: a mapping document, test loads, reconciliation and a cutover checklist. The migration checklist I use for ERP projects follows the same logic of inventory, mapping, testing and sign-off.

Staging QA and launch-day checks

Most migration problems can be found before launch if the new site is tested properly on staging. My staging QA compares the new site with the old one, template by template:

• Is the main content of each priority page carried over, or was it shortened during design?
• Do titles, headings, meta descriptions, canonicals and structured data match the requirements?
• Are internal links, navigation and breadcrumbs real links that crawlers can follow?
• Does the page content render without depending only on client-side scripts?
• Do analytics, conversion events and form-to-CRM connections still fire with source data?

Launch day has its own checklist. The most common launch errors are simple and expensive: a staging noindex tag or robots block left in place, redirects deployed to the wrong environment, a missing sitemap, or form tracking that no longer passes the lead source. I verify these on production while the launch team is still on hand, and I agree go or no-go criteria in advance so nobody has to make that call under pressure.

Diagnostic examples from migrations

These are illustrative patterns that come up in migrations, described in general terms rather than from a specific client:

• Everything to the homepage. Retired pages are redirected in bulk to the homepage, which search engines tend to treat as soft errors, so the signals are lost.
• Forgotten landing pages. Old campaign pages and resources that still earn links were not in the navigation, so they were left out of the inventory and now return errors.
• Content trimmed by design. The new templates look cleaner but carry much less of the text that explained services, so relevance drops.
• Lost lead attribution. The new form tool sends inquiries to the CRM without the original source and landing page, so nobody can tell whether organic leads changed.
• Redirect chains. Old redirects from a previous redesign now point through a second hop, slowing crawling and adding failure points.

None of these require advanced techniques to prevent. They require someone whose job is to check, and a process that does not let launch proceed until the checks pass.

Post-launch monitoring and KPIs

Some fluctuation after a migration is normal while search engines recrawl and reprocess the site. I cannot promise that visibility will hold, because that depends on the size of the change and factors outside your control. What monitoring does is separate normal fluctuation from real problems quickly. The indicators I track include:

• Redirect status for every mapped URL, rechecked after launch
• Crawl errors and not-found URLs reported in Search Console
• Indexed pages for each new template versus the old baseline
• Impressions and clicks for priority pages and topics, compared with the benchmark
• Organic landing page sessions and conversions in GA4
• Organic inquiries and opportunities by source in the CRM
• Core Web Vitals for key templates on the new platform

Issues go into a log with an owner and priority, the same way defects are handled after an ERP go-live. Once the site is stable, ongoing work can continue under technical SEO consulting or broader SEO consulting.