Traffic Dropped After a Site Migration: Settling or Failing?

Migrations are the one category of traffic loss where a drop is expected, which is exactly what makes them dangerous. Everyone involved has agreed in advance that some decline is normal, so the first six weeks pass without anyone investigating, and by the time somebody does the trail is cold and the lost rankings have been reassigned to competitors.

The useful question is not whether you dipped. It is whether the shape of your dip matches a migration settling or a migration failing. Those look different from week two onward, and this page covers how to read the difference and what to do about each.

What counts as a migration?

Worth defining, because the risk level varies enormously and people use the word for very different events. A visual redesign on identical URLs is a different problem, covered in traffic dropped after a website redesign.

Type of migration	Risk	Measurement (what usually breaks)	Typical settling
HTTP to HTTPS	Low	Mixed content, missing canonical updates, both versions indexed	1 to 2 weeks
URL structure change, same domain	Medium	Redirect gaps, chains, internal links still pointing at old paths	2 to 4 weeks
Platform or CMS change	Medium to high	URL patterns change silently, content transforms, rendering changes	3 to 6 weeks
Domain change	High	Everything above, plus the whole authority profile has to transfer	4 to 8 weeks
Consolidating several sites into one	Highest	Many-to-one mapping, duplicate content, competing pages	8 weeks or more

The last row is the one that goes wrong most often and is rarely budgeted for properly. Merging three sites into one is three migrations happening simultaneously, with the added problem that pages which used to rank on separate domains now compete with each other.

Why does a correct migration still lose traffic?

Because Google has to recrawl every URL, follow every redirect, and transfer the signals attached to each old address to its new one. That is not instant and it is not simultaneous.

Your most important pages are recrawled first because they are crawled most often. Your long tail can take weeks. So the normal shape of a healthy migration is a dip that is worst in week one, improves steadily as high-value pages transfer, and then takes longer to fully close because the tail is still catching up.

That shape is the diagnostic. A dip that recovers in steps, fastest at the top, is working. A dip that stays flat at the bottom or deepens is not.

How do I tell settling from damage?

Three signals, checked weekly. None of them is total traffic, because total traffic is the last thing to move and the least informative.

• Indexed page count on the new site. It should climb steadily toward the old site’s count. If it plateaus well below, URLs are not being found or are being excluded. The Pages report names the reason.
• Indexed page count on the old site. It should fall as the new one rises. If both are indexed simultaneously weeks later, your redirects are not being honoured or are not there at all.
• Crawl errors. A spike in 404s in week one is expected. A spike still present in week four means Google keeps finding URLs you did not map.

The second signal is the one people forget to check, because they stop looking at the old property in Search Console after launch. Keep both verified. The old property is where the evidence lives.

Did your redirect map actually cover everything?

Most redirect maps are built from the CMS export, which lists the pages the site owner knows about. Google’s list is different and usually longer, because it includes URLs with parameters, old URLs from previous migrations, paginated series, filtered views and pages that were deleted years ago but still hold links.

1. Export the Pages tab from the old property in Search Console, for the twelve months before launch. This is Google’s list, not yours.
2. Export your backlink data and pull every URL that has ever received an external link.
3. Pull your old XML sitemaps, including any archived versions.
4. Combine and deduplicate the three lists.
5. Test every URL and record the status code and final destination.
6. Fix anything returning 404, anything redirecting more than once, and anything landing somewhere irrelevant.

Step two is the one that recovers the most value for the least work. A URL with external links pointing at it is carrying authority that transfers only if the redirect exists. Every unmapped linked URL is authority you paid for and then discarded.

Are your redirects chained or looping?

Sites that have migrated more than once accumulate layers. The 2019 URL points at the 2022 URL, which points at the 2024 URL, which now points at the new domain. Each hop is an opportunity to lose the thread.

Google follows chains but treats long ones as a signal of poor maintenance and will stop following after several hops. The fix is to flatten every chain so each historical URL points directly at its current destination in one step, which also removes the risk of a middle layer being decommissioned and taking everything behind it down.

Watch for loops as well. A redirect rule written with a wildcard can send a URL back to itself through an intermediate, and the page becomes unreachable for both users and crawlers while returning no obvious error in a browser.

Did you tell Google about the domain change?

If you moved to a new domain, Search Console has a Change of Address tool that signals the move explicitly rather than leaving Google to infer it from redirects alone. It is under Settings in the old property.

It only applies to domain changes, not to URL restructures on the same domain, and it requires both properties verified with site-wide redirects already in place. Using it does not replace correct redirects, but skipping it on a domain move slows the transfer noticeably.

