NegativeSEO.ICU logo — negative SEO reference and recoveryNegativeSEO.ICUNegative SEO reference & recovery
Guide series

Detecting negative SEO, and the four duller explanations that come first

The symptoms of an attack and the symptoms of an ordinary bad month are the same symptoms, which is why detection is a discipline rather than a hunch.

Detection is diagnosis, and diagnosis is a different job from repair

Detecting negative SEO is the work of establishing whether a third party has done anything to your site at all, and if so what, before any remedy is chosen or paid for. It is diagnostic rather than defensive: nothing about the shape of a traffic loss identifies its cause on its own, so the question am I under attack can only be answered by going and looking at specific records, in a specific order, most of which have nothing to do with links.

The difficulty is not that evidence is scarce. It is that confirming evidence is always available. Every site on the web carries some spam links, has pages Google has crawled and declined to index, and has at least one competitor who moved up this quarter. Nobody was examining any of that the week before the drop, so whatever an investigation turns up will look new, and an investigation that begins by looking for signs of an attack will find some on a site where nothing has happened. That is not a failure of skill. It is what happens when a search is run for a conclusion instead of against one.

So the organizing rule of the whole subject is that diagnosis precedes remedy, and the reason is arithmetic rather than caution. Remedies here are asymmetric: the ones available to a suspected victim mostly subtract. A disavow file discards signal, a crawler block discards traffic, a public accusation creates an exposure that did not exist an hour earlier. When the remedy can only reduce something, buying it on a guess is a wager with no upside, and the only thing standing between an owner and that wager is a diagnosis good enough to be wrong.

The base rate, and the date it moved

Every diagnosis starts from a prior — how likely the explanation was before you looked at anything — and on this subject the prior is unusually lopsided. Most suspected attacks are not attacks, and the reason is not that people are credulous. It is that the mechanism they are imagining stopped being the mechanism.

Between 2012 and 2016 an inbound link profile could drag a whole site down, which made a hostile link campaign a coherent theory of a ranking loss. On 23 September 2016 Google announced that Penguin had become part of its core ranking system and that it now devalues spam by adjusting ranking based on spam signals rather than affecting the ranking of a whole site. The December 2022 link spam update went further in the same direction, describing spam links as nullified — the credit they carried simply lost rather than charged to anybody.

Read that as a statement about diagnosis, not about remedy. Its practical effect is that a wave of ugly inbound links is no longer a sufficient explanation for a fall in traffic, which means finding one is not a finding. Before 2016, spam links plus a drop was a hypothesis. After 2016 it is a coincidence that has to be tested like any other. And date every claim of this kind, including mine: a true sentence about link attacks written in 2013 is a false sentence today, and a great deal of what circulates on this subject is exactly that — accurate reporting that nobody re-dated.

What no honest page can give you is a percentage. No search engine publishes what share of reported ranking losses turn out to be third-party interference, and no study with a disclosed method exists to cite for one. Anyone who quotes you a figure invented it. The reasoning above is inference from Google's own account of why traffic falls plus the documented shift to devaluation — sound, and not a measurement.

The four things a drop is usually caused by instead

Google maintains documentation whose entire purpose is to explain why a site's search traffic falls, and the causes it enumerates — algorithmic updates, technical issues, security problems, spam policy violations, seasonality and shifting interests, migrations, and reporting glitches — contain no entry for sabotage by a third party. That absence is not Google denying hostile links get built. It means something narrower and more useful at eight in the morning: among sites that lose traffic, sabotage is rare enough that the triage document does not budget a paragraph for it.

Collapse that list and four families remain. They are the four things to exclude before the word attack is used at all.

  • A ranking change. Google announces some of what it changes and not most of it. An announcement here means a dated notice that a named system changed, carrying a launch date and a completion date, published on Google's search status dashboard. Both dates matter and reading only the first is the single most productive misreading in the subject, because rollouts have run for weeks and an owner who checks a launch column concludes the update was over long before their traffic moved.
  • A change you made. A template edit that dropped canonical tags, a staging directive shipped live, a migration with unreconciled redirects, a lapsed certificate, a firewall rule, a robots file that stopped answering cleanly. This family resolves more suspected attacks than every backlink tool ever built, and it has a cruel special case: the defensive product installed because an attack was suspected, throttling crawling across the whole site.
  • A change in measurement. A consent banner, a tag manager edit, a new analytics property, a bot filter. Clicks counted at Google's end and sessions counted at yours never reconcile and diverge further whenever tracking changes. The last day or two of any Search Console chart is preliminary data still being collected. And a results page that grew a new feature above you costs clicks without moving a single position.
  • A change in demand. Seasonality, compared year over year rather than against last month. An intent shift on the queries themselves. A competitor who simply got better, which is the explanation people find hardest to accept and the one that is most often true.

