B2B Website Migration

Seven Projects That Share One Word

A website migration is any change that alters the URLs a search engine has indexed, the infrastructure serving them, or the identity of the site as search engines understand it. That definition covers projects with almost nothing in common.

Type	What changes	Principal risk
Domain change	Hostname; every URL	All signal transfer rests on the redirect map
Rebrand	Domain, naming, often URLs	Brand queries and links point at a retired name
Redesign, same URLs	Templates and content	Content that earned the rankings gets cut
CMS or platform change	URL patterns, rendering	Pattern changes; JavaScript dependencies
HTTP to HTTPS	Protocol	Mixed content; both protocols left live
International consolidation	ccTLDs merged	hreflang clusters and canonicalisation
Post-merger consolidation	Two sites become one	Competing pages and two link profiles

These risks differ in kind, not degree. A protocol change is largely mechanical. A post-merger consolidation is an editorial project with a technical component, because somebody has to decide which of two overlapping pages survives.

Why the Downside Runs Only One Way

A corporate site's organic value concentrates in a few pages — a specification page, a handful of technical explainers, a documentation section — that have accumulated inbound links for ten or twenty years from suppliers, trade bodies, universities and journalists. Those links cannot be rebuilt on request, and budget does not replace them.

The lag makes it worse. A loss in March surfaces as a pipeline shortfall in the fourth quarter, long after the launch was declared a success, when causation is contested and the people who would fix it have other work.

Two conclusions follow. If the only reason to change domain is that someone prefers the new name, the search cost is real and the benefit is aesthetic. And never combine a domain change, a platform change and a redesign in one launch: when traffic falls you will not know which caused it. Stage them, with weeks of clean measurement between.

A Project With a Plan, Not a Launch Date

Migrations fail when the date is fixed first and the work is fitted around it. The plan starts with an inventory, assembled from every source, because no single source is complete.

A full crawl of the live site, every XML sitemap, and the CMS URL export.
Server access logs — the only source showing what is actually requested, including URLs no crawler finds.
Analytics landing pages over twenty-four months, not twelve, so long-cycle pages appear.
Search Console pages and queries, and a referring-domain export so link-bearing URLs are identified individually.

Against each URL record entrances, conversions, ranking queries, referring domains, and whether anything you control still links to it. That table is the specification, the test plan and, if the launch goes badly, the evidence.

The redirect map is built from it: one-to-one wherever a genuine equivalent exists, and to the nearest true equivalent — usually a section page — where one does not. Redirecting wholesale to the homepage is the most reliable way to destroy accumulated equity, because it states that none of those pages has a counterpart. Keep the map in version control.

What Google Documents About Redirects, and What It Does Not

Stated as Google states it, because imprecision here produces bad decisions.

Permanent: 301 (Moved Permanently) and 308 (Permanent Redirect). Google shows the redirect target in results and treats the redirect as a strong canonicalisation signal toward it.
Temporary: 302 (Found), 303 (See Other), 307 (Temporary Redirect). Google shows the source page and does not treat the redirect as indicating a new canonical.
Meta refresh is treated by delay: 0 seconds as permanent, greater than 0 seconds as temporary.
Method: server-side redirects are ranked most reliable, then meta refresh, then JavaScript.
Hops: by default, Google's crawlers follow up to 10 redirect hops. Google Inspection Tools do not follow redirects at all, so a URL Inspection result on a redirecting URL is not a test of the redirect. Content from the redirecting URL is ignored; the target's content is processed.
Duration: keep the redirects for as long as possible, generally at least 1 year.

Google documents the ten-hop limit but not the consequence of exceeding it; claims about that are practitioner inference.

On link equity, be precise. Google's redirects documentation does not mention PageRank or link equity at all. Its site-move documentation says keeping redirects for at least a year allows Google to transfer signals to the new URLs, including recrawling and reassigning links from other sites — so signals transfer, unquantified. The claim that 301s lose no link equity traces to a 2016 remark by Google's Gary Illyes on Twitter, not to documentation. Promise nobody a percentage.

Change of Address, Canonicalisation, and Two Clocks

Search Console's Change of Address tool tells Google about a move from one domain to another. Its prerequisites are strict: you must own both properties in the same Google account, both must be domain-level rather than path-level, and the 301 redirects must already be live before you submit.

Its scope is narrower than assumed. It covers all paths under the domain and both protocols, but not subdomains, including www variants. It cannot be used for HTTP to HTTPS, for path changes within one domain, or for a www to non-www switch. It has not been retired.

