Site Migration Failures: Causation and Evidence

Q: What is the difference between a 301 and a 302 in a migration case?

A 301 is a permanent redirect, and Google's indexing pipeline treats it as a signal that the redirect target should become the canonical URL, so the target inherits the old URL's standing. A 302 is temporary and is not used as that signal. In practice, a site-wide 302 issued where a 301 was intended is one of the most common defects in these matters, and it is usually a platform or edge default rather than a deliberate choice. It is also easy to prove either way from a crawl.

Why a migration is the cleanest causation case in search

Most search-visibility disputes founder on the same problem: nobody can point to a day on which something changed. A migration is the exception — a discrete, dated event, performed by an identifiable party, measured against a standard that was public before the work began. Google has documented moving a site with URL changes for years, and archived versions establish what it said on the launch date.

A migration is any change to the URLs a site serves or the host serving them: a domain change, a move from http to https, a replatform onto a different content management system, a redesign that alters URL structure, or a consolidation of several sites into one. A redesign leaving every URL untouched is not a migration in this sense.

I have been retained to recover sites after failed migrations often enough to say this plainly: the redirect map is almost never the only problem. It is what everyone examines first because it is the most visible, and when it is fixed the site is frequently still down — staging directives still in place, canonical tags still naming a hostname that no longer resolves, navigation still three hops from its destination.

The baseline nobody captured

The first question in a migration matter is whether the party doing the work captured a pre-migration baseline. Where none exists, the standard-of-care question is largely answered before the technical analysis begins: there is no defensible way to verify a migration succeeded without a record of the site before it.

A competent baseline is a specific list, not a sentiment. Google's documentation identifies the sources of the legacy URL inventory: sitemaps, server logs, analytics data, link reports, and CMS records. On top of that inventory the record should hold a Search Console Performance export by page and by query; a Page Indexing export with status counts by reason; ranking positions for the priority query set; a server log sample showing Googlebot crawl volume and status codes; a full crawl capturing status codes, canonical tags, hreflang annotations and robots directives; and a URL-level backlink export.

Note the window. Search Console retains sixteen months of performance data on a rolling basis, so if the “before” period is older than that when analysis begins, the first-party baseline does not exist unless somebody exported it contemporaneously.

Redirect types, chains, and the failure signatures

A redirect tells a browser or a crawler that requested content now lives at a different URL, and the type decides the outcome. A permanent server-side redirect — 301 or 308 — is used by the indexing pipeline as a signal that the target should be canonical, so the target inherits the old URL's standing. A temporary redirect — 302, 303, 307 — is not. A meta refresh at zero seconds is treated as permanent; with any delay, as temporary. A JavaScript redirect carries a permanent signal, but Google instructs using one only where server-side or meta refresh is impossible, because it waits in the render queue.

The most common defect I see is a site-wide 302 where a 301 was intended, nearly always a default — a load balancer setting, a framework helper, an edge rule written by someone who did not know there was a difference. It is also trivially provable: a crawl of the legacy URL set after launch either returns 301 or it does not.

Googlebot follows up to ten hops in a chain, and Google advises redirecting to the final destination directly, keeping chains ideally under three to five. Chains form when a protocol redirect, a host redirect, a trailing-slash redirect and the content redirect stack; loops appear in Search Console under “Redirect error.” Two further signatures repay testing: a mass redirect to the homepage, technically a 301 but frequently treated as a soft 404; and redirects removed too early, against Google's instruction to keep them at least a year.

Directives left on from staging, and canonical conflicts

The signature migration disaster is a staging directive that survives into production, and Google's migration documentation warns about it in terms: remove any noindex or robots.txt blocks needed only for the move.

Three mechanisms get confused, and the confusion generates more testimony than anything else here. A robots.txt Disallow — a rule in a text file at the top level of a host — prevents crawling, not indexing. A noindex rule — a <meta name="robots" content="noindex"> element or an X-Robots-Tag header — removes a page from the index, but only once it is crawled. And rel="canonical" — a <link> element naming which of several similar URLs should be indexed — is a signal, not a directive.

