What should you know about recovering your rankings after a domain change?

What does a domain change really imply from Google's perspective?

A domain migration is never just a simple administrative operation. For Google, it signals that the entire URLs of a site are changing addresses, requiring a complete overhaul of mapping in the index. 301 redirects inform the crawler that the content has permanently moved, while notification via Search Console speeds up the recognition of this change.

The problem is that this process is never instantaneous. Google must re-crawl the old domain, discover the redirects, follow the new URLs, reassess signals (backlinks, authority, user behavior), and redistribute rankings. If any link in this chain breaks — misconfigured redirects, insufficient crawl budget, conflicting canonical tags — ranking recovery can fail partially or totally.

Are 301 redirects enough to ensure the transfer of rankings?

In theory, yes. In practice, it's rarely that simple. 301 redirects transfer about 90-95% of PageRank according to field observations, but it is not an absolute guarantee that rankings will mechanically follow. Other factors come into play: how quickly Google detects and follows redirects, the quality of the new domain, and especially its history.

If the target domain has previously been used for spam, poor quality content, or has been penalized, Google may apply a form of distrust that slows down or blocks ranking recovery. This is where Mueller's statement makes complete sense: it's not just about technically migrating; you also need to ensure that the destination domain is clean.

Why does Google emphasize 'domain history'?

Because domains have a memory. A domain name that has been previously used can bear residual penalties, toxic backlinks, or simply a total lack of authority. Google does not start from scratch: it inspects the existing link profile, indexing history, and any past manual actions.

Specifically, purchasing an expired domain for a migration without checking its history is a common mistake. Tools like Wayback Machine, Ahrefs, or SEMrush allow you to travel back in time and detect warning signs. If the domain hosted a shady casino site two years ago, it's better to avoid it.

• 301 redirects: essential, but insufficient if misconfigured (redirect chains, loops, interspersed 404 errors).
• Search Console Notification: speeds up detection, but does not compensate for an underlying technical issue.
• Target domain history: an often-overlooked factor that can sabotage the entire migration if the domain is 'dirty'.
• Crawl budget: after migration, Google needs to massively re-crawl. A slow or poorly structured site slows down recovery.
• Backlinks: they must be progressively updated to the new domain to maximize authority transfer.

Does this statement align with real-world observations?

Yes, generally. Domain migrations that fail almost always show one of the two problems identified by Mueller: either a technical error (incomplete redirects, poor sitemap configuration, canonical tags still pointing to the old domain), or a problematic target domain. Senior SEOs have all experienced the case of a technically flawless migration that stalls due to a rotten domain history.

What this statement lacks is the temporal dimension. How long should you wait before concluding that a migration has failed? Google does not provide any figures, but field observations show that 2 to 4 weeks are generally enough to see the first signs of recovery. If after 6 weeks nothing changes, there is likely a structural problem. [To be verified]: Google has never communicated an official deadline.

What edge cases does this statement not cover?

Mueller remains vague on some complex scenarios. For example: what happens during a partial migration where only a section of the site changes domain? Or during a merger of two domains into one? In these cases, redirects become a puzzle, and the concept of 'ranking recovery' becomes blurry, as there is no 1:1 match between old and new URLs.

Another blind spot: the post-migration user behavior. If the new domain is less memorable, visually less credible, or generates a higher bounce rate, Google may interpret this as a signal of degraded quality, regardless of the technical quality of the migration. Mueller does not mention this UX dimension, which is nonetheless critical.

Should you always prefer a new domain for a migration?

Not necessarily, but it’s often safer. An expired domain with a good history can provide an initial boost thanks to its existing backlink profile and age. But the risk is high: if you miss the pre-purchase audit, you inherit invisible penalties or toxic links that hamper the migration.

The real question is: do you have the means to meticulously verify the history? If yes, a clean expired domain can be an asset. Otherwise, a new brandable domain remains the most prudent choice, even if it means sacrificing some startup speed.

What concrete steps should you take before migrating a domain?

Before even pointing the first DNS, you need to audit the target domain. Use Wayback Machine to explore its history, Ahrefs or Majestic to analyze its backlink profile, and Google Search Console (if you have access from the previous owner) to detect any manual actions. A domain that has hosted spam or dubious content is a ticking time bomb.

Next, map all of your URLs with a crawler (Screaming Frog, Sitebulb) and prepare a 1:1 redirect plan. Each old URL must point to its most relevant new version. Cascading redirects (301 → 301 → 200) dilute PageRank and slow down the crawl. Test this plan on a staging environment before going live.

How can you check that the migration went smoothly?

Once the redirects are in place, immediately notify Google via Search Console (Settings > Change of Address). Then monitor three key metrics: the crawl rate on the old domain (it should gradually decrease), the crawl rate on the new one (it should increase), and the evolution of rankings on your strategic queries.

Within the first 48 hours, you should see the new URLs start to appear in the index. If after a week Google is still crawling mainly the old domain, there is a problem: undetected redirects, robots.txt blocking, or an outdated XML sitemap. Also, check that your strategic backlinks have been properly redirected: contact referring sites to update their links.

What mistakes should you absolutely avoid during a domain migration?

First classic mistake: leaving the old domain as 404 or a blank page instead of maintaining the 301 redirects. Google needs time to transfer authority, and if you cut the redirects too early (before 6-12 months), you lose some of the PageRank. Second mistake: forgetting to update canonical tags on the new domain. If they still point to the old one, Google will get confused.

Third mistake: not managing the crawl budget post-migration. A large site with thousands of URLs can saturate Googlebot. Clean up parasitic URLs (useless parameters, infinite pagination, facets) and prioritize crawling strategic pages through the XML sitemap. Finally, never underestimate the UX impact: if the new domain degrades user experience (loading times, mobile usability), rankings may drop regardless of the technical quality of the migration.

• Audit the target domain's history (Wayback Machine, Ahrefs, Majestic) before purchase or setup.
• Map all URLs and create a 1:1 redirect plan without chains or loops.
• Test the redirects in a staging environment before going live.
• Notify Google via Search Console as soon as the redirects are active.
• Monitor crawl and rankings for at least 4 to 6 weeks.
• Keep the 301 redirects active for at least 6 to 12 months.