Preventing negative SEO means shrinking what a stranger can change

What prevention can mean, and what it cannot

Preventing negative SEO is reducing the number of ways a third party can change something you own. That is the whole of the definition, and it is deliberately narrower than the phrase suggests, because the wider version is not available: nothing stops a stranger publishing a page that links to you, filing a report about you, or writing something false about you. Those acts happen outside your perimeter, on infrastructure you do not control, and no subscription reaches them.

What is available is control over the things a hostile party would otherwise be able to alter — your files, your templates, your redirects, your DNS records, your search-side accounts, your business listing. Reframing prevention that way is not a rhetorical trick. It changes the shopping list completely, and it explains why the defensive product most heavily marketed under this heading removes no risk at all while the measures that do remove risk are sold under a different name and a different budget line.

The organizing claim of this section of the site, and the finding the whole corpus produced: every attack that still works against an ordinary site is a security compromise or a platform abuse, and nearly every attack that has stopped working is a link or click-signal attack. Prevention follows from that sentence directly. Security first, platform accounts second, link paranoia last — and last is a considered position rather than a shrug.

The inversion, stated plainly

Spending in this market is close to exactly inverted relative to risk. The category aimed at the attacks that reliably work — patching, credentials, access control, integrity monitoring, backups — is systematically under-purchased, dull to sell, and rarely described as negative SEO defense at all. The category aimed at the attacks that mostly stopped working is sold as essential, priced as insurance, and generates a monthly report whose only actionable output is a recommendation Google's own documentation warns against.

Google publishes its own taxonomy of how sites get taken over, and it reads better as a defensive plan than as background reading. The causes it names are compromised passwords, missed security updates, insecure themes and plugins, social engineering, security policy holes, and data leaks. Now notice the absence: Google's own account of how a site gets ruined contains nothing a competitor can do to you from outside. Five of the six are conditions inside your own administration and the sixth is somebody talking one of your people out of a credential.

Set that beside Google's position on the link side — that it works to keep actions on third-party sites from affecting a website — and the ordering stops being a matter of taste. It is what the documentation says, read in the order the documentation puts it.

What a vulnerability actually is here

A vulnerability is a flaw or a gap that lets somebody do something to a system that they were never authorized to do. In this subject it is almost never exotic. It is an extension nobody updated, a password used somewhere else that has since been breached, an administrator account belonging to a contractor whose engagement finished in March, or an integration token issued years ago for a service the business no longer uses.

Three doors account for practically all of it, and thinking in doors rather than in products is what stops a defense becoming a shopping list.

• Code you run. Every plugin, theme, library and dependency is code you have accepted responsibility for patching. Unused code is the worst kind, because deactivating something is a state in an admin screen rather than a security boundary — the files remain on disk and remain reachable. Deleting beats deactivating, every time.
• Credentials you hold. Reuse converts somebody else's breach into your compromise. Least privilege is the item most often skipped and most often decisive: every administrator account is a full site takeover waiting for one leak, and an editor publishing copy does not need to install code.
• Accounts that own your identity. The registrar, the DNS host, the hosting panel, the search consoles, the business listing, and the mailbox that resets all of them. Failure here does not damage the site. It takes the site.

The uncomfortable qualification that hardening guides tend to smooth over: diligence has a ceiling. Defensive code is still code, and a documented authentication bypass has appeared in a security plugin's own two-factor feature, exploitable precisely because that feature was switched on. Components have been altered at their source, inside an official repository, so that the provenance rule everybody repeats would not have helped. The correct inference is not despair and not more plugins — it is fewer moving parts, and monitoring for the change rather than trusting the supply chain to stay clean. The platform-specific version is hardening WordPress against attacks, which matters because that is what most victims are running.

The perimeter is bigger than the website

Most defensive effort stops at the content management system, which is the visible thing. The accounts around it are less visible and their failures are worse, because they are unrecoverable at your end.

Start with status. A domain carries status codes — flags recorded against the registration that describe what may be done to it — and reading yours takes about a minute. ICANN documents both families: the client codes set from inside your registrar account, which is what most people mean by domain lock, and the server codes set by the registry itself, described as uncommon and usually enacted during disputes or at the registrant's request. That difference is the entire point of the paid registry lock service: because the registry holds the flag and no login can clear it, it is the only control in this whole area that still protects a domain after the registrar credentials themselves are compromised. For a business that would stop trading without its domain, that is worth pricing. For a side project the client-side codes are proportionate.

Then DNS, where an attacker who gets in does not need to touch your server at all — they simply change where your name points. The audit is unglamorous and effective, and it is the first action required by the United States cyber agency's emergency directive on DNS tampering, issued in January 2019 after a documented campaign of credential theft: verify that every published record resolves where it is meant to, change the passwords on every account that can edit DNS, require multi-factor authentication on all of them, and watch for certificates issued that you did not request. Delete the records nobody can explain, because stale address entries and orphaned verification strings for services long since dropped are how old access survives. Certificate transparency monitoring is close to free; a certificate issued for your name that you did not request is among the earliest signals a hijack is under way. Expect your CDN and mail provider to generate the first false positives.

