A recognisable arc: a massage site climbs steadily for two or three months, reaches the first page for several district queries, and then loses most of it inside a fortnight. Nothing was changed. Nobody was told why. This piece is about the three causes behind that arc and how to tell which one you are looking at, because the recovery differs completely.
Cause one: the aggressive phase caught up
The most common by a distance. Rankings were bought with tactics that work quickly and then stop working: bulk directory links, generated location pages, text written to hold keywords. The rise is real and so is the fall - the site is not penalised so much as re-evaluated once the engine has enough signal.
How to tell: the drop hits the generated pages hardest while genuinely useful pages hold. Check whether the URLs that lost the most are the ones that were cheapest to produce.
Cause two: near-duplicate mass crossed a threshold
Fifty district pages differing only by the district name will rank for a while. As coverage grows, the proportion of the site that is near-duplicate rises, and at some point the assessment stops being per-page and becomes site-wide. This is why the drop feels sudden after months of nothing.
How to tell: the loss is even across the site rather than concentrated, including on pages that were written properly. That evenness is the signature.
Cause three: something technical broke quietly
An age gate deployed in front of the content, a robots rule that widened, a migration that lost canonicals, a certificate error the crawler saw and visitors did not. Less common than the first two but far cheaper to fix, which is why it is worth ruling out first.
How to tell: check crawl statistics and index coverage before anything else. A technical cause usually leaves a visible date and a visible drop in pages indexed.
Telling them apart in an afternoon
| Symptom | Most likely cause | First move |
|---|
| Generated pages lost, good pages held | Aggressive phase | Remove or rewrite the generated set |
| Even loss across the whole site | Near-duplicate mass | Consolidate; fewer, better pages |
| Pages indexed dropped on a specific date | Technical | Crawl report, then the deploy log for that date |
| One query lost, the rest intact | Competition, not a problem | Look at who now occupies the position |
What recovery actually involves
For the first two causes, recovery means having less: removing the generated pages rather than improving them, consolidating district coverage down to the areas with real demand, rewriting service copy as explanation. Operators consistently resist this because it feels like undoing work, and it is - the work was the problem.
Timelines are not encouraging and should be stated plainly. A technical fix can show movement within weeks. Recovery from near-duplicate mass takes months and does not always return the site to its previous peak, because that peak was partly borrowed. Building fewer, better pages from the start is dramatically cheaper than earning back trust.
If you are already choosing a contractor rather than diagnosing this yourself: here is what we do for massage and spa sites.
The first forty-eight hours
The instinct after a drop is to change something. Resist it: a change made now is indistinguishable from the cause when you try to read the recovery later. Do this instead, in order.
- Record the date the drop began, from impressions rather than from position.
- Pull index coverage and compare the indexed count with the week before.
- Check the deploy log for anything that shipped in the three days before that date.
- Fetch three affected URLs as the crawler and read what comes back.
- Only then decide which of the three causes fits.
Steps two to four take about an hour and rule out the technical cause, which is the cheapest to fix and the easiest to miss.
Sizing the damage honestly
Position is the wrong metric for this. Measure impressions by page type before and after: it separates a site-wide assessment from the loss of a handful of queries, and it survives the ranking noise that makes position charts look dramatic.
Then convert to enquiries, not to traffic. A drop that removed pages which never produced a booking is a cosmetic loss; a drop on the two district pages that produced most of the calls is an operational one, even when the traffic numbers look identical. In this category those two situations look the same in an analytics dashboard and completely different in the appointment book.
The rebuild, in order
Consolidate first: fewer pages, each with a reason to exist. Rewrite second, as explanation rather than as keyword placement. Rebuild proximity signals third. Only then look at links, which is the reverse of the order most operators choose and the reason recoveries stall.
Expect the site to look smaller when it is finished. Forty district pages becoming eight, with the eight actually describing their areas, is a normal outcome and usually recovers more traffic than the forty ever held.
Not repeating it
The pattern is self-inflicted and avoidable. Build a page when there is a query for it and not before; write for someone who will read it; add locations at the pace you can describe them properly. A site built that way climbs more slowly and does not have this arc - which is worth more than the months of ranking that get borrowed and then returned.
Common questions
Our rankings dropped without any changes. Why?
Usually the site is being re-evaluated after a phase of quick tactics, or the proportion of near-duplicate pages crossed a threshold and the assessment became site-wide. Rule out a technical cause first - it is rarer but far cheaper to fix.
How do we tell a penalty from ordinary competition?
Look at the spread. Losing one query while the rest hold is competition. Losing evenly across the site, including on well-written pages, points at a site-wide assessment.
How long does recovery take?
A technical fix can move within weeks. Recovery from near-duplicate mass takes months and may not return the site to its previous peak, because part of that peak was borrowed against tactics that stopped working.
Related reading