SEO Migration: The Ultimate Guide to Moving a Website

A website migration can replace your domain, CMS, design, hosting platform, URL structure or several of them at once.

The visible site may look better after launch while search engines see something much less reassuring:

• Familiar URLs have disappeared,

• internal routes have changed,

• content has become harder to render, and

• signals now disagree about which pages should appear in search.

That is why an SEO migration is not simply a redirect exercise. It is controlled change across five connected layers:

• URL identity: domains, protocols, hosts, paths and parameters;

• content identity: page purpose, copy, metadata, structured data and media;

• discovery: navigation, internal links, XML sitemaps and hreflang;

• delivery: DNS, servers, CDN rules, HTTP responses, mobile output and JavaScript rendering; and

• measurement: Search Console, analytics, logs and a record of the release.

Your migration succeeds when people and crawlers can move from the old state to the intended new state, and when your evidence shows that important pages remain discoverable, accessible, indexable and useful. This guide gives you the planning system, acceptance tests, launch sequence and diagnostic method to get there.

If you need the wider context first, read Technical SEO: A Practical Guide for Website Owners. It explains the crawl-to-index dependency chain that a migration can disrupt.

What counts as an SEO migration?

An SEO migration is any coordinated website change that can alter how search engines discover, fetch, render, interpret, consolidate or rank your pages.

A new domain is the obvious example, but a redesign on the same URLs can be just as risky if it removes content or depends on JavaScript that search engines cannot process reliably.

Google recommends changing one major dimension at a time when practical. If you can move the hosting first, stabilise it, and only then change the domain or design, you reduce the number of possible causes when something breaks. Business constraints sometimes force a combined release. In that case, raise the testing standard and define who can stop or reverse the launch.

Expect some temporary search fluctuation during a significant move while Google recrawls and reindexes the changed URLs. That possibility does not justify vague reporting or a promise that traffic will recover on a fixed date. Monitor important URL groups and compare their actual signals.

Use five gates, not one launch-day checklist

A migration is ready only after it passes five gates.

1. Scope gate: Everyone agrees on exactly what will change and what must remain stable.

2. Mapping gate: Every valuable old URL and asset has a recorded destination or intentional retirement status.

3. Parity gate: The new site preserves the page purpose, content, metadata, internal relationships and technical signals you intend to keep.

4. Launch gate: Redirects, access controls, DNS and tracking switch in a controlled sequence with named owners.

5. Evidence gate: Your team can see whether Google and users are reaching the correct new pages and can diagnose deviations by URL group.

These gates prevent a common failure: a project appears “SEO complete” because somebody uploaded a redirect file, even though the new templates still contain noindex, canonicals point at staging, product copy is missing, or navigation no longer links to important categories.

1) Define the migration before development locks it in

Write a short migration charter before building or approving the new information architecture. It should name:

• the business reason for the move;

• domains, protocols, hosts, folders, page types and assets affected;

• systems changing, including CMS, analytics, consent, CDN and checkout;

• elements explicitly staying stable;

• launch window and business blackout periods;

• decision owners for content, SEO, development, infrastructure and analytics;

• approval criteria and stop-launch conditions; and

• rollback options for infrastructure and application failures.

Then list the variables you can separate. A Kenyan retailer moving from an old domain to a new ecommerce platform may want a new brand, new URL structure, new design and rewritten product catalogue on the same day. That gives the team four overlapping causes for every post-launch loss. A safer programme may deploy and test the platform on the existing domain, then move the domain after the templates and transactions have stabilised.

You cannot always separate the work, but you can always make the scope explicit. Record the migration date in analytics and retain the release version or deployment identifier. Without that record, teams often compare the wrong periods or blame an algorithm update for a deployment defect.

2) Build a baseline that can expose losses

A total organic-traffic line is too blunt for migration control. One directory can disappear while branded homepage traffic hides the loss. Build a baseline by page type and URL group.

Crawl and classify the existing site

Export URLs from more than one source:

