Traffic drop after website migration: find what broke and win the rankings back

What actually causes a traffic drop after website migration?

A traffic drop after website migration happens when Google can no longer connect the pages it ranked to the pages you now serve. Rankings belong to URLs. If an old URL disappears without a clear permanent redirect, the signals it built up (links, clicks, history) have nowhere to go.

In practice the causes fall into four buckets. Addressing faults: missing redirects, redirects to the homepage, chains and loops. Directive faults: noindex, robots.txt blocks or canonicals copied from the staging server. Content faults: pages merged, shortened or left out during the rebuild, including category descriptions and blog archives nobody thought were important. Experience faults: a slower theme, broken internal links, or JavaScript that hides content from crawlers.

One more cause is not a fault at all: measurement. If GA4 was installed on the old theme and not the new one, or the consent banner now blocks analytics, your reports show a fall that Search Console does not. That is why we compare both sources before touching anything.

Google’s own site-move documentation says to expect ranking fluctuations while it recrawls and reindexes a moved site, and that a small to medium-sized site can take a few weeks for most pages to move. So a shallow wobble in week one is normal. A cliff, or a slide that continues past a month, is a fault until proven otherwise.

Is it really a traffic drop after website migration? Rule out other suspects

Line up the launch date against the date traffic fell. A genuine traffic drop after website migration starts within days of go-live. If they match to within a few days, the migration is the prime suspect; if the fall came weeks later, check for a Google update or a manual action first.

Open the Search Console Performance report and compare the 28 days after launch with the 28 days before, filtered by page. If the old URLs lost clicks and the new URLs did not pick them up, that is a mapping problem. If both old and new URLs appear and clicks are merely spread thin, Google is still consolidating and patience plus clean redirects usually does it.

Next compare queries. When branded searches (your business name) hold steady but product and service queries collapse, the site is reachable and the problem is page-level. When even branded searches fall, suspect a sitewide block: noindex, robots.txt, a DNS mistake or an expired SSL certificate on one hostname variant.

Finally, look outside. A core update in the same fortnight muddies the picture; our page on recovering from a Google core update covers that pattern. A message under Security and Manual Actions changes everything, and penalty recovery is a separate job. If all three checks point back at launch week, carry on with the triage below.

Traffic drop after website migration: the first 48 hours of triage

When you face a traffic drop after website migration, check the things that remove pages from Google entirely before the things that merely weaken them. A sitewide noindex costs you everything; a slow hero image costs you a little. Work top-down.

• Fetch the live homepage and three deep pages; view source and search for noindex, nofollow and the canonical tag
• Open robots.txt on every hostname variant (www, non-www, http, https) and read it line by line
• Run the top 50 old URLs from Search Console through a status checker: you want a single 301 to a relevant page
• Confirm http and non-www versions redirect to the one preferred version in one hop
• Check the XML sitemap: does it list new URLs only, return 200, and sit on the right host?
• Confirm GA4 and Tag Manager fire on the new templates
• Look at server response times and error rates in the hosting dashboard

Most of these take minutes each. The pattern of results tells you which of the longer jobs in the next sections you actually need, so nobody spends a week rebuilding redirects when the real fault was one line in robots.txt.

How do I rebuild a redirect map after a traffic drop after website migration?

If nobody kept a list of the old URLs, you can reconstruct it, and for most sites with a traffic drop after website migration this is the main repair. The old site left traces in at least five places, and combining them usually recovers nearly every URL that ever earned traffic or links.

Start with the sources in the table further down this page: old XML sitemaps (sometimes still on the server or in a backup), Search Console’s Pages and Performance reports, GA4 landing-page reports for the months before launch, backlink exports, and archived copies in the Internet Archive’s Wayback Machine. For an old WordPress or WooCommerce site, the database backup is gold: every post slug, product slug and category path is in it.

De-duplicate the list, strip tracking parameters, and sort by value: clicks, backlinks and conversions. Then map each old URL to the single closest new page. A discontinued product should go to its category or a close alternative, not the homepage. Google’s site-move guide warns that sending many old URLs to one irrelevant page such as the homepage confuses users and might be treated as a soft 404, so those redirects rarely carry ranking value across.

