Web Maintenance
WordPress Maintenance Services
Your WordPress site is not one codebase. It is your theme plus twenty or thirty codebases written by people you have never met, each one holding your database credentials, each one updated on a schedule you do not control. WordPress maintenance services are, underneath the patching and the uptime graphs, a supply-chain function: someone has to decide, continuously, whose code is still safe to run inside your business. Facet does that work because it is the work our engineers already do — our own delivery runs on agent loops, and every line an agent writes clears the same review as a line a person typed. Reading unfamiliar code and deciding what is safe to let in is not a discipline we assembled for your site. It is the one our week is built around.
How could AI agents run your WordPress maintenance? Book a WordPress site audit — bounded, run on your real environment, with a written findings report at the end.
The people maintaining your site should be able to read what they are installing
Most WordPress maintenance is a button-pressing job: a dashboard shows twelve updates, someone clicks twelve times, the invoice says maintenance. That model has no opinion about the code it is installing, which is fine until the week one of those updates is the attack.
Facet approaches it as a code-review problem, because that is what our engineers are set up to do.
- We read code we did not write, every day. Facet's software, content and quality review move through agent loops under human command, and nothing an agent produced ships without a person reading it. The muscle that builds — judging unfamiliar code quickly, and knowing when to stop and look harder — is exactly what a plugin decision needs, and it is not a muscle a support desk develops.
- Agents carry the volume; a Facet engineer owns the call. Changelog diffs, advisory matching, regression runs across a staging clone: that is high-volume, checkable work and it runs unattended. Whether a maintainer's change of ownership is routine or a reason to remove the plugin entirely is a person's judgment, on the record, with your name on the approval.
- We name the failure modes. An agent told to "keep WordPress current" with no boundary will happily take a major plugin version that rewrites your checkout template, then spend a day reconciling it. A scanner tuned to report everything trains your team to skim the report inside a month. Both of those are configuration defects we have caused and corrected on our own environments.
What you are actually buying is a trust decision, repeated weekly
Every plugin on your site is a standing decision to run somebody else's code with full access to your data. You made that decision once, probably years ago, probably for a good reason — and nothing in WordPress will ever ask you to revisit it.
So it does not get revisited. The plugin whose author stopped shipping updates in 2023 still runs. The one that quietly changed hands to a new owner with a different business model still runs. The one installed to solve a problem you no longer have still runs, still exposed, still holding credentials.
That is the WordPress-specific risk, and it is not a patching problem. Patching assumes there is a patch. An abandoned plugin is a vulnerability with a future date on it: the disclosure will arrive, and there will be nothing to apply. The only defence is knowing what you are running and who is still behind it — continuously, not once at install time.
What the loop actually does
- Maintain the inventory as a living document. Every plugin, theme and dependency, with its version, its maintainer, its last release date and its advisory history. High volume, entirely mechanical, and revealing the first time anyone sees it assembled.
- Match disclosures against what you actually run. Not "there was a WordPress vulnerability this week" but "this affects the version of this plugin on this site." Most days it matches nothing, which is why it never got done by hand.
- Flag the abandonment signals before they become advisories. A plugin with no release in eighteen months, a maintainer transfer, a support forum going unanswered, a WordPress.org listing pulled. These are findable, boring to check, and predictive.
- Stage, test and diff every update. Build on a clone, run the critical paths, compare the rendered output. Nobody's attention survives the hundredth visual diff at the quality it brought to the first.
What a person still decides
- Whether a plugin should still be here at all. Removal is the strongest remediation available and it is never the automated answer, because something on your site depends on it and only you know whether that something matters.
- What replaces it. Swapping a form plugin is a two-hour job or a three-week migration depending on where its data went, and that assessment is engineering judgment.
- What the checkout path is permitted to risk. See below — this is the most consequential rule we will ask you to set, and it is a business decision.
- Every production deploy, with your sign-off on anything customers touch.
- Whether the honest answer is a rebuild. A site carrying eighty plugins to hold together a structure that three would do properly is not a maintenance problem wearing a disguise. We will say so, and it costs us the retainer.
WooCommerce: the plugin chain runs through your checkout
On a content site, a broken plugin is an inconvenience with a workaround. On a WooCommerce store, the plugin chain and the revenue path are the same path — gateway, cart, tax, shipping, subscriptions, fulfilment, each a separate codebase, each able to break the transaction on its own.
This changes the maintenance rules in a way most providers do not adjust for:
- A broken checkout is not a support ticket. It is a revenue stoppage, and it is usually silent — orders simply stop, and the first signal is a quiet afternoon somebody rationalizes.
- Synthetic transaction monitoring is not optional. The loop puts a test order through the real checkout on a schedule, because the only reliable proof that checkout works is checkout working. Uptime monitoring will report a perfectly healthy 200 on a page that cannot take money.
- Gateway and tax plugins get a stricter update rule than everything else. They update on their own compliance calendars, they break in ways that pass a visual diff, and they are the ones worth staging twice.
Put your own numbers on it (illustrative frame — the inputs are yours). Take your last full month of store revenue and divide by 720. That is roughly what an hour of stopped checkout costs you. Now ask how long it would currently take anyone to notice, given that nothing alerts on an absence of orders. For most stores the second number is the expensive one, and it is measurable this afternoon whether or not you ever call us.
How could AI agents run your WordPress maintenance? Book a WordPress site audit — we run the inventory, the abandonment check and the advisory match on your real environment and hand you the findings in writing.
What is included
Supply chain. Living plugin, theme and dependency inventory; maintainer and abandonment monitoring; advisory matching against installed versions; removal recommendations with a replacement path.
Updates. Core, plugin and theme updates staged on a clone, regression-tested, visually diffed, then deployed with a tested rollback. PHP runtime management, including the awkward part: which of your plugins have not certified against the version you need to move to.
Security. Malware detection and remediation, login and wp-config hardening, XML-RPC and REST API exposure review, file permission and firewall review, certificate monitoring.
Commerce. Synthetic checkout transactions on a schedule, gateway and tax plugin compatibility testing on every release, order-flow monitoring that alerts on an absence of orders rather than only on errors.
Performance and recovery. Core Web Vitals against your baseline, database optimization, caching and image configuration, daily off-site backups with restore verification — a backup nobody has restored is a hope, not a plan — and a defined recovery time objective.
Scope and pricing. Engagements begin at $6,000 and scale with plugin count, environment count, commerce configuration and support tier. We quote after the audit.
Where this goes next
- AI Managed Services — the run layer across your systems rather than one site: the same named-team, logged-output discipline applied to integrations, data and the tooling your store depends on.
- Agentic Engineering — the build layer, for when the audit finds the right answer is replacing three fragile plugins with something purpose-built and owned.
Facet has run technology work for clients since 2014 and was named a CIOReview Top 10 Digital Transformation Services Company in 2021. A site that comes out of the audit needing nothing is a complete outcome, and we will tell you when that is what we found.
FAQ
How much do WordPress maintenance services cost?
Engagements begin at $6,000 and scale with plugin count, environments, WooCommerce configuration and support tier. We quote after the audit — plugin count alone swings the work more than site size does, and we have inherited both eighty-plugin sites with no staging environment and lean configurations that genuinely need very little.
What is the difference between this and managed WordPress hosting?
Managed hosting — WP Engine, Pantheon, Kinsta — owns the infrastructure: server uptime, PHP availability, platform-level backups, CDN. It does not own the supply chain. It will not tell you a plugin you depend on has been abandoned, will not decide whether a maintainer transfer is a risk, and will not test your checkout. This service runs at the application layer on top of whatever host you are on. The two are complementary.
What if a plugin update breaks something in production?
It is staged and diffed first, so most of these are caught before deployment. If one gets through, rollback restores the prior state before users accumulate, and you get a post-incident note naming the conflict and what changed. We then work the compatibility issue — with the plugin vendor where that is the right route — and re-deploy when it is confirmed.
Do you only maintain WordPress sites you built?
No, and most start elsewhere. The audit documents what we are inheriting — plugin hygiene, update lag, undocumented customizations, security gaps — before we commit to an SLA, including the remediation that has to happen before a maintenance loop can run cleanly on it.
Can you tell us which plugins to remove?
That is one of the audit's outputs, ranked. Removal is the strongest remediation available, and the reason it rarely happens is that nobody has the inventory in front of them or the time to trace what depends on what. That tracing is the work.
You can find out whose code you are running this afternoon
Open your plugins page and pick any five at random. For each one, answer three questions: who maintains it, when did they last ship a release, and what would break if it were gone tomorrow.
Most teams cannot answer two of the three for most of the list, and that is not negligence — nothing in WordPress ever prompts the question, and the software keeps working either way. But those five answers are the actual security posture of the site. Everything else in this category is downstream of them.
The audit answers all three for every plugin you run, and it does it once so that the loop can keep it answered. That is the part worth buying: not a tidier update queue, but a site where the decision to trust somebody else's code is one somebody is still making, on purpose, this month rather than in 2021.
How could AI agents run your WordPress maintenance? Book a WordPress site audit: bounded, on your actual environment. You leave with a full plugin and dependency inventory including maintainer status, an advisory match against your installed versions, a checkout and critical-path test result, a performance baseline, and a ranked remediation list. If the audit says your configuration is lean and current and you do not need us, that is what it will say — and the inventory is yours either way.

