Updates are the job every agency says it does and few do properly. Clicking “update all” on thirty client dashboards takes an afternoon. Checking that each site still works afterwards takes much longer, so it quietly gets skipped. Then a client emails to say their contact form has stopped sending, three weeks after the update that caused it, and nobody can remember what changed.
White label WordPress updates are our answer to that: the core, plugin and theme updates on your client sites, done with a backup first, tested afterwards and written up in notes you can send as your own. This page explains the routine and the decisions that stay with you. For how this fits into a wider outsourcing setup, see our guide to WordPress outsourcing for agencies.
Why “update all” is not a process
The risk in an update is rarely the update itself. It is the combination: a plugin that now expects a newer PHP version than the host provides, a theme that overrides a WooCommerce template which has just changed, two plugins that both load the same library in different versions. Each of these looks fine in the dashboard. The problem only appears on the front end, sometimes only on one page or one checkout step.
So the useful part of an update service is everything around the button. Reading what changed. Choosing the order. Knowing which pages on this particular site matter most. Checking them afterwards. If you want the technical background on how core, plugin and theme updates differ, our post comparing core, plugin and theme updates and the order to run them covers it in detail.
The routine on each site
- Backup. A fresh backup of files and database, stored away from the server, before anything changes.
- Read the changelogs. Major versions, security releases and anything that mentions breaking changes, removed features or new requirements get attention before they are applied.
- Staging where it exists. On sites with a staging copy, updates are applied there first. On sites without one, we work in a quiet period agreed with you and keep the backup ready.
- Update in a sensible order. Usually plugins first, then theme, then core, in small groups rather than all at once, so a fault can be traced to its cause.
- Check what matters on this site. The homepage, key landing pages, forms, logins, search and, on stores, the cart and checkout. We keep a short list per site so the checks reflect what the client actually depends on.
- Write it up. What was updated, from which version to which, anything held back and why.
On sites where you already have a staging workflow, we fit into it. If you are still deciding how staging and approvals should work across your clients, the post on running staging and deploys for client sites is a practical starting point.
When we hold an update back
Not every available update should be installed the day it appears. We hold one back when the changelog describes a large rewrite, when the plugin’s support forum shows a wave of fresh complaints, when it needs a PHP version the host does not offer yet, or when the client has asked for no changes during a busy period such as a sale or a launch.
Security releases are the exception. If an update fixes a vulnerability that is being exploited, we tell you and recommend applying it promptly, with extra checking, rather than waiting for the next cycle. You make the call; we make sure you have the facts to make it.
Held updates are not forgotten. They appear in your notes with a reason and a suggested date to revisit, so the list of pending updates never grows silently.
Premium plugins and licences
Many client sites depend on premium plugins and themes, and those only update when a valid licence is in place. Licences expire, get registered to a developer who left years ago, or sit on the agency’s own account across dozens of sites. When we find a premium component that cannot update, we tell you which site, which product and what the licence status appears to be. We do not buy or renew licences on your behalf.
If this is a recurring headache across your client list, our post on keeping premium licences in order across many clients covers how to organise them. We also flag plugins that are no longer maintained by their developers, because an abandoned plugin will eventually need replacing even if it updates cleanly today.
When an update breaks something
Careful testing reduces breakage; it does not eliminate it. When a check fails, we stop updating that site, identify which component caused the fault and either roll it back or fix the conflict, depending on what is simplest and safest. You get a note of what happened and what we did, written plainly enough to pass on if the client noticed.
Sometimes the fault only shows up later, after a client reports something odd. Because each update round is logged with versions and times, tracing it back is much quicker. For broken sites that arrive from outside our routine, such as a client who ran updates themselves, our repair service for sites broken by an update is the specific page to point to.
Sites that have been left for years
Every agency has a few. A site built long ago, still live, with a dashboard full of pending updates and a PHP version the host is about to retire. Updating it in one go is how a working site becomes a broken one. Leaving it is how it eventually gets hacked.
For sites like this we do not treat the first round as routine. We take a full backup, build a staging copy if there is none, and work through the backlog in stages: the most outdated or riskiest plugins first, then the theme, then core, then the PHP version if the host allows a change. Anything that cannot be brought up to date safely, such as a plugin whose developer has disappeared, is listed with a suggested replacement. You get an estimate for this catch-up work before it starts, because it is a project rather than a monthly task.
Store sites need their own rules
WooCommerce updates deserve more care than most. The plugin moves fast, many stores rely on extensions from different developers, and themes often override WooCommerce templates that change between versions. A fault in checkout costs the client money while it lasts.
On store sites we place a test order where the payment setup allows it, check that order emails still send, and look at the template override warnings WooCommerce shows in its status screen. We agree with you when updates should not happen at all, such as the days around a big promotion. If your store clients need more than updates, our WooCommerce support for agencies covers the wider work.
What your client sees, and what you control
Your client sees a site that keeps working and a note from your agency saying it has been updated. Plugin notification emails go to an address you choose, and the admin account we use is one you created, so the activity log shows a user you can name and remove. We never contact the client, and we never decide on your behalf to change something visible on their site.
You stay in control of three things. The schedule: how often each site is updated, and when not to touch it. The exceptions: whether a held update gets applied, and whether a security release jumps the queue. The message: what the client is told, in your words, through your channel.
The notes you receive
After each round you get unbranded notes per site: versions before and after, checks performed, anything held back and why, anything that broke and how it was handled, and anything the client should know, such as a feature that now looks different in their dashboard. They are written so you can paste them into your own report. If you want that report produced for you, the white label reporting page explains how.
Updates are usually one part of a broader maintenance arrangement. If you want backups, monitoring and small edits handled too, our ongoing maintenance service for agencies builds on the same routine. And because all of this sits inside our wider agency development and support work, a fix that turns into a larger job can move across without starting from scratch.
To get started, send us a list of the sites you want covered, the access you can share, and anything special about each one: staging copies, premium plugins, store sites, or periods when the client wants no changes. We will review a couple of sites first and come back with any risks we see before the first update round.