Migrating Your Site? Here's How to Not Lose Your Rankings

The problem

A migration changes URLs, and every changed URL breaks the link between the trust signals Google has accumulated for the old address and the content now living at the new one. A domain change (old-domain.com to new-domain.com), a platform migration (moving CMS or hosting stack), or a full redesign that restructures the URL hierarchy all do the same underlying damage if the redirect mapping is incomplete: search engines re-crawl the old URLs, find nothing (a 404) or a generic redirect to the homepage instead of the specific equivalent page, and treat the content as gone rather than moved. Rankings, indexed pages, and the internal link equity built up over years can all be lost in the same event — not because the new site is worse, but because the signal chain from old URL to new URL was never explicitly declared.

Symptoms of a migration gone wrong

• Organic traffic drops sharply in the days immediately after launch, well beyond the temporary dip that even a well-executed migration can briefly show while Google re-crawls and re-evaluates the new URLs.

• Search Console's Page Indexing report shows a spike in "Not found (404)" or "Page with redirect" errors for URLs that used to rank, meaning the old-to-new mapping never reached those specific pages.

• Previously ranking keywords disappear from position tracking entirely rather than shifting to a new URL, which usually means the redirect either doesn't exist or points somewhere irrelevant (commonly the homepage as a catch-all).

• Internal and external backlinks that pointed at old URLs now resolve to a 404 or an unrelated page instead of passing their link equity through to the new equivalent.

• Hreflang errors appear in Search Console's International Targeting report because the Arabic and English URL pair that used to reference each other correctly now points at a stale or missing counterpart post-migration.

Why it matters

A migration is one of the few events that can undo years of accumulated ranking signal in days, and the loss compounds: a dropped page loses its rankings, the internal links pointing at it lose their destination, and the backlinks other sites built to it stop passing equity — all from the same root cause. Because the damage is structural rather than content-related, it also doesn't self-correct the way a quality issue might; a URL that 404s stays 404 until someone builds the redirect, no matter how good the content living at the new address is. Treating migration SEO as a checklist item during planning, rather than a cleanup task after traffic has already dropped, is the difference between a migration that holds its rankings and one that needs months of recovery work afterward.

How we diagnose it

