Checking for negative SEO, in the order that keeps you out of trouble

The rule that governs everything below

Establish what happened before establishing who did it. Nearly every wasted month in this subject comes from running these steps backwards - opening a backlink tool first, finding spam, and reasoning back to a cause. Every site has spam links. None of them were being examined the week before the drop, which is precisely why whatever you find will look new.

Google's own enumeration of why traffic falls - algorithmic updates, technical issues, security threats, spam policy violations, seasonality, migrations, reporting glitches - does not include third-party sabotage. Sabotage is the residual you arrive at after the documented causes are excluded, not the hypothesis you open with.

Second rule, and it is the one that saves people from themselves: do nothing irreversible until the end. No disavow file, no reconsideration request, no robots.txt edits, no crawler blocks, no public accusation. Each of those is far easier to do than to undo, and at least two of them can create a real incident on top of the suspected one.

What follows is the order I work in. It is deliberately front-loaded with the checks that are free, first-party and conclusive, and it puts the expensive, ambiguous, third-party data last - which is the reverse of how most audits are sold.

Step 0 - preserve the evidence before you change anything

Diagnosis alters the thing being diagnosed. Capture state first, because if this does turn out to be sabotage, what you capture now is the only contemporaneous record that will ever exist, and it is the difference between a timeline counsel can use and an assertion nobody can test.

• Export Search Console Performance for the widest range available, with a date comparison applied.
• Export the Links report both ways. Google documents two paths with different limits: the Export button on the report's landing page yields up to 100,000 rows, while the per-table download yields a single table capped at 1,000. Take both; they are not the same data.
• Screenshot the brand results page - the full first page for the company name, dated, including the Business Profile panel if one appears.
• Snapshot the site: a crawl of your own site as it stands now, plus copies of robots.txt, the server configuration, the sitemaps and the theme templates.
• Preserve raw server logs before rotation deletes them. Most default configurations discard logs within days or weeks. This is the evidence most often lost, and the only evidence that records what actually requested what.

That last item is the one people skip and the one they later need. Logs cannot be reconstructed. Everything else on this list can be redone next week; the logs cannot.

Step 1 - manual actions and security issues, which are not the same thing

Search Console's Security and Manual Actions menu holds two reports that get conflated constantly, including by people selling remediation. They are different mechanisms, with different causes, different symptoms and different remedies, and the difference decides what you do next.

A manual action is a penalty in the ordinary sense of the word - the only thing on Google's side that deserves it. Google's Manual Actions report documentation states that Google "issues a manual action against a site when a human reviewer at Google has determined that pages on the site are not compliant with Google's spam policies," and that "If a site has a manual action, some or all of that site will not be shown in Google search results." A person decided. The action types are named and listed, and the one that matters here is Unnatural links to your site, described as Google having "detected a pattern of unnatural, artificial, deceptive, or manipulative links pointing to your site."

A security issue is a safety judgment, not a spam judgment. Google's Security Issues report documentation covers cases where "a Google evaluation determines that your site was hacked, or that it exhibits behavior that could potentially harm a visitor or their computer," across hacked content - "any content placed on your site without your permission because of security vulnerabilities in your site" - malware and unwanted software, and social engineering, which is "content that tricks visitors into doing something dangerous, such as revealing confidential information or downloading software."

Say the distinction to yourself in one sentence each. A manual action is a spam judgment about your site's own behavior, issued by a person, that suppresses ranking or listing. A security issue is a judgment that your site is dangerous to visitors, which puts warnings and interstitials in front of users and therefore destroys traffic without necessarily changing your rankings at all. Owners who confuse the two spend weeks on links while an interstitial is doing the damage.

Both are cleared through a reconsideration request, which Google defines as "a request to have Google review your site after you fix problems identified in a manual action or security issues notification." With neither outstanding there is nothing to reconsider, and filing anyway spends a channel you may later need. A clean Manual actions report is also the gate on the disavow tool, which Google restricts to cases where the links "have caused a manual action, or likely will cause a manual action, on your site."

Step 2 - Performance, and dating the event to the day

Open Performance, Search results, and turn on all four metrics: impressions, clicks, click-through rate and average position. Then read them as a combination rather than one at a time, because the combination is the diagnosis:

