A site migration is the highest-risk event in an SEO campaign. Not because migrations are inherently damaging — done correctly, they're largely neutral and sometimes beneficial. But because the window in which mistakes cause irreversible damage is narrow, the mistakes are easy to make under deadline pressure, and the consequences are slow enough to develop that many teams don't recognise the damage until weeks after the migration goes live, when rankings have already deteriorated and the causal connection to the migration is less obvious.

The specific risk is link equity. Backlinks are the product of years of content, outreach, PR, and acquisition work. They're attached to specific URLs — not to domains, not to sites in the abstract, but to precise URL strings. When those URLs change or disappear during a migration without correct redirect implementation, the equity those links were delivering is interrupted. Some of it can be recovered. Some of it is gone. how link equity degrades when migrations aren't handled correctly when redirects are mishandled is not gradual — it can be immediate and significant for the highest-equity pages in the site.

Why Migrations Damage Link Equity More Than Most Teams Expect

The gap between how migration teams think about URL changes and how Google processes them is where most damage occurs. The developer's mental model is: 'We're moving the site to a new structure, we'll add redirects, users will be fine, job done.' The SEO's mental model should be: 'Every URL that has backlinks pointing at it is an equity endpoint. Every change to that URL without a correct redirect is a broken equity connection. And even correct redirects introduce a discount versus direct links.'

The practical consequences of this gap include: high-equity pages redirected to the homepage rather than an equivalent destination (because nobody tracked which old URLs had backlinks), redirect chains accumulating because migration redirects stack on top of previous ones, URLs that were in the index but not in the sitemap getting 404s because the redirect map was built from the sitemap not from the full crawl, and JavaScript-based redirects being implemented where server-side 301s were needed.

None of these mistakes require malice or incompetence to make. They require the absence of a systematic pre-migration audit process that treats link equity protection as a first-class requirement rather than an afterthought.

Phase One: The Pre-Migration Equity Audit

Before a single URL changes, the equity audit identifies exactly which pages carry link value worth protecting. This is the most important pre-migration task and the one most commonly skipped or done superficially. auditing which pages carry your most valuable link equity before moving at this stage means pulling the full backlink profile from Ahrefs, sorting by referring domain count and estimated link equity per page, and producing a ranked list of URLs ordered by the value of the backlinks pointing at them.

The Four Sources of the Redirect Map

The complete redirect map — the document that specifies every old URL and its new destination — must be built from four data sources combined, not any one of them alone:

• Full site crawl: Screaming Frog or equivalent crawling every URL on the current site, including parameter variations, paginated pages, and anything not in the sitemap. This catches every indexed URL that needs a redirect.
• Google Search Console URL inventory: The Coverage report shows every URL Google has indexed. Some indexed URLs won't appear in a crawl if they're orphaned pages with no internal links. The GSC coverage report catches these.
• Backlink profile export: Every URL appearing as a link destination in the backlink profile needs a redirect, regardless of whether it's in the sitemap or crawl results. High-value link destinations that aren't in the main site navigation are common — blog posts, resource pages, old landing pages — and they're exactly the URLs that get missed in deadline-pressured migration work.
• Google Analytics historical data: Pages that have received significant organic traffic historically, even if currently not in the top navigation, have likely attracted backlinks. The GA historic organic landing page report surfaces these.

Prioritising the Redirect Map

Not all redirects are equally important. The redirect map should be tiered by priority based on the equity at stake:

• Priority 1 — High referring domain count (10+ referring domains): These URLs must have exact, one-to-one destination mappings. A homepage redirect is not acceptable. The destination must be the most topically equivalent page on the new structure.
• Priority 2 — Pages with any referring domains plus significant historic traffic: Same standard as Priority 1 but for pages where link equity and traffic history both indicate value.
• Priority 3 — Indexed pages with no backlinks: Still need redirects to prevent 404s, but a category or parent page destination is acceptable rather than exact equivalents.
• Priority 4 — Indexed pages with no backlinks and no historic traffic: Redirect to the most relevant parent page. If no reasonable parent exists, a 410 (Gone) is preferable to a redirect to an entirely irrelevant page.

Phase Two: Technical Implementation Standards

The redirect map is only as valuable as the technical implementation that delivers it. Several implementation requirements are non-negotiable for equity preservation:

Server-Side 301s Only

Every redirect in the map must be implemented as a server-side HTTP 301 response — in .htaccess configuration, Nginx rules, CDN routing, or CMS redirect manager that generates server-level responses. JavaScript redirects, meta refresh tags, and canonical tags are not substitutes for 301s in a migration context. Canonical tags tell Google which URL to index but do not transfer equity from inbound links. JavaScript redirects are processed in Googlebot's deferred rendering queue with inconsistent results. Only server-side 301s reliably handle both user navigation and crawler equity transfer simultaneously.

