Hardening WordPress, and why it is a search problem

Why a plugin update is an SEO task

WordPress is what most negative SEO victims are running, and its security posture is the largest single variable in whether an attack against them succeeds. The connection is not vague. Of every vector documented on this site, the ones that still work against ordinary sites - hacked site injection, malware and blacklisting, redirect hijacking, keyword stuffing injection - all require the attacker to obtain write access to your files. On a WordPress site, write access normally arrives through an unpatched extension, a reused credential, or a compromised hosting account.

Which means the distance between "my WordPress is current" and "my WordPress has an eighteen-month-old plugin on it" is very nearly the whole of the defense you can practically mount against the attacks that work. An attacker does not need to know anything about your business; they need to find an install running something with a published, unpatched vulnerability, and that search is automated.

The injected payload is often literally negative SEO. In the June 2024 supply-chain incident, code planted in several plugins hosted in the official WordPress.org repository "attempts to create a new administrative user account and then sends those details back to the attacker-controlled server", and the same actor "injected malicious JavaScript into the footer of websites that appears to add SEO spam throughout the website", as BleepingComputer reported that month drawing on Wordfence's analysis. A plugin compromise becomes footer spam becomes a search-visibility problem, in that order, without anyone touching your backlinks.

What Google does when your own server serves the spam

This is what separates a WordPress compromise from an ordinary IT incident. Google's spam policies define hacked content as "any content placed on a site without permission, due to vulnerabilities in a site's security", and name code injection, page injection, content injection and redirects as its forms.

Unlike inbound link spam, which Google says it works very hard to neutralize, injected content is served from your domain, over your certificate, inside your templates. Google is not being asked to attribute a stranger's content to you. It is correctly attributing your own server's output to you. This is the one vector where Google acts against the victim, and that asymmetry is the reason the ordering on this site puts patching above link watching.

What follows, in Google's documentation: an entry in the Security Issues report - not the Manual Actions report, which is the most common triage error on this subject; the search label "This site may be hacked", which Google explains appears when it believes a hacker may have altered existing pages or added spam pages; a Safe Browsing interstitial where malware is being served, alongside the label "This site may harm your computer" and Google's advice to searchers not to visit until the message clears; and a slow way back, since reviews for sites hacked with spam "can require up to several weeks", against a few days for malware.

Then the notification gap. In #NoHacked: A year in review, published 20 March 2017 and covering 2016, Google reported it could not notify 61% of affected site owners because their sites were not verified in Search Console. There is no successor figure, so read it as a dated measurement rather than a current rate - but an unverified site still learns about its compromise from its traffic graph, weeks late.

Updates, and why deleting beats deactivating

WordPress.org's own documentation is the right source for this, and it is unambiguous: "You should always keep up to date with the latest version of WordPress. Older versions of WordPress are not maintained with security updates," and downloads should come from wordpress.org rather than from wherever a search result leads (WordPress.org, Hardening WordPress).

Automatic updates. Background updates have been in core since WordPress 3.7, covering core, plugins, themes and translations, and are controlled by the WP_AUTO_UPDATE_CORE constant with values true, false and 'minor'. Per-plugin and per-theme automatic updates reached the admin interface with WordPress 5.5 on 11 August 2020.

The honest recommendation splits by circumstance. If you have a staging environment, a test suite and somebody who watches deploys, staged updates are better. For everybody else, turn automatic updates on for minor core releases, plugins and themes. The failure mode of automatic updates is an unattended layout break - visible, and reversible in fifteen minutes. The failure mode of manual updates on an unwatched site is a nine-month-old known vulnerability, which is invisible and not reversible at all. Those risks are not symmetrical, and treating them as if they were is how sites end up running known-exploitable code for a year to avoid a rollback.

Delete rather than deactivate. WordPress.org again: "if you are not using a specific plugin, delete it from the system." A deactivated plugin's PHP files remain on disk and remain reachable by URL, so a vulnerability in one is often still exploitable. Deactivation is a state in the admin interface, not a security boundary.

Abandoned and lapsed components are scheduled compromises. A plugin with no release in years will never be patched. A commercial plugin whose license lapsed keeps running while silently receiving nothing. Both need a replacement and a date, even where the replacement is deleting the feature.

The supply chain, where diligence runs out

Hardening guides handle this part worst, because it is the one thing a careful owner cannot fix by being careful.

A security plugin's vulnerability is still a vulnerability. CVE-2024-10924, published 15 November 2024 with a CVSS base score of 9.8, is described by the National Vulnerability Database as an authentication bypass in the Really Simple Security plugins for WordPress in versions 9.0.0 to 9.1.1.1, arising from "improper user check error handling in the two-factor REST API actions" and making it "possible for unauthenticated attackers to log in as any existing user on the site, such as an administrator, when the 'Two-Factor Authentication' setting is enabled" (NVD, CVE-2024-10924).

