Traffic drop after a site migration or redesign? A recovery checklist

You launched the new site, the redirects went live, and a couple of weeks later the Search Console chart is heading the wrong way. Some wobble after a migration is expected, but a drop that keeps getting deeper almost always has a specific, findable cause. This checklist shows you how to tell the two apart and where to look first.

Quick answer: A short, shallow dip after a site migration is normal while Google recrawls your site and processes the new URLs. A deep or growing drop usually comes from missing or broken redirects, staging leftovers like a noindex tag or a blocking robots.txt, canonicals pointing to the wrong place, or content and internal links that disappeared in the redesign. Compare equal periods before and after launch in Search Console, find the pages that lost the most clicks, and check those URLs one by one.

#What a normal post-migration dip looks like

Google's guide on how to move a site with URL changes says to expect temporary fluctuation while Google recrawls and reindexes. For a medium-sized site, it can take a few weeks for most pages to move in the index, and larger sites take longer. The same guide notes that permanent redirects don't cause a loss in PageRank, so a well-executed move shouldn't cost you rankings in the long run on its own.

A healthy migration tends to look like this:

• Clicks and impressions dip, then climb back over several weeks.
• Old URLs gradually drop out of the index as the new ones appear.
• The dip is spread across the site rather than concentrated in one section.

The warning signs are different: the drop keeps deepening after the first few weeks, it's concentrated in one folder or page template, or the Page indexing report shows a jump in errors right after launch. Those point to something broken, and waiting won't fix it.

#Set up a clean before-and-after comparison

First, mark the launch date. Search Console's custom annotations let you right-click the Performance chart and choose "Add annotation" (ppc.land covered how they work). Each note is limited to 120 characters, and annotations don't show in comparison mode, so check them on the regular chart.

Next, use Compare mode with equal-length windows on either side of launch, such as the 28 days after go-live against the 28 days before. Avoid windows where a holiday falls on only one side. Search Console's help page on data discrepancies notes that Performance data is usually available in 2-3 days and that the table shows at most 1,000 rows, so leave out the most recent days and, on a large site, filter by folder to work section by section. For a full walkthrough, see how to compare date ranges in Search Console.

Then open the Pages tab and sort by "Clicks Difference", as Google recommends in its guide to debugging drops in Search traffic. If your URLs changed, expect old URLs to lose clicks and new ones to gain them. You're hunting for old URLs whose clicks vanished without a new equivalent picking them up.

After a domain move, the new site is a separate Search Console property. Verify it and add old and new clicks together to see the real net change.

#Check redirects first

Redirects come first, because when they're wrong, the rankings tied to your old URLs have nowhere to go. Start with a full list of old URLs: a crawl you ran before launch, your old XML sitemap, or an export of the Pages table from before the move. Run that list through a crawler or bulk status checker and look at four things.

#Status code

Each old URL should return a server-side permanent redirect (301 or 308), as Google's site move guide recommends. Temporary, JavaScript and meta refresh redirects aren't what you want for a permanent move.

#Destination

Each old URL should point to its closest equivalent on the new site. Sending hundreds of old pages to the homepage or a broad category is a common shortcut that throws away their relevance, because a homepage isn't a substitute for a specific article or product.

#Chains

Redirect straight to the final URL, since Google's guide says to avoid chains. If you've migrated before, update the older redirects too so they point directly at the new final URLs instead of stacking on top of each other.

#Lifespan

Google says to keep redirects in place for at least one year. Don't let the old domain expire or the old server get switched off while redirects still depend on it.

#Check that the new URLs can be indexed

If the redirects look right, check whether Google can crawl and index the destination pages. Open the Page indexing report and look for reasons that jumped after launch: "Not found (404)", "Excluded by 'noindex' tag", "Blocked by robots.txt", "Server error (5xx)", "Redirect error" and "Soft 404". Google's debugging guide suggests this report for site-wide drops, and URL Inspection on a sample of pages when only a group of pages is affected.

#Staging leftovers

The classic migration bug is a setting copied from the staging site: a noindex meta tag or X-Robots-Tag header, a robots.txt that disallows everything, or canonical tags that still point to the staging or old domain. Google notes that a misplaced noindex tends to cause a slower decline, so a gradual slide after launch doesn't rule it out.

