Recover lost organic traffic
The shape of the drop tells you what caused it
A cliff on a single date, a slow bleed across months and a broken tracking tag look similar on a dashboard and have nothing else in common. Identify the shape first, then the date, then the cause.
Before you read one word about the last core update, find the exact date your traffic changed. Almost every wrong diagnosis in this field begins with skipping that step.
The date is the single most discriminating piece of evidence available, and it is free. It either lines up with a published ranking update, with a release from your own team, with a tracking change, or with nothing at all — and each of those points somewhere completely different.
Set Search Console to sixteen months and switch the chart to daily. Weekly aggregation turns a cliff into a gentle slope and has probably caused more misdiagnosed traffic drops than any algorithm ever has.
Differential diagnosis
Three shapes of drop, three different investigations
Look at the graph before you look at anything else. The shape narrows the cause faster than any audit, and it takes about a minute.
| Dimension | A cliff on one date | A slow bleed over months | A reporting artefact |
|---|---|---|---|
| What the graph looks like | Normal, then a step down within one or two days, then a new flat line | No single break. Three months later the line is a third lower | An instant drop to a suspiciously round shape, or to near zero on one property |
| First thing to check | What your own team shipped that week, before anything external | Which pages and queries lost, not the total | Whether Search Console agrees with analytics on the same dates |
| Most likely causes | A migration with broken redirects, a noindex shipped to production, a manual action, a robots change, or a documented ranking update | Content ageing against fresher competitors, a rival investing steadily, or losing a search results feature you used to hold | A tag removed in a release, a consent banner change, a new filter or view, or bot traffic being excluded correctly for the first time |
| How to confirm it | Match the exact date against the release log and the published update dates, then crawl the old URL list | Compare position and impressions per page group across a year, not a month | Reconcile server logs or Search Console clicks against the analytics session count |
| Realistic outlook | Often the fastest to fix, and sometimes fully recoverable if it was self-inflicted | Slow. Recovery means the pages become genuinely better, not merely updated | Nothing was ever lost. The reporting was wrong and the correction is the work |
| Common misdiagnosis | Blaming an update that rolled out three weeks after your date | Publishing more content instead of fixing what already ranked | Six months of recovery work on traffic that had not actually gone anywhere |
The sequence
How we work a traffic loss, in order
Each step either eliminates a class of cause or narrows it. Nothing gets changed on the site until the sequence has produced a single hypothesis.
Prove the loss is real
Reconcile analytics against Search Console and, where possible, server logs. If they disagree, the investigation stops here and becomes a measurement repair. This step is skipped constantly and it is the cheapest one available.
You get: Confirmation that traffic, not tracking, changed
Fix the date and the shape
Daily granularity, sixteen months, clicks and impressions on the same chart. Establish whether the break is a step or a slope, and whether impressions fell with clicks or held steady while clicks fell.
You get: A dated, characterised loss
Segment before theorising
Split the loss by page group, query type, device, country and search appearance. A loss confined to one template, one directory or one market is a self-inflicted problem. A loss spread evenly across everything is a different conversation.
You get: Where the loss actually sits
Reconcile against known events
Your release log, CMS history and DNS or hosting changes first. Published ranking update dates second. Manual actions and security issues in Search Console third. Your own team is a more common cause than the search engine.
You get: A timeline with your changes and external events side by side
Form one hypothesis and test it
One, not five. Crawl the old URL set, check indexing on the affected group, compare the surviving competitors against the pages that lost. A hypothesis that survives this is worth spending money on.
You get: A written cause with the evidence attached
Fix in a way that can be attributed
Ship the change that addresses the cause, and ship it separately enough that its effect can be read. Twenty simultaneous changes make the next drop undiagnosable and teach you nothing about this one.
You get: A sequenced remediation plan
What it usually turns out to be
The causes we find most often, and their tells
- A migration went live and the redirects were partial.
- The tell is a cliff on the launch date and a Search Console coverage report full of pages that were once earning. Redirect maps are usually built from the sitemap, which contains the pages someone remembered — not the older URLs that quietly earned links and traffic for years. Reconstructing that list from historical data is tedious and it is normally the highest-value work available.
- Something shipped a noindex or a robots rule to production.
- The tell is a steep decline over one to three weeks rather than a single day, because pages drop out as they are recrawled rather than all at once. It usually originates in a staging configuration promoted by accident. It is the fastest problem on this list to fix and the easiest to miss, because the site looks completely normal to a human visitor.
- Clicks fell but impressions did not.
- You are still ranking and fewer people are choosing you. That points at the search results page rather than at your site: a new feature occupying space above you, an AI answer satisfying the query, a competitor with a sharper title, or your own title being rewritten. The fix is in the snippet and in targeting queries where the click still exists, not in a technical audit.
- A content cleanup removed pages that were working.
- The tell is a drop that follows an internal tidying project by a fortnight, and a set of missing URLs nobody deliberately targeted. Pruning is sound in principle and dangerous in execution, because low-traffic pages frequently carry links, support internal linking, or rank for a small number of very valuable queries that never show up in a page-level traffic sort.
- The pages simply fell behind.
- The tell is a slow bleed with no event to attach it to, concentrated in older pages, while the competitors now above you have visibly reinvested. This is the least dramatic cause and the most expensive to reverse, because the answer is genuine improvement rather than a fix. It is also the one most often mislabelled as an algorithm penalty.
Accountability
How we handle a recovery, and what we will not do
Traffic recovery attracts confident guessing, because the client is anxious and the evidence is rarely examined. These are the rules we work to.
What a recovery engagement commits to
- Establishing the exact date and shape of the loss before proposing a single change
- Separating a ranking loss from a click loss from a tracking loss, with evidence for each
- Showing you the queries and pages that lost, not only the total
- Telling you when the honest answer is that demand fell rather than rankings
- Saying plainly when a page is not worth recovering
- Sequencing fixes so their effects can still be attributed afterwards
What we will not do
- Attribute the drop to a core update without dated evidence that supports it
- Promise that traffic will return to its previous level, or by a particular date
- Ship thirty changes in one release so that nothing can be measured
- Recommend a rebuild before we know what broke
- Publish new content as a response to a technical or indexing problem
- Sell a recovery retainer when the finding is that the tracking was wrong
Questions
What people ask while the graph is still falling
How do I find the exact date the drop started?
Use Search Console rather than your analytics, set the date range to sixteen months, and switch the chart to daily rather than weekly. Weekly aggregation smooths a cliff into a slope and is responsible for a great many wrong diagnoses.
Then compare clicks and impressions on the same chart. If both fell together on one day, look at rankings and indexing. If clicks fell while impressions held, look at what changed on the search results page itself.
Was it a core update?
Possibly, but that should be a conclusion rather than an opening assumption. Compare your exact drop date against the published dates of confirmed ranking updates. If your date falls inside a documented rollout window and the loss is spread broadly across queries rather than concentrated in one section, an update becomes plausible.
If the date does not match anything published, or the loss is confined to one directory, one template or one country, something on your side changed. That is more common than people expect and considerably more fixable.
Can traffic be recovered after a core update?
Sometimes, and never on a promise. Recovery after a broad ranking change typically requires genuine improvement to the pages rather than adjustments to markup, and it usually becomes visible only at a subsequent update rather than immediately.
We will tell you what we think is realistic before you commit budget, including when our honest view is that the pages were not competitive and that rebuilding them is a larger job than a recovery project.
Our traffic dropped but leads did not. Should we worry?
Often not. That combination usually means you lost informational traffic while the commercial pages held, which is a change in the mix rather than a loss of revenue. Chasing it can cost more than it returns.
Confirm it first by segmenting the loss by page group and by query intent. If the pages that lost traffic were never converting, the correct response may be to document what happened and move on.
How long does a diagnosis take?
Usually days rather than weeks, provided we have access to Search Console, analytics, the CMS release history and whoever knows what shipped that month. The date and the shape are normally established in the first session.
The fix is the variable part. A redirect map can be repaired in days; content that has genuinely fallen behind the results it competes with is a quarter of work, not a task.
What if the site was migrated and nobody kept the old URL list?
It is recoverable more often than people assume. Old URLs can usually be reconstructed from Search Console history, from analytics landing page reports, from server logs, from internal link data and from third-party crawl archives.
The reconstruction is tedious and it is normally the highest-value work available after a botched migration, because unredirected URLs that once earned traffic are pure recoverable loss rather than a competitive problem.
Get a dated, evidenced explanation of what happened
Give us read access to Search Console and analytics and tell us who knows what shipped this year. We will come back with the date, the shape, the segment that lost and our single best hypothesis — before any recovery work is proposed.
If we don't deliver the work we agreed to deliver for reasons within our control, you don't pay for the undelivered work. Read our guarantee
Last updated · Reviewed by Zubair Afzal