At five WordPress sites, you can just about manage with spreadsheets and manual checks. At fifteen, things start slipping — an SSL certificate expires over a bank holiday weekend and a client emails you Monday morning to say their site is showing a security warning. At twenty-five or more, you have a genuine operational problem that costs real money in emergency firefighting, reactive support, and the slow erosion of client trust.
This guide is written for agencies that have accumulated a portfolio of WordPress client sites and need to move from ad hoc maintenance to a real system. We’ll cover how to structure your plugin update process, how to set up monitoring that actually catches problems before clients do, how to handle security at portfolio scale, and how to make site management a revenue line rather than a hidden cost centre.
The goal is not to recommend any single tool — it’s to give you the operational framework that makes any tooling choice work properly.
Why WordPress Management Gets Hard Exactly When You Can Least Afford It
WordPress sites don’t fail randomly — they fail in clusters. A major WordPress core release drops, and suddenly half your portfolio needs testing. A popular plugin gets compromised (it happens several times a year across the ecosystem), and you need to audit every installation that afternoon. A hosting migration you planned for one client reveals configuration issues that were lurking on three others. The work arrives in spikes, and those spikes hit precisely when your team is already fully utilised on project work.
The compounding factor is that most agencies don’t charge explicitly for ongoing site maintenance when they first take on clients. It gets bundled into the retainer under “ongoing support,” without anyone calculating how much time it actually consumes. A portfolio of 30 WordPress sites, each receiving roughly 45 minutes of maintenance attention per month — updates, checks, backups, minor content fixes — adds up to 22.5 hours a month. At a blended rate of £75/hour, that’s £1,687.50 of uncosted work, every month, before a single support ticket arrives.
The agencies that manage WordPress at scale profitably have solved two things: they’ve made the work systematic enough that it takes far less than 45 minutes per site, and they’ve made it visible enough to clients that they’ll pay for it separately. Both require the same foundation — a proper monitoring and maintenance system.
Start With a Portfolio Audit
Before you can manage anything systematically, you need a clear picture of what you’re actually managing. A portfolio audit sounds obvious, but most agencies have never done one properly. They have a vague sense of how many WordPress sites they’re responsible for, but not a complete, accurate inventory with the specific data that maintenance decisions require.
Your audit should capture, at minimum: PHP version, WordPress core version, the full list of active plugins with current versions, the hosting environment (who hosts it, on what plan, with what backup policy), the domain registrar and SSL provider, and when the site was last updated. For a portfolio of 30 sites, this will take two to three hours to compile from scratch — but it will immediately surface things that need urgent attention. Expect to find at least two or three sites running PHP 7.4 (which has been end-of-life since December 2022), several plugins that haven’t been updated in over a year, and at least one expired or imminently expiring SSL certificate.
Record this in a structured format — a spreadsheet works initially, though purpose-built tooling is worth it once you’re past 20 sites. The point is that you need a single source of truth for the portfolio, not a series of logins you check one by one when something breaks.
Building a Safe Plugin Update Strategy
Plugin updates are where most agency WordPress work actually lives, and they’re where most of the risk is. The naive approach is to apply all available updates immediately — it’s what most automatic update tools do by default, and it occasionally breaks sites in ways that are embarrassing and time-consuming to fix. The overly cautious approach is to review every update manually before applying it, which quickly becomes a full-time job at portfolio scale.
The approach that works in practice sits between these extremes, and it’s based on classifying updates by risk level.
Low-risk updates: apply automatically
Minor version updates (e.g. 3.4.1 to 3.4.2) from established, well-maintained plugins are typically safe to apply automatically. So are WordPress core minor updates (the security-focused ones, like 6.4.3 to 6.4.4). These updates fix bugs and patch vulnerabilities without changing functionality. Most site breakages from plugin updates happen on major version increments, not minor ones. Configuring your portfolio management tool to auto-apply minor updates — with a backup taken immediately before — is the right default.
Medium-risk updates: stage first
Major version increments for core plugins (WooCommerce going from 8.x to 9.x, for example, or Elementor, Advanced Custom Fields, or any page builder) warrant a staging test before being applied to production. The same applies to any update on a site with custom code — a bespoke theme or a plugin that’s been modified by a developer. Set these sites to require manual approval after a staging test, and build a brief checklist for what to verify: homepage loads correctly, checkout process works, contact forms submit, custom post types display as expected.
High-risk: schedule and communicate
PHP version upgrades, hosting platform migrations, or switching core infrastructure plugins (caching, security, backup) should be treated as mini-projects with a defined time window, pre-update backup, post-update verification, and a client communication. Trying to squeeze these into a maintenance window without advance notice is how you end up explaining to a client why their site was down at 10am on a Tuesday.
The rhythm that works for most agencies is a monthly maintenance window — a specific day, communicated to clients in your service documentation — with auto-updates running continuously for minor patches. This gives you predictability, reduces emergency work, and gives you something concrete to include in a monthly report to clients.
Setting Up Monitoring That Catches Problems First
Your clients will tell you when their site is down. What you want is a system that tells you before they notice. The gap between “the site went down” and “the client emailed us” is typically 20 minutes to a few hours for most business sites — long enough to significantly damage client confidence if it happens repeatedly, but short enough to recover from gracefully if you’re already on it when they get in touch.
Effective monitoring for a WordPress portfolio covers three layers: uptime, SSL certificates, and plugin security status.
Uptime monitoring
Check every site every few minutes from a server geographically close to your clients’ audiences. A 5-minute check interval means the worst-case scenario is that a site has been down for 5 minutes before you know about it — acceptable for most use cases. The check should verify an HTTP 200 response from the actual homepage, not just that the server is responding to a TCP ping. A WordPress site can return a 200 from a database error page, a maintenance mode splash, or a caching layer that’s serving a cached version of an already-broken page. Use a keyword check if you can: verify that a specific string that only appears on the live site (the site’s name in the title tag, for instance) is present in the response.
SSL certificate monitoring
Let’s Encrypt certificates expire every 90 days and are typically set to auto-renew. “Typically” is doing a lot of work in that sentence. Auto-renewal fails when: the domain’s DNS has been changed without updating the certificate, the hosting account is suspended or over quota, the renewal cronjob was removed during a server migration, or the email associated with the account has changed and nobody read the expiry warnings. SSL expiry is almost always preventable and yet it remains one of the most common causes of client site emergencies. Monitor expiry dates across your entire portfolio and set alerts at 30 days and again at 7 days. That gives you two chances to act before the certificate expires.
Plugin vulnerability monitoring
The WordPress vulnerability database (maintained by Wordfence, Patchstack, and WPScan among others) tracks known security issues in plugins. When a vulnerability is published for a plugin you have installed across 15 client sites, you need to know the same day — not when you happen to log in to each site for another reason. A good portfolio management setup will cross-reference your installed plugin inventory against the vulnerability database and surface any matches immediately. This is the difference between proactively patching a vulnerability the same day it’s disclosed and finding out about it when a client site gets defaced three weeks later.
The agencies that never have a “sorry your site was hacked” conversation with a client aren’t necessarily luckier — they’re just monitoring vulnerability disclosures instead of waiting for incidents.
WordPress Security at Portfolio Scale
Security for a single WordPress site and security for a portfolio of 30 sites are meaningfully different problems. For a single site, you can apply best practices manually and remember the specifics. At portfolio scale, you need standards that are applied consistently by default — because anything that requires a human to remember to do it on each individual site will eventually not get done.
The security baseline that every site in your portfolio should meet — and that you should be able to verify from a central dashboard, not by logging into each site individually — includes:
- No default admin username. Still remarkably common on sites migrated from one host to another or built quickly by a developer who didn’t think about it.
- Two-factor authentication on all admin accounts. This is the single most effective control against credential-stuffing attacks on WordPress admin panels. It’s non-negotiable for any site with a retainer agreement.
- XML-RPC disabled. Unless a client is actively using it for something specific (rare for most agency clients), XML-RPC is an attack surface with no business justification. Disable it.
- wp-login.php rate limiting or login URL change. The default WordPress login page receives automated brute-force attempts constantly. Either rate-limit it or move it. The latter is more controversial (security through obscurity), but combined with rate limiting it’s a practical defence.
- File editing disabled from the WordPress admin. The ability to edit theme and plugin files from the WordPress admin is a significant privilege escalation path if an admin account is compromised. Add
define('DISALLOW_FILE_EDIT', true);to wp-config.php across your portfolio. - Automated off-site backups. Daily for active sites, with 30-day retention minimum. The backup should be in a location entirely separate from the hosting account — if the hosting account is compromised or suspended, your backup should not be affected.
Applying this baseline across 30 sites is a one-time project — probably two days of work. Maintaining it as new sites join your portfolio is the ongoing discipline. Build a client onboarding checklist that covers these items explicitly, so the baseline is applied from day one rather than retrofitted after an incident.
Packaging Maintenance as a Revenue Line
The mistake most agencies make is treating WordPress maintenance as overhead — something that has to happen to keep clients happy but that doesn’t generate any direct income. This framing leads to under-resourcing it, under-charging for it, and eventually resenting it. The better framing is that maintenance is a managed service with real, demonstrable value, and clients should pay for it explicitly.
A site care plan — charged at £75–£200/month depending on site complexity and SLA requirements — is a standard revenue line for agencies that have made peace with being responsible for their clients’ WordPress infrastructure. The economics are straightforward: at £100/month across 25 sites, that’s £2,500/month of largely predictable recurring revenue, generated by work that takes less time each month as your processes mature.
The key to selling this is showing clients what they’re getting. A monthly report that shows uptime percentage (99.8% over the past 30 days), SSL status, plugins updated, vulnerabilities patched, and backup status turns invisible maintenance work into visible value. Clients who receive a monthly report rarely question the fee. Clients who receive nothing inevitably start to wonder what they’re paying for. The report doesn’t need to be elaborate — a clean one-page summary sent on the first of each month is enough to establish the habit and make the value tangible.
If you haven’t yet built a formal site care offering, start with your existing retainer clients. Most of them are already relying on you to keep their sites running — you’re just not charging separately for it or reporting on it. Formalising that into a named service with defined deliverables is a straightforward conversation, not a difficult sales pitch.
Connecting Site Management to Your Agency CRM
The gap in most agencies’ WordPress management setup is not the monitoring tool — it’s what happens after the monitoring tool fires an alert. An alert that goes to a generic inbox or a Slack channel without a clear owner and a clear escalation path will be ignored or actioned too slowly roughly 20% of the time, which is exactly the 20% of the time when something serious is actually happening.
The agencies that handle this well connect site monitoring alerts directly into their support ticket system, tied to the relevant client record. When a site goes down, a ticket is automatically opened against the client, an account manager is notified, and the incident is tracked to resolution. When the SSL certificate hits 30 days to expiry, a task is created and assigned. When a plugin vulnerability is published, a priority ticket is raised and a message goes to the client explaining that a security update is being applied.
This is what Marque CRM’s built-in site monitoring is designed to do — uptime checks, SSL monitoring, and WordPress plugin tracking that feeds directly into your client management workflow rather than sitting in a separate tool that nobody remembers to check. For agencies managing 20 or more WordPress sites, having monitoring integrated into the same platform where you manage client records, support tickets, and retainers eliminates a category of operational overhead that is genuinely significant at scale. There’s no separate dashboard login, no manual cross-referencing of alert emails against client records, and no risk of an alert being missed because the wrong person was watching the wrong inbox. You can learn more about how this works on the features page, or see how it fits into the broader pricing on the pricing page.
The practical test for whether your current setup is working: when a client site goes down at 11pm on a Friday, does someone on your team know about it before the client does on Saturday morning? If the answer is “sometimes” or “probably not,” you have a monitoring and alerting problem that is costing you client relationships and team stress in roughly equal measure.
From Reactive to Proactive: The Mindset Shift
Managing WordPress sites at scale is ultimately an operational discipline, not a technical one. The technology — monitoring tools, update managers, security scanners — is mature and accessible. What separates agencies that handle their WordPress portfolio well from those that are perpetually firefighting is the decision to treat it as a system rather than a series of one-off tasks.
That means a complete portfolio inventory, a documented update policy with clear risk tiers, monitoring that covers uptime, SSL, and plugin vulnerabilities, a security baseline that every site in the portfolio meets, and a way to connect monitoring alerts to your client management workflow so that nothing falls through the gaps. Build the system once, refine it over a few months, and the time cost drops substantially while the quality of service goes up.
The agencies we’ve spoken to that have done this properly describe a similar transition: from dreading the monthly maintenance window to barely noticing it, and from client complaints about site issues to clients citing site reliability as a reason they’ve stayed on retainer for three or four years. That’s the compounding return on getting this right.
If you want to explore how Marque CRM’s built-in site monitoring fits into a wider agency management system, take a look at the full feature set or read more in our related articles below.