WordPress Is Not The Problem By Itself
I do not buy the lazy version of the WordPress security conversation.
WordPress is not automatically insecure just because it is WordPress. The real problem is the way many WordPress sites are assembled, handed off, updated, extended, ignored, rescued, patched, and then extended again.
That is especially true for agencies. One site is manageable. Fifty client sites, each with different plugins, hosts, forms, page builders, SEO tools, analytics setups, users, update histories, and business expectations, is a very different job.
The security question is not "Is WordPress safe?" The better question is: "Do we have enough control and evidence to know when this specific client site becomes risky or broken?"
The Agency Risk
Agencies inherit complexity.
A client may have an old theme from a previous vendor, a pile of plugins installed for one-time campaigns, unused admin accounts, abandoned tracking pixels, a form plugin connected to a CRM nobody remembers, and a checkout flow that only one person has tested recently.
Security problems and business-function problems start to blur together. A vulnerable plugin matters because it can become a breach. A broken form matters because it costs leads. A failed WooCommerce checkout matters because it costs revenue. A sudden spike in blocked scripts might be a security signal, or it might be a tag manager change that broke analytics.
The agency needs a way to see the site as a working business asset, not just a WordPress install with a list of plugin versions.
The Myths That Create False Confidence
- A security plugin means the site is secure.
- Automatic updates mean nobody needs to verify the site afterward.
- The site is fine because the homepage loads.
- Backups are handled because a backup plugin is installed.
- Forms are working because the plugin is active.
- Checkout is working because WooCommerce is updated.
- Security headers are a one-time setup task.
- No client complaints means no current problem.
Plugins Are Where Most Of The Operational Risk Lives
Plugins are also why WordPress is useful. That is the tension.
A contact form plugin, SEO plugin, cache plugin, page builder, payment plugin, membership plugin, security plugin, and analytics plugin can each be perfectly reasonable on its own. Together, they create a living system with a lot of edges.
The risk is not only "plugin has a vulnerability." It is also "plugin changed behavior," "plugin stopped sending mail," "plugin added a script," "plugin update broke checkout," "plugin is abandoned," or "plugin stores sensitive form data longer than anyone realized."
What I Look For In A Plugin Review
- Is the plugin still maintained, and when was it last updated?
- Does it handle public input, file uploads, payments, logins, forms, or email?
- Does it add scripts, styles, frames, or API calls to public pages?
- Does it store personal data, order data, form entries, logs, or tokens?
- Does it require broad administrator permissions for routine use?
- Does the site still need it, or is it historical clutter?
- Is there a tested rollback plan if the plugin update breaks something important?
Updates Need Proof, Not Hope
Updating WordPress is not the finish line. It is the beginning of the verification step.
I want updates. I also want evidence after updates. Did the homepage load? Did key landing pages render correctly? Did the lead form submit? Did the email arrive? Did checkout still complete? Did analytics still fire? Did the CSP policy start blocking new scripts? Did the security headers change? Did the site get slower?
For a small agency, the hard part is not knowing that updates matter. The hard part is proving that the client site still works afterward without manually babysitting every page.
The Baseline I Want On Client Sites
This is the practical baseline I like to see before calling a WordPress site reasonably cared for.
WordPress Security Baseline
- Unique administrator accounts with two-factor authentication for privileged users
- Least-privilege roles for editors, marketers, contractors, and clients
- Regular core, plugin, and theme updates with post-update checks
- A short plugin list that someone actually understands
- A backup strategy with tested restores, not just backup files somewhere
- A web application firewall or host-level protection appropriate for the site's risk
- Security headers, including HSTS where HTTPS is stable and Content Security Policy where rollout is monitored
- File permissions and write access kept as tight as the host and workflow allow
- Spam, bot, and card-testing controls for forms, comments, login, and checkout
- Monitoring for uptime, domains, DNS, TLS, headers, browser errors, forms, checkout, and important public pages
Forms And Checkout Deserve Special Treatment
Most client websites exist to create a business outcome. A lead form, booking form, donation form, membership signup, or checkout flow is not just another feature.
From an agency-assurance perspective, these flows should be monitored more aggressively than cosmetic issues. The site can be up while the form silently fails. The checkout page can load while payment submission breaks. A CRM integration can fail while WordPress happily stores entries locally.
That is why I do not like security monitoring that stops at "malware not found." I want to know whether the site is still doing the job the client pays the agency to protect.
Signals Worth Watching
- Plugin, theme, and WordPress core update events
- New administrator users or privilege changes
- Failed login patterns and suspicious authentication behavior
- Form submission failures, missing confirmation emails, and CRM delivery failures
- WooCommerce cart, checkout, payment, and order-status problems
- Browser JavaScript errors on conversion pages
- CSP violations from new or suspicious scripts
- Security-header drift after host, cache, CDN, or plugin changes
- DNS, TLS, domain, redirect, and sitemap changes
- Performance degradation that makes the site effectively unusable
What An Incident Should Tell You
A useful alert should not just say "something happened." It should help answer what changed, who is affected, and what evidence exists.
For example: "The checkout submission started failing after WooCommerce and a payment plugin were updated. Product pages still load, uptime is healthy, but mobile Chrome sessions are seeing JavaScript errors on the checkout step."
That is the kind of summary an agency can act on. It is also the kind of summary a client can understand if the agency needs to explain what happened.
A Safer Update Routine
- Know what changed: core, theme, plugin, content, CDN, DNS, host, or tag manager.
- Back up first and make sure the restore process has been tested recently.
- Update high-risk plugins with extra care, especially forms, payment, membership, security, cache, and page-builder plugins.
- Check critical pages after updates from outside the WordPress admin.
- Submit test forms and confirm the expected downstream result, including email or CRM delivery where possible.
- Run checkout or booking checks for stores and revenue-critical flows.
- Watch browser errors, CSP reports, security headers, uptime, and performance after the update window.
- Keep enough evidence to explain the incident if a client asks what happened.
Where MetricPoints Fits In My Head
I am building MetricPoints around this exact problem: agencies need to know when client sites are broken, unsafe, or no longer trustworthy before the client finds out.
That means WordPress plugin context is useful, but it should not be the whole story. External checks still matter. Browser evidence still matters. CSP and security-header evidence still matters. Forms, checkout, DNS, TLS, redirects, analytics, and performance all matter too.
The goal is not to turn MetricPoints into a generic WordPress manager. The goal is to help agencies see the health of the client websites they are responsible for, with enough evidence to respond calmly and quickly.
Bottom Line
WordPress security is not a plugin you install and forget. It is an operating practice.
Keep the site lean. Limit access. Update carefully. Verify important business functions. Watch for suspicious changes. Keep evidence. And do not let a green homepage check convince you the whole client site is healthy.