Each of those has a discriminator that is free, first-party and takes minutes. None of them requires buying anything. The symptom-by-symptom version of this argument, with the innocent reading of each alarm placed ahead of the alarming one, is in signs of a negative SEO attack; the procedure for dating a fall precisely and matching it against the update record is attack or algorithm update.

What a real attack looks like when it is real

A page that only counsels calm is negligent, because attacks that work exist and the people running them are not imaginary. The useful observation is that the ones that survive diagnosis share a structural property: they changed something, and the change is visible in a first-party record. They are not inferred from a chart.

Three shapes account for nearly all of them. Your own site serving content you did not write — injected pages, injected outbound links, a redirect that fires for a crawler and not for you — which is a security finding and appears as one. Google's index preferring another host for your content, which shows as a canonical selection naming a domain you do not control and is the cleanest positive evidence available anywhere in this subject. And a platform surface altered by somebody else: a business listing edited, a review corpus flooded, a copyright removal filed against specific URLs of yours.

Notice what is missing from that list. "A large number of links appeared" is not on it, because links appearing is an observation about somebody else's web pages rather than a change to anything of yours. The distinction between an attack that altered your assets and an attack that merely aimed something at them is the most load-bearing distinction in detection, and it sorts the subject better than any other cut: the vectors that still work reach inside; the vectors that mostly stopped working stayed outside.

Evidence, suspicion, and the difference between them

Sources in this subject are not interchangeable, and ranking them by what they can settle is most of what expertise consists of here.

Only Google reports what Google decided. A manual action, a security issue and the canonical Google selected for a URL exist inside Google's systems and are disclosed to a verified owner and to nobody else. No third-party product detects any of them; every product claiming to is inferring from ranking movement, and ranking movement cannot separate a penalty from an update from a competitor improving. Google Search Console Help — Google's own documentation set for those reports, and where every definition worth quoting on this subject lives — is the reference for what each report means, and it is worth reading before a vendor explains it to you.

Only your server logs record what actually happened at your end: which address, carrying which user agent, requested which URL, and what it received. That is also the only evidence here that can be authenticated later, and the only one that routinely disappears before anyone thinks to keep it. Third-party crawls sit below both. They estimate what exists on the open web, they are useful for anchor text at scale, and their date axis records when a vendor's crawler found something rather than when anyone made it — which is why so many alarming spikes are somebody's crawl schedule. What each category can and cannot observe is set out in negative SEO tools.

Two verification habits sit underneath all of it. The first is that a user agent is a claim, not an identity. Verifying Googlebot has two documented methods — a reverse DNS lookup on the accessing address that resolves into one of Google's domains, confirmed by a forward lookup returning the same address, or a match against Google's published crawler address ranges. Anything failing both is not Googlebot however it introduces itself, and that one check is the difference between a crawler flood you tolerate and a forged one you rate-limit. The second is that the default answer is not the live answer. URL Inspection reports the most recently indexed version of a page. The live test is a separate tester, run on demand, that fetches the current page as Googlebot receives it, and the gap between the two panes tells you whether a fault is historical or still happening — which decides whether you are remediating or watching.

The rule that keeps a diagnosis interpretable

Do nothing irreversible while the diagnosis is open. That single rule prevents most of the expensive outcomes in this subject, and it is worth naming the five actions it forbids, because each of them is easier to take than to undo.

  1. Filing a disavow file on suspicion, which discards links you earned along with links you did not.
  2. Filing a reconsideration request with no manual action outstanding, which asks a reviewer to reverse a decision nobody made.
  3. Blocking address ranges or crawler classes in a panic, which reliably catches legitimate crawlers and produces a genuine traffic loss that then gets blamed on the attacker.
  4. Deleting or rewriting your own pages because an attacker's anchor text mentioned them, which finishes the job on their behalf.
  5. Naming a suspected competitor in public, which converts a hypothetical search problem into an actual legal exposure.

There is a sixth item that is not a prohibition but a sequence: capture the state of things before you change any of it. Diagnosis alters the thing being diagnosed, and server logs, index states and search results are all destroyed by the ordinary work of fixing them. Everything else on a diagnostic worklist can be redone next week. The logs cannot.

