A negative SEO protection checklist you can finish in an afternoon

How to work this list

Work it top to bottom and stop wherever the afternoon runs out. The blocks are sequenced by risk removed per minute spent, so whatever you never reach is what mattered least. That is the whole design: a worklist - an ordered set of tasks with an explicit finishing condition for each one - is only useful if the ordering carries information.

Two annotations run through every item. Reason is one line on why the item exists at all; it is there so you can drop an item deliberately rather than by accident. Check is how you confirm the item is done rather than believed to be done - because "the backups are running" and "a restore has been performed" are different states, and only one of them survives an incident.

The reasoning behind the sequence is set out separately in protecting a site from negative SEO. This page assumes you accept it and want the tasks.

Rough timings, assuming nothing breaks: Block 0 ten minutes, Block A an hour, Block B forty-five minutes, Block C forty-five minutes, Block D half an hour, Block E half an hour plus a restore test, Block F fifteen minutes. Those are my estimates, not measurements - treat them as ordering information rather than commitments.

Block 0 - establish what is already true

Ten minutes. Do not change anything yet. A compromise already in progress - an intruder holding live access to your site - changes the order of everything that follows.

1. Open Search Console, Security and Manual Actions, Manual actions. Reason: "No issues detected" means no human reviewer at Google has acted against the site, which retires most of what gets sold to you on the premise of a penalty. Anything else, and you stop here and work that specific action instead. Check: screenshot with the date visible.
2. Open the Security issues report in the same menu. Reason: hacked content, malware and social-engineering flags land here and not in Manual actions - the most common triage error on this subject. Check: screenshot with the date. If anything appears, leave this list for hacked site injection or malware and blacklisting.
3. Search your own domain with two or three commercial terms you would never publish - pharmaceutical, gambling, loan or replica vocabulary. Reason: Google's own hacked-site fix steps prescribe this search, and it surfaces injected pages faster than a scanner will. Check: nothing unexpected in the results.
4. Check Safe Browsing status from a network that is not yours. Reason: a browser interstitial stops traffic dead while rankings stay intact, so it does not look like a ranking problem and gets missed for weeks. Check: the status reads clean.
5. Write down today's date and plot the last ninety days of traffic against published Google update dates. Reason: most suspected attacks are a core or spam update. Settling this first stops you spending the afternoon fixing the wrong thing.

Block A - site access control

About an hour, and the highest-value block on the page.

1. List every account on the content management system and delete the ones that should not exist. Contractors, leavers, temporary accounts, anything a plugin created, anything you cannot attach a living human to. Reason: an unrevoked credential from a finished relationship is the most common identifiable-attacker fact pattern - the recurring shape a set of facts takes - in site compromise, and it is also the one where legal recourse is realistic. Check: every survivor maps to a named person who still needs it.
2. Demote everyone who does not need administrator. Reason: least privilege turns a stolen author account from a takeover into a nuisance.
3. Confirm no account is called admin, administrator, or your domain name. Reason: WordPress.org says plainly not to use the username admin, and a guessable username halves the work in a credential-guessing attack.
4. Reset every administrator password to a unique generated string held in a password manager. Reason: Google lists compromised passwords first among the ways sites get hacked. Check: none of the new values exists anywhere else.
5. Turn on 2FA for every administrator - two-factor authentication, a second credential demanded after the password, from a one-time-code app or a hardware key rather than SMS where you have the choice. Reason: it is the control that still works once a password is known to somebody else. Check: sign out, sign back in, and confirm the second factor is actually demanded.
6. Invalidate every existing session. Reason: a password change does not necessarily evict somebody who is already signed in.
7. Revoke application passwords, API tokens and integration keys you cannot account for. Reason: these skip the login form, which means they skip the second factor too. Most forgotten credential class there is.
8. Rotate hosting panel, file transfer, shell and database passwords, and switch the hosting account to two-factor. Reason: the content management system is not the only door into the filesystem.

Block B - patch and shrink the surface

Forty-five minutes.