The trap is that the first two cancel each other. Google is explicit that for noindex to be effective the page must not be blocked by robots.txt and must otherwise be reachable. A page both disallowed and marked noindex stays indexed, because the crawler never reads the directive, and its fingerprint is the Page Indexing warning “Indexed, though blocked by robots.txt.” Note also that robots.txt governs only the host, protocol and port where it sits, so an https move needs its own file.

On canonicals, Google ranks its signals: a redirect is a strong signal that the target should become canonical, rel="canonical" is a strong signal for the URL specified, sitemap inclusion is weak. The documented mistakes are what to test for after a launch — conflicting canonicals set by different methods on one page, canonicals pointing at fragments, and relative rather than absolute URLs.

hreflang, internal links, parameters, and the edge

hreflang is an annotation declaring that a page has equivalents in other languages or regions, set in the HTML head, in a Link: HTTP header, or in sitemap elements. The rule that breaks in migrations is reciprocity: if two pages do not both point to each other, the tags are ignored. When one locale's URLs change and the others are not, the whole cluster is discarded and the wrong locale surfaces in each market — and a single-locale crawl shows nothing wrong.

Internal links and URL form. Google's guidance requires internal links on the new site to be updated using the mapping; leaving them pointed at redirected URLs creates a site-wide chain, measurable by counting internal links resolving to anything other than 200. Separately, /page and /page/ are different URLs, as are tracking-parameter variants unless canonicalized, and where the legacy server and the new stack handle them differently, duplicate URL sets appear in Page Indexing as “Duplicate without user-selected canonical.”

CDN and edge rules. Redirects implemented at a content delivery network rather than at the origin can differ from origin behavior, can be conditional on geography or device, and can be cached. The evidence is edge configuration exports with change timestamps, edge access logs and origin logs; comparing the last two is often what shows a redirect existed for users but not for Googlebot. A rule serving Googlebot differently from users falls inside Google's definition of cloaking, and an accidental one looks identical in the logs to a deliberate one.

Search Console configuration and the Change of Address tool

Each item here generates a dated first-party record showing whether the work was done.

Both properties verified across www and non-www and both protocols, with verification surviving the move — which a token embedded in the old site's HTML will not.
The disavow file re-uploaded to the new property, since it is property-scoped and does not travel with a domain.
The Change of Address request submitted after the redirects are live. Required for domain-to-domain moves, including subdomains and www variants; not needed for HTTP-to-HTTPS.
New sitemaps submitted, the old one retained temporarily so Google recrawls the old URLs and finds the redirects. Google states the resulting warnings are normal — which matters, because they get produced in discovery and characterized as proof of failure.

What a normal dip looks like and what a break looks like

Google's stated expectation is that a medium-sized site can take a few weeks for most pages to move in the index, and that larger sites take longer depending on server speed and URL count. No Google documentation states a maximum recovery period, and I would not offer one: an expert who testifies to a fixed recovery benchmark will be asked for the source and will not have one.

The distinction that holds up is not the depth of the drop. It is whether the curve returns to trend once the crawl completes. A properly executed migration produces a short, shallow dip and recovery; a failed one produces a step change that does not recover. Establishing that the crawl actually completed — server logs showing Googlebot fetched the redirect set, Page Indexing showing old URLs moving to “Page with redirect” — is what separates “Google has not caught up yet” from “the migration broke.” Skip it and the two hypotheses are indistinguishable.

Be candid about the confound as well. Core updates run often enough that a launch inside an update window is common rather than exceptional, and the analysis has to address that overlap directly against Google's dated record of when updates ran.

Proving the failure was foreseeable and preventable

A bad outcome is not by itself a claim. What converts one into the other is that the risk was documented, public and avoidable on the launch date — which is why the foreseeability record deserves the care given the technical findings.

