Skewcheck Launch checklist Traffic dropped after a migration
Traffic dropped after a redesign? Check these first
Updated · By SwynQ Labs Private Limited
The new site launched, it looks better than the old one, and search traffic has fallen. That is a horrible place to be, especially if you built the site for a client.
Some movement after a big change is normal. Google says rankings may fluctuate while it recrawls and reindexes a site, and that for a medium-sized site it can take a few weeks for the new URLs to replace the old ones. But a sharp drop that starts on launch day and doesn't come back usually has a specific, findable cause, and most of them are fixable. Work through these checks in order; the early ones are the quickest and the most common.
1. Make sure the drop is real
Before you change anything, rule out a measurement problem.
- Compare analytics with Search Console. If analytics shows a drop but Search Console clicks look normal, the new site's tracking is probably the issue, not search: a missing or changed analytics tag, a different property, or a consent banner that now blocks it. Search Console counts clicks from Google whatever your site's tag does.
- Check for seasonality. In the Search Console Performance report, set the date range to the last 16 months and look at the same weeks last year. Google's own guide to traffic drops suggests exactly this, plus checking your main queries in Google Trends.
- Check Search Console's data anomalies page for known reporting issues on Google's side.
2. Find which pages lost the traffic
In the Performance report, compare the period since launch with the period before (Date > Compare), then open the Pages tab and sort by Clicks Difference. Google recommends this to see whether the drop is site-wide, a group of pages, or one important page.
Look at the URLs at the top of that list. If they're the old site's addresses, the problem is almost always that those old URLs no longer lead anywhere. That is the most common cause after a platform move, and it's the next check.
Also look at the shape: if impressions and clicks both fell, pages are being shown less. If impressions held but clicks fell, Google's guide points to titles and snippets instead.
3. Test the old URLs that used to get traffic
Take the old URLs from that Pages list (and from the old sitemap, if you have it) and request each one on the live site. Each should answer with one permanent redirect (301 or 308) to the page that replaced it, and that page should return 200.
From a terminal, with one full old URL per line in old-urls.txt:
while IFS= read -r url; do
[ -z "$url" ] && continue
first=$(curl -s -o /dev/null -w '%{http_code} %{redirect_url}' "$url")
final=$(curl -s -o /dev/null -L --max-redirs 10 -w '%{http_code} %{num_redirects} %{url_effective}' "$url")
echo "$url | first: $first | final: $final"
done < old-urls.txtWhat you might see:
first: 404– there is no redirect. The page's search traffic stops here. This is the classic migration loss, and nothing on the new site looks broken, so nobody notices. The sample record on our Migration Repair page shows a real WordPress-to-Framer move where this happened.first: 302– a temporary redirect. Change it to permanent.- A hop count above 1 – a chain. Google advises redirecting straight to the final page.
- Every old URL ending on the homepage – Google warns that redirecting many old URLs to one irrelevant page, such as the home page, may be treated as a soft 404. Each should go to its closest replacement.
Search Console shows the same picture from Google's side. In the Page indexing report, look for Not found (404): Google describes these as URLs it found that return 404, possibly because "the page existed before and was deleted". Also look for Soft 404.
4. Check that the new pages can be indexed
A redirect only helps if the page it lands on can be indexed. On the new site's most important pages, check for:
- A
noindexleft over from staging. Very common: the staging site was hidden from search and the setting came along. See Noindex left on after launch. - robots.txt blocking Google. See robots.txt blocks Google.
- A canonical pointing at the staging address (for example the webflow.io address) instead of the page itself. See Canonical points to staging. In the Page indexing report this can show as "Duplicate, Google chose different canonical than user".
- Pages that return an error to visitors who aren't signed in, such as a leftover password or coming-soon setting. See Page returns an error.
Google's site-move troubleshooting lists leftover noindex or robots.txt blocks and incorrect redirects as common mistakes that stop a new site being indexed. The free Skewcheck page check tests a page for all of these in one go.
5. Check the sitemap
- The new sitemap should list the new URLs, and be submitted in Search Console. See No sitemap.
- Redirected old URLs shouldn't be in it.
- If you still have the old sitemap, Google suggests submitting it as well during a move: its indexed count should fall while the new one rises. Search Console may warn that its URLs redirect; Google says that's normal.
6. Did the domain change?
If the move also changed the domain, both the old and new domains need to be verified in Search Console, and Google's Change of Address tool should be submitted for the old domain. Google says the tool is only for domain or subdomain moves, not path changes on the same domain.
7. If you've lost the list of old URLs
This is common when the old site has been switched off. You can rebuild the list from:
- Search Console's Performance report (Pages tab, last 16 months), which still holds the old URLs that got clicks;
- the Page indexing report's Not found (404) list;
- Search Console's Links report, for old pages other sites link to;
- old analytics landing-page reports;
- the Internet Archive's Wayback Machine.
Put them in our free redirect map template, match each one to its new page, and add the redirects: see Webflow migration redirects or Framer migration redirects.
8. After the fix: what to expect
- Ask Google to look again: submit the sitemap, use URL Inspection on your most important pages, and use Validate fix in the Page indexing report. Google says validation typically takes up to about two weeks.
- Keep the redirects for as long as possible, generally at least a year, as Google recommends.
- Re-check the old URLs a week later: redirects get broken by later edits.
We can't tell you how fast traffic comes back, and nobody honestly can. Google says there's no fixed crawl schedule, that a move happens URL by URL, and that the time depends on the size of the site. Fixing the redirects and indexing settings removes the problem; it doesn't guarantee a ranking.
When it isn't the migration
If every old URL redirects correctly and the new pages are indexable, the drop may have another cause. Google's guide to traffic drops lists:
- Algorithm updates. Check Google's list of ranking updates for one that lines up with your drop.
- Security issues. Check the Security Issues report.
- Spam and manual actions. Check the Manual Actions report.
- Seasonality and changing interest, which the 16-month view and Google Trends show.
A redesign can also change the content itself: shorter pages, merged pages, removed text or changed titles. If the lost pages are new URLs that redirect correctly, compare the old and new versions of the content.
Want us to find and fix it?
Migration Repair works after launch as well as before it. We go through the old URLs that used to get search traffic, find the ones that now 404, chain or land on the wrong page, map each one to its new page, put the redirects in on Webflow or Framer (or hand you the file), and check them live, then again 7 days later. You get a record of every old URL, where it now goes, and the status we saw.
- Free first: a redirect map for your top 10 traffic pages within 48 hours.
- Then: $500 per site (₹40,000 + GST in India), agreed before we start. We fix redirects and indexing settings; we don't promise rankings or traffic.
Email hello@swynq.com with the old and new site addresses · How Migration Repair works
Questions
Is it normal for traffic to drop after a website migration?
Some fluctuation is normal. Google says rankings may fluctuate while it recrawls a moved site, and that a medium-sized site can take a few weeks for the new URLs to replace the old ones. A sharp drop that starts at launch and doesn't recover usually has a specific cause, most often old URLs that return 404.
What is the most common cause of lost traffic after a redesign?
After a move to a new platform, it is usually old URLs that changed address without a permanent redirect, so visitors and Google reach a 404. Leftover noindex tags, robots.txt blocks and canonicals pointing at the staging site are the next things to check.
How do I find the old URLs if the old site is gone?
Use the Search Console Performance report over the last 16 months, the Page indexing report's Not found (404) list, Search Console's Links report, old analytics landing pages and the Wayback Machine.
How long does it take to recover after fixing redirects?
There is no fixed time. Google says a site move happens URL by URL and depends on the size of the site; for a small to medium site, most pages take a few weeks to move. Fixing redirects removes the problem but doesn't guarantee rankings.
Can you fix a migration that has already launched?
Yes. Migration Repair finds the old URLs that lost their traffic, maps each to its new page, puts the redirects in and checks them live and 7 days later, for $500 per site. Email hello@swynq.com and we start with a free redirect map for your top 10 traffic pages.