What a finished diagnosis actually says

A diagnosis is finished when it can be written down as a small number of dated statements, each of which could have come back the other way. Not "it looks like an attack" — that is a mood. Something closer to: the fall began on a specific day; a confirmed ranking update did or did not overlap that day; the manual actions and security reports were or were not clean; the loss was site-wide, page-level or confined to one topic; Google's selected canonical for the affected URLs was or was not on a host I control; the logs did or did not show a crawl-side fault in the window.

Two properties make that list worth writing. It is falsifiable, so a wrong diagnosis fails visibly instead of quietly becoming an invoice. And it names its own confidence, which means naming the observation that would overturn it — a habit that costs nothing and is almost entirely absent from commercial reporting on this subject.

Most of the time the honest ending is an update, a deployment or a measurement change. Some of the time the honest ending is not established, which is a real answer rather than a failed one, and considerably better than an attacker invented to fill the gap. The step-by-step version — which report, in which order, and what each one proves — is how to check for negative SEO. What makes the next diagnosis possible is a baseline recorded while nothing is wrong, which is the honest argument for negative SEO monitoring and very nearly the only one.

The thing detection cannot do

Detection establishes what happened and when. It very rarely establishes who, and being clear about that gap is part of doing it properly.

Link indexes show pages, not people. Change monitors report that a file was modified, never who modified it or why. A registration record now discloses far less than it did a decade ago. Attribution surfaces reliably in exactly two places — server logs, which record a requesting address and agent, and published takedown notices, which carry a submitter's own claims about their identity — and it surfaces circumstantially in a third, which is the case where the intruder used credentials nobody revoked when a relationship ended. Everything else is inference, and inference is not something to put in a letter.

The practical consequence is worth stating flatly, because it disappoints people and it is still true: a diagnosis strong enough to act on is usually not a diagnosis strong enough to accuse anybody with. Those are different standards of proof, they are reached at different costs, and treating the first as though it were the second is how a search problem becomes a legal one. Fixing your own site needs the first. Anything aimed at another party needs the second, and it needs counsel before it needs a consultant.

Frequently asked questions

How can I tell if my rankings dropped because of an attack?

By excluding rather than confirming. Date the fall to the exact day, check that day against Google's published update record, open the manual actions and security issues reports, then list every change made to your own site and your own tracking that week. If all four come back clean and the loss is still unexplained, you have a candidate — not before. Running the checks in the other order produces an attacker on almost any site, because every site has spam links and a competitor who moved.

A tool says my site is under negative SEO attack. Is that a detection?

No, because no third-party tool can see the things that would settle it. A manual action, a security issue and Google's canonical choice exist only inside Google's systems and are reported only to a verified owner. Any product announcing an attack is reading link counts or ranking movement, and neither can distinguish sabotage from an update, a deployment or a rival improving. Treat the alert as a prompt to run the checks, never as their result.

How quickly would a real attack show up?

It depends on the vector, and that dependency is itself diagnostic. Changes to your own site — injected pages, an altered redirect, a hijacked canonical — can register within a crawl cycle and are visible in URL Inspection within minutes of looking. Inbound link campaigns cannot move that fast, because discovery, reprocessing and any consequence are spread over weeks. So a one-day cliff makes links the least likely explanation rather than the most likely one.

Do I need to buy anything to detect negative SEO?

Not for the checks that decide most cases. Search Console verification is free and first-party, your own server logs already exist if retention has not thrown them away, and Google's update record is published. The paid layer buys anchor text at scale and a dated discovery record, which are genuinely useful and which answer none of the questions that settle a diagnosis. Anything sold as a negative SEO detector is inferring from data that cannot support the inference.

What should I not do while I am still working out what happened?

Anything irreversible. No disavow file, no reconsideration request, no crawler or address blocks, no deletion of your own pages, and no public accusation. Each of those adds a variable to a picture that is already unclear, and at least two of them can create a genuine incident on top of the suspected one. Capture the current state first — exports, screenshots with dates, and above all the server logs, which are the only evidence here that cannot be recreated later.

Can detection tell me who attacked me?

Almost never. Tooling in this subject observes pages and file changes, not people, and public registration data now hides most registrant detail by default. Attribution genuinely surfaces in server logs, in published takedown notices, and in the fairly common case where the access used belonged to a former employee, contractor or agency. Absent one of those, what you have is a description of what happened, which is enough to repair a site and not enough to name anyone.

Top