Two clocks run at different speeds: Google maintains the migration relationship for 180 days after you start it in Search Console, while the redirects should stay at least a year, and in practice for as long as you hold the old domain. The tool accelerates the move; the redirects do the work.

Underneath is canonicalisation, where Google ranks redirects and rel=canonical as strong signals and sitemap inclusion as weak, and states that indicating a canonical preference is a hint, not a rule. Where the outcome must be deterministic, redirect.

DNS, Certificates, and Measurement Continuity

TTL. Google documents lowering DNS TTL values at least a week before a move.
Certificates. The certificate must cover every hostname that will be requested: apex, www, every subdomain, and the old domain, which still has to terminate TLS to serve its redirects. An expired certificate on a retired domain breaks the whole redirect chain, silently.
Access controls. Confirm the new host's firewall and denial-of-service protection do not block Googlebot; verify with the URL Inspection tool.
Staging controls removed. Delete the test environment's robots.txt disallow rules and any noindex tags. A site-wide noindex shipped to production is the most expensive two-word error in this discipline.
Search Console. Preserve verification, and add every property variant — both protocols, www and non-www, each subdomain — before launch rather than after.

Measurement continuity matters as much, because a migration you cannot measure cannot be diagnosed. Keep the same analytics property where the business is continuous; a fresh property makes before and after incomparable at the moment comparison matters. Keep event names identical, port the consent-mode configuration, re-test every conversion tag against the new templates, update final URLs in the ad platforms, and annotate the launch date.

The Monitoring Window, and the Order to Diagnose In

Decide before launch what would count as a problem. In the first forty-eight hours, read the server logs — is Googlebot receiving 200s and 301s rather than 404s and 500s? Request every URL in the old inventory programmatically and record the status code and final destination, because spot-checking in a browser proves nothing; a browser follows chains invisibly. Over the following weeks, watch index coverage on both properties, crawl statistics, impressions and queries by page, and Core Web Vitals on templates that just changed. Google documents that most pages on a small-to-medium site move within a few weeks and that fluctuation is normal, which is why abnormal must be defined in writing beforehand.

When it has already gone wrong, the order matters more than the tooling. Most failed recoveries begin at step five.

Indexability. robots.txt, meta and header noindex directives, canonical tags left pointing at staging or the old domain, and status codes on templates rather than the homepage alone.
Redirects. Request every old URL and record final status and destination. Look for 404s, 302s where 301s were intended, chains, loops, and everything resolving to the homepage.
Content parity. Did the pages that earned the rankings survive as content? Redesigns cut specification tables and long explanatory sections. A redirect to a page that no longer answers the query is not a preserved page.
External signals. Change of Address submitted where it applies; the highest-value inbound links resolving through a single permanent redirect rather than a chain.
Only then rankings and content quality. Attribute nothing to an algorithm update until the first five are demonstrably clean.

If the redirects were removed because someone judged the migration finished, restore them; that is often the entire fix.

Frequently Asked Questions

How long does it take to recover traffic after a website migration?

Google documents that a small-to-medium site typically takes a few weeks for most pages to move and that fluctuation is normal. A clean migration should look substantially normal within weeks.

The distinction that matters is between settling and defect. A migration with a real defect — a stray noindex, a broken redirect pattern, content removed in a redesign — does not recover with patience. Work the diagnostic order instead of waiting longer.

Do 301 redirects lose link equity?

Precisely: Google's redirects documentation does not address PageRank or link equity at all. What Google does document is that a permanent redirect — 301 or 308 — is a strong canonicalisation signal toward the target, and that keeping redirects in place for at least a year allows Google to transfer signals to the new URLs.

The claim that 301s lose no link equity traces to a 2016 statement by Google's Gary Illyes on Twitter, not to documentation.

How long should we keep redirects in place after a migration?

Google's documented instruction is to keep the redirects for as long as possible, generally at least 1 year. In practice, keep them for as long as you hold the old domain — a redirect rule costs nothing to maintain.

Two clocks are involved. The Change of Address tool maintains the migration relationship for 180 days; the redirects themselves are what moves signals.

Can we redirect all our old URLs to the new homepage?

No. A redirect to the homepage tells a search engine the old page has no equivalent, so the relevance that page built — the queries it answered, the links pointing at it — has nowhere to go. It also delivers a visitor who clicked a specific result to a page that does not answer their question.

Map one-to-one where a genuine equivalent exists, and to the nearest true match where none does.