• the current XML sitemap;

• a crawler that follows internal links;

• CMS, product or database exports;

• Google Search Console landing-page and indexing data;

• analytics landing pages and conversions;

• server logs, where available;

• backlink data for externally linked pages; and

• important PDFs, images, feeds and other non-HTML assets.

No single source represents the whole site. A sitemap can omit an orphan page that still earns visits. Analytics can miss a crawlable URL that receives no sessions. A crawler cannot discover a page with no internal links.

Add decision fields to the combined inventory:

Snapshot more than rankings. Save Search Console performance by query, page, country and device; current index coverage; analytics landing pages and goals; top external links; sitemap counts; and a crawl of titles, descriptions, headings, canonicals, robots directives, status codes, structured data and internal links.

For a Kenya-focused site, segment Kenya in Search Console where the data volume allows it. Also preserve device splits: a template that works on desktop but hides key mobile content can damage the audience that matters most without producing an obvious site-wide failure.

3) Turn the URL map into a disposition register

The URL map is the operational centre of a URL-changing migration. It should account for each relevant old URL using one of five decisions:

• Retain: the public URL stays exactly the same.

• Redirect: the old page has a direct, close replacement.

• Merge: several old pages consolidate into one destination that genuinely satisfies their intent.

• Remove: no suitable replacement exists, so the old URL returns 404 or 410.

• Investigate: ownership, duplication or destination remains unresolved; this blocks launch for valuable URLs.

Do not map by convenience alone. Redirecting every retired product, article or service page to the homepage gives users an irrelevant destination and can look like a soft 404. Map a discontinued product to a true successor or a useful category only when that page answers the same underlying need. Otherwise, remove it honestly and repair internal links.

Resolve mapping conflicts explicitly

Suppose three old pages target “office cleaning Nairobi,” “commercial cleaners Kenya” and “office cleaning prices.” A new generic cleaning-services page may not preserve all three purposes. Before merging them, decide whether the new page covers location, commercial service scope and pricing intent. If it does not, retain distinct destinations or strengthen the planned page.

Treat the map as version-controlled project data. Require approval for bulk rules, and generate redirects from the approved register where possible. A pattern such as “replace /old/ with /new/” can save time, but only after testing exceptions, encoded characters, uppercase paths, parameters, trailing slashes and files.

Protect high-value and externally linked assets

Prioritise pages with search demand, conversions, strong external links or important internal roles. Include linked PDFs and images if their URLs change. Contact the owners of your most valuable external links after launch and ask them to update the destination; the redirect remains necessary, but a direct link reduces dependence on an intermediary.

4) Build the new site for parity before improvement

A migration can improve a site, but first prove that the new system carries forward what you intend to preserve. Compare representative old and new pages for every template rather than inspecting the homepage alone.

Check:

• primary copy, headings, tables, media and downloadable assets;

• title tags and meta descriptions;

• meta robots and X-Robots-Tag directives;

• self-referencing canonical URLs on the final host;

• hreflang annotations and return links where used;

• structured data and the visible content that supports it;

• breadcrumbs, navigation and contextual internal links;

• pagination, filters and parameter behaviour;

• mobile content and controls;

• forms, checkout and other conversion paths; and

• rendered HTML when JavaScript supplies important content or links.

This does not mean freezing weak content forever. It means separating deliberate improvement from accidental loss. If you shorten a service page, change its purpose or merge it with another page, record that editorial decision in the disposition register. Do not let a template migration silently make the decision for you.

Keep staging private without carrying the block into production

Protect staging from public indexing through authentication or access controls. Teams also use robots rules or noindex while testing, but these controls become dangerous when copied into production.

Add explicit launch tests for:

• production robots.txt;

• page-level meta robots;

• HTTP X-Robots-Tag headers;

• authentication and firewall rules;

• canonical hostnames; and

• links or asset URLs containing a staging domain.

Do not rely on memory to remove them during the launch.

5) Engineer direct, permanent redirects

