The 2026 WordPress Security Survey from Melapress dropped last week, and one number stopped me cold: 78 percent of WordPress site owners say they’re worried about security — yet nearly 68 percent have already been hit by at least one incident in the past year. That’s not a knowledge problem. That’s an action problem, and I see it play out on almost every site I audit.

Here’s what the data actually means, and what I do differently on client projects.

1. The concern-vs-action gap

The survey data from Melapress is a near-perfect picture of what I call security theater: people are worried enough to answer “very concerned” on a survey, but not worried enough to spend two hours setting up a proper backup regime or enabling two-factor authentication across all admin accounts.

I’ve done WordPress audits on maybe 40 sites over the past three years. A consistent pattern: the site owner is aware that security “matters,” they have Wordfence installed (usually free tier), and they haven’t looked at a security log in six months. That’s it. No enforced 2FA, no offsite backups, no hardened wp-login.php.

Awareness without process is nearly useless. The gap isn’t knowing — it’s doing.

2. AI is changing the attack surface

The survey specifically flags AI-assisted threats as an escalating concern, and it’s worth being concrete about what that actually means in practice:

  • Automated vulnerability discovery. Attackers can now feed plugin codebases to LLMs and get a ranked list of potential injection points in minutes. What took a skilled attacker days now takes an automated pipeline hours.
  • Credential stuffing at scale. AI-assisted tools make it cheaper to run credential stuffing attacks — testing thousands of username/password combinations against xmlrpc.php and the REST API auth endpoints.
  • Convincing phishing for admin accounts. AI-generated phishing emails targeting WordPress admins are now indistinguishable from legitimate plugin update notices. I’ve seen two clients click through fake “critical security update” emails this year alone.

None of these are new attack vectors. They’re old vectors that are now cheaper and faster to execute. The response has to be structural — you can’t out-vigilance automation.

3. The recovery plan nobody has

The survey found a wide gap in recovery planning — most site owners have never documented what they’d actually do if their site was compromised tonight. I ask this question directly on every new client call: “If your site went down right now, what’s your recovery time objective?”

The honest answer from most small business owners: “I’d call my hosting company and hope.”

That’s not a plan. A real recovery baseline looks like this:

  • Daily offsite backups (not just host-level snapshots — those are often wiped in an attack)
  • Backup restoration tested at least once per quarter
  • A documented list of every plugin version, theme version, and custom code location
  • A staging environment you can restore to before touching production
  • At least one person who knows the WordPress admin credentials other than the site owner

Most sites have none of that. Getting to even three of five puts you ahead of the majority of the WordPress install base.

4. Plugin sprawl is still the #1 entry point

AI threats get the headlines, but the survey’s underlying data (and my own experience) keeps pointing back to the same root cause: too many plugins, many of them unmaintained, several of them abandoned by their authors.

A few patterns I see constantly:

  • Plugins that haven’t been updated in over a year, still active because “it still works”
  • Free plugin versions installed, with the author pushing security patches only to paid tiers
  • Duplicate functionality — two form plugins, two SEO plugins, three caching plugins — because nobody cleaned up after the last developer left

Every installed plugin is an attack surface. Fewer plugins isn’t just good for WordPress performance — it’s good for your security posture too.

5. What I actually implement on client sites

This is the stuff the survey correctly identifies as the gap between “worried” and “protected.” When I take on a WordPress development engagement that includes a security review, here’s what I always set up before I hand anything back:

  • Enforced 2FA on all admin accounts. Not optional, not “we should probably do this” — enforced at the plugin level so it can’t be bypassed. Melapress’s own WP 2FA plugin handles this cleanly.
  • Login page hardening. Move wp-login.php to a non-default URL, rate-limit login attempts, disable XML-RPC if the site doesn’t need it. Takes 20 minutes; closes a huge percentage of automated attacks.
  • Activity logging. I want a record of every admin action, every plugin install, every file change. If something goes wrong, the log tells me when and what. WP Activity Log is the tool I reach for here.
  • Offsite backups on a separate account. Backups that live on the same server as the site are useless in a full compromise. I push to S3 or Backblaze B2 on a credential that only has write access to the backup bucket — so even if the server is compromised, the attacker can’t delete the backups.
  • A quarterly plugin audit. Every plugin on the site gets checked: last updated, active installs trend, changelog reviewed. Anything with no updates in 12 months and no clear reason to stay gets removed.

Is this a complete security program? No. But it addresses the most common failure modes I see, and it’s achievable on a real budget. The survey data suggests most sites have done maybe one or two of these. Doing all five puts you in a meaningfully different risk category.

The AI-specific angle deserves one extra note: I’ve started recommending that clients add a policy of never installing a plugin based on an email prompt — only from the WordPress.org repository or a vendor dashboard they navigate to directly. It sounds obvious. It isn’t obvious to a business owner managing their own site at 11pm.

6. Stop treating security as a “later” task

The survey data isn’t surprising, but it is clarifying. The problem was never awareness — WordPress security is well-documented, well-resourced, and endlessly discussed. The problem is that security work doesn’t feel urgent until after the incident. By then, you’re paying emergency rates, losing revenue, and rebuilding trust with customers.

Spending four to six hours on proper hardening now is categorically cheaper than a post-breach recovery. I’ve done both kinds of engagements — I know which one I’d rather bill and which one the client would rather pay for.

If your WordPress site is overdue for a real security review — not just “Wordfence is installed” but an actual audit and hardening pass — that’s something I cover as part of WordPress development engagements. Or if you want to talk through where your site stands, book a call.