[Agency Talks Recap] How to Make Your WordPress Sites Secure

Managing security for a single WordPress site is manageable. Managing it across dozens of client sites, each with various plugins and themes, and multiple clients with different levels of technical literacy, is a different problem entirely. The exposure is multiplied, the margin for error is smaller, and the consequences of one compromised site can ripple across everything else you’re responsible for.

We recently brought together two of the sharpest minds in WordPress security, Oliver Sild from Patchstack and Ben Gabler from Hosting.com, to talk through what managing security looks like for agencies in 2026. Between the two of them, they’ve seen pretty much every way a WordPress site can go wrong, and more importantly, how the risks compound when you’re trying to make your WordPress sites secure at scale.

What came out of that conversation was more like a reality check. They explained how agencies should think about security, where the gaps are, role of AI in WordPress security, and what’s coming that none of us are really prepared for.

How to make your WordPress sites secure

1. Stop thinking about security as something you finish

The first question we asked was: What does “secure enough” mean for an agency managing dozens, sometimes hundreds, of client sites at once?

The answer was that the question itself is the problem. The moment you think you’ve reached “secure enough” is the moment you stop paying attention, and that’s when things go sideways. Security isn’t a state you achieve. It’s closer to a habit, or a practice, like keeping your books or doing site backups. You don’t do it once.

This sounds obvious until you look at how most agencies operate. They install a security plugin, maybe set up some basic firewall rules, and then mentally file “security” under done. The plugin is there. The box is checked. The assumption is that unless something breaks, everything is fine.

That assumption is what gets agencies into trouble. The threat landscape doesn’t stay still. New vulnerabilities come out constantly. Attackers adapt faster than most agencies have time to track. The only way to make your WordPress sites secure long-term is to treat security as ongoing maintenance, not a one-time setup.

The practical version of this is boring but true: keep everything updated, know what’s installed across your client sites, and don’t let security updates fall behind because you’re nervous about breaking something. That nervousness is understandable, but it’s not a security strategy.

2. Your hosting company has more responsibility than you think, but you need to ask for it

One of the more interesting threads in the conversation was about where responsibility sits when something goes wrong. Agencies blame clients or the hosting provider. Clients blame agencies. And the host’s terms of service usually say it’s not their problem.

The reality is that security at the hosting level covers things most agencies aren’t equipped to handle themselves, including infrastructure hardening, network-level threat detection, malware scanning, and firewall rules that operate before a request ever reaches WordPress. That’s not something you replicate with a plugin. It either exists at the infrastructure level or it doesn’t.

The issue is that hosting companies vary enormously in how seriously they take this. Some have dedicated security teams, active relationships with vulnerability researchers, and clear incident response processes. Others have essentially nothing, and they’ve written their contracts accordingly.

When you’re evaluating a host, the conversation goes: how’s the uptime, how fast is it, what does it cost? Security barely comes up. That needs to change.

A better set of questions:

• Does the host provide a web application firewall?
• Do they do malware scanning?
• What happens if a client site gets infected: who does what, and how fast?
• Do they have relationships with security companies that give them early warning on emerging threats?

That last one is an important point because when a major vulnerability hits, the hosts who have those relationships find out quickly and can act. The ones who don’t are just waiting to see which of their customers get hit.

3. Five hours is not enough time to just update a plugin

The statistic that landed hardest in the conversation: the average time between a WordPress vulnerability being disclosed and the first active exploit attempt is now around five hours.

Think about what that means in practice for an agency. A plugin developer ships a security fix at midnight. By five in the morning, automated bots are already scanning for sites still running the vulnerable version. If you’re managing fifty client sites and you review updates manually before pushing, or worse, wait for clients to approve them, you’re already behind before you’ve even started your day. Multiply that across your entire portfolio and the exposure is significant.

This is a fundamentally different situation than it was a few years ago. It used to be that you had a few days, maybe a week, to get updates applied before the real attack traffic arrived. That window is gone. The bots are faster now, there are more of them, and they’re increasingly AI-assisted, which means they’re not just faster; they’re smarter about targeting.

The uncomfortable implication is that manual update workflows, however carefully managed, aren’t sufficient as a WordPress vulnerability management strategy on their own anymore. Updates are still important. But by the time you’re applying an update, that window of exposure has already been open.

What this points toward is the need for some form of automated mitigation that doesn’t depend on you being awake and in front of a screen. Whether that’s virtual patching through a security service like WP Umbrella‘s Site Protect (which is powered by PatchStack), infrastructure-level WAF rules that block known exploit patterns, or something else, the point is that the human-in-the-loop update cycle can’t be the only line of defense.

