If your traffic dropped sharply and Google confirmed a core update in the same window, you are not looking at a penalty. You are looking at a re-scoring of how useful your pages are compared with everything else that could answer the same query. Google core update recovery starts with an honest diagnosis, not a panic list of fixes. Before you change anything, you need to know which pages lost, which queries they lost, and whether the update is even the cause.
This post is the sequence our team follows when a site slides after an update. It is deliberately slow in the first two weeks and deliberately blunt after that. It reflects the way we structure ongoing search work for Indian businesses, where one enquiry form often carries the whole month. Nothing here promises a return to your old numbers, because nobody can honestly promise that.
What a core update is, and what it is not
A core update is a broad change to how Google weighs relevance and quality across every query. It is not a manual action. There is no notification in Search Console and no reconsideration request to file. Your pages did not become worse overnight; their position in a re-sorted set changed, which is a different problem with a different fix.
That distinction rules out the reflexes most owners reach for first. Swapping title tags, adding three hundred words, or repeating the keyword a few more times will not move a page whose whole approach to the query is now second best. It also rules out self-blame. A site can be clean, fast and honest and still lose ground because two competitors published something more useful.
One more thing a core update is not: permanent. Pages come back when the reason they were outranked stops being true. That almost always means real work on the page rather than a settings change.
How do you confirm a core update actually hit you?
Open Search Console, compare the 28 days after the rollout started with the 28 days before it, and split the data by page and by query. If the drop begins inside the rollout window and concentrates in particular page types, the update is the likely cause. If it started earlier, look elsewhere.
Do that comparison in this order. It takes about an hour and saves weeks of guessing.
- Note the exact rollout start and end dates Google published for the update.
- Compare the 28 days after the rollout began with the 28 days before it in Search Console.
- Split by page type: home, service pages, location pages, blog posts, product pages.
- Split by query type: brand, service plus city, informational, comparison, price.
- Read impressions separately from clicks, because steady impressions with fewer clicks is a different problem.
- Confirm no change of your own landed in the same fortnight.
If the loss is spread evenly across every page type, a broad quality reassessment is plausible. If it sits inside one template or one folder, the problem is narrower and easier to fix. If your average position held but clicks fell, you may be losing the click to AI answers and richer result formats, which the shift from classic search to answer engines covers in detail.
And if Search Console shows the slide starting weeks before the rollout, stop blaming the update. The ordinary reasons a site stops ranking are worth ruling out before you attribute the loss to a core update.
What should you not do in the first week?
Do nothing structural. Do not delete pages, do not redirect them into each other, do not rewrite your main templates, and do not change agencies on day three. Rankings keep moving until a rollout has finished, so anything you change now becomes impossible to measure later.
Week one is for recording, not repairing. Capture the evidence while it is fresh, because Search Console data ages out and nobody remembers in March what was changed in January.
- Export 16 months of query and page data before the window rolls forward.
- Record current positions for the 20 queries that actually produce enquiries.
- Write down the rollout dates, the update name Google published, and the day your drop began.
- Check whether enquiries fell in the same proportion as sessions, or less.
- Confirm nothing on your side changed: no migration, no theme update, no robots.txt edit, no plugin swap.
- Tell your sales team what to expect so a slow fortnight does not get misread.
A structured diagnosis: four causes worth ruling out
Once the rollout has finished, work through the four failure modes below in order. It is common for more than one of them to be running at once. The table maps the pattern you see in Search Console to the cause you should investigate first.
| What you see in Search Console | Most likely cause | Check this first |
|---|---|---|
| Blog posts lost, service pages held | Unoriginal content | Whether the post contains anything a reader cannot find elsewhere |
| Service and city pages lost on local queries | Thin or duplicated pages | How many of those pages carry unique, verifiable local detail |
| One template lost across hundreds of URLs | Site-wide quality drag | The ratio of useful pages to filler pages in that folder |
| Positions held but clicks fell | Intent and result format mismatch | What the top five results look like for those queries |
| Sessions fell but enquiries held | Loss of low-intent traffic only | Whether the lost queries ever converted |
Intent mismatch
This is a common cause and one of the least discussed. Your page answers the question you wanted the searcher to have, not the one they typed. Read the top five results for a lost query and ask what format they share: a price, a comparison, a checklist, or a booking page. If your page is a different format, rewriting sentences will not help.
Thin or duplicated pages
Plenty of Indian service sites carry dozens of near-identical city pages built from one template with the location name swapped. Those pages survived for years and now drag the whole domain down. Either give each one genuine local substance, or cut the set back to the areas you actually serve. That decision gets easier once you see how local and national search strategies pull in different directions.
Weak experience signals
Slow pages, aggressive pop-ups and unusable mobile forms do not cause a core update drop on their own. They do decide close contests, and after an update a lot of contests are close. Start with the pages that lost the most and measure them against Core Web Vitals field data rather than a lab score from a single test run.
Unoriginal content
If a blog post is a rearrangement of the top three results, it was always borrowed authority, and core updates are efficient at removing borrowed authority. The test is simple: does the page contain anything a reader cannot get elsewhere? Your own pricing logic, your own failure cases, photographs of your own work, numbers from your own projects. If the answer is no, editing it will not save it.
Google core update recovery: a 60 day plan
This is the schedule we run. It follows the same Connect, Build, Launch, Optimise method our team uses on every engagement, compressed into two months and with weekly checkpoints.
- Days 1 to 14: record everything, change nothing, and wait for the rollout to finish.
- Days 15 to 21: segment the loss and pick the 20 percent of URLs carrying most of the damage.
- Days 22 to 35: fix intent first, rewriting or replacing those pages so the format matches the query.
- Days 36 to 45: consolidate near-duplicates into one strong page, redirect the rest, remove what you cannot justify.
- Days 46 to 52: repair experience issues on the pages you just reworked, not across the whole site.
- Days 53 to 60: rebuild demand you control, through your profile, reviews, email list and referrals.
- Then hold, and re-measure at the next confirmed core update rather than every Monday.
Notice what is missing. No disavow file, no keyword density tool, no fresh batch of thin posts, and no appeal to Google. None of those has a mechanism by which it could reverse a quality reassessment.
How long does recovery usually take?
Plan for one to two full core updates, which in practice means months rather than weeks. Google re-rates quality on its own schedule, so a page you improve this month may sit unchanged until the next broad rollout. In our experience, reworking substance gives a page a better chance than tuning details does.
That is uncomfortable to hear when enquiries have halved. It is also why the second half of the plan puts effort into channels you control rather than waiting on an algorithm. Our team does not guarantee rankings for any client, before or after an update, and you should be wary of anyone who does.
When rework beats repair
Sometimes the honest answer is that a site cannot be edited back into contention. If the content was written to fill a keyword list rather than to answer anything, or the whole site is one template with a different city in the heading, patching it costs more than replacing it. That call is easier to make with numbers in front of you.
For budgeting, local SEO in India typically runs Rs 15,000 to Rs 40,000 a month and national SEO Rs 40,000 to Rs 1,50,000, depending on how many pages and markets are in scope. A rebuild is a separate line item: brochure sites sit under Rs 50,000, while custom builds run to Rs 5 lakh and beyond. If the structure itself is the problem, a proper rebuild usually beats another six months of edits. Send the Search Console export and your list of lost URLs through our enquiry form and we will tell you which of the two you are looking at.
Businesses in Pune and Pimpri-Chinchwad can have that conversation at our Akurdi office, and we run the same process remotely for clients in Vadodara. Either way the first step is data, not opinion, which is how our search team in Pune opens every engagement.
Frequently asked questions
Can we recover before the next core update?
Sometimes. Google re-crawls and re-evaluates pages continuously, so a genuinely improved page can gain ground between updates. Site-wide reassessments tend to settle only when the next broad update runs. Plan for the slower case and treat early movement as a bonus.
Does disavowing links help after a core update?
Almost never. Core updates are about content quality and relevance, not link penalties, and Google ignores most low-quality links without being asked. Use the disavow tool only if you have a manual action or a real history of paid link building.
Should we delete the pages that lost traffic?
Not as a first move. Deleting a page removes it from the index but does not tell Google your site improved. Merge near-duplicates into one useful page and redirect them, and delete only the pages you would be embarrassed to show a customer.
Do you guarantee that our rankings will come back?
No. We do not guarantee rankings for any client, and no agency controls how Google scores a query. What we commit to is a documented diagnosis, weekly checkpoints, a clear scope of work, and a reply within one business day.
Getting back to steady ground
A core update is feedback, not a verdict. It tells you that for the queries you care about, somebody is now answering better than you are. The work is to find where that is true, rebuild the pages that matter commercially, and stop spending on the ones that never earned their place.
Recovery is slower and less tidy than most articles admit, and some sites need substantial rework rather than repair. If you want a second opinion on which of those applies to you, start a conversation with our Akurdi team with your Search Console access ready, and we will go through the data with you before anyone suggests a budget.