The published standard was public before launch. Google's site-move documentation with its retrieval date, plus archived prior versions establishing what it said when the work was performed.
The scope of the engagement. Whether the contract or statement of work listed a redirect map, a pre-launch crawl, and removal of staging directives. A scope promising a redirect map is a different matter from one that did not.
Change history. Ticketing, version control, deploy logs and edge rule timestamps.
Contemporaneous warnings. Email and chat in which somebody raised the risk before launch. These frequently decide the question and are rarely inside the technical production.
Google's own alerts. Search Console messages and Page Indexing errors accumulating after launch, which also fix the date the defendant knew.

Two of those five are technical and three are documents. An opinion built from a crawl alone is answerable; one tying crawl findings to the scope of work, the deploy log and the pre-launch warning is much harder to move. References: Google's site move documentation, its guidance on redirects, and the robots.txt specification.

Frequently Asked Questions

Can an expert prove a site migration caused a traffic loss?

Causation here is provable to a higher standard than in most search disputes, because the launch is a fixed date and the defects are mechanically testable. The analysis compares the legacy URL inventory against post-launch behavior, shows which URLs returned which status codes and when, and demonstrates from server logs that Googlebot actually processed the redirect set. What still has to be addressed is whether a concurrent algorithm update or a contemporaneous business change explains part of the movement. An opinion that ignores that overlap invites exclusion.

What is the difference between a 301 and a 302 in a migration case?

A 301 is a permanent redirect, and Google's indexing pipeline treats it as a signal that the redirect target should become the canonical URL, so the target inherits the old URL's standing. A 302 is temporary and is not used as that signal. In practice, a site-wide 302 issued where a 301 was intended is one of the most common defects in these matters, and it is usually a platform or edge default rather than a deliberate choice. It is also easy to prove either way from a crawl.

What records should be preserved immediately after a failed migration?

Search Console Performance and Page Indexing exports for both the old and new properties, before the sixteen-month window rolls past the baseline period. Raw server logs from both origin and CDN. The redirect map or rewrite configuration in the form it existed at launch. Deploy logs, version control history, and edge rule change timestamps. Ticketing and chat records covering the pre-launch period. Full crawl exports of the site as launched. Analytics exports. Screenshots and archived copies fix what the pages looked like on given dates.

Does a defendant have a defense if the site eventually recovered?

Recovery goes to the damages period, not to whether a defect existed. Google's own expectation is that most pages on a medium-sized site move in the index within a few weeks and that larger sites take longer, so a shallow dip that returns to trend after the crawl completes is consistent with a competent migration. A step change that persists after the crawl demonstrably completed is not. The evidence that decides it is server logs and Page Indexing status transitions, not the shape of the traffic chart.

How does foreseeability change a migration claim?

It is usually what converts a bad outcome into a viable claim. The published guidance existed and was public before the launch date, which can be established with archived copies of the documentation. The remaining question is whether the party performing the work agreed to do the steps that guidance describes, and whether anyone raised the risk beforehand. The strongest records are the statement of work, the deploy log, and contemporaneous email or chat. Those are document questions, and they often sit outside the technical production.

Are staging directives really a common cause of migration failure?

Yes, and Google's migration documentation warns about it directly, instructing that any noindex rule or robots.txt block needed only for the move be removed. The failure is easy to demonstrate because it leaves a record: the directive appears in archived copies of the live site, in the crawl, and in Search Console's Page Indexing report as pages marked noindex or blocked by robots.txt. Where a page is both disallowed and marked noindex, neither works as intended, which produces its own distinctive reporting signature.

Can hreflang problems cause a loss that a normal audit misses?

They can, and this is one of the few defects that is genuinely invisible without looking for it. hreflang annotations must be reciprocal: if two pages do not both point to each other, the tags are ignored. When one locale's URLs change in a migration and the other locales are not updated, the entire cluster is discarded and the wrong regional version surfaces in each market. A crawl limited to a single locale reports nothing wrong, which is why multi-market migrations need the annotation set checked as a whole.

Published 2026-08-11

Site Migration Failures