Site Migration Traffic Recovery
Traffic fell after a redesign, a CMS change or a domain move? We compare the old site with the new one, page by page, find what Google lost in the move, and give your developer the exact fixes in the order that matters.
Why does traffic drop after a site migration?
Because something Google relied on did not make the move. The usual causes are old URLs with no redirect, content that now appears only after JavaScript runs, internal links that were dropped in the new design, and a noindex tag or robots.txt block carried over from the staging site. The design can look identical in a browser while Google receives a much thinner page.
Most of this can be put right, because the old site is still on record: Search Console keeps 16 months of data and web archives hold the old pages. Fixed price: ₹19,999 for the diagnosis, or ₹44,999 for the diagnosis and the fixes.
Your traffic fell within weeks of a launch
This service is for sites whose drop starts close to a launch date: a redesign, a platform change such as WordPress to a headless CMS, Shopify or Webflow, a new domain, or a new URL structure. If you are not sure the dates line up, check them against Google’s confirmed updates with the update matcher first. A drop that matches an update and not your launch is a different problem, and SEO recovery is the better fit.
It is also for agencies and developers whose client lost traffic after a build went live. We work in the background on those jobs under our white-label terms. If the move was on WordPress or Shopify, the checks in our WordPress and Shopify traffic drop guides are a good first pass you can run yourself.
Seven things that most often get lost in a move
You can check all of these yourself before hiring anyone. They are in the order we look at them, and Google documents the first one in its own site move guidance.
- Redirects. Old URLs that now return a 404, or that all point to the homepage. Each old page needs a redirect to its closest new equivalent.
- Rendered content. Text that used to be in the page source and now only appears after JavaScript runs. Look at the page with JavaScript switched off.
- Internal links. Menus, footers, related links and breadcrumbs that the new design dropped. Pages that lose their internal links lose their rankings slowly, which is why this one is missed.
- Titles and headings. Templates that rewrote every title, or pages that lost their main heading.
- Index settings from staging. A noindex tag, a canonical pointing at the staging domain, or a robots.txt that still blocks the site.
- Sitemap and language tags. A sitemap that still lists old URLs, and hreflang tags that did not move with the pages.
- Removed pages. Pages that were left out of the new site on purpose, without anyone checking how much traffic they brought.
Four steps, in writing
1. Before and after map
We collect the old URLs from Search Console, the old sitemap and web archives, and match each one to the new site. Every old URL ends up in one of four groups: redirected correctly, redirected to the wrong place, gone, or changed.
2. What Google receives now
We fetch the new pages the way Googlebot does and compare them with the archived old versions: content, titles, headings, internal links, canonicals and structured data.
3. A fix list for your developer
Every problem ranked by the clicks it cost, with the exact redirect map and the template changes needed. It is written so a developer can work through it without a call.
4. Check and track
When the fixes are live we crawl again to confirm them, then track recovery in Search Console by page group, so you can see which fixes worked.
Recovery Audit
Steps 1 to 3: the full comparison and a fix list your developer can work from. 5 working days, async. Its price counts toward the Recovery Fix if you go ahead.
Recovery Fix
Steps 1 to 4: the diagnosis, the redirect and index fixes made by us or briefed to your developer, the confirming crawl and the tracking. About 14 days of our work. Includes the 90-day progress guarantee.
Not sure yet? Book a 20-minute call and send your URL when you book.
What we won’t do
- Promise all of it back. Pages that were removed on purpose take their traffic with them. We tell you how much that was.
- Rebuild your site. We fix redirects, index settings and metadata, and brief your developer on template changes. The build stays with them.
- Tell you to roll back by default. Going back to the old site is sometimes right and usually not. We say which, with the evidence.
- Blame the migration for everything. If the drop matches a Google update and not your launch, we say so before you pay for the wrong fix.
Site Migration FAQ
It depends on how much was lost and how quickly Google recrawls the site. For a broken migration we usually see recovery build over 4 to 10 weeks after the fixes are in place.
Usually not, but sooner is better. Redirects added late still help, and Search Console keeps 16 months of data, so the old picture can still be rebuilt. The longer the old URLs have returned errors, the less of their history carries over.
No. Search Console history, the old sitemap if you have it, and web archives are normally enough. A backup of the old site helps if one exists.
Yes. Send the staging URL and the current live site, and the Recovery Audit becomes a pre-launch check of the same seven things.
Read access to Google Search Console and the launch date. For the Recovery Fix, access to the redirect settings or a developer we can brief.
Yes. The work is async and in writing, so time zones do not matter. International clients are billed in USD by card or PayPal.