Website migration without avoidable SEO loss: redirects, testing and monitoring

A website migration is not one domain redirect. It transfers relationships between content, URLs, links, canonicals, XML sitemaps, analytics and search systems. When a team treats it as a visual launch completed on release day, defects surface only after customers and crawlers arrive.

No responsible plan can promise zero visibility fluctuation. Google warns that substantial URL changes can produce temporary movement while pages are recrawled and reindexed. What a team can do is remove avoidable faults, preserve user journeys and give search engines coherent signals. One rule organises the work: every important old URL needs an explicit decision and a testable outcome.

Name the migration before planning controls

The appropriate checks depend on what changes. Moving infrastructure without changing URLs presents a different risk from merging two domains while redesigning the information architecture.

Common migration types include:

• changing a domain or subdomain;
• moving from HTTP to HTTPS or between www and non-www;
• replacing a CMS, framework or rendering model;
• redesigning category and URL structures;
• merging several websites;
• removing, consolidating or splitting content;
• changing language, regional and hreflang arrangements.

Record simultaneous changes. The more layers changed in one release, the harder it becomes to attribute a ranking loss, conversion fault or increase in 404 responses. Where it is safe to separate a platform replacement from a content reorganisation, the test becomes clearer.

Build the old inventory before designing destinations

A redirect map is only as complete as its inputs. Gather old URLs from several sources: a current crawl, XML sitemaps, analytics, Search Console, the CMS and lists of pages with external links. No single source is guaranteed to contain the whole estate.

The sitemap inspector can help export URLs declared in XML. Merge the records and remove technical duplicates while retaining their source. Useful fields for each URL include:

• current status and canonical;
• page type and language;
• traffic, conversions and commercial significance;
• important internal and external links where data is available;
• intended destination or removal decision;
• content owner and approval state.

The inventory becomes the post-release test list. Without it, a team sees only defects that somebody happens to report.

Map by user intent, not URL similarity

The best destination is the new page serving the same user task. Do not redirect hundreds of removed products and articles to the homepage. Google warns that bulk redirects to an irrelevant destination may be treated as soft 404s, and the visitor still fails to find the promised information.

Each row in the map should receive one decision:

Google recommends permanent server-side redirects such as 301 and 308 for permanent moves. Avoid chains: the oldest known URL should go straight to the final destination rather than replaying the history of previous migrations.

Use the redirect chain checker for an individual route. A large map needs an automated suite that reports every status and destination, loops, chains and timeouts.

Prepare the new estate to receive users and signals

A redirect cannot repair a destination carrying noindex, blocked by robots.txt, declaring the wrong canonical or missing its useful content. Test production or the closest safe pre-production equivalent before launch.

Each new URL should:

• return the planned status and declare a self-referencing canonical;
• be reached through new internal links without a redirect;
• contain the intended content, title, heading and structured data;
• use new URLs in hreflang, media and social metadata;
• appear in the new XML sitemap when canonical and intended for indexation;
• preserve measurement of critical events and consent choices.

Do not copy a staging block into production, but do not remove it prematurely either. The release checklist should identify the exact moment for changing access controls, noindex, DNS, redirects and sitemaps.

For a multilingual site, test reciprocal hreflang relationships after URLs change. A correct redirect does not automatically rewrite annotations embedded in pages or sitemaps.

Define acceptance tests before launch

“We clicked a few pages” is not a migration test. Set measurable conditions:

• every approved old URL has its intended result;
• every redirect reaches its final destination in one hop;
• redirect targets return 200 and are indexable according to plan;
• no loops, long chains or irrelevant soft-404 destinations exist;
• canonicals, hreflang and sitemaps use the new URL scheme;
• navigation and content do not retain redirecting internal links;
• primary forms, search, authentication and purchase paths work;
• analytics recognises new hosts without unwanted self-referrals.

Prepare a rollback plan for technical failure, but do not confuse it with reversing a domain migration after the first reporting fluctuation. Rollback criteria should be agreed faults such as mass 5xx responses, loss of access or a broken payment path.

Keep a signed version of the mapping and generated redirect configuration. If rules are transformed for a server, compare their effective behaviour with the source table rather than assuming successful deployment means correct destinations.

Launch day begins the observation period

After release, run the full redirect suite and crawl the new estate. Compare counts, statuses, canonicals, robots directives and internal links with the plan. The broken link checker supports inspection of a particular page; a substantial website also needs collection-wide testing.

For a domain or subdomain move, verify old and new properties in Search Console and use the Change of Address tool where Google specifies it. The tool is not required for every path change, HTTP-to-HTTPS move or switch between www and non-www. Submit the new sitemap and monitor both URL sets as discovery and indexation transfer.

Google recommends retaining redirects for as long as possible, generally at least one year. Keeping them indefinitely can make sense for users while old links remain in circulation. Update first-party navigation, campaigns and profiles so that your own traffic does not continue through an unnecessary hop.

Monitor the system rather than one traffic line

Compare old and new evidence in layers:

1. availability: 4xx and 5xx errors, DNS, response time and server logs;
2. crawling: bot visits, discovery of new URLs and use of old ones;
3. indexation: submitted, indexed and excluded URL groups;
4. visibility: queries, pages, countries and devices in Search Console;
5. behaviour: landing pages, application errors and task completion;
6. business: enquiries, bookings, transactions and data quality.

Annotate the release date and preserve pre-migration exports. Year-on-year comparison can be more useful than week-on-week movement for a seasonal business. Check campaigns, stock, offer changes and demand before attributing every movement to migration.

Set alert thresholds before launch. A small expected decline in old indexed URLs is different from new commercial templates returning 500 errors. Separate leading technical signals from slower search outcomes so the team can respond without panic or false reassurance.

Make ownership part of the migration architecture

The URL map needs one accountable owner even when content, SEO, development, analytics and infrastructure contribute. Every exception should have a named decision-maker and a deadline. Otherwise, ambiguous pages become last-minute wildcard rules.

A useful control table includes the phase, check, owner, evidence, acceptance condition and response to failure. It turns launch from a collection of personal checklists into a shared release gate.

When the scope combines domain, CMS, architecture and analytics, my design and development services can connect the migration plan to implementation. You can also describe the estate, platform and target date to begin with the inventory and risk model rather than the redirect file alone.

Sources

• Google Search Central: Site moves and migrations
• Google Search Central: Redirects and Google Search
• Google Search Central: Build and submit a sitemap
• Google Search Console Help: Change of Address tool