What happens to rankings after a site migration

What actually happens when you migrate a site

A migration is any change that alters how Google sees your URLs. Moving to a new domain, switching from HTTP to HTTPS, changing your CMS, restructuring your folders, merging two sites into one. All of these tell search engines “the thing you indexed yesterday isn’t the same thing anymore,” even if the content on the page hasn’t changed at all.

That’s the part people underestimate. Google doesn’t know your new URL is the same page with a new address. It has to figure that out, and figuring it out takes crawling, comparing, and re-evaluating signals that were attached to the old URL. Rankings don’t transfer instantly because nothing transfers instantly. They get rebuilt.

I’ve moved sites in my own portfolio between domains, folded smaller sites into bigger ones, and rebuilt URL structures that were a mess from years of neglect. Every single time, there’s a dip. The question isn’t whether you’ll see one. It’s how deep it goes and how fast it closes.

The three things Google has to redo

When a URL changes, three separate processes have to happen before rankings settle:

Discovery. Google has to find the new URLs, either through your XML sitemap, internal links, or a redirect from the old address. If the new URLs aren’t linked anywhere and there’s no redirect, discovery can stall indefinitely.

Crawling and indexing. Once found, each new URL gets crawled and evaluated against the old one. If you set up a 301 redirect correctly, Google treats this as a strong signal that the new URL is the successor. Without a redirect, it’s treated as a brand new page with no history.

Signal consolidation. This is the slow part. Things like internal link equity, historical engagement patterns, and the site’s overall trust profile get reattributed to the new URL over a series of crawls, not in one pass. This is also the part where I have zero visibility into exact weighting, and neither does anyone selling you a migration service. Nobody outside Google can tell you precisely how these signals get recombined. What’s observable is the outcome: rankings wobble, then they don’t.

Why traffic dips even when you do everything right

This is the part that causes panic, and it’s also the part that’s normal. Even a technically flawless migration, redirects mapped one to one, sitemap updated, internal links fixed, will usually produce a period of ranking volatility. Some pages move up, some move down, and the net effect at the aggregate traffic level often looks like a dip before it stabilizes.

Part of this is mechanical. Google is re-crawling your site at whatever rate your crawl budget allows, and a large site with thousands of URLs doesn’t get fully re-crawled overnight. Part of it is that Google is genuinely re-evaluating the new URLs rather than blindly copying over the old rankings. A redirect is a strong hint, not a guarantee of identical treatment.

I don’t promise myself or anyone else a specific recovery window when I run a migration. I’ve seen small sites settle down quickly and larger, older sites take a lot longer to fully stabilize. The variance depends on site size, how often Google was already crawling it, how clean the redirect map is, and how much else changed at the same time. Anyone telling you migrations recover in a fixed number of weeks is guessing, and usually guessing in a way that’s convenient for a sales pitch.

Redirects: the part everyone gets wrong

The single biggest mistake I see, including mistakes I’ve made myself, is treating redirects as an afterthought instead of the core of the migration.

A few things that actually matter:

• Map every old URL to its closest matching new URL. Not to the homepage. A blanket redirect of every old URL to your new homepage tells Google those pages have no real equivalent, and you lose whatever ranking history they had.
• Use 301s, not 302s, for permanent moves. A 302 signals “temporary,” and search engines are cautious about fully consolidating signals onto a page that might revert.
• Avoid redirect chains. Old URL to new URL to newer URL is a chain. Each hop adds friction and can cause some of the equity to get lost or delayed in being recognized. Fix chains so every old URL points directly to its final destination.
• Keep redirects live for the long haul. Old links from other sites, bookmarks, and social shares keep hitting the old URLs for years. I’ve killed old redirects too early on past projects and watched isolated pages lose the traffic they’d rebuilt, simply because a redirect that was still catching real referral traffic got removed in a cleanup pass.

None of this is exotic. It’s just unglamorous, detail-heavy work that has to be done for every single URL, not just the ones with the most traffic.

What I check before I let a migration go live

Before I touch a live site, I confirm:

• A full crawl of the old site exists, so I have a real list of every URL, not just the ones I remember.
• Every URL on that list has a mapped destination, even low traffic pages and old blog posts.
• The new site’s internal linking points to the new URLs directly, not through the redirect. Internal links that still point at redirected URLs waste crawl budget and slow signal consolidation.
• The XML sitemap reflects the new URL structure and is submitted through Search Console.
• If it’s a domain change specifically, I use the change of address tool in Search Console, which exists precisely to tell Google “this is a full domain move” rather than leaving it to infer that from redirects alone.
• Canonical tags on the new pages point to themselves, not to the old domain.

Skipping any one of these doesn’t guarantee failure, but it adds friction to a process that’s already going to take time. I’d rather remove every avoidable source of delay than hope the important stuff resolves on its own.

Backlinks don’t move themselves

A redirect passes signal from an old URL to a new one, but it doesn’t rewrite the actual links pointing at you from other sites. Every external site still links to your old URL. The redirect is doing the work of forwarding that value, which is why redirect integrity matters so much.

Where I can, I reach out to update a handful of high value links directly to the new URL instead of relying on the redirect indefinitely. This isn’t required, and for most links it’s not worth the effort. But for the handful of links that matter most to a page’s rankings, a direct link to the live URL removes one layer of dependency on a redirect staying correctly configured forever.

I’ll say plainly that buying or renting links to smooth over a migration, or leaning on any kind of link network to prop up rankings during the volatile period, isn’t something I do or recommend. It doesn’t address what’s actually happening during a migration, which is Google re-evaluating existing signals, and it introduces risk that has nothing to do with the migration itself.

How long the volatility actually lasts

I won’t give a number here, because I don’t have one that’s honest. What I can tell you is what determines the range: how large the site is, how frequently it was already being crawled before the migration, how clean the redirect map is, and whether anything else changed at the same time, like content, site structure, or hosting.

Stacking multiple big changes into one migration, new domain and new CMS and a content rewrite all at once, makes it harder to diagnose anything that goes wrong, because you can’t isolate which change caused which movement. When I have the choice, I separate these changes and give each one room to settle before making the next one.

What kills a migration for good

The failures I’ve actually seen come down to a short list: redirects that were never implemented or implemented as blanket homepage redirects, internal links left pointing at dead old URLs, a change of address never submitted in Search Console, and content that got rewritten or deleted at the same time as the URL change, so there’s nothing for Google to match the new URL against.

None of these are algorithm mysteries. They’re execution failures, and they’re the reason migrations get a bad reputation. The mechanics aren’t secret. They’re just easy to get wrong at scale, and the cost of getting them wrong shows up in traffic you don’t get back quickly.

If you’re planning a migration and want a second set of eyes on the redirect map or the technical checklist before you flip the switch, that’s the kind of work we cover in depth on the channel and the site.

Head back to the home page for more on technical SEO, redirects, and the operational side of running sites that actually rank.