A successful website migration can still involve downtime and come out ahead. One UK e-commerce migration reported 4 hours of go-live downtime, followed by two further downtime periods, yet organic visibility rose 21.1% and organic traffic grew by more than 33% within a few weeks. The lesson isn't that downtime is harmless. It's that SEO migration services must protect crawl paths, redirects, content signals and indexation, not only chase a perfect launch-day dashboard. (UK e-commerce migration case study)
I treat SEO migration as a 12 to 18 month programme, not a technical switch that ends when DNS changes. Google recommends permanent redirects, a mapped URL change, a new sitemap and ongoing redirect retention, while its site-move guidance says redirects should remain in place for at least 180 days and recommends keeping the old domain for at least a year. (Google's site-move guidance, Google Search Central's URL-change guidance)
The practical work covers commercial scoping, crawl and analytics baselines, URL mapping, staging checks, launch control, rollback planning and post-launch monitoring. For modern sites, I also benchmark AI citations, structured data and entity signals, because a move can affect how search engines and AI-assisted search surfaces understand the brand.
Table of Contents
- What SEO migration services really deliver
- The three triggers that justify a migration project
- Scoping and pre-migration checks
- Building a redirect strategy that holds
- Launch day and the roll-back plan
- Post-migration monitoring across the first year
- Typical deliverables and commercial outcomes
- When to walk away from a poorly scoped migration
What SEO migration services really deliver
The primary job of SEO migration services is simple: preserve earned visibility before looking for growth. A proper engagement identifies what already works, maps it to the new site, tests the changes before launch and keeps monitoring after the development team has moved on.
That means the deliverable isn't just a spreadsheet of redirects. It's a controlled programme with named owners, evidence, decision points and a clear definition of success. A clean launch is useful, but it proves very little if important pages disappear from the index over the following months.
Practical rule: Judge the migration by whether valuable search demand, links and entity associations transfer to the new site, not by whether the launch call finishes without an incident.
The work begins before development
A serious project starts with a business decision. Why is the organisation moving? The answer might be a rebrand, a platform limitation, a consolidation of competing properties or a structural problem that prevents users and crawlers reaching important content.
From there, the SEO work should produce:
- A migration scope: Domains, subdomains, protocols, templates, languages, product areas and supporting assets included in the move.
- A baseline pack: Rankings, organic sessions, conversions, revenue, indexed URLs, backlinks, crawl behaviour and page-level performance.
- A risk register: URL groups graded according to their traffic, links, conversions, strategic importance and technical complexity.
- A redirect and content map: Every valuable old URL assigned to the closest relevant new destination.
- A launch runbook: Testing steps, owners, monitoring windows, escalation routes and rollback criteria.
- A recovery programme: Regular reporting that distinguishes temporary volatility from a genuine technical failure.
Google's own guidance requires more than redirect deployment. It covers permanent redirects, the Change of Address tool at domain level, sitemaps and keeping redirects live for a prolonged period. (Google's site-move instructions)
The overlooked layer beyond rankings
I now capture AI citations and entity signals alongside conventional SEO metrics. Before launch, I record which pages and domains appear when users ask AI systems about the company, its products and its expertise. I also review organisation schema, sameAs relationships, author information, brand descriptions and other machine-readable signals.
This doesn't replace Search Console, server logs or rank tracking. It adds another baseline. A migration can preserve a ranking while weakening the connections that help an AI system identify the correct company, page or product.
For practical ecommerce considerations, the guide on how to avoid Shopify migration pitfalls is useful because platform moves often combine URL changes, product data transfer, templates and tracking in one project.
The three triggers that justify a migration project
Not every redesign needs specialist migration support. If the URLs, templates, internal links and indexable content remain stable, an SEO review may be enough. The risk changes sharply when the site move alters the address of pages, the way content is rendered or the route by which search engines discover it.
The industry benchmark is sobering. A migration analysis cited in UK industry coverage found that the average site took 523 days to regain pre-migration organic traffic, while 17% never recovered even after 1,000 days, and only about 10% improved rankings. (Migration recovery benchmark and strategy)
Domain or protocol change
Moving from HTTP to HTTPS, changing the primary domain or switching country-code domains affects how Google associates old and new URLs. Each important old address needs a permanent redirect to its new equivalent, and the new property must be verified and submitted correctly.
A domain change also affects brand references, email addresses, external profiles, structured data and AI citations. A redirect can carry a user to the right destination, but it won't automatically update every third-party reference or teach every system that the brand now operates on a different domain.
Platform or CMS replacement
Replatforming from WooCommerce, Magento or another system to Shopify, Adobe Commerce or a headless stack can alter product paths, category templates, filters, pagination, metadata and internal linking at once. The danger isn't limited to missing redirects. A new platform may create duplicate parameter URLs, remove useful copy or make important products harder to crawl.
A UK Shopify migration case study recorded 77% more organic sessions, a 19% increase in average order value and almost twice as many returning customers after the move from WooCommerce to Shopify. (Shopify migration case study) That outcome reflects implementation quality, not a guaranteed platform benefit.
Structural or security overhaul
Consolidating subdomains, rebuilding faceted navigation, rewriting URL taxonomy, merging duplicate content or applying site-wide SSL can change the information architecture even when the brand and CMS stay the same.
These projects justify specialist support when they affect thousands of URLs, valuable landing pages or crawl allocation. A cosmetic redesign that preserves the URL set may need technical QA. A structural overhaul needs a migration plan.
Scoping and pre-migration checks
I won't approve a redirect rule until I know what the old site contains. The first deliverable is a source-of-truth inventory assembled from several systems, because no single crawl sees every URL that matters.
Build the inventory from evidence
I start with a crawl in Screaming Frog or Sitebulb, exporting status codes, canonicals, titles, headings, indexability, internal links and crawl depth. I then compare that crawl with Google Search Console, GA4, XML sitemaps, backlink data and server logs.
The aim is to find four different groups:
- Live URLs: Pages returning successful responses and carrying content or internal links.
- Search URLs: Addresses with impressions, clicks or indexation history in Search Console.
- Commercial URLs: Pages associated with organic conversions, transactions or assisted revenue in GA4.
- External URLs: Pages that have earned backlinks, even if they receive little current traffic.
Search Console gives the search baseline. GA4 gives the business baseline. Logs show which URLs crawlers request. Together, they reveal orphan pages, forgotten PDFs, old subdomains and URL patterns that a standard crawl may miss.
The website migration SEO checklist is a useful companion for checking that benchmarking, URL mapping, redirect testing and post-launch verification have been covered.
Grade risk before mapping
A high-traffic product page with strong backlinks shouldn't sit in the same queue as an obsolete tag archive. I grade URL segments according to their organic and commercial value, then assign an owner to review the highest-risk groups.
I also inspect parity between old and new templates. That includes images, alt text, visible copy, headings, internal links, canonical tags, hreflang where relevant, structured data, pagination and indexation controls. If the new template removes useful content, a technically correct redirect won't preserve the same relevance.
The baseline must now include AI visibility. I record which URLs AI systems cite for branded and non-branded questions, how the organisation is described, which entities are associated with it and whether schema identifies the new domain consistently. That makes post-migration change measurable rather than anecdotal.
| Deliverable | Purpose | Typical tool |
|---|---|---|
| Full URL inventory | Identify live, indexed, linked and commercially valuable addresses | Screaming Frog, Sitebulb, Search Console |
| Traffic baseline | Establish organic sessions, conversions and revenue before launch | GA4 |
| Search baseline | Record queries, clicks, impressions and indexed URL signals | Google Search Console |
| Crawl and log review | Find crawler paths, orphan URLs and unexpected legacy patterns | Server logs, log analyser |
| Asset parity audit | Check content, images, metadata and structured data across templates | Crawl exports, browser QA |
| AI and entity baseline | Record citations, brand descriptions and machine-readable associations | AI surface testing, schema validation |
Building a redirect strategy that holds
The redirect map is the most important migration artefact. I create one row for every old URL that returns a successful response or already redirects, then assign one direct 301 destination on the new site.
Google recommends server-side permanent redirects, a URL mapping and a new sitemap. It also warns against redirect chains. Although Googlebot can follow up to 10 hops, the final destination should be reached directly. (Google's guidance on site moves with URL changes)
Map meaning, not just addresses
The correct destination is the page with the closest semantic and commercial role. An old product page should normally reach its replacement product page. An old category should reach the equivalent category. If no equivalent exists, recreating the content may be better than sending users to a vague substitute.
The UK guidance on site migration redirect mapping makes the same practical distinction: redirecting every old page to the homepage is not a strategy, and a loosely related target is only a fallback.
| Old URL situation | Recommended redirect target | Common mistake to avoid |
|---|---|---|
| Live page with a direct replacement | The equivalent new URL | Sending it through an interim URL |
| Old product or category merged into another page | The closest relevant surviving page | Redirecting to the homepage |
| No suitable replacement | Recreate the useful content, or allow a clean 404 where appropriate | Creating a soft 404 with an irrelevant redirect |
| Existing redirect | Test the final destination and collapse the chain | Preserving an A to B to C sequence |
| Faceted or parameter URL | Document whether it maps to a clean equivalent or remains controlled separately | Leaving every variation to self-index |
| Excluded or non-valuable URL | Retain its intended exclusion or handle it deliberately | Sending blocked and obsolete URLs to one generic page |
Validate the rules before launch
I test the mapping sheet against a fresh crawl, including trailing slashes, capitalisation, query strings and legacy URL patterns. Regex rules can reduce manual work, but narrow patterns are safer than broad substitutions that catch unintended addresses.
The new page should self-canonicalise. The old URL must not declare itself canonical after redirecting, because that creates conflicting signals. I export the approved map as deployable rules for the relevant server, CDN or edge layer, then keep the source file in version control so every change has an owner and history.
Google recommends keeping redirects for at least a year. Pages with valuable external links may deserve longer retention because users and crawlers can continue arriving through old references. The practical guide to 301 redirects and SEO covers the underlying principles without reducing the task to a bulk homepage redirect.
Launch day and the roll-back plan
Launch day should be a controlled release, not a heroic all-nighter. I prefer staging parity first, then a limited rollout where the team can observe redirects, rendering, internal links, schema, hreflang and robots behaviour before exposing the full site.
The staging environment must resemble production closely enough to catch template and routing differences. A single low-traffic section can provide an early test of the redirect layer and crawl behaviour, provided it represents the patterns used elsewhere.
Make the launch observable
On go-live, I watch Search Console, server logs, redirect responses, real-time analytics and ranking data together. One system can look healthy while another shows a serious problem. A sitemap may submit successfully while the new pages remain blocked, or analytics may record sessions while internal links still point to the old domain.
I also freeze non-essential code changes for 14 days. That gives the team a clean causal window. If a developer changes templates, tracking and routing during the same period, diagnosis becomes guesswork.
Before launch, the rollback runbook should name the decision-maker and list the exact actions for reverting DNS, redirect rules, the previous application version and stakeholder communications. I use written review thresholds such as:
- Crawl errors rising by more than 15% in 24 hours: investigate the affected URL patterns immediately.
- New URL indexation falling below 80%: check robots, canonicals, rendering and sitemap coverage.
- Organic sessions falling by more than 20% within 72 hours: compare affected templates and assess whether rollback is safer.
These thresholds aren't universal laws. They're pre-agreed triggers that stop a tired team debating from scratch at two in the morning.
Keep the old environment available
The old stack should remain warm and the old domain should continue resolving while external links, caches and third-party integrations update. Google advises keeping redirects live for at least a year, while the operational rollback window is much shorter, so the two decisions shouldn't be confused.
The video below gives a concise visual explanation of the launch sequence and the checks that belong around it.
Post-migration monitoring across the first year
The first week tells you whether the implementation works. The following months tell you whether search engines have understood the move. I set the cadence before launch so reporting doesn't disappear once the new site appears stable.
Google says site moves can take at least 180 days to settle, and its guidance supports keeping redirects active for at least that period. (Google's domain-move guidance) The industry recovery benchmark is longer, so I don't treat a quiet Search Console report as proof that the programme is finished.
Weeks one to four
Daily checks focus on the mechanics:
- Redirect coverage: Sample old URLs by template, status and traffic value.
- Indexation: Confirm that the new URL set is being discovered and processed.
- Crawl errors: Review 404s, 5xx responses, blocked resources and unexpected redirect chains.
- Rendering: Compare important templates in rendered crawls and browser checks.
- Sitemaps: Confirm that submitted URLs are valid, canonical and indexable.
- Analytics: Reconcile sessions, conversions and revenue against the captured baseline.
After the first few days, the cadence can move from daily to weekly for stable areas. I still investigate patterns rather than isolated errors. A cluster of missing product URLs is more important than a single obsolete page.
Months one to three
I segment performance by template, directory, device, query group and commercial role. This exposes problems that domain-level totals hide. For example, overall traffic may look steady because the blog is performing while high-value category pages have lost internal link equity.
I also check keyword cannibalisation, new sitemap coverage, backlink updates and old URLs appearing in internal links. The aim is to make the new architecture authoritative internally, not merely dependent on redirects.
Months three to twelve
Later monitoring measures recovery, consolidation and upside. A Shopify case study documented 77% growth in organic sessions, alongside commercial improvements, after a WooCommerce migration. (Zatu Shopify migration case study) That is evidence of what a well-executed replatform can achieve, not a forecast for every move.
At this stage, I rerun the AI citation and entity checks captured before launch. I compare cited URLs, brand descriptions, organisation schema, product entities and references to the old domain. A monthly one-page dashboard should show indexation, traffic, revenue, rankings, backlink reattribution, redirect coverage and AI visibility in the same view.
| Time window | What to monitor | Alert threshold |
|---|---|---|
| Launch to 24 hours | Status codes, redirects, logs, 5xx errors, robots and key templates | Any critical template failure or unexpected blocking |
| Weeks one to four | Indexation, sitemap health, 404 patterns, sessions and conversions | Crawl errors above the agreed baseline or new pages failing to index |
| Months one to three | Template-level traffic, revenue, rankings, internal links and cannibalisation | Sustained loss in a high-value segment |
| Months three to twelve | Recovery, backlinks, AI citations, entity signals and technical drift | Recovery stalling, old-domain signals persisting or new associations weakening |
Typical deliverables and commercial outcomes
A credible engagement leaves behind working artefacts, not just recommendations. I expect to see a redirect map in CSV or crawl-export format, a URL risk register, a baseline reconciliation, launch QA evidence and a monitoring dashboard that someone can use without asking the consultant to interpret every row.
What clients should receive
The core pack usually includes:
- A verified URL map: Old URL, response status, target, action, owner and validation result.
- A risk register: Page groups prioritised by search demand, links, conversions and business value.
- A technical QA record: Redirect, canonical, sitemap, structured data, internal link and rendering checks.
- A traffic reconciliation: Pre-migration and post-migration sessions, conversions and revenue compared by segment.
- A monitoring dashboard: Search Console coverage, indexation, crawl behaviour, errors and redirect health.
- A recovery report: What changed, which losses were fixed, where gains came from and what remains unresolved.
The right commercial expectation is protection first, then improvement. Faster templates, cleaner architecture, better product information and stronger internal linking can create upside, but no consultant can promise that a move will improve rankings because the new platform is fashionable.
A UK e-commerce case study reported 21.1% higher organic visibility and more than 33% traffic growth within a few weeks, despite downtime during launch and further interruptions afterwards. (UK site migration case study) That reinforces the importance of crawlability and indexation stability over simplistic zero-downtime claims.
| Engagement tier | Core deliverables | Realistic traffic outcome | Indicative UK price |
|---|---|---|---|
| Standard site move | Crawl inventory, baseline, URL map, redirect QA and launch monitoring | Protect valuable visibility, with recovery tracked after launch | £8,000 to £25,000 |
| Complex ecommerce move | Product and category mapping, faceted navigation review, analytics reconciliation and extended support | Protection first, with possible gains from cleaner templates and architecture | £8,000 to £25,000, depending on scope |
| Enterprise or international migration | Multiple domains, subdomains, hreflang, log analysis, staged releases and governance | Longer recovery programme with detailed segment reporting | £40,000 or more |
| Post-launch recovery | Error triage, redirect repairs, indexation work, backlink and AI-signal monitoring | Restore lost visibility and identify structural causes | Scoped after the baseline and incident review |
For independent technical oversight, technical SEO consultants can be brought in to audit implementation, coordinate with developers or own the measurement programme. The quoted price matters less than whether it includes the artefacts and accountability needed to manage the risk.
When to walk away from a poorly scoped migration
I decline migrations that exclude redirect mapping, staging parity or baseline capture. I also walk away when a development team refuses controlled testing, stakeholders set an immovable launch date before risk review, or nobody with authority can delay the release.
A low budget can be reasonable for a small, stable site. It isn't credible for a large URL estate when the brief still expects crawling, mapping, QA, launch support and recovery reporting. The same applies when the client wants a single day of consultancy but expects a year of reassurance.
The warning sign is not a difficult migration. It's a team that refuses to own the difficult parts.
Google's guidance makes the migration a long-duration responsibility, and the recovery benchmark shows why a rushed handover can create a problem that lasts far beyond launch. A good consultant records the risk, sets the conditions for safe delivery and declines the work if those conditions won't be met.
I help businesses and agencies plan SEO migration services around URL inventories, redirect maps, technical QA, launch monitoring and longer-term recovery, with AI citations and entity signals included in the baseline where they matter. Visit Sibley Digital to discuss a planned domain change, platform move or structural rebuild before the launch date becomes the project plan.