Protecting a site from negative SEO, in the order that actually matters

The short answer: guard the doors, not the links

Almost everything a stranger can do to your site from outside your perimeter is something Google says it already discounts. Almost everything that has actually cost a site its visibility began with somebody getting write access to something you own. That asymmetry sets the order below, and the order is close to the reverse of how negative SEO protection is normally sold.

1. Keep an intruder out of the site. Patching, credentials, and two-factor authentication - a second proof of identity beyond the password, usually a rotating code from an app or a tap on a hardware key, demanded at every login.
2. Keep an intruder out of the accounts that own your identity - the registrar, whoever answers DNS (the Domain Name System, the lookup layer that turns a domain name into the server address a browser connects to), the hosting panel, and the mailbox that resets all three.
3. Keep control of your search-side accounts - Search Console, Google Business Profile, Bing Webmaster Tools.
4. Be able to get back, from a backup you have restored at least once.
5. Know when something changed, through an alert that reaches a human.
6. Watch the links. Last, deliberately, and mostly for the record.

Working in search since 1996, the pattern I keep meeting is the same: sites that genuinely lost something to a hostile competitor had first lost control of something small - a stale login, an abandoned plugin, a DNS record nobody could explain. Sites that merely received a pile of junk links carried on ranking.

Why security comes first, in Google's own words

Google publishes a list of the ways sites get taken over, and it reads better as a defensive plan than as background. Six causes are named. Compromised passwords: "Attackers may get your password by guessing different passwords until they guess correctly." Missed security updates: "Earlier software versions can have high-risk security vulnerabilities that enable attackers to compromise an entire site." Insecure themes and plugins: "Outdated or unpatched themes and plugins are a major source of vulnerabilities." Then social engineering, security policy holes, and data leaks (Google, Top ways sites get hacked by spammers).

Now notice the absence. Google's own taxonomy of how a site gets ruined contains nothing a third party can do to you from outside. No links, no anchor text, no competitor. Five of the six are conditions inside your own administration; 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 very hard to make sure that actions on third-party sites do not negatively affect a website" - and the hierarchy stops being a matter of taste.

Tier one - keeping an intruder out of the site

Most of the available risk reduction lives here, and none of it is interesting.

Patch everything and delete what you do not use. WordPress.org is blunt: "Older versions of WordPress are not maintained with security updates," and on extensions, "if you are not using a specific plugin, delete it from the system." Deactivated is not deleted - a deactivated plugin's files sit on disk and stay reachable by URL, so a published vulnerability in one is often still exploitable. Per-plugin automatic updates arrived in the WordPress admin with version 5.5 on 11 August 2020, and for a site without staging and somebody watching deploys they are the right default: an unattended layout break is visible and reversible, and a nine-month-old known vulnerability is neither. Platform detail is in hardening WordPress against attacks.

Unique generated passwords, everywhere, in a password manager. Reuse converts somebody else's breach into your compromise. In June 2024 several plugins in the official WordPress.org repository were modified to create rogue administrator accounts and inject search-spam scripts into site footers; Wordfence attributed the intrusion to developer accounts compromised through reused credentials. A password produced a negative SEO outcome across tens of thousands of sites.

Two-factor authentication on every administrator. WordPress core does not ship it, and WordPress.org's brute-force guidance says to add it using a one-time-code app, a hardware key or your identity provider, with SMS as a fallback rather than a first choice. It is the one control still standing after a password has been guessed, phished or bought.

Least privilege, the item most often skipped. Every administrator account is a site takeover waiting for one leak, and editors publishing copy do not need to install code. This also decides whether an intrusion is ever attributable: where recourse exists at all, it is usually because the intruder was a former employee or supplier using access nobody revoked. Audit application passwords and API tokens in the same pass - they bypass the login form, and so bypass two-factor authentication entirely.

Tier two - the accounts that own your name

This tier is invisible until it is catastrophic, because failure here does not damage the site. It takes the site.

The registrar. Two-factor on the login; a registrant email at a domain you also control and which is not the one being protected, since a hijacked or lapsed name takes the recovery channel down with it; auto-renew on, with a card that has not expired. From outside, a domain lost to a dead payment card is indistinguishable from one lost to an attacker.

Registrar lock and registry lock are two different things, and the difference is the point. ICANN documents both sets of status codes - the flags a domain carries describing what may be done to it. The client codes are set by your registrar and are what most people mean by domain lock: clientTransferProhibited, which ICANN describes as telling "your domain's registry to reject requests to transfer the domain from your current registrar to another," plus clientUpdateProhibited and clientDeleteProhibited. The server codes are set by the registry itself, which ICANN calls "an uncommon status that is usually enacted during legal or other disputes, at your request" (ICANN, EPP status codes). Registry lock, the paid service that sets them, requires an out-of-band human authorization rather than a login, which makes it the only control here that survives total compromise of your registrar credentials.

DNS. Two-factor on whoever hosts the zone, plus an actual audit of the records in it. CISA's Emergency Directive 19-01, issued in January 2019 after a documented campaign of DNS credential theft, writes the checklist: verify that public records "resolve to the intended location," change the passwords on every account that can edit DNS, "implement multi-factor authentication (MFA) for all accounts on systems that can make changes" to those records, and monitor Certificate Transparency logs "for certificates issued that they did not request." That last item is free, almost nobody does it, and a certificate issued for your name that you never requested is among the earliest signals of a hijack. Expect false positives from your CDN and mail provider first.