Load the redirects at the server, CDN or platform level (Nginx, Apache .htaccess, Cloudflare rules, Shopify URL redirects, a WordPress redirection plugin) and then test the whole list automatically. We do not mark a row done until the old URL returns one 301 or 308 to a new URL that itself returns 200.

Redirect chains, loops and homepage dumps

A redirect chain is a series of hops, and a common hidden cause of a traffic drop after website migration: old page to http version to www version to the new slug. Each hop adds delay and risk. Google’s site-move guidance recommends permanent server-side redirects and warns against long chains; Googlebot follows up to 10 hops, but a crawler giving up halfway leaves the old page stranded.

Chains are common after a second or third migration. The 2019 redesign redirected /services.php to /services/, and the 2026 replatform redirected /services/ to /what-we-do/. Now /services.php takes two hops. The fix is to flatten: every historic URL points straight at its final destination.

Loops are worse. A rule that sends /blog/ to /news/ plus a plugin that sends /news/ back to /blog/ makes both pages unreachable. They usually appear when a CMS redirect module and a server rule disagree, or when trailing-slash settings on the platform fight with rules written by hand.

Homepage dumps are a shortcut many developers take under deadline pressure: “anything not found, send to /”. It hides 404 errors from reports while throwing away the relevance of every old page. When we inherit one, we replace the catch-all with specific mappings for valuable URLs and let genuinely dead ones return an honest 404 or 410.

Staging noindex and canonicals that went live

If a staging setting went live, Google is being told to drop your pages, and the result is the steepest kind of traffic drop after website migration. This is the single fastest fault to fix and one of the costliest to miss, because pages fall out of the index steadily until someone notices.

WordPress has a “Discourage search engines from indexing this site” checkbox under Settings, Reading. Developers tick it on staging and the setting often travels with the database. Shopify stores behind a password page cannot be crawled at all. Custom builds on Next.js, Laravel or Astro sometimes carry an environment variable that adds a robots meta tag outside production, and a misconfigured deploy sets the wrong environment.

Canonical tags are subtler. If the staging hostname was staging.example.in and the template built canonicals from a configured base URL, every live page may now declare the staging copy as the original. Google then either ignores your canonical or, worse, trusts it. Search Console’s URL Inspection shows the “user-declared canonical” and the “Google-selected canonical”; if they differ from the live URL, you have found your problem.

Google’s documentation on site moves specifically says to remove any noindex or robots.txt blocks that were temporary migration measures. After fixing, request indexing for the most valuable pages and resubmit the sitemap so recrawling starts sooner.

Lost content: the quiet cause of traffic drops after website migration

Redirects move the address; they do not replace the words, which is why a traffic drop after website migration can happen even with perfect redirects. If the new page is thinner than the old one, it may rank lower even with a perfect 301 in place.

Redesigns often cut copy to make pages look cleaner. A category page that used to carry 400 words about fabric types, sizing and delivery becomes a grid of product tiles with a heading. A service page loses its FAQ block. A location page with directions and nearby landmarks gets merged into one “Contact” page. Each cut removes the text that matched long-tail searches.

Compare old and new versions side by side. The Wayback Machine or a backup gives you the old copy; a crawl of the new site gives the current word counts, headings and internal links per template. Where the old page answered questions the new one does not, restore that material into the new layout, rewritten where it had aged.

Blog archives are another casualty. Teams skip importing “old posts nobody reads” and then discover those posts were drawing a steady trickle of search visits and links. If they were worth nothing, 410 them deliberately; if they carried traffic, bring them back with their original slugs or a one-hop redirect.

Structured data also goes missing in rebuilds: product, FAQ, breadcrumb and LocalBusiness markup that the old theme or plugin produced. Losing it does not usually remove rankings by itself, but it can remove rich results that were pulling clicks.

Platform-specific traps: WordPress, Shopify, Wix and custom builds

Every platform has its own URL shape, and the traffic drop after website migration you see often follows a platform pattern, and moving between two shapes is where most redirect gaps appear. Knowing the patterns speeds up the rebuild.