• Impressions down, position down, clicks down - a genuine ranking loss. Update, technical fault, or rarely an attack.
• Impressions flat, position flat, clicks down - the results page changed shape, or your measurement did. Not a ranking event.
• Impressions down, position flat, clicks down - demand fell. Seasonality or changing interests.
• Impressions flat, position down - you were displaced within the same set of impressions.
• A sharp fall confined to one country or one device - almost never an attack. Check hosting, geo-routing and tracking.

Do the country and device split explicitly. It takes two clicks and resolves a large share of cases before anyone looks at a link.

Then discard the last day or two of the chart before concluding anything. Google states that "The newest data can be preliminary, meaning it's still being collected and might change in the next few hours," and a meaningful share of "my traffic just collapsed" reports are the trailing edge of an incomplete collection window.

Now date the fall precisely - to the day, from the Dates table rather than by eye on the chart - and take that date to attack or algorithm update, which is the discrimination procedure and probably the page you actually need. Google's own instruction on timing applies from here on: wait "at least a full week after a core update completes before analyzing your site in Search Console."

Step 3 - the Page indexing report, read by delta

Indexing, then Pages. The purpose, per Google, is to "See which pages Google can find and index on your site, and learn about any indexing problems encountered." The mistake is reading the table by size. Sort it by change since the drop date instead. Absolute counts are noise; deltas are signal.

The rows divide cleanly into three groups, and knowing which group moved tells you where to look:

• Self-inflicted or hosting: "URL blocked by robots.txt," "URL marked 'noindex'," "Not found (404)," "Server error (5xx)," "Soft 404," 401 and 403. A jump here is your configuration or your host, and it is by far the most likely finding.
• Consolidation: "Duplicate without user-selected canonical," "Duplicate, Google chose different canonical than user," "Alternate page with proper canonical tag," "Page with redirect." A sudden rise in these is the report-level fingerprint of the canonical and redirect hijack families, and it is the one pattern in this report worth escalating immediately.
• Ordinary: "Crawled - currently not indexed" and "Discovered - currently not indexed." These alarm owners more than any other rows and mean the least. A page Google has seen and not yet found a reason to keep is not a page anyone attacked.

A duplicate here means one thing only: two or more URLs Google considers to be the same content, of which it will index one. Which one it picks is the subject of the next step, and it is the question the whole procedure has been walking toward.

Step 4 - URL Inspection, and the field that decides the case

URL Inspection is the tool at the top of Search Console that reports what Google knows about a single address - whether it is indexed, how it was found, when it was last crawled, and which version of it Google treats as authoritative. It is the most under-used tool in the console and the only one that gives a per-URL, first-party answer. A URL here is simply one addressable page; the point of inspecting one is that site-level reports average away exactly the detail an attack leaves behind.

Start with the caveat, because misreading it wastes days. Google's URL Inspection documentation says the default result "is not a live test. The results shown are from most recently indexed version of a page, not the live version on the web." Always run Test live URL afterwards and compare the two panes. The difference between them tells you whether a fault is historical or current, which is the question that decides whether you are remediating or monitoring.

Read the fields in this order:

1. Google-selected canonical - "The page that Google selected as the [canonical] URL when it found similar pages on your site." If this names a host you do not control, stop the procedure here. That is Google telling you, in the first person, that it treats someone else's URL as the authority for your content. It is the cleanest positive evidence of an attack available anywhere in the tooling, and no backlink report comes near it evidentially. Go to the hijack pages and start remediating.
2. User-declared canonical - what your page claims. Compare the two. A mismatch on your own domain is common and usually benign; a mismatch pointing off-domain is not.
3. Indexing allowed? and Crawl allowed? - these catch a stray noindex or a robots.txt rule in seconds.
4. Page fetch, Last crawl and Crawled as - the last of these matters when a fault is agent-conditional, which is the signature of cloaking on a compromised site.
5. Discovery - how Google found the URL. On a page you did not create, this is where an injected sitemap or a hostile referring page surfaces.

Then inspect a URL you did not create, if any exist. The rendered HTML in the live test shows what Googlebot receives rather than what your browser receives, and that is where a cloaked injection becomes visible.

Step 5 - link data, and the limits of both kinds