For a permanent URL move, Google recommends server-side permanent redirects such as 301 or 308. Each important old URL should resolve directly to its final relevant destination.

Avoid chains:

old.example/page -> www.old.example/page -> new.example/section/page -> new.example/page

Prefer:

old.example/page -> new.example/page

Chains add latency, complicate debugging and create more failure points. They often appear when teams layer a new migration on top of historical redirect files without resolving every old source to the newest destination.

Test more than the status code. For each sample, verify:

1. the old URL returns the intended permanent redirect;

2. the Location header points to the exact approved destination;

3. the chain reaches the destination in one hop where possible;

4. the destination returns a valid 200 response;

5. the destination contains the expected page, not a generic error template; and

6. query parameters are retained, removed or transformed intentionally.

Google states that permanent redirects do not cause PageRank loss. That does not make every mapping good. A technically correct 301 to an irrelevant page fails the user and may not support meaningful consolidation.

Keep migration redirects as long as possible. Google's site-move guidance says generally at least one year; old external links, bookmarks and printed materials can justify keeping them indefinitely. Do not delete the old domain while it still needs to serve redirects.

6) Align every canonical and discovery signal

Redirects are strongest when the rest of the site agrees with them.

On the new site:

• use self-referencing canonicals on final indexable URLs;

• update internal links so they point directly to final URLs;

• update hreflang URLs and return annotations;

• include only preferred canonical URLs in the new XML sitemap;

• use absolute URLs in the sitemap;

• update structured-data URLs, Open Graph fields and feeds where relevant;

• remove staging and legacy hosts from templates and configuration; and

• repair links that still pass through redirects.

A sitemap helps search engines discover the new URLs, but Google does not guarantee crawling or indexing merely because a URL appears there. Submit the new sitemap after launch and watch its processing. Google says the old sitemap can then be removed, although you should retain your exported pre-migration records.

If a page remains outside the index after launch, use the diagnostic sequence in Why Google Is Not Indexing Your Website. First determine whether Google can discover and fetch the final URL, then inspect rendering, directives, canonical selection and page value.

7) Prepare Search Console and measurement before launch

Verify access before you need it. For a domain move, verify the old and new Search Console properties, including relevant variants. A Domain property can aggregate protocols and subdomains, while URL-prefix properties help when you need a specific segment.

Use Search Console's Change of Address tool after the permanent redirects are active for a supported domain or subdomain move. It does not replace redirects. Google says not to use it for HTTP-to-HTTPS changes, path-only moves, www/non-www changes, or hosting/CDN changes where public URLs remain the same.

Also prepare:

• analytics and tag-manager code on every production template;

• conversion tests that do not pollute reporting;

• consent behaviour where applicable;

• campaign annotations and release timestamps;

• uptime and error monitoring;

• access to DNS, CDN, application and server logs; and

• dashboards split by old/new host, directory and page type.

You can use Glarify to organise Search Console, Coverage, Indexing and Sitemaps views around the migration. Treat it as a workspace for comparing URL groups, not as proof that redirects or recovery are correct. The underlying evidence still comes from live HTTP tests, rendered pages, logs, analytics and Search Console.

8) Handle a hosting or CDN move differently

If URLs do not change, you do not need a URL redirect map or Change of Address. Your main risk moves to infrastructure.

Google's guidance for a hosting move without URL changes supports this sequence:

1. Prepare the new host and copy the site.

2. Test the new infrastructure before public DNS changes, including whether Googlebot can access it.

3. Lower DNS time-to-live in advance where your DNS plan and provider make that appropriate.

4. Update DNS records in the launch window.

5. Monitor traffic and logs on both old and new hosts.

6. Keep the old infrastructure available until traffic has shifted and the new system is stable.

Check TLS certificates, firewall and bot controls, CDN cache rules, compression, headers, timeouts and origin capacity. A browser loading the homepage once does not prove that Googlebot, mobile users, API-backed pages and long-tail URLs receive the correct response.