Tracking a traffic drop after website migration in Search Console

Search Console is the only place you see Google’s view of your move, so set it up properly for the new site on day one: a Domain property verified by DNS covers every hostname and protocol at once.

Submit the new XML sitemap. Google’s site-move documentation notes that the old sitemap will show warnings about redirecting URLs and that those warnings are expected; some teams keep the old sitemap submitted for a while precisely so Google recrawls the old URLs and sees the redirects sooner.

Then watch four reports. Pages: the “Not found (404)” and “Page with redirect” counts should climb for old URLs and the indexed count for new URLs should rise. Performance: filter by page to see clicks shift from old addresses to new. Crawl stats (under Settings): a spike in crawl requests after launch is healthy; a spike in server errors is not. URL Inspection: test your top twenty pages individually.

When you work through a traffic drop after website migration, log what you change and when, because recovery is gradual and you need to tie improvements to fixes. We keep a dated change log in a shared sheet for every recovery, so you can see which repair moved which chart. If pages are crawled but stay unindexed, that is a different problem covered in crawled, currently not indexed.

How long does traffic take to recover after a website migration?

Once the faults behind a traffic drop after website migration are fixed, recovery usually shows within weeks, not days, and larger sites take longer. The speed depends on how often Google crawls you and how many URLs changed.

Google’s guidance for a clean site move says a small to medium-sized site can take a few weeks for most pages to move. A recovery is slower than a clean move because Google first learned the wrong thing: it saw 404s or noindex tags, may have dropped pages from the index, and now has to recrawl, see the fixes and reassess. High-value pages that attract links and clicks tend to come back first; deep, rarely crawled pages come last.

A realistic outline for a site of a few hundred pages: fixes deployed in week one, Search Console shows old URLs as redirects within one to three weeks, and clicks on the main pages start returning over the following weeks. Nobody can promise the exact curve or that every position returns, and anyone who does is guessing.

Some traffic may not return at all. If content was deliberately removed, if the new site targets different topics, or if competitors improved while you were invisible, the new baseline can sit below the old one. We say so plainly in the first report rather than letting you wait for something that will not come.

Choosing someone to fix a traffic drop after website migration

Hire someone who asks for evidence before offering a fix for a traffic drop after website migration: Search Console access, the launch date, the old sitemap or database, and the redirect rules as they stand. A quote given without those is a guess.

Good signs: they explain the cause in plain language, test redirects in bulk rather than by clicking a few links, show you the before-and-after status codes, and tell you which traffic probably will not come back. Bad signs: an instant promise of “full recovery in 7 days”, suggestions to buy backlinks to compensate, or a plan to roll everything back without diagnosing why.

Ask who will have access and how. Recovery needs hosting or CMS admin rights; you should create a user for the contractor rather than sharing your own password, and remove it when the job ends. Ask what they will change and whether it will be reversible, because a redirect rule written badly can break working pages.

If the original developer is still around, involve them. They know how the site is deployed and where rules live. Our role then can be the SEO half of the pair: we produce the map and test results, and they deploy. When that is not possible, we work directly in your accounts. Our broader website migration service covers planned moves done right the first time.

What does fixing a traffic drop after website migration cost in India?

The cost of fixing a traffic drop after website migration follows three things: how many old URLs need mapping, how many platforms and rule layers are involved, and how much lost content has to be rebuilt. A diagnosis is quick; the mapping and content work is where hours go.

A five-page business site with a noindex left on might need an hour’s work. A 2,000-product store moved from WooCommerce to Shopify, with filters, variants and a blog, needs a proper crawl, a spreadsheet of thousands of rows, bulk import and automated testing. Content restoration is priced separately because it depends on how much text vanished.

Across the market, quotes for this kind of work vary widely. Some bundle it into a retainer; some charge a one-off audit fee and leave you to implement. Ask whether the quote includes implementation and retesting, or only a report. Our quotes list diagnosis, redirect mapping, implementation, content restoration and monitoring as separate lines, so you can do parts yourself.