The agencies that will struggle most are the ones who’ve built their security story entirely around “we stay on top of updates.” That used to be enough. It isn’t anymore.

4. Your backups are probably less reliable than you think

Nobody likes to say this, but the backup conversation needs to be had more honestly in this industry.

The default assumption is: backups exist, therefore we’re covered. The reality, based on what happens when agencies need to restore, is messier. Backup plugins frequently produce incomplete archives, and you often don’t know until you try to use them. By then, it’s too late to do anything about it.

There’s also the question of where backups are stored. Storing them on the same server as the site itself is a single point of failure. Storing them with the same hosting provider, even on different infrastructure, still exposes you if the provider has a major incident. Data center fires happen. Companies go out of business. Therefore, offsite, geographically separate backups aren’t paranoia; they’re just how this is supposed to work.

And then there’s the problem nobody talks about: malware in the backup itself. If a site was compromised before the backup was taken, restoring from it just re-infects the site.

And then test a restore. Pick a non-critical site, do a restore into a staging environment, and verify that what comes back is a working, complete copy of the site. Most agencies have never done this. Most would find at least one thing that didn’t work the way they expected.

One more thing worth mentioning: when something does go wrong, a full site restore is almost never what you need. A bad plugin update doesn’t require rolling back the entire database and all site files. Often, you just need to restore the plugins folder, or in some cases, just reinstall the specific plugin. Going nuclear because that’s the only restoration option you’ve practiced is a problem with how you’ve set things up, not a problem with the site.

5. Restrict admin access and take passwords seriously

The most common entry point for hacked WordPress sites isn’t a sophisticated exploit. It’s a compromised admin account. Usually, this is because someone is using a weak password, reusing a password from another service that was breached, or because their device or browser has been compromised and their session cookies have been harvested.

Those session cookies, by the way, are actively bought and sold. There are marketplaces in the dark web where you can buy direct access to WP admin accounts. Attackers aren’t always brute-forcing their way in. Sometimes they’re just buying the key.

When you hand a client an admin account, you’re extending your attack surface. That client may have a great website. They may have terrible security practices on their devices and accounts, and you have no visibility into any of it. Across a portfolio of thirty or forty clients, the odds that at least one of them has a compromised device or a reused password from an old data breach are not small.

Restrict client admin access wherever possible. Most clients don’t need it and don’t want the responsibility of it. For anyone who does have admin access, require two-factor authentication. It’s not optional, it’s a condition of the relationship. And enforce password manager use for your own team at a minimum: strong, unique passwords for every site, no exceptions.

One tip from the webinar that’s easy to pass along to clients: stop thinking about passwords and start thinking about pass-phrases. A sentence is easier to remember than a random string of characters, and it’s significantly harder to brute force because of the length. “My dog hates Monday mornings in November” is both memorable and not in any dictionary list of common passwords.

The other piece is onboarding. Security conversations shouldn’t wait until something goes wrong. When you bring a new client on and explain that they’re about to have an online presence that will be scanned by bots within minutes of going live. That reframes what a maintenance plan is for. It’s not upselling. It’s explaining the reality of what it means to have a website.

6. AI’s impact on WordPress security in 2026 and beyond

We ended the conversation with a question about AI. The volume of WordPress vulnerability reports is already at a level that would have seemed unthinkable a few years ago. According to Oliver, January 2026 alone saw more reports than the entire year of 2022 did. And that’s partly AI-assisted security research, which is a good thing. But the same tools are available to attackers.

The scenario that’s already starting to play out: automated agents that are given a task: find vulnerabilities, exploit them, collect money, and report back. They are just left to run. No human checking in. The barrier to becoming an attacker has dropped to almost nothing, and the scale at which attacks can be launched is basically unlimited.

At the same time, WordPress is getting more complex as a platform. Agencies using AI to vibe-code custom plugins, headless setups with React frontends sitting on top of WordPress backends, and Node.js dependencies mixed into what used to be a straightforward PHP stack, all of that expands the attack surface in ways that traditional WordPress security tools weren’t built to handle.

None of this means it’s time to panic. But if you’ve been treating security as an afterthought, or something you’ve already handled, 2026 is going to be a hard year. Stay current, think in layers, and know what your incident response plan is before you need it, and you’ll be doing better than most.

Summing up

• Know your contingency plan before something goes wrong.
• Test your host’s response before you’re in a crisis.
• Verify your backups work and contain what you think they do.
• Lock down admin access and get serious about passwords.
• And stop thinking of security as a finished project.

If you’re doing all of that, you’re doing more than most to make your WordPress sites secure, and it will show.