WordPress security from the architect level, not the plugin level.

The fastest path is to take the site offline (or behind a maintenance page), preserve the current state for forensic review, then start triage. Most people’s instinct is to start deleting suspicious files and changing passwords immediately, which destroys the evidence trail needed to find the actual entry point. If a clean backup exists, restoring it can get the site back online within hours after triage (with the understanding that the same entry point could be exploited again until hardening is in place). Full recovery and hardening then run over the following days, scope dependent on what we find.

Recovery is structured in two phases. The first focus is getting a clean version of the site back online as quickly as possible, often within 1-2 days if a clean backup exists or longer if we need to rebuild. Hardening then runs over the following days, with the scope dependent on what was compromised. Most engagements complete in 1-7 days total, longer if the database itself was tampered with or the site has years of accumulated technical debt that complicates the cleanup.

The top three vectors, in order: outdated plugins with known vulnerabilities (the WordPress security ecosystem publishes CVEs faster than most sites apply patches), weak or reused admin passwords getting cracked or leaked in unrelated breaches, and themes or plugins from untrusted sources that contained malicious code from day one. Although AI may change this, as of today almost no real-world compromise is a sophisticated zero-day attack against WordPress core; it’s almost always one of these three.

No, and anyone who guarantees that is lying. What’s deliverable is a security posture where the most common attack vectors are closed off, monitoring catches anything unusual within minutes, and the platform recovers gracefully if something does get through. The goal is making compromise dramatically less likely and dramatically faster to detect and contain when something happens.

Multiple layers of protection so a failure at any one layer doesn’t expose the site. In practice: edge-layer WAF and bot mitigation at Cloudflare or the host, brute-force and login hardening at the WordPress layer, file system lockdown so even an authenticated admin can’t write where they shouldn’t, server-level malware scanning that catches suspicious activity before it spreads, and continuous patching of WordPress core and plugins so known vulnerabilities don’t sit open. Each layer is imperfect on its own; together they make most real-world attacks fail before they cause damage.

In most cases, a hardened platform with edge-layer WAF and server-level monitoring is the better default than relying on an in-WordPress security plugin. The reasoning: anything running inside WordPress can only protect WordPress from the moment the request reaches it; an attack that compromises WordPress itself also compromises the plugin. Edge and server-layer protection runs outside WordPress, so it keeps protecting even when WordPress is compromised. That said, Wordfence and similar plugins are still useful for some specific use cases, and we use them where they’re the right tool.

The hardening work is staged and tested specifically so it doesn’t. The typical pattern: stand up a parallel copy of the site, apply the hardening configuration there, run the site through normal admin tasks and public-facing user flows to verify nothing’s broken, then apply to production once everything’s validated. The exceptions are usually plugins that were doing something they shouldn’t (writing to system directories, modifying core files).