Diagnose a traffic drop
Traffic drop diagnosis: read the shape, then the date, then the cause
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, then the date, then go to the page that deals with that cause.
Prefer to talk it through? Book a strategy call
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, which is enough to send a diagnosis in the wrong direction.
Where to go from here
This page classifies the drop. These pages take it further
Use the shapes below to put a name on the drop. If you want the whole investigation step by step, or you already know the cause and want it fixed, go straight to one of these.
Work through it yourself
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 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 gone anywhere |
One chain, four break points
Every cause below breaks the same chain in a different place
A URL has to survive four separate steps to still be earning clicks. The causes are not a list of unrelated faults. Each one severs the chain at a different link, which is why each needs different evidence.
- 1URLs that once earned clicks — A larger set than the page list in your content system, and reconstructable from Search Console history, analytics, server logs and link exports.
- 2Still reachable at an address — A migration with partial redirects shows as a cliff on the launch date and a coverage report full of pages that used to earn.A redirect map built from the sitemap, which never held the older earning URLs
- 3Allowed into the index — Shows as a decline over one to three weeks rather than one day, because pages drop out as they are recrawled. The site looks normal to a visitor.A staging noindex or robots rule promoted to production by accident
- 4Still ranking against the results — The slow bleed with no event to attach it to. The least dramatic cause, the most expensive to reverse, and the one most often called a penalty.Pages that fell behind competitors who have visibly reinvested
- 5Still being clicked — Clicks fall while impressions hold. You are still ranking and fewer people are choosing you, so the fix is in the snippet rather than in an audit.A feature, an answer or a rewritten title taking the click above you
What it often turns out to be
Five common causes, 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 better pages 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 straight 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 real 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 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 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.
Prefer to talk it through? Book a strategy call
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
References
Sources
The primary documents and published research this page relies on. Platform rules change, so check the source before acting on a detail.
Last updated · Published by Zubair Afzal (responsible editor), on owner authorisation