No Chains

Redirect chains — where URL A redirects to URL B which redirects to URL C — are the most common technical problem in post-migration sites. They accumulate when a new migration's redirects stack on top of old ones that were never removed. Before the new migration goes live, every URL in the redirect map should be tested to confirm it resolves in a single hop. Screaming Frog's redirect chain report does this at scale. Any chain detected before launch should be collapsed to a single direct redirect from origin to final destination.

Internal Links Updated Simultaneously

Internal links throughout the new site should point directly to new URLs, not to old URLs that then redirect. Internal redirect following wastes crawl budget — Googlebot has to follow the redirect on every internal link visit rather than going directly to the destination. In aggregate across a large site, this can meaningfully reduce how many pages Googlebot processes per crawl session. Update all internal links to direct destinations as part of the migration, not as a follow-up task.

Sitemap Updated Before Launch

The XML sitemap submitted to Google Search Console should contain only new URLs before the migration goes live. Submitting a sitemap with old URLs after migration creates a confusing signal — Google is being told to crawl URLs that are now returning 301s. The sitemap should represent the current state of the site at all times, and at launch that means exclusively the new URL structure.

Phase Three: The 90-Day Post-Migration Monitoring Protocol

Migrations require active monitoring, not passive observation. The 90 days following a migration are the highest-risk period for undetected equity loss. fixing the indexation problems that cut off link equity flow post-migration is the first priority: the Coverage report in Search Console must be checked daily for the first two weeks and weekly for the following six weeks. New 404 errors appearing after migration indicate URLs that were not included in the redirect map — every 404 on a previously indexed page with backlinks is equity loss accumulating daily until the redirect is added.

Crawl Stats as an Early Warning System

The Crawl Stats report in Search Console shows daily crawl requests and average response times. A post-migration crawl pattern that shows consistent daily crawl activity at reasonable response times indicates Googlebot is processing the new structure normally. A pattern showing low request counts, high error rates, or declining activity indicates technical problems — redirect chains, server performance degradation under crawl load, or WAF configuration issues — that are preventing normal crawl behaviour. the metrics that confirm whether equity has transferred successfully for confirming post-migration link equity transfer include the appearance of the new URLs in GSC's links report within four to six weeks of launch. If the old domains that were pointing at your site before migration do not appear as linking sources to your new URLs within this window, investigate whether the 301 chain is functioning correctly.

Ranking Variance vs Baseline

Establish ranking baselines for all tracked keywords the week before migration. Normal post-migration behaviour includes some temporary ranking fluctuation in the first two to three weeks as Google re-crawls and re-evaluates the new structure. Fluctuations that persist beyond four weeks, or that affect primarily the highest-traffic keywords rather than being distributed across the keyword set, are signals that something specific went wrong — either a specific high-equity page's redirect mapping is incorrect, or there's a broader crawlability issue affecting how Google is processing the new structure.

When a Migration Has Already Gone Wrong

If you're reading this after a migration that produced ranking losses, the diagnosis process mirrors the pre-migration audit but in reverse. The immediate step is identifying every 404 error in GSC's Coverage report and cross-referencing them against the backlink profile. Any 404 URL with referring domains needs a redirect added immediately — this stops the ongoing equity loss even if it doesn't immediately recover the rankings that have already dropped. rebuilding rankings after a migration that went wrong covers the broader ranking recovery process including the timeline expectations for regaining positions after migration-related equity loss.

For sites that migrated and then invested in PBN backlinks or niche edit backlinks to rebuild link equity after the migration, the same redirect audit applies — links acquired post-migration need to point to correctly implemented URLs that are indexed and returning 200 status codes, not to URLs caught in redirect chains or returning intermittent errors. New link investment on a technically compromised site delivers diminished returns regardless of the quality of the links. free SEO and backlink advice is available for anyone navigating a migration-related ranking recovery. The SEO and backlink resource section covers the full range of post-migration link strategy considerations.

Migration as a Link Building Opportunity

One underappreciated aspect of pre-migration work is that the backlink audit required to protect equity is also the most complete picture of which pages have the most accumulated link value — and therefore the clearest guide to where new link acquisition should be directed. identifying which link sources in your profile are worth protecting is a natural companion to the migration audit: understanding both your own link equity distribution and which link sources your top competitors have built provides the strategic input for a post-migration link campaign that addresses the gaps the migration created while building toward the competitive positions that matter most.

A migration executed with proper link equity protection and followed by targeted link building to consolidated, well-structured pages is often a net positive for search performance — it resolves accumulated technical debt in URL structure, improves crawl efficiency, and creates the opportunity to redirect equity from legacy pages into a cleaner, more targeted architecture. The prerequisite is doing the pre-migration audit work that turns a potentially damaging infrastructure change into a strategically sound one.