If you want us to keep watching after the fix, monthly SEO starts at ₹10,000/mo (US$150/mo for clients abroad). If the new site is so broken that rebuilding is cheaper, a static business site starts at ₹10,000 and an SEO site of 299+ pages at ₹20,000, with the redirect map built in from day one. Current figures live on the pricing page.

Preventing the next traffic drop after a website migration

The cheapest fix for a traffic drop after website migration is the one you never need. Most migration losses are preventable with a URL inventory, a tested redirect map and a launch-day checklist.

• Crawl the old site and export every URL, title, word count and canonical before anything changes
• Export Search Console Performance data by page for the last 16 months and keep it
• Write the redirect map in a spreadsheet and get it reviewed before launch
• Block staging with a password, not with noindex, so the setting cannot travel
• Test the full redirect list on staging, then again within an hour of going live
• Keep the old sitemap file and database backup somewhere safe
• Keep redirects in place long term; Google advises at least a year and ideally longer
• Plan launch for a quiet trading week, not a festival sale

Google’s site-move documentation says to keep redirects for as long as possible, generally at least one year. We usually leave them indefinitely: they cost almost nothing and old links keep working. If the move also involves a new domain name, the extra steps are on change domain without losing SEO.

Worked example: a replatformed store in Surat

This is a hypothetical scenario to show the method, not a client story. Say a saree wholesaler in Surat moves from WooCommerce to Shopify. Launch goes well, but three weeks later organic clicks are well below the usual level and WhatsApp enquiries from the site have slowed.

Day one: Search Console shows branded searches steady, so the site is reachable. The Pages report lists several hundred new “Not found” URLs, all of the pattern /product-category/…/ and /product/…/. The developer had imported products with new handles but added redirects only for the top twenty products. GA4 is fine.

Days two to four: the old database backup provides every product and category slug. We match products by SKU to their new Shopify handles, map categories to collections, send discontinued lines to their parent collection and let a handful of spam-generated URLs return 404. The Wayback Machine supplies the old category descriptions, which the new theme had dropped; they go back in, lightly edited.

Day five: redirects are bulk-imported and every row is tested. Internal links in blog posts are updated to point straight at new URLs. The old sitemap stays submitted for a few weeks alongside the new one.

Weeks two to eight: Search Console shows old URLs switching to “Page with redirect” and new product URLs gaining impressions. The owner gets a fortnightly note of what changed. The outcome is not guaranteed, but the faults that caused the drop are gone and measurable.

Migrations and AI search: do ChatGPT and AI Overviews notice?

Yes, indirectly. A traffic drop after website migration usually means lost AI visibility too, because AI answers draw on pages that search systems can fetch and trust. If your best explanatory pages now return 404 or sit behind a noindex, they drop out of that pool as well.

Google’s AI Overviews are built on its own index, so anything that removes a page from Google search also removes it as a candidate citation there. Other assistants that browse the web follow links and search results too; a page that redirects cleanly keeps its links working, while a dead one quietly disappears from the sources they can reach.

After a migration, check that your key answer pages (pricing explanations, how-to guides, FAQs) are indexed, render their main text in the HTML rather than only after JavaScript runs, and still carry the structured data they had. Keep headings as questions where they were questions, and keep one-paragraph answers near the top. If AI visibility is a priority, see AI Overview optimisation for the wider picture.

One practical tip: when you restore lost content, do not just paste it back. Update facts, add the date you revised it and tighten the opening answer. A recovery is a good moment to make the page better than it was before the move.

Migration recovery for businesses across India

We fix a traffic drop after website migration remotely for site owners in every state, on calls in English or Hindi, and take payment by UPI or bank transfer with a GST-compliant invoice where applicable. Access is shared through your own accounts, so no one needs to visit.

Our city pages describe local business context in more detail: Surat, Jaipur, Kochi, Lucknow, Indore, Coimbatore, Chandigarh, Guwahati, Rajkot and Visakhapatnam. For a slow new theme, pair this page with Core Web Vitals assessment failed; for an audit before you commit to any fix, see SEO audit services.