For a single site, stick with manual updates through wp-admin, but only after confirming a working backup. For an agency running a fleet, move to a central dashboard with staged testing and documented approval steps. The one rule that overrides everything else: never touch a live update without a verified backup and a staging copy to test against first. If you manage client sites for a living, running the numbers on what unmanaged maintenance costs you is worth ninety seconds of your time before you read further.
TL;DR:
- Using a central dashboard for managing multiple sites saves time through bulk updates, inventory tracking, and rollback features, especially for larger or WooCommerce-focused clients.
- Always verify and test backups on staging before updating themes or plugins, and avoid updating critical plugins like payment gateways and page builders simultaneously.
- Maintaining detailed activity logs and implementing version control for custom code enhances troubleshooting, rollback options, and collaboration efficiency.
- Regularly removing unused or outdated plugins and themes minimizes security vulnerabilities and potential performance issues.
- Following a documented update process with risk-based scheduling and proactive security measures reduces the likelihood of emergency fixes and site outages.
Table of Contents
- How should you manage themes and plugins: manual, multisite, or a dashboard?
- How do you install and update WordPress themes and plugins manually?
- What’s the safest workflow for updating themes and plugins?
- How do agencies manage themes and plugins across dozens of sites?
- What tools actually matter for managing plugins and themes at scale?
- What SOP and update cadence should agencies follow?
- What security practices protect a plugin and theme portfolio?
- How do you spot and remove unused or obsolete plugins?
- How do you check compatibility before updating anything?
- How does managing plugins and themes affect site performance?
- Why should you monitor plugin and theme activity logs?
- Should agencies use version control for custom themes and plugins?
- What agencies get wrong about managing themes and plugins
- Let Wpcto handle your themes and plugins so you don’t have to
- Sources
How should you manage themes and plugins: manual, multisite, or a dashboard?
The right approach depends entirely on how many sites you’re responsible for, not personal preference.
Manual updates through wp-admin or SFTP work fine for a single site or a handful of low-traffic ones. They’re simple, free, and give you direct visual confirmation of what changed. The cost shows up at scale: doing this across 20 client sites means 20 separate login sessions, 20 sets of credentials, and 20 chances to forget a backup.
WordPress Multisite suits agencies running near-identical sites off one codebase (franchise sites, membership networks), but it’s the wrong fit when clients need different plugin stacks or you don’t control their hosting.
Separate installs connected to a central dashboard is where most agencies end up. Tools in this category handle inventory, bulk updates, rollback protection, and reporting from one screen, which reduces the time spent on repetitive maintenance tasks considerably compared with logging into each site individually.
Consider these factors when choosing:
- For a few sites with low complexity: manual is defensible, provided backups are non-negotiable.
- For several sites with mixed stacks: a connector-based dashboard can quickly pay for itself.
- For larger numbers of sites or any client running WooCommerce: managed services or a dedicated fractional WordPress lead usually beats internal tooling on cost and risk.
How do you install and update WordPress themes and plugins manually?
Here’s the sequence for a single site, whether you’re working through the dashboard or dropping files in via SFTP.
- Confirm a recent backup exists and restore it once on a test environment. A backup you haven’t tested is a guess, not a safety net.
- Install via wp-admin: go to Plugins > Add New (or Appearance > Themes > Add New), search or upload the zip file, click Install, then Activate.
- Install via SFTP when a plugin isn’t in the WordPress.org directory or wp-admin file uploads are disabled: connect with FileZilla or Cyberduck, unzip the package locally, and upload the folder to
/wp-content/plugins/or/wp-content/themes/. - Activate themes carefully. If you’re customising anything beyond colours and logos, build a child theme first so the parent theme’s updates don’t wipe your changes.
- Switch on maintenance mode before major changes on a live site, particularly for anything touching checkout or membership logic.
- Check compatibility notes in the changelog for the plugin or theme version against your current WordPress core version before updating.
- Run post-update smoke tests: load the homepage, a product or checkout page, the contact form, and check the admin error log for new warnings.
Trusted plugins and themes are worth sourcing from the official WordPress plugin directory or theme repository, where install counts and update history give you a genuine read on maintenance quality before you commit.
What’s the safest workflow for updating themes and plugins?
A safe update workflow isn’t about being cautious for its own sake. It’s about sequencing risk so a bad update never reaches a live client site unannounced.
- Verify your backup restores, not just that it exists. Restore it to a staging copy and load the homepage. An unverified backup has failed you before you needed it.
- Route anything medium or high-risk through staging first. That means WooCommerce, page builders (Elementor, Divi), and any major WordPress core version jump.
- Batch low-risk updates together (minor plugin point releases, translation updates) and run them on a fixed weekly slot. Batch high-risk updates separately and sequence them one at a time, checking dependencies as you go, since some plugins (like WooCommerce extensions) break if updated out of order relative to their parent plugin.
- Use vulnerability or risk scores where they’re available. A connector plugin that surfaces risk scores before you update lets you push safe updates automatically and hold back anything flagged, rather than treating every update as equally urgent.
- Keep a rollback window open for at least 24 to 48 hours after any high-risk update, with logs recording exactly what changed and when.
Pro Tip: Never update a payment gateway plugin and a page builder in the same maintenance window. If something breaks, you want exactly one variable to investigate, not two.
How do agencies manage themes and plugins across dozens of sites?
Once you’re past a handful of sites, the job stops being “update things” and becomes an operations problem. It needs the same rigour you’d apply to any client-facing process.
Start with a site inventory that records, for every client: the hosting provider, the owner or account manager, a risk profile (does it take payments, does it hold personal data, is it a lead-gen site with no real consequence if it’s down for an hour), and the plugins that would cause real damage if they broke.
From there:
- Assign update policies by risk tier: low-risk sites get automatic minor updates, high-risk sites require a named approver before anything goes live.
- Group sites for batched maintenance windows by hosting environment or client tier, so you’re not context-switching between 15 unrelated sites in one afternoon.
- Decide Multisite versus separate installs based on whether clients share a codebase or need independent plugin stacks. Most agency portfolios need the latter.
- Build the inventory to include critical plugin dependencies per site, because tracking site type and business risk against your maintenance schedule is what actually prevents the 6pm Friday emergency call.
If you’re doing this in a spreadsheet today, a workflow built around plugin inventory and bulk updates will save you hours a month the moment you cross ten sites.
What tools actually matter for managing plugins and themes at scale?
Tool categories matter more than individual products. Evaluate against four functions, not feature lists.
Connector and dashboard platforms should give you one-click login to every client site, bulk updates with a preview before you commit, rollback if something breaks, and an audit trail of who updated what. A tool such as Modular DS, accessed through its connector plugin, adds risk scoring so safe updates run automatically while flagged ones wait for a human.
Vulnerability scanners should surface a plain-language risk score, not just a CVE number nobody on your team has time to research. A high score on a plugin running on three client sites should trigger an immediate staging test, not a “we’ll get to it” ticket.
Backup and restore tooling only earns trust once you’ve tested a real restore, not just confirmed a backup file exists in a folder somewhere.
Reporting closes the loop with clients. Greenskeeper logs every update session and generates branded maintenance emails, which turns invisible admin work into something a client can actually see and value on their invoice.
What SOP and update cadence should agencies follow?
A short, repeatable checklist beats an ad hoc process every time, because it means the work doesn’t live only in one person’s head.
- Confirm the site’s entry in your inventory (owner, risk tier, critical plugins).
- Verify the latest backup restores cleanly.
- Test medium and high-risk updates on staging first.
- Run smoke tests on core pages after any live update.
- Log the update session and send a client report.
- Hold a rollback window before closing the ticket.
Cadence should follow risk: daily vulnerability checks, weekly low-risk update batches, monthly full-site health reviews, and quarterly core version audits. Documented SOPs with a defined cadence reduce the environment drift that causes most “it worked on the other site” surprises. Client reports should show update counts, security patches applied, and uptime, which is exactly the evidence that justifies a maintenance retainer rather than a one-off invoice.
What security practices protect a plugin and theme portfolio?
Security failures in WordPress rarely start with a zero-day exploit. They start with an abandoned plugin nobody remembered to update.
Limit plugin installs to what’s genuinely needed, and audit new additions against the WordPress.org plugin directory listing for update frequency and open support tickets before installing anything unfamiliar. A plugin with no update in 18 months is a liability regardless of how well-reviewed it once was.
Enforce role-based access so client staff can’t install plugins themselves, and require two-factor authentication for every admin account, particularly on sites handling payments or personal data. File permissions matter more than most agencies treat them: wp-config.php should never be writable by the web server user, and wp-content/uploads/ should never allow PHP execution.
Run a vulnerability scan against your full site inventory on a weekly basis rather than waiting for a breach to prompt one. A risk-scoring connector flags exposure before it becomes an incident, which is the entire point of proactive maintenance over reactive firefighting. Keep a documented incident response plan too: who gets notified, what the rollback sequence is, and how quickly a compromised site gets isolated from the rest of your hosting environment so one breach doesn’t cascade.
Security monitoring isn’t a one-off task you complete and forget. It’s a cadence, the same as updates, and it belongs on the same inventory sheet.