1. Bring the platform to its current release. Reason: WordPress.org states that older versions receive no security updates, and Google names missed updates second among causes of compromise. Check: the dashboard offers no core update.
2. Update every plugin and every theme. Reason: Google calls outdated or unpatched themes and plugins a major source of vulnerabilities.
3. Delete - do not deactivate - anything unused, including spare default themes beyond one fallback. Reason: deactivated files remain on disk and remain reachable, so a vulnerability in one is often still exploitable. Check: the plugin screen lists only things the site genuinely uses.
4. Switch on automatic updates for minor core releases, plugins and themes. Reason: available in the admin since version 5.5 on 11 August 2020, and on any site without staging the unattended breakage risk is smaller than the unpatched-vulnerability risk. Check: each plugin row reads enabled.
5. Identify anything abandoned upstream - no release in years, a vanished vendor, a lapsed commercial license that has silently stopped delivering updates. Reason: a component nobody will patch is a scheduled future compromise. Check: write down a replacement and a date, even where the replacement is removing the feature.
6. Disable the dashboard file editor with define( 'DISALLOW_FILE_EDIT', true ); in wp-config.php. Reason: WordPress.org hardening guidance, and it removes the fastest route from a stolen session to arbitrary code.
7. Inventory every third-party script the pages load - advertising, pixels, chat, fonts, hosted libraries - and remove what you cannot justify. Reason: a site can be flagged for malware served by a script it does not host, with nothing on its own server altered. No file scanner catches that one.

Block C - domain, DNS and email

Forty-five minutes, and the block whose failures are unrecoverable at your end.

1. Two-factor on the registrar account. Reason: losing the domain is worse than losing the site and no technical measure of yours reverses it.
2. Move the registrant and administrative email to an address on a different domain you control. Reason: if the protected name is hijacked or expires, an address on that name dies with it, and you lose the asset and the recovery channel together.
3. Confirm auto-renew is on and the card on file is live. Reason: a lapse looks exactly like a theft from outside, and costs about the same to unwind.
4. Run a lookup on your own domain and read its status codes. You want clientTransferProhibited at minimum, ideally with clientUpdateProhibited and clientDeleteProhibited. Reason: ICANN defines the first as instructing "your domain's registry to reject requests to transfer the domain from your current registrar to another" (ICANN, EPP status codes). Most registrars set it by default; almost nobody has confirmed it. Check: the codes appear in the lookup. If they do not, enable domain lock and look again.
5. Price registry lock with your registrar for any domain the business depends on. Registry lock is the paid service that sets the registry-side codes - serverTransferProhibited, serverUpdateProhibited, serverDeleteProhibited - rather than the registrar-side ones, and it works by requiring a human, out-of-band authorization before any change is accepted. Reason: because the registry holds the flag and no login can clear it, registry lock is the only item on this entire page that still protects you after your registrar credentials are fully compromised. The costs are real: a fee, and legitimate changes that now take hours instead of seconds. Check: availability differs by top-level domain, so confirm yours rather than assuming; ICANN documents the status codes, not the commercial service.
6. Export the whole DNS zone, read it, and delete every record you cannot explain - stale address records, orphaned aliases for services you dropped, old verification strings. Reason: CISA's Emergency Directive 19-01 makes auditing records "to verify they resolve to the intended location" its first required action (CISA, ED 19-01). Check: every surviving record has a named purpose.
7. Two-factor on the DNS host. Reason: the same directive requires multi-factor authentication on every account that can change DNS records.
8. Enable DNSSEC where both registrar and DNS host support it. Reason: it authenticates the origin and integrity of DNS answers against forgery. Check: do the previous item first. DNSSEC does nothing about an attacker signed into your DNS panel, and treating it as a substitute is a common and expensive misreading.
9. Start Certificate Transparency monitoring for your names. Reason: the same directive requires watching for certificates issued that you did not request, which is among the earliest signals of a hijack under way. Check: expect noise from your content delivery network, host and mail provider, and tune before you trust the alerts.
10. Two-factor on the mailbox that receives all of the above. Reason: every reset link on this page lands there. It is the master key, and it is routinely the least protected account in the set.

Block D - search-side identity

Half an hour.

1. Verify a Domain property in Search Console, not just a URL-prefix property. Reason: the Domain type covers all subdomains and protocols; the prefix type does not, and spam under an unverified subdomain generates no notification whatsoever. Check: the property picker shows the bare domain, verified by DNS record.
2. Open Users and permissions and remove every owner and user you cannot name. Reason: Google's own guidance on one injection pattern notes that "The hacker will typically add themselves as a property owner in Search Console," which hands over sitemaps, removals, targeting and the disavow file.
3. After removing an owner, delete their verification token too - the HTML file, the meta tag, the DNS text record, the analytics link. Reason: Google states that removing an owner leaves their verification tokens in place, so they can simply verify again. Check: look for stray verification files in the web root and stray text records in the zone.
4. Confirm the property is owned by an account the business holds, and add a second owner inside the business. Reason: a property whose sole owner has left is a property whose alerts nobody reads.
5. Find out where Search Console messages actually go, and add a monitored shared mailbox. Reason: permission level determines who is told - restricted users get only the messages that specifically affect them. Check: at minimum, confirm the address on file is one somebody opens daily.
6. Claim and verify the Google Business Profile, on a business-controlled account with two-factor enabled. Reason: Google's ownership-request process gives the existing owner three days to answer an email, after which the requester may be able to take the profile. Three days of email is the whole defense. Check: the profile reads as verified and you can see the owner list.
7. Repeat the property and alerting items in Bing Webmaster Tools if Bing revenue is material. Reason: different index, different notifications, different security flags.