Before a migration, we crawl the existing site to produce a complete inventory of every indexed URL, its current rankings, its inbound internal and external links, and its canonical/hreflang/schema state — this becomes the baseline the new site has to account for, URL by URL, not just section by section. After launch (or when we're brought in to fix a migration already in progress), we diagnose the same way: cross-reference Search Console's Coverage and International Targeting reports against the pre-migration URL inventory to find exactly which old URLs never received a valid redirect, crawl the new site to check for redirect chains and broken hreflang pairs, and check whether canonical tags on the new URLs point at themselves correctly rather than a stale old-domain reference left over from a lazy migration script.

The fix

The fix is a redirect map that covers the full pre-migration URL inventory, not a sample of it — every old URL gets a single 301 redirect to its most relevant new equivalent (never a blanket redirect to the homepage, which discards the specific relevance signal Google associated with that page). Canonical tags, hreflang pairs, and schema markup are carried over and re-validated on the new URLs rather than assumed to survive the move automatically. Everything is crawl-tested end-to-end on a staging environment before the new site goes live, and Search Console is watched closely in the days after launch so a missed redirect or an unexpected canonical issue gets caught and fixed within days, not discovered a month later in a quarterly traffic report.

Implementation: a practitioner's migration checklist

URL mapping and 301 redirect strategy: build a spreadsheet-level map of every existing URL to its exact new-site equivalent before writing a single redirect rule — a domain change or platform migration that redirects by pattern-matching URL structure instead of an explicit map is how specific pages end up defaulting to the homepage. Every redirect should be a 301 (permanent), implemented in one hop, never chained through an intermediate URL. Preserving canonical tags through the migration: the canonical tag on each new URL must point at itself (the new URL), not at the old domain or old path — a canonical left pointing at a now-redirected old URL creates a conflicting signal (redirect says "go here," canonical says "no, index that") that can leave Google uncertain which URL to actually index. Preserving hreflang through the migration: this site's own EN/AR hreflang pairs (declared from the single shared mapping in page-mappings.ts) are exactly the kind of relationship a migration has to carry over deliberately — both the English and Arabic URL for a given page need to move together and keep referencing each other's new address, or the pair breaks and Search Console's International Targeting report starts flagging missing return tags. Preserving schema markup through the migration: structured data (Organization, BreadcrumbList, FAQPage, and any page-specific schema) should be re-implemented on the new templates and validated fresh, not assumed to have carried over just because the visible content did — a template change is exactly the kind of event that silently drops a JSON-LD block if it isn't explicitly checked. Staging environment crawl-testing before launch: crawl the staging site the same way a search engine would — full site crawl checking every redirect resolves in a single hop, every canonical is self-referential, every hreflang pair is reciprocal, and nothing on the new site is accidentally left disallowed in robots.txt or set to noindex from staging defaults. This is the single highest-leverage step in the whole process, because every issue caught here is an issue that never reaches production. A blue/green-style launch reduces migration risk: deploying the new site to an inactive slot, crawl-testing it there while the current live slot keeps serving real traffic unaffected, and only cutting over once the audit is clean is a materially lower-risk pattern than editing a live production site in place — the same principle this site's own blue/green deployment model applies to ordinary releases applies with even more force to a full migration, where a mistake is far more expensive to unwind. Monitoring Google Search Console post-launch: watch the Coverage report daily for the first two weeks for a spike in 404s or redirect errors, the Performance report for ranking and click-through changes by URL, and the International Targeting report for hreflang errors — catching a missed redirect on day three is a five-minute fix; catching it a month later after Google has demoted the page is a much longer recovery. Handling redirect chains: audit for any redirect that itself points to another redirect rather than the final destination (common when a URL has been migrated more than once over a site's history) and collapse every chain to a single direct hop — each extra hop both wastes crawl budget and dilutes the link equity passed through. Preserving internal link equity: update internal links across the site to point directly at the new final URLs rather than relying on redirects to carry old internal links forward — a redirect will get a user or crawler to the right place, but a direct link avoids the hop entirely and keeps internal link equity flowing without any dilution. A rollback plan: before cutting over, define exactly what "this migration failed" looks like (a defined threshold of broken redirects, a defined traffic drop, a defined error rate) and exactly how to revert — keeping the old site or slot reachable and the DNS/routing change easily reversible for a defined window after launch, so a serious problem can be undone in minutes rather than requiring an emergency rebuild. Timeline and phasing recommendations: a migration is not a single event but a sequence — build and validate the redirect map first, crawl-test staging second, launch during a low-traffic window third, then hold a heightened-monitoring period (we recommend a minimum of two to four weeks) before considering the migration complete. Migrating in phases (by section or by URL cluster) rather than all at once is worth considering on very large sites, since it limits the blast radius of any single mapping mistake and makes the cause of any traffic change easier to isolate.

Common mistakes

• Redirecting every old URL to the new homepage as a catch-all instead of building a specific old-to-new map — this discards the page-level relevance signal Google associated with each individual URL.

• Chaining redirects through an intermediate URL (old URL -> interim redirect -> final new URL) instead of a single direct 301, which wastes crawl budget and weakens the signal passed through each extra hop.

• Leaving canonical tags on the new site pointing at the old domain or old path, which conflicts with the redirect and leaves Google uncertain which URL should actually be indexed.

• Migrating the English URL set without migrating its Arabic hreflang counterpart on the same timeline, which breaks reciprocal hreflang pairs and triggers International Targeting errors in Search Console.

• Skipping a full crawl-test of the staging environment and instead spot-checking a handful of pages by hand, which reliably misses redirect gaps that only show up at full-site scale.

• Launching without a rollback plan, so a serious post-launch problem has to be fixed live under pressure instead of reverted cleanly within a pre-defined window.

Validation

We validate with a full crawl of the live new site confirming every mapped old URL now returns a single-hop 301, every canonical is self-referential, and every hreflang pair is reciprocal with no errors in Search Console's International Targeting report. We then track the Coverage report daily through the post-launch monitoring window, confirm indexed page count on the new URL set recovers to at least its pre-migration level, and check the Performance report by URL to confirm previously ranking pages are recovering position on their new address rather than losing it permanently.

Related service & solutions

A migration touches nearly every technical SEO fundamental at once — redirects, canonical tags, hreflang, and schema markup all have to survive the move intact, so this page is meant to be read alongside the dedicated implementation guides below and, for a full pre-migration or post-migration audit, our SEO Consulting service.