Only now do links enter the procedure, and they enter with their limits attached.

First-party: the Links report. Read Top linking text before Top linking sites. Volume is not the finding; anchor distribution is. Google states three limits that all matter: the report "isn't a comprehensive list of every link on your site" but a sample; tables cap at 1,000 rows against a 100,000-row landing-page export; and it "doesn't specify if a link is marked as nofollow," so follow status cannot be derived from it. It also retains links that no longer exist, which routinely produces confident conclusions about pages that returned 404 months ago.

Third-party indexes are useful for one thing - anchor text and discovery dates at scale - and misleading about nearly everything else. They are samples of their own crawls, not of Google's index; their date axis is discovery date, not creation date, so a vertical spike is often the vendor's crawl batch; their toxicity scores are vendor opinions with no counterpart inside Google; and two vendors will report materially different totals for the same site without either being wrong. What each category can and cannot see is set out in negative SEO tools.

The operating rule for both: use link data to build a list to look at, never a list to act on.

Step 6 - logs, crawl stats, removals, and index checks done properly

Server logs are the only source that records what actually happened at your server, by address, agent, timestamp and response code - and the only source that can be authenticated. Extract Googlebot request volume and response codes across the drop window; a shift from 200s to 5xx, 403s or timeouts around the date is a technical finding, and it outranks any link theory. Look for requests to URLs that do not exist on your site, which is the log signature of an injection. Verify anything claiming to be Googlebot by reverse DNS on the accessing address followed by a forward lookup, or by matching Google's published ranges; anything failing both is not Googlebot.

Corroborate in Settings, Crawl stats, and read the host status section before the graphs. Google documents three states there - robots.txt fetching, DNS resolution and server connectivity - and warns that if a robots.txt request "doesn't return either a valid file (either populated or empty) or a 404 (file does not exist) response, then Google will slow or stop crawling your site until it can get an acceptable robots.txt response." This is the most under-diagnosed cause of a site-wide collapse there is, and it is routinely self-inflicted by a firewall rule added in response to a suspected attack.

Do not use site: as a measurement. Google disqualifies it in its own words: the operator "doesn't necessarily return all the URLs that are indexed under the prefix specified in the query," results are "not always exhaustive," "Bigger sites shouldn't expect to see all their URLs in the results," and it is "designed primarily for search users," with owners pointed at URL Inspection instead. It is good for exactly one thing: paging through it looking for pages you did not create. That is a qualitative sweep, not a count.

Then check Removals. The Outdated content tab shows removal requests filed by non-owners through Google's public tool, which is where a third party submitting removals against your URLs becomes visible. Copyright takedowns do not appear there at all - that route runs through public takedown records instead, and it is how a fraudulent DMCA notice is identified.

Finally, look outside Google Search: the Business Profile change history and pending suggested edits, the review corpus, Safe Browsing status, a verbatim phrase search for duplicated content, and Bing Webmaster Tools as a second opinion from a different index. If both indexes show the same pattern, the cause is likelier to be on your site; if only Google moved, the cause is likelier to be a Google ranking change.

Step 7 - write down what you found, in eight sentences

At the end you should be able to complete each of these with evidence attached. If you cannot, the answer is not "attack" - it is "not yet established."

1. The drop began on a specific date, from Performance.
2. A confirmed ranking update did or did not overlap that date.
3. Search Console does or does not show a manual action.
4. Search Console does or does not show a security issue.
5. The drop is site-wide, page-level, confined to one query cluster, or confined to one country or device.
6. Google's selected canonical for affected URLs is or is not on a host you control.
7. Server logs do or do not show a crawl-side fault in the window.
8. The link profile did or did not change materially in anchor distribution, as opposed to in raw count.

Then read the answers together. If an update overlapped, go to the update comparison before doing anything else. If three and four are both clean, no penalty of any kind has been issued against your site - and a penalty is a specific thing, not a mood - which puts the disavow tool out of scope by Google's own criteria. If six comes back off-domain, you have found a real attack and the remediation is known. If seven comes back positive, you have a technical problem rather than an attacker.

Most of the time the honest finding is an update, a deployment or a tracking change. Writing it down in this form is what stops a suspicion becoming a purchase.

Frequently asked questions