Two related checks worth doing at the same time. Submit a fresh XML sitemap on the new property so Google has a complete list of destinations. And keep the old domain registered and redirecting for at least a year, because links pointing at it keep passing value only while the redirect exists.

What gets permanently lost in a migration?

Being honest about this matters, because it changes what a realistic recovery looks like and prevents a team chasing a baseline they can no longer reach.

Asset	Transfers?	Measurement (what to expect)
Link authority via 301 redirects	Yes, largely	Transfers over weeks as URLs are recrawled
Rankings on mapped URLs	Usually	Return as signals consolidate, often not identically
Authority on unmapped URLs	No	Lost permanently once the URL 404s
Search Console history	No	New property starts empty; export the old one before you lose access
Rankings for content you did not migrate	No	Pages left behind stop ranking, correctly
Brand signals and direct traffic	Partly	A domain change resets brand recognition; budget for it

The fourth row causes real problems later. Once the old property stops collecting data, your pre-migration baseline exists only in whatever you exported. Export the full Performance data from the old property now if you have not, because Search Console retains sixteen months and you will want that comparison when somebody asks whether the migration cost anything.

Did a robots file or canonical come across from staging?

The most catastrophic and the fastest to fix. A staging environment is normally blocked from search, and on a platform migration that block can travel to production inside the deployment.

• Check the live robots.txt for a blanket Disallow line. Why: Thirty seconds, and it explains a total collapse completely.
• Check for noindex tags on live templates. Why: Platform migrations often apply these per template, so the homepage can be fine while the entire blog is blocked.
• Check canonicals point at the new domain. Why: A canonical still referencing the old domain tells Google the old version is the real one, which undoes your redirects.
• Check hreflang tags if you run multiple languages. Why: These break silently on domain changes and cause the wrong regional version to surface.

This is not your cause if

• The decline started before the migration date. Establish the break date from daily data rather than assuming the launch caused it. Migrations shipped during an existing decline routinely take the blame for it.
• Indexed counts are healthy and positions fell evenly. That is an algorithmic pattern. Check whether your dates fall inside a confirmed rollout.
• Impressions held while clicks fell. A migration does not usually cause that. See traffic dropped but rankings the same.
• You are eight weeks in and still recovering steadily. Large migrations take time. A rising trend is working, even if it has not closed the gap.
• Only pages you deliberately removed lost traffic. That is the migration working as designed, not failing.

What order should I fix things in?

Blocking problems first, then value recovery, then refinement. Nothing here waits on a reassessment cycle, which is the good news about migration damage: it responds to fixes rather than to time.

1. Remove any robots block or noindex, and correct canonicals pointing at the old domain.
2. Rebuild the redirect map from Search Console, backlink and sitemap data combined, not from the CMS export.
3. Fix the linked URLs first, since those carry authority that is otherwise discarded.
4. Flatten every redirect chain to a single hop.
5. Update internal links to point at final destinations rather than relying on redirects.
6. Submit the Change of Address tool if this was a domain move, and resubmit sitemaps.
7. Re-check indexed counts weekly on both properties until the old one empties.

Before any of it, confirm the break date with the drop analyzer, because if the decline predates launch then none of this is your problem. The page scope analyzer will show whether specific URL groups vanished or the whole site fell, which separates mapping failure from an algorithmic cause.

Frequently asked questions

How long does it take to recover from a site migration?

A correctly executed migration typically dips for two to four weeks on the same domain, and four to eight weeks for a domain change. Large consolidations take longer. A dip that deepens after six weeks is a mapping failure rather than settling.

Do 301 redirects pass full link value?

Google has said 301 redirects do not lose PageRank, but the transfer happens as each URL is recrawled rather than instantly, and it only applies where a redirect actually exists. Authority on unmapped URLs is lost permanently once they return 404.

How long should I keep the old domain?

At least a year, and longer if it has significant backlinks. External links pointing at the old domain keep passing value only while the redirect is live, so letting the registration lapse discards that permanently.

Should I use the Change of Address tool?

Yes for a domain change, once both properties are verified and site-wide redirects are in place. It does not apply to URL restructures on the same domain, and it does not replace correct redirects.

Why are both my old and new sites still indexed?

Either the redirects are not in place, they are returning a status other than 301, or canonical tags on the new site still point at the old domain. Check the response codes directly rather than testing in a browser, which follows redirects invisibly.

Can a migration cause a Google penalty?

No. A penalty means a manual action, which is a human decision about a policy violation and appears in Search Console. Migration losses are mechanical, which is why they respond to fixes within weeks rather than waiting for a reassessment.