DNSSEC is worth enabling and worth understanding narrowly. The Domain Name System Security Extensions sign DNS answers cryptographically, providing what ICANN calls "data origin authentication" and "data integrity protection" against forged responses. They encrypt nothing, and they do not inconvenience an attacker already logged into your DNS panel signing hostile records with your key. DNSSEC defends the path, not the account, and no Google statement makes it a ranking factor.

Hosting. Two-factor on the control panel, keys rather than passwords for shell access, and the question nobody asks: how long does your host retain access logs, and can you export them? A host keeping seven days of them has decided on your behalf that you will never learn who did this.

Tier three - keeping your search-side identity

Verify a Domain property in Search Console, not only a URL-prefix property. Google's definitions decide the outcome: a Domain property "Includes all subdomains (m, www, and so on) and multiple protocols," where a URL-prefix property "Includes only URLs with the specified prefix." Spam injected under a subdomain you never verified produces no notification at all. There is a dated figure for what that costs: in #NoHacked: A year in review, published 20 March 2017 and reporting on 2016, Google said it could not notify 61% of affected site owners because their sites were not verified. No successor figure exists, so read it as a 2016 measurement of a mechanism that has not changed.

Audit who is verified, and know the trap. Google's hacked-site guidance records that in one common injection pattern "The hacker will typically add themselves as a property owner in Search Console," which hands over your sitemaps, removals, targeting and disavow file. And when you remove a verified owner, Google states that "their verification tokens are not deleted or revoked." A removed owner whose HTML file is still in your web root, or whose TXT record is still in your zone, can verify again at will.

Own the property inside the business, grant the agency access, and route notifications to a monitored shared mailbox as well as an individual - restricted users receive only the messages that specifically affect them, so permission level decides who hears the alarm.

Claim the Google Business Profile before somebody else does. Google's ownership-request process notifies the current owner by email and gives them 3 days to respond; with no response, the requester "may have the option to claim the profile." A three-day email window is the entire defense, delivered to whatever address happens to be on the account. See Google Business Profile hijacking and fake business closure. Repeat the exercise in Bing Webmaster Tools if Bing sends meaningful traffic.

Tier four - a backup you have actually restored

WordPress.org gets the part people miss right: there are two halves, the files in the web directory and the database, which "is stored in a separate database system (usually MySQL/MariaDB)." A files-only backup restores an empty site. Beyond that, copies in different locations and three to five recent restore points.

Three things the documentation does not press hard enough, and which decide how long an incident lasts. A backup you have never restored is a hypothesis - do a real restore into a staging environment once a quarter with a stopwatch running, because the number worth having is not whether backups exist but how many hours a full restore takes. That one is my judgment rather than documentation, and you should know which is which. Retention has to outlive detection: a compromise found six weeks late is not helped by seven days of restore points. And backups must live outside the account, or the same intruder deletes them with the same credentials.

Tier five - knowing that something changed

• Search Console email alerts for Security Issues and Manual Actions, delivered to an address a human opens. Free, first-party, and the earliest genuine warning Google gives anyone.
• External uptime and content-change monitoring on the homepage and two or three key templates - what catches an injected footer script or a conditional redirect, neither of which any search tool will show you.
• File-integrity monitoring, so a new executable file in an uploads directory produces an alert rather than a discovery.
• Safe Browsing status checks run from outside your network, since a browser interstitial halts traffic completely while leaving rankings intact and so looks like nothing at all in a rankings report.
• Analytics and Search Console review on a fixed cadence, compared against a dated list of confirmed Google updates before anything is called an attack. Most suspected sabotage is a core update, a spam update, a botched migration, a stray noindex, or a canonical tag aimed at the wrong page.
• Backlink monitoring, last, and for a reason it is never sold on: the value is evidentiary rather than operational. See backlink monitoring and alerts.

The protections sold hardest, which remove no risk

Say this plainly, because a reader will not get it from a vendor.

• A standing, continuously updated disavow file. Google's criteria are conjunctive and the word AND does all the work: disavow "only if: 1. You have a considerable number of spammy, artificial, or low-quality links pointing to your site, AND 2. The links have caused a manual action, or likely will cause a manual action, on your site." A pre-emptive file satisfies neither. Google calls the tool "an advanced feature" that "can potentially harm your site's performance in Google Search results" if used incorrectly, and says "most sites will not need to use this tool" (Google, Disavow links to your site). This is not a harmless waste of money; it has a downside.
• "Toxic backlink" monitoring subscriptions. Google publishes no toxicity metric and never has - every Toxic Score and Spam Score is a vendor's opinion of a domain. On 31 January 2023, Google's John Mueller said of both halves of that trade: "That's all made up & irrelevant. These agencies (both those creating, and those disavowing) are just making stuff up, and cashing in from those who don't know better." He added: "Don't waste your time on it; do things that build up your site instead." On 12 May 2020 he had already said of the disavow tool that "negative SEO is not a reason we have this tool - and I honestly can't recall a situation where a site ever needed to do a disavow for that." Reported by Search Engine Journal on 2 February 2023 and 14 May 2020.
• Automated disavow-on-threshold services, which take both errors above and add a machine that executes them unread.
• Blocking crawlers and address ranges broadly to stop scrapers. The reliable outcome is blocking legitimate crawlers, Googlebot included, and deindexing yourself - after which the lost traffic gets blamed on the attacker. See content scraping and spoofed Googlebot.
• Link detox and profile rehabilitation retainers sold with no manual action outstanding. If Manual Actions reads "No issues detected", no human reviewer at Google has penalized the site and there is nothing to rehabilitate. The same goes for filing a reconsideration request as a precaution.
• Registering defensive domain variants against link attacks. It does nothing for that purpose, though it has separate and real value against typosquatting and brand impersonation.

Frequently asked questions