How do you spot and remove unused or obsolete plugins?
Every WordPress site accumulates dead weight. Plugins installed for a campaign that ended two years ago, themes swapped out but never deleted, page builders left active after a redesign moved elsewhere.
Start by checking each plugin’s last updated date against the current WordPress core version. Anything untouched for over a year, especially if it’s flagged as “not tested with your version of WordPress,” is a candidate for removal, not an update.
Cross-reference activity: deactivate, don’t delete, first, then monitor the site for a week. If nothing breaks, functionality it provided clearly isn’t in active use and it’s safe to remove entirely. Keep a rollback note in your inventory in case a client notices something missing three weeks later and you need to explain what changed.
Watch for the classic warning signs: multiple SEO plugins running simultaneously, two caching plugins fighting each other, or a page builder installed alongside the theme’s native builder. These conflicts often cause the exact performance and compatibility issues clients complain about, without anyone realising the cause is duplication rather than a single faulty plugin.
Audit themes with the same discipline. Delete every theme except the active one and one known-good fallback (a default WordPress theme like Twenty Twenty-Five works well for this), since dormant themes still get scanned for vulnerabilities even when inactive.

How do you check compatibility before updating anything?
Compatibility failures happen at three intersections: plugin against plugin, plugin against theme, and plugin against WordPress core. Skipping any one of these checks is how a routine update becomes a support ticket.
Before any update, read the plugin’s changelog and its “Tested up to” field on its listing page. A plugin tested against an older WordPress version than the one you’re running is a signal to test on staging first, not a guarantee of failure, but a reasonable warning.
For theme compatibility specifically, check whether the theme depends on a page builder or specific plugin version to render correctly. Many builder-based themes break visually when the builder updates ahead of the theme, or vice versa, so update them together and test immediately after.
Core version compatibility matters most for older or heavily customised sites. A plugin built for WordPress 5.x that hasn’t been touched since may function on 6.x but fail silently on specific features, like block editor integrations or REST API endpoints. Staging is the only reliable way to catch this before a client does.
Keep a simple compatibility log per site noting the WordPress core version, PHP version, and the last date every major plugin and theme was confirmed working together. That log becomes invaluable the moment something breaks and you need to identify which update caused it.
How does managing plugins and themes affect site performance?
Every active plugin adds database queries, script loads, or both, whether or not it’s doing anything useful for the visitor in front of the browser.
The biggest performance drains tend to be: plugins loading scripts and styles on every page rather than only where needed, multiple plugins duplicating functionality (two contact form plugins, two SEO plugins), and themes with bloated frameworks bundling features most sites never use.
Audit your plugin list against actual page load impact, not just plugin count. A site with 15 lightweight, well-coded plugins often outperforms one running five poorly built ones. Tools that measure server response time before and after an update give you a clear before-and-after comparison rather than a guess.
Themes deserve the same scrutiny. A theme built around a heavy page builder framework can add measurable load time compared with a lightweight, purpose-built theme, particularly on mobile connections. When performance complaints come in, check theme framework overhead before assuming the problem is hosting.
Bulk update tools that let you test performance impact against a staging copy before pushing to a live site catch this early, rather than after a client notices their bounce rate climbing.
Why should you monitor plugin and theme activity logs?
An activity log answers the question every agency eventually gets asked: “what changed, and when did it happen?” Without one, that conversation is a guess.
Logs should capture, at minimum, who updated what, the version before and after, and the timestamp. This matters most during disputes, when a client claims a feature broke “for no reason” and you need to point to the exact update that coincided with the issue.
Session-based logging, where every update action is recorded and summarised into a report, turns this from a defensive necessity into a client-facing asset. Monthly reports built from these logs are the clearest way to demonstrate the value of a maintenance retainer, because they show concrete work rather than an invoice with no detail behind it.
Review logs proactively too, not just after something breaks. A pattern of frequent emergency updates on one site often signals a deeper stability issue worth flagging to the client before it becomes a bigger problem.
Should agencies use version control for custom themes and plugins?
Any custom theme or plugin your agency builds should live in Git from day one, not just the projects that feel important enough to warrant it.
Version control gives you a rollback option that’s faster and more precise than restoring a full site backup: reverting a single problematic commit rather than an entire environment. It also means multiple developers can work on the same custom code without overwriting each other’s changes, which matters the moment your agency grows past a solo operation.
For custom plugins specifically, tag releases against a changelog so you know exactly what shipped in each client-facing update. This pairs naturally with the same update logging discipline you’d apply to third-party plugins, giving you one consistent record across everything running on a site, whether you built it or installed it.
What agencies get wrong about managing themes and plugins
Most agencies treat plugin and theme management as an annoyance to minimise rather than a service to operationalise. That’s the wrong instinct. The work doesn’t shrink by ignoring it. It just moves from a scheduled Tuesday afternoon task to an unscheduled Sunday evening emergency, which is worse for everyone, including the client relationship you’re trying to protect.
The conventional advice (“just update everything regularly”) misses the actual risk, which is sequencing and testing, not frequency. An agency updating weekly with no staging discipline is more exposed than one updating monthly with a proper rollback plan.
Prioritise by client risk and revenue before anything else. A low-revenue client on a simple brochure site doesn’t need the same cadence as one running a six-figure WooCommerce store. Most agencies discover, once they actually run the numbers on the Profit Calculator, that the maintenance work they’re doing for free or at cost is worth structuring as a proper retainer, not absorbing as overhead.
— Marcel
Let Wpcto handle your themes and plugins so you don’t have to
Wpcto is the alternative to building this operation in-house: instead of hiring, training, and managing an internal maintenance function, you hand the entire plugin and theme workload to a specialist team that already runs the SOPs, staging environments, and reporting this article describes, at a fraction of the cost of doing it yourself. Our care plans cover plugin and theme management, security monitoring, SLA-backed response times, and fully white-labelled reporting, so your clients see a polished maintenance service with your agency’s name on it.
If you’re still unsure whether this is worth the change, run your numbers through the WordPress Profit Calculator. It takes under 90 seconds and shows exactly how much revenue is sitting unclaimed in your current client base from maintenance work you’re already doing for free.
From there, visit our agency services page to book a demo or discuss a white-label partnership, and see how Wpcto sits invisibly behind your brand while you keep the client relationship and the recurring revenue.
Sources
- How to manage multiple WordPress sites without losing control – WP Remote
- 6 essential SOPs for WordPress agencies | Pressable