9) Run a pre-launch acceptance test

Sample every template and every migration rule, but test all high-value URLs. A defensible acceptance run covers four layers.

Access and response

• Production-like pages return the intended HTTP status.

• Robots rules, authentication and security systems permit required crawling.

• Redirect rules work without loops, mass homepage mappings or unnecessary chains.

• Error pages return real 404 or 410 responses.

Content and signals

• Primary content appears in rendered output.

• Titles, descriptions, headings, canonicals, robots directives and structured data match the plan.

• Mobile pages preserve essential content and internal links.

• Sitemaps, hreflang and pagination use final URLs.

Discovery and journeys

• Navigation, breadcrumbs, related content and body links resolve correctly.

• No internal link points to staging, an old host or a redirecting URL.

• Forms, search, login, checkout and lead tracking work.

• Important orphan pages receive a valid discovery route or leave the index intentionally.

Measurement and operations

• Search Console access exists for old and new properties where needed.

• Analytics receives page views and conversions without duplication.

• Monitoring alerts reach a named owner.

• Backups, deployment reversal and redirect-file restoration have been tested or documented.

Record the result, tester, date and build identifier. “Checked” is not evidence unless the team can identify what it checked and against which expected output.

10) Use a controlled launch sequence

The exact order depends on your stack, but a URL-changing launch normally follows this logic:

1. Freeze untracked content and URL changes.

2. Take final database, configuration, crawl and analytics snapshots.

3. Deploy the approved production build.

4. Remove staging-only access and indexing restrictions from production.

5. Activate tested redirects from every old URL to its final destination.

6. Verify representative old and new URLs from outside the development environment.

7. Confirm canonicals, internal links, robots rules, sitemaps and tracking on the live host.

8. Submit the new sitemap in Search Console.

9. Use Change of Address if the domain move qualifies.

10. Start enhanced monitoring and record every hotfix.

Run the highest-value tests first: homepage, primary service or category pages, major landing pages, top organic entries and conversion journeys. Then test a stratified sample across every template and redirect rule.

Stop or roll back an application or infrastructure release when users cannot reach the site, core templates return widespread errors, primary content fails to render, checkout or lead capture breaks, or redirect rules create loops and broad misrouting. A domain move is harder to reverse than a code deployment; any reversal needs its own redirect and communication plan. Do not improvise alternating redirects between two hosts.

11) Monitor the migration by evidence and URL group

Monitoring should answer three questions: Can users and crawlers reach the new site? Are the right URLs becoming the selected versions? Are search demand and business outcomes transferring by page type?

Immediately after launch

Watch uptime, DNS resolution, TLS, 5xx errors, redirect loops, blocked resources, analytics, forms and server capacity. Crawl the old URL list and compare every result with the approved map.

During the first days

Inspect Googlebot activity in server logs, Search Console sitemap processing, indexed-page patterns, selected canonicals and important URL Inspection samples. Repair internal links and template errors quickly. Compare old and new hosts separately.

Over subsequent crawl and indexing cycles

Compare clicks, impressions, queries, landing pages, conversions and index status by directory and page type. Look for a coherent transfer from old URLs to new ones rather than waiting for one site-wide percentage.

Keep monitoring until old-URL crawling has declined, important new URLs have been discovered and selected as intended, redirect errors have stabilised at an acceptable level, and performance differences have an explained cause. There is no honest universal recovery deadline.

12) Diagnose a post-migration traffic drop in the right order

Start with the earliest failed dependency. This prevents you from rewriting content while the server is blocking crawlers.

Compare like with like: same country, device, page group and seasonally relevant period. Account for promotions, stock changes, demand shifts, manual actions, security incidents and search updates. The migration date creates a strong hypothesis, not automatic proof.

When you find a defect, repair the underlying rule and retest the entire affected group. If one product redirect used a faulty pattern, checking only that product can leave thousands of related URLs broken.

13) Know when to repair, roll back or accept the change

