WordPress update management
Updating one WordPress website is a button. Updating sixty is a policy: what runs on its own, what waits for a person, what happens at three in the morning when a plugin update takes a client's website down, and how you find out. This is how SiteVigilante answers each of those.
What happens when an update runs
One item at a time, in the same loop whether a person pressed the button or the maintenance window came round.
The website's state is recorded first
Before anything is installed, SiteVigilante takes a reading of the website — including its error log — so that "it was already like that" and "we did that" can be told apart afterwards. Without a before, an after proves nothing.
One item is updated
A single plugin, theme or core release — not a batch. Updating one thing at a time is slower and is the only way to know which thing broke the website when one of them does.
The website is checked from the outside
The platform then forms its own verdict on whether the website is healthy, rather than accepting the website's word for it. That distinction is recorded: a check that passed is verified, a check that failed is unhealthy, and no check taken after the last action is unknown — which is never treated as a synonym for fine.
If it is healthy, the run moves on
The item is recorded as updated, with the version it came from and the version it went to, and the loop takes the next one.
If it is not, the plugin or theme is put back
The previous version is restored and the website is checked again. If that fixed it, the item is recorded as rolled back and held at the working version rather than being offered again the next night.
If it is still broken, the plugin is switched off
A last resort, and it is deliberately the last one: a client's website with one plugin deactivated is a website that works. It is recorded as deactivated so that a person knows to look, rather than discovering it from the client.
You are told what happened, in plain language
When an update fails or is reversed, SiteVigilante explains what happened, what state the website is in now, and what you can do next — automatically when it happens, and again on demand from the update history.
The honest boundary on rollback
Reversal is attempted for plugin and theme updates, by reinstalling the version that was there before. It is not a whole-website restore, it is not attempted for a WordPress core release, and no restore point is taken before every update.
When recovery is not possible, this product does not pretend otherwise: you get a failure report naming the item, the outcome and the state the website was left in. A tool that claims universal rollback is making a promise about somebody else's server that it cannot keep, and finding out which is true costs a client.
What runs on its own, and what waits
Automatic updating is a per-website decision, not an account-wide switch. Turn it on for the estate of small brochure sites and leave it off for the shop you would rather watch — the setting lives on each website.
A major WordPress core release is never installed automatically. It stays on the website's Updates page until a person chooses to run it. Major releases are where themes and page builders break, and that is a decision an agency makes with its client's calendar in front of it, not one a scheduler makes at three in the morning.
Automation runs in each website's own maintenance window — the small hours in that website's timezone, not in ours. A Belgian agency's Australian client does not get their updates in the middle of their working day.
Who decides what
- Automatic updates: on or off, per website.
- Major core releases: always a person, never the scheduler.
- When it runs: each website's own night.
- Held components: your decision, estate-wide or for one website.
- Right now: run any item, or a batch, by hand.
Two ways an update stops being offered
Both exist because a queue that keeps retrying the same impossible install is a queue nobody reads.
You hold it
A decision: leave this plugin alone. It applies to your whole estate or to one website, the narrower rule wins, and it ends when you say so. A held component still appears on the Updates page and is still installable by a person — hiding it would hide it from the only person who can decide about it — and it never reads as up to date.
It failed the same way twice
A measurement, not a decision. When the same component fails to install the same way twice, automation stops attempting it and tries again later, because the usual cause is an expired licence and nothing on the website will change until somebody renews it. This one expires by itself, because the evidence for it goes stale.
A download that fails because a premium licence has lapsed is recognised as a licence problem rather than being reported as a broken plugin, so you chase the renewal instead of debugging the website.
Every run leaves a record
Update history covers the estate, not one website: every item attempted, the versions it moved between, how it ended, and on which website. A failed item can be retried from that record, or explained again if the first explanation was not enough.
This is also what a client report is built from. The work is recorded because the product needs the record, and the report is a view of it — not a separate document somebody has to remember to keep true.
Recorded per item
- The website, and the component.
- The version before and the version after.
- The outcome: updated, rolled back, deactivated, failed, or a licence problem.
- Whether the website was verified healthy afterwards, or only reported itself so.
- The explanation, when something went wrong.
The part that updates itself
The connector installed on each website is a WordPress plugin, and it needs updating like anything else. That is usually where a management tool quietly asks you to trust it, so here is exactly how it works.
Every release is built to be byte-reproducible: the same source produces the same archive, and its SHA-256 is declared before it is published. A version, once published, is never rebuilt with different content — a correction takes the next number.
And an upgrade will not start unless the way back has been checked first. The platform asks the website which version it is running and confirms that the previous release is still available and still matches its published hash. If it cannot confirm that, it refuses to upgrade rather than proceeding and hoping.
Before an Agent upgrade
- The website is asked what it is running, over a signed request.
- The previous release is confirmed present and hash-matched.
- The new release is confirmed to match its declared SHA-256.
- Any one of those unconfirmed, and the upgrade does not happen.
Try it on a website you already look after
14 days, no card required, €1.49 per website per month afterwards, excluding VAT. Connect one website, let a maintenance window pass, and read what it did.
Read next
WordPress management for agencies
The estate view, client organisation, component inventory, the checks that run on their own, and branded client reporting.
Security monitoring
The other half of keeping an estate safe: what is checked, what a finding carries, and what this product will not do.
Performance monitoring
Plugin count and PHP version move page speed more than most advice about page speed. This is how both are measured.
What we hold, and for how long
What this product stores about you and your websites, how long it keeps it, and how to have it deleted.
Terms of Service
The agreement governing use of SiteVigilante. Business and professional customers.