Read that slowly, because the lesson is uncomfortable. The vulnerability sat in a security plugin, in its two-factor authentication feature, and was exploitable precisely because that feature had been switched on. The correct inference is not to avoid security plugins. It is that plugin count is itself a risk variable, and that defensive code needs patching with the same urgency as everything else - installing more security plugins in response to feeling insecure adds surface rather than removing it.

Compromise at the source. In June 2024 five plugins in the official WordPress.org repository were modified to carry malicious code, with injections around 21 to 22 June and discovery on 24 June. The payload created rogue administrator accounts and injected search spam into site footers. Reported affected-site counts varied, one account giving more than 35,000, and the plugin count grew after first publication, so treat it as a dated incident with an evolving figure rather than a settled number. Wordfence later attributed the access to developer accounts compromised through credential reuse.

The defensive conclusion is awkward and should not be smoothed over: "only install plugins from the official repository" is good advice that would not have prevented this. The plugins came from the official repository. What limits exposure to a source compromise is having fewer plugins, noticing new administrator accounts, and watching for file changes - not the provenance rule everybody repeats. Worth knowing in the same breath: WordPress.org's security team says it "backports fixes to older versions as a courtesy, to ensure older sites receive critical security fixes via auto-updates", which is a further reason automatic updates matter even on an old major version.

Accounts, privileges and the credentials nobody audits

WordPress.org's brute-force guidance is short and worth following literally: do not use the username admin, and create a separate admin account and demote or remove legacy users; encourage unique, long passwords and password managers; "Enable 2FA for all administrators and privileged users using a reputable plugin or your identity provider (TOTP app, hardware key, SMS fallback)"; and where the host or content delivery network does not rate-limit at the edge, let a security plugin throttle login attempts (WordPress.org, Brute Force Attacks).

Two things that documentation understates. First, WordPress core does not ship two-factor authentication, so it arrives as a plugin or through an identity provider - which, per the vulnerability above, means the second-factor implementation is itself code you must keep patched. Prefer a widely maintained one, prefer a one-time-code app or a hardware key over SMS, and update it as a priority component rather than a background one.

Second, least privilege is the item most often skipped and most often decisive. Every administrator account is a full compromise waiting for one credential leak, and editors publishing copy do not need to install plugins or edit theme files. Contractors get removed the day the engagement ends. This is also the control that determines whether an intrusion is ever attributable to anyone: the negative SEO matters where legal recourse is realistic are usually the ones where the intruder was a former employee, contractor or agency using access nobody revoked.

And the forgotten class: application passwords and API tokens bypass the login form, and therefore bypass two-factor authentication entirely. Audit and revoke them alongside the user list.

XML-RPC, the REST API, and the advice that is contested

Some of the standard hardening advice is well documented and some of it is repeated without its caveats. Separating the two is the useful thing this section can do.

XML-RPC is documented. WordPress.org names it: xmlrpc.php is a frequent brute-force target, particularly the system.multicall method; if you do not use XML-RPC, disable it, and if you do - Jetpack, some mobile publishing apps, some remote management tooling - restrict and rate-limit it aggressively. The reason system.multicall matters is that it packs many operations into one HTTP request, so credential guessing can proceed at a rate a per-request limit on the login page would never allow. Check what depends on the endpoint before you switch it off; breaking your own publishing workflow to close a hole two-factor authentication had already closed is a poor trade.

The pingback denial-of-service claim is contested. The widely repeated assertion that WordPress pingbacks can conscript your site into reflected denial-of-service attacks against third parties traces to security research from around 2014, and I could not verify it against a primary WordPress.org or CERT source. Treat that framing as an unverified industry claim. The brute-force rationale is documented and is sufficient reason to restrict the endpoint on its own, so nothing practical turns on the disputed part.

REST API user enumeration is real but weak. The endpoint at /wp-json/wp/v2/users returns public author fields in the default context - identifier, name, slug, link, description, avatars - while username, email, roles and capabilities are restricted to an authenticated context. The concern is the slug, which on many installs is the login name, and the author archive link, which reveals the same. That converts credential guessing from "guess a username and a password" to "guess a password". Two qualifications, though: WordPress's documentation does not state precisely which users an unauthenticated request returns, so test your own install logged out rather than assuming; and username disclosure matters enormously on a site defended only by a password and very little on one with two-factor authentication and rate limiting. Fix the authentication first, then decide whether restricting enumeration is worth the integrations it may break.

Database privilege restriction carries a warning that is usually stripped off. WordPress.org notes that routine operation needs only SELECT, INSERT, UPDATE and DELETE, and that revoking DROP, ALTER and GRANT improves containment - and then says on the same page that attempting updates without those privileges "can cause problems when database schema changes occur" and that it is therefore "NOT" recommended to revoke them. Hardening guides quote the first half constantly and the second half almost never. Restricting privileges means owning schema migrations manually at every core update, and a site that then silently stops updating is worse off than when it started.