Block E - backup and recovery

Half an hour to configure, plus however long a restore takes.

1. Confirm both halves are captured: files and database. Reason: WordPress.org treats them separately because they live in separate systems, and a files-only backup restores an empty site. Check: open the newest archive and confirm it holds both a database dump and the content directory.
2. Confirm at least one copy sits outside the hosting account. Reason: a copy under the same credentials is deleted or encrypted by the same intruder.
3. Confirm retention outlasts your realistic detection lag. Reason: the usual failure is not the absence of backups, it is the absence of a backup from before the event. Seven days does not help with a six-week-old injection.
4. Restore to a staging or local environment, and time it. Reason: an untested backup is a hypothesis. Note that WordPress.org does not tell you to do this - it asks only that you verify the process is working - so this item is my judgment, and you should know which items are documentation and which are not. Check: record the elapsed time and the date, and repeat quarterly.
5. Write the callout order on one page - host, developer, registrar support, counsel, with account numbers and out-of-band contacts - and store it somewhere that does not need the site to be up. Reason: an incident is a poor moment to find the recovery instructions living on the thing that is down.

Block F - monitoring, and only now the links

Fifteen minutes.

1. Turn on external uptime and content-change monitoring for the homepage and two or three key templates. Reason: it catches injected footer scripts and conditional redirects, which are the vectors that actually work and which no search tool reports.
2. Turn on file-integrity monitoring or a scheduled server-side scan. Reason: a new executable file in an uploads directory should raise an alarm, not be discovered by accident later.
3. Establish your host's log retention period and whether you can export logs. Reason: logs are what turn an incident into something investigable and occasionally into something actionable. Check: download last week's access log now, so you know the mechanism works before you need it.
4. Take a dated baseline export of the link profile - Search Console's external links report, plus whichever commercial index you use. Reason: the value is evidentiary rather than operational, and a dated baseline is the only way to later state what appeared, how much of it, and between which two dates. Check: the file is stored with its date intact. The full argument is in backlink monitoring and alerts.
5. Put a monthly repeat of that export in the calendar. Reason: Search Console's report is a sample and it drops links over time, so the artifact worth owning is the series of snapshots rather than today's view.
6. Configure no automatic disavow rule of any kind. Reason: Google's test is conjunctive - a considerable number of spammy links and a manual action they caused or will likely cause - and Google warns that the tool "can potentially harm your site's performance in Google Search results" if used incorrectly (Google, Disavow links to your site). A threshold satisfies neither limb and carries a real downside.

Eight items deliberately left off this list

Each of these is widely sold or widely recommended. Each is absent on purpose, so that its absence reads as a decision rather than an oversight.

• Maintaining a standing disavow file. Fails Google's two-limb test and carries a documented downside.
• Subscribing to toxic backlink monitoring. Google has never published a toxicity metric; the scores are vendor inventions, and in January 2023 Google's John Mueller described the agencies on both sides of that trade as "cashing in from those who don't know better."
• Automated disavow-on-threshold services, which combine both of the above and remove the human who might have noticed.
• Blocking address ranges or crawler classes broadly to deter scrapers. The reliable result is blocking legitimate crawlers and deindexing yourself.
• Filing a reconsideration request as insurance. With no manual action outstanding there is nothing to reconsider.
• Counter-building exact-match anchor text to rebalance a ratio. This manufactures the over-optimization pattern the attacker was hoping for.
• Registering defensive domain variants as a negative SEO measure. Useful against typosquatting; useless against link attacks.
• Naming a suspected competitor publicly. Converts a search problem into a defamation exposure and proves nothing.

Finally, the recurring items. Updating the platform, updating extensions, auditing Search Console owners and testing a restore are not one-time tasks - put all four in the calendar before you close the laptop, because a checklist worked once and never again decays into a screenshot of a good afternoon.

Frequently asked questions