Then the search-side identity, which is the part practitioners forget precisely because it feels administrative. Verify the domain rather than a single prefix, so that spam injected under a subdomain still produces a notification. Audit who is verified, and know that removing an owner does not revoke their verification token — the file in your web root or the record in your zone lets them verify again at will. Own the properties inside the business and grant agencies access rather than ownership, because ownership sitting outside the business is what turns an ordinary supplier relationship into an unrecoverable one.

Two-factor authentication, and its honest limits

If only one control gets implemented this quarter, enable 2FA on every account that can change anything. Two-factor authentication demands a second proof of identity beyond the password — a rotating one-time code from an app, or a tap on a hardware key — at every login, and it is the one control still standing after a password has been guessed, phished, reused or bought. Compromised passwords sit first on Google's own list of how sites get taken over, and this is the measure that makes that first item survivable.

Enable it everywhere the perimeter runs, not just on the site: the registrar, the DNS host, the hosting panel, the search console account, the business listing, and above all the mailbox that receives every reset link on the list. That mailbox is the master key and it is routinely the least protected account in the set.

Three limits deserve saying out loud, because a control sold as absolute gets trusted past its range. Application passwords, API tokens and integration keys bypass the login form entirely, and therefore bypass the second factor entirely — audit and revoke them in the same pass as the user list, because they are the most forgotten credential class there is. A one-time-code app or a hardware key is meaningfully stronger than an SMS fallback. And on platforms where the second factor arrives as an add-on rather than in the core, the implementation is itself code you have to keep patched, with the same urgency as everything else.

The complete version of this list, in risk order and with a way to confirm each item is done rather than believed to be done, is the protection checklist; the reasoning behind the ordering is set out at length in protecting a website from negative SEO.

Recoverability is part of prevention

Prevention that only tries to stop things is half a plan, because some of them will happen anyway. The other half is the ability to get back, and to find out what occurred — and both have to exist before the incident, which is what makes them prevention rather than response.

Backups have two halves that get separated at the worst moment: the files and the database live in different systems, and a files-only archive restores an empty site. Beyond that, three properties decide whether backups help. At least one copy outside the hosting account, because the same credentials that reached the site reach a copy stored beside it. Retention that outlives your realistic detection lag, because seven days of restore points do nothing for a compromise found six weeks late. And a restore that has actually been performed, with a stopwatch running, because an untested backup is a hypothesis and the number worth having is how many hours a full restore takes.

Then the records that make a later diagnosis possible at all: extended server log retention, a dated crawl of your own site, periodic first-party exports of the reports that hold no history, and a rank record that stores the whole result set rather than only your own position. None of these prevent anything. All of them are the difference between reconstructing an incident and asserting one, and every one of them has to have been running beforehand — configured afterward, they say nothing about the event. That is the entire honest case for continuous watching, and it is an evidentiary case rather than an operational one; backlink monitoring and alerts makes it in full, including why the alerts themselves usually call for no action.

What cannot be prevented, and what is sold as if it could

Say this part plainly, because a reader will not get it from a vendor and it is where the money goes.

• A standing, pre-emptively maintained disavow file. Google's criteria are conjunctive and the word and does the work: a considerable number of spammy links, and a manual action they have caused or will likely cause. A precautionary file satisfies neither limb, and Google warns in the same document that incorrect use of the tool can harm a site's performance. This is not a harmless waste of money. It has a downside.
• Toxic backlink monitoring subscriptions. The scores they are built on are vendor inventions with no counterpart inside any search engine's published documentation, and the product's entire output is a standing recommendation to use the tool above.
• Automated disavow-on-threshold services, which combine both errors and remove the human who might have noticed.
• Broad crawler and address-range blocking to deter scrapers. The reliable outcome is blocking legitimate crawlers and deindexing yourself, after which the lost traffic gets attributed to an attacker.
• Filing a reconsideration request as insurance. With no manual action outstanding there is nothing to reconsider, and the control to file one does not exist.
• Registering defensive domain variants as a link-attack measure. Genuinely useful against typosquatting and brand impersonation, and useless for this.

The general test, and it applies beyond this list: if a product cannot name the decision its output informs, it is selling alarm. A control that removes a way in is prevention. A subscription that reports on somebody else's web pages is a newsletter with a threat model attached.

Prevention is a schedule, not a project

Every control described here decays. Extensions go stale, staff leave with access intact, tokens outlive the integrations they were issued for, verification tokens sit in a web root long after the owner was removed, and a card on file expires so that a domain is lost to a payment failure in a way indistinguishable from a theft.

So the last item is calendar work rather than technical work. Platform and extension updates, an owner audit on the search properties, a restore test, and a review of who still has access are all recurring, and access removal is not a schedule item at all — it belongs on the day somebody leaves. A checklist worked once and never again decays into a screenshot of a good afternoon.

One closing disclosure, because it is the reason this page is worth reading. A practice that sells negative SEO recovery has an obvious commercial interest in telling you that the link half of this subject is dangerous and that protection from it is purchasable. The evidence does not support it, the ordering above is what the documentation says rather than what the invoice would prefer, and I would rather lose the engagement than have you buy the wrong thing. If something has already happened, the frame to start from is detection, not remediation.

Frequently asked questions