Renaming the login URL is not hardening. Plugins that hide the admin path raise the cost of untargeted scanning slightly and do nothing against anyone who is actually aiming at you. It is obscurity, and it does not substitute for a second factor and a rate limit.

Files, permissions and the edge

WordPress.org sets a tiered permission scheme: the root directory, /wp-admin/ and /wp-includes/ should have "all files ... writable only by your user account", while /wp-content/ is "intended to be writable by your user account and the web server process", with directories at 755 and files at 644.

Never 777. A world-writable directory lets any process on the server - including one belonging to a compromised neighbor on shared hosting - write executable code into your site. This is the most common self-inflicted WordPress vulnerability there is, and it is usually created by somebody following an upload-error troubleshooting post.

Beyond that: move wp-config.php above the install directory or deny it over HTTP, since it holds the database credentials and the authentication salts. Disable the dashboard file editor with define( 'DISALLOW_FILE_EDIT', true );, which removes the fastest route from a stolen session to arbitrary code and costs you a convenience you should not be using. Rate-limit the login and XML-RPC endpoints at the edge where you can. Restrict the admin area by address only if your team's addresses are stable and you have written down a recovery path first, because that control locks out owners at least as often as attackers. Keep PHP current, since an end-of-life version receives no patches and no amount of WordPress hygiene compensates. And keep staging copies behind authentication and out of the index - an unprotected staging site is an unpatched second install sharing your database credentials.

One rule overrides all of the above: never block Googlebot while doing any of it. Over-broad rewrite rules, address blocklists and aggressive bot filtering catch legitimate crawlers routinely, and the traffic loss that follows gets blamed on an attacker rather than on the edit. Verify Googlebot by reverse-then-forward DNS rather than by user agent - see spoofed Googlebot - and read your crawl stats after any change at the edge.

Your comment section outranks your backlinks as a liability

The risk here is inverted from what most owners assume. Spam links pointing at you are what Google says it works hard to neutralize. Spam comments published on your site are your own content, and user-generated spam is a documented manual action category. The comment queue is the bigger exposure, and nobody sells protection for it.

Practically: hold first-time commenters for moderation, keep an anti-spam layer current, hold or reject comments carrying links, disable pingbacks and trackbacks, and never leave a queue publishing automatically. See blog comment spam attacks. Switching comments off entirely is a legitimate choice for a business site that gets no real discussion, and a poor one for a site that does, since moderation solves the same problem without discarding the conversation.

Detection deserves the same attention as prevention. Watch for new administrator accounts - the June 2024 payload created accounts named "Options" and "PluginAuth", and an administrator you did not create is the single clearest indicator of compromise available. Watch Search Console's owner list too, since Google's guidance records that a hacker "will typically add themselves as a property owner in Search Console", and note that removing an owner leaves their verification token in place unless you delete it as well. Run file-integrity monitoring so a new PHP file in the uploads directory raises an alarm; uploads directories should never contain executable code, which makes them the highest-signal thing to watch. And when you think you have cleaned a compromise, use live URL testing to compare what Googlebot receives with what your browser receives, because Google's own guides warn that hackers try to make a page look fixed when it is not.

Removing the surface entirely - the static option, honestly

This site is itself being rebuilt off WordPress onto static HTML, and it would be dishonest to describe that as anything other than a security decision among others. A static site has no PHP execution, no plugins, no database, no login form, no XML-RPC endpoint and no REST API. The entire class of attack described on this page - an unpatched component granting write access, followed by injected pages or footer scripts - has no mechanism against it.

But it relocates risk rather than abolishing it, and the accounting has to be honest:

• The build pipeline becomes the attack surface. Deploy keys, continuous-integration tokens, the code host account and the generator's own dependency tree are now the path to injected content, and a compromised deploy credential publishes whatever the attacker likes - into output that is trusted precisely because static sites are trusted.
• The developer's machine becomes the attack surface, since the build often runs locally.
• Every identity-layer risk is untouched. Registrar, DNS, hosting, Search Console, Google Business Profile, email. Static HTML defends none of them, and those are exactly the accounts covered in the defensive hierarchy.
• You lose the ecosystem. No scanner, no forced password reset, no vendor pushing patches at you. There is nothing to patch, and also nothing watching.
• Dynamic features move to third parties. Forms, comments, search and commerce become external services with their own credentials and their own breach histories. The dependency did not vanish; it moved off your server and out of your control.
• Content-change monitoring matters more, not less, since an external monitor watching the published HTML is now the main detection mechanism you have.

The accurate summary: moving to static removes the most commonly exploited category of vulnerability and does nothing whatever about the accounts that control your domain and your search identity. That is a real reduction in risk. It is not a solution to negative SEO, and treating the migration as completed security work while the registrar account still has no second factor on it is the version of this decision that fails. I should also be clear that no source I could find measures static hosting against maintained WordPress; the comparison above is reasoning about mechanisms, not a cited finding.

Frequently asked questions