#Rendering

Run URL Inspection on each key template, test the live URL, and check that the rendered HTML contains your main content, links and title. Sites rebuilt on a JavaScript framework can look fine in a browser but render incompletely for Google if scripts fail or are blocked.

#Sitemaps and Change of Address

Submit an XML sitemap that lists only final, indexable new URLs. For a domain move, use the Change of Address tool in the old property. Since a June 17, 2026 update to Google's site move guide, Google says to submit it for every variant of the old domain, both www and non-www. The tool isn't used for an HTTP-to-HTTPS move.

#Check what the redesign changed on each page

If your URLs didn't change, or the redirects and indexing look clean, compare the old and new versions of the pages that lost the most. These are the usual losses:

• Copy cut for a cleaner look. Category intro text, detailed product descriptions, comparison tables and FAQ sections are often the first things trimmed.
• Titles and headings rewritten. A new template can turn hand-written titles into generic ones like "Product | Brand". If impressions held but clicks fell, Google's guide points you to titles and snippets. See clicks dropped but impressions didn't for that diagnosis.
• Structured data dropped. If a rich result type disappears from the Search appearance tab of the Performance report, check whether the new templates still output the markup.
• Internal links thinned out. A simplified menu or a removed sidebar can leave deep pages with far fewer internal links. Also point internal links at the new URLs directly rather than through redirects.

#Match the symptom to the cause

Once you know which pages lost clicks, use this as a shortcut.

#The recovery checklist

Work through these in order.

1. Confirm the drop is real: check the Search Console "Data anomalies" page and leave out the last few days of data.
2. Annotate the launch date and compare equal windows before and after.
3. Sort the Pages table by Clicks Difference and list old URLs whose clicks didn't transfer.
4. Check each old URL on that list: one server-side permanent redirect, straight to the closest equivalent.
5. Inspect the matching new URLs: indexed, self-referencing canonical, no noindex, not blocked by robots.txt.
6. Review the Page indexing report for reasons that spiked after launch.
7. Compare old and new versions of your top losers: content, titles, headings, structured data and internal links.
8. Submit a clean sitemap and, for a domain move, a Change of Address for every old domain variant.
9. Check whether a Google ranking update overlapped with your launch.
10. Ship fixes, annotate them, and wait a few weeks before judging the result.

#How long recovery takes, and when it isn't the migration

Google's debugging guide says some changes show up within days while others can take months, and it suggests waiting a few weeks before re-analyzing. Fixes don't guarantee recovery either. They remove the obstacle, and the rest depends on how your pages compare with the competition.

If every check comes back clean, look at timing. Check the Google Search Status Dashboard for ranking updates that overlapped your launch. Say you went live on May 18, 2026: the May 2026 core update started three days later and took about 12 days to roll out, so a drop in that window has two candidate causes. If you suspect an update, our guide to core update recovery covers what to do next, and the 7-step traffic drop diagnosis covers causes unrelated to the move. For a quick first look at where clicks fell, you can also run the free traffic drop checker.

If you'd rather not re-run this comparison by hand every week while the new site settles, RankSlide checks every page and query in your Search Console daily, flags pages whose clicks fall well below their recent weekly average, and emails you a plain-English explanation of the likely cause with a few suggested actions. You can explore the demo with sample data.

#FAQ

#How long does it take for traffic to recover after a site migration?

Google's site move guide says a medium-sized site can take a few weeks for most pages to move in the index, and larger sites take longer. If the drop is still getting deeper after a few weeks, treat it as a problem to diagnose rather than a delay to wait out.

#Should I remove redirects once the new pages rank?

No. Google recommends keeping redirects for at least one year. Keeping them longer costs little, and removing them sends anyone following an old backlink or bookmark to a dead page.

#Can a redesign hurt SEO if the URLs stay the same?

Yes. Keeping URLs avoids redirect problems, but changes to content, titles, structured data and internal links can still cost rankings.

#Do I need the Change of Address tool for an HTTPS move?

No. Google's guide says the tool is for moving to a new domain, not for switching from HTTP to HTTPS. For a domain move, submit it for both the www and non-www versions of the old domain.