Some movement after a migration is normal, but a lasting drop almost always has a specific cause. Google says rankings can fluctuate while it recrawls a moved site, and that small to medium sites can take a few weeks to settle. If traffic hasn’t recovered after that, the usual culprits are missing or wrong redirects, pages that were dropped, blocked crawling, weaker content or broken internal links. Each one can be found and fixed.
I’ve audited sites before and after migrations, from a London clinic’s redesign to a headless Shopify rebuild. The faults behind traffic drops are rarely complicated. They’re usually small things nobody checked.
What’s normal after a migration
It’s normal for rankings and traffic to fluctuate for a few weeks after a migration while Google recrawls and processes the changes. Google says small to medium sites can take a few weeks for most pages to move, and larger sites longer. A drop that deepens or doesn’t recover after that points to a problem.
Google’s site move documentation says to “expect temporary fluctuation in site ranking during the move”, and that for medium-sized sites it can take a few weeks or more for Google to start showing the new URLs instead of the old ones. Its guide to debugging traffic drops also lists site moves as one of the main causes of falling Search traffic.
| What you see | What it usually means |
|---|---|
| A dip in the first two to four weeks, levelling off | Normal fluctuation while Google processes the move |
| Old URLs gradually replaced by new ones in results | Redirects working as expected |
| Traffic still falling after several weeks | A specific fault, worth investigating now |
| A sudden near-total loss | Crawling or indexing blocked, or redirects missing across the site |
| Some sections fine, others down | Problems in particular templates or URL mappings |
The seven usual causes
Lasting traffic losses after a migration usually come from one of seven causes: missing or wrong redirects, valuable pages removed, crawling or indexing blocked, weaker content, broken internal links, lost titles and metadata, or old and new URLs competing. Most migrations that go wrong have more than one.
1. Missing or wrong redirects
Old URLs that return a 404, redirect through several hops, or all point to the homepage lose the value they’d built. Google’s site move guide warns against redirecting many old URLs to one irrelevant page such as the homepage, which can confuse users and might be treated as a soft 404 error.
2. Valuable pages removed
Pages get dropped because nobody knew they mattered. On the Evewell fertility clinic’s site, the pre-migration audit found a page outside the main /support/ section bringing in 5,145 clicks a year, the ninth-highest on the site. It was exactly the kind of page that gets tidied into a new structure and lost. Because it was found first, the brief kept it at its existing URL.
3. Crawling or indexing blocked
Staging sites are often blocked with robots.txt rules or noindex tags, and those sometimes go live. Google’s site move guide lists forgetting to remove noindex or robots.txt blocks that were only needed for the migration as a common mistake.
4. Weaker content
New templates can quietly cut text, headings, FAQs or product detail. If a page ranked because it answered a question thoroughly, a slimmer version may not.
5. Broken or outdated internal links
Menus and in-content links still pointing at old URLs send visitors and Google through redirects, or to errors. Google’s guide says to update internal links to the new URLs.
6. Titles and metadata reset
Platforms often generate titles and descriptions automatically. A migration can replace carefully written titles with a bare page name, lowering click-through even where rankings hold.
7. Old and new URLs competing
If old URLs still load instead of redirecting, both versions can rank, splitting signals. After Kwiat’s move to a headless Shopify build, later checks found old category URLs still returning pages and relying on canonical tags, with old and new URLs both ranking for many searches.
Faults that are easy to miss
Some of the most damaging faults don’t show up in a quick check of the homepage: a missing XML sitemap, content that only appears after JavaScript runs, and redirects that were already broken before the migration started. These need deliberate checks after launch.
On Kwiat’s headless build, the new site’s /sitemap.xml returned a 404 error after the move, so Google had no sitemap to find the new URLs from. The same build served education articles whose text sat inside a script payload rather than the initial HTML. Google renders JavaScript, but some other crawlers don’t. The Kwiat migration case study covers how both were handled.
On Evewell, the audit found an existing fault: an old IVF landing page redirected to a URL that itself returned a 404. Carrying that into a new site would have kept a dead end in place. The Evewell case study covers the full plan.
How to find the cause in Search Console
Compare clicks for the weeks after launch with the same weeks before, by page rather than site-wide. Pages that lost the most clicks show where to look. Then check how each old URL behaves now, and use the Page indexing report to spot errors, redirects and noindexed pages.
- Performance report, Pages tab. Compare the period since launch with an equal period before it. Sort by lost clicks.
- Check each losing page’s old URL. Does it redirect once, to the right new page, which returns a 200 status?
- Page indexing report. Look for rises in “Not found (404)”, “Excluded by ‘noindex’ tag”, “Blocked by robots.txt” and “Duplicate without user-selected canonical”.
- Sitemaps report. Confirm the new sitemap was read and how many of its URLs are indexed.
- URL Inspection. Inspect the most important new pages to check they’re indexed and that Google has picked the right canonical.
- Compare content. Put the old version of a losing page (from an archive or crawl) next to the new one. Look for missing text, headings, FAQs and internal links.
- Check the live results for your top queries. Is the old URL still showing? Has the title changed?
| Finding | Likely fix |
|---|---|
| Old URL returns 404 | Add a permanent redirect to the closest matching page |
| Redirect chain or homepage redirect | Point the old URL straight to its equivalent |
| New page noindexed or blocked | Remove the block, then request indexing for priority pages |
| Old and new URLs both ranking | Redirect the old URL rather than relying on a canonical tag |
| Content thinner than before | Restore the depth the old page had, or improve on it |
| Title reset to a platform default | Rewrite titles for priority pages |
| No sitemap, or old URLs in it | Generate a sitemap of live, indexable new URLs and submit it |
How long recovery takes
Once the causes are fixed, recovery depends on how quickly Google recrawls the affected pages. Priority pages can recover within weeks. Large sites and long-tail pages take longer. Keep redirects in place for at least a year, and ideally for good, because links from other sites don’t expire.
Google’s site move guide says to keep redirects “for as long as possible, generally at least 1 year”. Its Change of Address help page gives a minimum of 180 days, and longer if the old URLs still get traffic from Google Search. Removing redirects early is one of the few ways to cause a second drop after a site has recovered.
Some losses may not come back in full, particularly if pages were merged, content was cut or the market changed at the same time. That’s why separating migration faults from other changes, such as AI Overviews answering questions or a Google update, matters before judging whether recovery is complete.
What I learned
Every migration I’ve seen lose traffic had at least one fault that a check would have caught before launch. The fixes were rarely difficult. The problem was assuming something had carried across, a sitemap, a redirect, a popular page, instead of confirming it.
That’s shaped how I work. The inventory of old URLs gets built from several sources, the redirect map is checked before and after launch, and the most important pages are inspected by hand once the new site is live.
If your traffic has already dropped, migration traffic recovery follows the process above to find and fix the causes. If you’re still planning, the site migration checklist covers every step.
FAQ
Is it normal to lose traffic after a website migration?
Some fluctuation is normal. Google says rankings can move temporarily while it recrawls a moved site, and small to medium sites can take a few weeks to settle. A drop that continues or doesn’t recover after several weeks usually points to a specific fault, such as missing redirects or blocked pages.
How long does it take to recover SEO after a migration?
If the migration was done properly, most pages on a small to medium site move within a few weeks, according to Google. After a faulty migration, recovery starts once the problems are fixed and Google recrawls the pages. Priority pages can recover within weeks, while large sites take longer.
Can a website redesign cause a drop in Google traffic?
Yes, even without a domain or platform change. Redesigns often change URLs, templates, content, headings and internal links. If old URLs aren’t redirected, or pages lose content and structure, rankings can fall. A redesign planned with a URL inventory and redirect map can protect or improve visibility.
Should I undo a migration if traffic drops?
Rarely. Reverting usually means another round of URL changes for Google to process, which can make things worse. It’s normally better to find and fix the specific faults, such as missing redirects, blocked pages or lost content, and give Google time to recrawl the corrected pages.
More on migrations and search traffic:
- Impressions up, clicks down: what it means
- Google Search Console for small businesses
- The site migration checklist
If you’re planning a move or recovering from one, get in touch or ask for a free assessment.
Sources
- Site moves and migrations, Google Search Central, accessed 15 September 2026. Supports: temporary fluctuation, a few weeks for small to medium sites, irrelevant homepage redirects and soft 404s, removing noindex and robots.txt blocks, updating internal links, keeping redirects generally at least 1 year.
- Debug Google Search traffic drops, Google Search Central, accessed 15 September 2026. Supports: site moves as a cause of traffic drops.
- Change of Address tool, Search Console Help, accessed 15 September 2026. Supports: maintaining redirects for at least 180 days.
- The Evewell, pre-migration SEO audit, Search Console data. Supports: the page with 5,145 clicks a year and the broken IVF redirect.
- Kwiat, post-migration technical audit, 2026. Supports: the 404 sitemap, client-rendered education pages and old category URLs still ranking.