Not every decline requires a full reversal.

Repair forward when the new platform is stable and the problem is specific: missing canonicals, incorrect redirect targets, stale internal links, omitted content or a blocked resource. Correct the template or rule, retest affected groups and annotate the change.

Roll back the deployment when site-wide availability, rendering, transactions or crawl access fail and the previous application can be restored cleanly. Preserve evidence before rolling back so you can reproduce the failure.

Accept an intentional loss when you deliberately removed weak, duplicate or obsolete pages. Judge the move against qualified demand and business outcomes, not the old raw URL or traffic count. The disposition register should explain this expected difference before launch.

A hypothetical Kenyan migration

Consider a hypothetical Nairobi professional-services firm moving from oldbrand.co.ke to newbrand.co.ke while replacing a custom CMS. Its old site has 420 crawlable URLs, but the inventory finds:

• 160 current service, industry, location and article pages to preserve;

• 90 tag and filter variants that should not remain separate search pages;

• 110 obsolete articles without useful replacements;

• 40 pages that overlap and should merge into 15 stronger resources; and

• 20 URLs whose ownership needs investigation.

The team first deploys the new CMS on the old domain and checks content, metadata, structured data, navigation, mobile output and conversion tracking. After that platform stabilises, it maps the 160 retained pages directly, maps the 40 merged pages to their 15 evidence-backed destinations, lets the 110 obsolete URLs return 410, resolves the remaining 20 and launches the domain move.

It verifies both domains in Search Console, activates one-hop redirects, submits the new sitemap and uses Change of Address. Reporting separates service, location and editorial URLs, so a location-template defect cannot hide behind stable branded homepage clicks.

The numbers are illustrative, but the operation is real: classify first, preserve page purpose, separate major changes where possible, and measure groups that share the same migration rule.

SEO migration master checklist

Scope and ownership

• Migration reason, affected systems and unchanged elements are documented.

• SEO, content, development, infrastructure, analytics and approval owners are named.

• Major changes are separated where practical.

• Launch, stop-launch and rollback criteria are agreed.

Inventory and mapping

• URLs from sitemaps, crawls, CMS, analytics, Search Console, logs and backlinks are combined.

• Important pages and assets have performance and ownership data.

• Every old URL is marked retain, redirect, merge, remove or investigate.

• Valuable URLs have approved, intent-matched destinations.

• Redirect rules cover exceptions and avoid mass homepage mappings.

New-site parity

• Primary content, metadata, headings, media and structured data are compared by template.

• Mobile and rendered output preserve essential content and links.

• Production canonicals, robots directives and hreflang are correct.

• Internal links and sitemaps use final URLs.

• No staging host, authentication or noindex control leaks into production.

Launch

• Final backups, crawls and measurement snapshots exist.

• Direct permanent redirects return the approved destinations.

• DNS, TLS, CDN, firewall and server capacity are ready.

• Analytics and conversion paths work.

• New sitemap is submitted.

• Change of Address is used only for a supported domain move.

Evidence and response

• Old and new URLs are crawled against the approved map.

• Search Console, logs, analytics and uptime are monitored by URL group.

• Errors and hotfixes have named owners and timestamps.

• Ranking and traffic changes are diagnosed from access through conversion.

• Redirects remain available for at least the recommended period and longer where users need them.

Decide whether you need an independent migration review

You can manage a small, well-documented migration internally when the URL set is limited, the team controls the stack and the acceptance tests are clear. Independent review becomes more valuable when you are changing domains, merging sites, replacing a JavaScript framework, moving a large catalogue, handling several language versions or launching without reliable crawls and logs.

Start with the free Amplify SEO Scorecard to identify broad technical and visibility risks. If the move involves complex URL mapping, conflicting signals or a post-launch loss, an Amplify SEO audit can examine the affected templates and URL groups in context.

The essential discipline is simple: account for the old site, define the intended new state, test the relationship between them, and keep enough evidence to explain what happens after launch.