Your WordPress site worked on Friday. On Monday a plugin update left the checkout blank, or the contact form stopped sending leads, or the homepage showed a white screen. Someone fixed it, and three weeks later it happened again.
That pattern is not bad luck. It is what happens when updates reach a live site untested and nobody owns the result. A proper WordPress maintenance service replaces that gamble with a process: staging, tested updates, restorable backups, monitoring and a named team on the hook.
This guide is for marketing leads and teams who have to decide who maintains and secures the site. We cover why updates break things, what a service must include, how in-house, freelancer, host and agency options compare, and how the Care plan at werun.dev runs it.
Key takeaways
- WordPress sites break after updates because untested changes reach production, not because updates are inherently dangerous.
- A real maintenance service means staging, tested updates, restorable backups and monitoring, with a named team responsible for the result.
- Security is a process of fast patching, tight access and incident response, and a security plugin covers only a small part of it.
- Accountability is the deciding criterion: choose the option where one party owns the outcome when an update goes wrong.
Why WordPress sites break after updates
WordPress itself is not fragile. A typical business site is a core install plus a theme, often a page builder and dozens of plugins, each written by a different team on a different release schedule. Every update changes code that something else depends on.
Three causes explain most of the breakage we see. None of them is solved by clicking Update more carefully.
Cause 1
Plugin and theme conflicts
Two pieces of code touch the same hook, template or library, and an update changes the contract between them.
Cause 2
Version gaps
PHP, WordPress core and plugins drift apart until one update forces a jump of several versions at once.
No staging
Updates are applied to the live site, so the first test is performed by your visitors.
Plugin and theme conflicts
Two plugins hook into the same action or filter. Or they bundle incompatible versions of the same library. Or a WooCommerce extension and a theme both try to override the same checkout template.
An update to any one of them changes behavior the others relied on. The result is a blank page, a broken form or a layout that quietly shifts. We wrote about the structural reason in the plugin problem: the same open ecosystem that gives WordPress its reach also multiplies the number of code paths that can collide.
PHP and WordPress core version gaps
Hosts retire PHP versions on their own schedule, and PHP releases eventually reach end of life and stop receiving security fixes. A plugin that needs a newer PHP than your server runs will fail on update. An old plugin that calls a function removed in newer PHP will fail after the host upgrades.
Core follows the same logic. Minor security releases usually install automatically, but major releases change APIs, and abandoned plugins never follow. The gap widens quietly for months, and then one forced update has to cross several versions in a single step. That is the update most likely to break the site.
Updating production with no staging
Pressing Update on a live site is a test with customers watching. Without a staging copy you cannot see the failure before visitors do. Without a backup you have actually restored, you cannot undo it either.
In many companies the person who pressed the button is a marketing lead with no developer to call. The fix is not more caution. It is a different place to run the update.
What a WordPress maintenance service covers
A WordPress maintenance service is a recurring agreement in which a named team keeps your site updated, backed up, monitored and secure, and fixes what breaks. The two words that matter are recurring and named. 'We click Update All once a month' is not maintenance. It is the habit that caused your problem.
Use the four areas below as the scope you expect to see in writing.
Updates tested on staging
Every batch of updates goes to a copy of the site first. Someone then checks the paths that earn money: forms, checkout, login, the templates that carry traffic. Only after that does the batch reach production.
This covers core, plugins and themes, including premium plugins whose licenses and update channels need tracking. Security releases get priority. Major releases are scheduled and tested rather than applied the day they ship.
Backups you have actually restored
A backup is a hypothesis until someone restores it. Ask what is included (database and uploads, not just files), where it is stored, how long it is kept and when a restore was last tested.
Backups kept only on the same server as the site fail in the exact scenarios you need them for. Copies stored off the server, with a restore drill on a schedule, are what make a rollback a routine action instead of a crisis.
Uptime, performance and error monitoring
Monitoring means someone is told before your customers tell you. That includes uptime checks from outside your host, PHP error logs and a watch on performance after each release.
Performance matters because updates can regress it silently. Google publishes thresholds for Core Web Vitals on web.dev: an LCP of 2.5 seconds or less and an INP of 200 milliseconds or less, measured at the 75th percentile. A plugin update that adds a render-blocking script can push a page past those lines without anything looking broken.
Support and response times
You need to know who you write to, through which channel and how fast you get an answer. Response targets should be written down, not implied.
Also settle the border between maintenance and new work. Fixing something an update broke belongs in maintenance. Building a new template or integration is development, which is a separate budget line.
WordPress security service: what it must include
Security on WordPress is a process, not a product. Not a plugin problem. A patching, access and response problem. A useful WordPress security service covers three layers, and each one needs a person responsible for it.
Vulnerable plugins are the usual entry point
Public vulnerability databases list far more issues in plugins and themes than in WordPress core. Attackers scan the web for sites running known-vulnerable versions, so the time between a fix being published and your site installing it is the exposure window.
That makes patch speed the main control. It also means abandoned plugins are a liability: if the author no longer ships fixes, the plugin has to be replaced, not just monitored. For the wider picture of risk categories, see our piece on web application security and OWASP priorities.
Scanner, not a patch
A security plugin scans files and blocks some bad traffic. It does not update your vulnerable plugins, replace an abandoned one or review who has admin access. Those three jobs need a person.
Access control, two-factor and least privilege
Most sites carry admin accounts nobody remembers: a former employee, an old agency, a freelancer from a past campaign. Each one is a door.
A security service reviews users on a schedule and applies a short set of rules:
- Two-factor authentication for every admin and editor.
- Roles by need, so authors and shop managers do not hold administrator rights.
- Unique credentials per person, with no shared logins.
- Unused plugins and themes deleted, not just deactivated.
- Server and hosting accounts owned by your company, not by a vendor.
Monitoring and incident response
Prevention fails sometimes. What separates a bad day from a bad month is whether a plan exists. File-change detection, malware scans and login alerts tell you something happened.
The response itself is a sequence: isolate the site, restore a clean backup, rotate every credential, find the entry point and patch it. Ask who does this at night and on weekends, and where that is written down. The official WordPress documentation describes the platform-level tools, but it cannot assign the responsibility.
Choosing a WordPress maintenance service: your options
There are four realistic ways to get this done: your own team, a freelancer, a hosting plan or a specialist agency. Compare them on four criteria: who is accountable, what is covered, what the cost looks like over time and what can go wrong.
Cost deserves a note. Maintenance is a continuing line item, and the real comparison is not monthly price against zero. It is a predictable monthly amount against unpredictable emergency work, lost leads and the cost of rebuilding trust after an outage.
Where each option fails
Each option works in some situations. The failure points are different, so it helps to name them.
- In-house: works when you have a developer with time to spare. It fails when the person is a generalist, goes on holiday or leaves, because the process lives in one head.
- Freelancer: a good one knows your site well. The risks are availability and a single point of failure, and scope that stays informal until something breaks.
- Host plan: managed hosts handle servers, often backups and sometimes core updates. They do not test your plugins against your site or fix it when a plugin update breaks a template.
- Specialist agency: gives you a team, a process and written scope. The risk is uneven quality, which is why vetting matters.
Option A
Freelancer
- One person who may know the site well
- Testing depends on their habits
- Coverage ends when they are busy or away
Option B
Host plan
- Server, uptime and often backups handled
- Your plugins and theme are out of scope
- Staging may exist, but testing is on you
Our pick for this case
werun.dev Care plan
- Team accountable for the outcome
- Every update tested on staging first
- Backups, monitoring and security in one scope
A comparison table by criteria
The table puts all four options side by side. Read the bottom row first: the main risk is the best predictor of which option fits your situation.
| Criterion | In-house | Freelancer | Host plan | Specialist agency |
|---|---|---|---|---|
| Accountability | Your team, shared with other work | One person | Server level only | A contracted team |
| Staging and tested updates | Depends on skills | Depends on the person | Staging often offered, testing is yours | Standard process |
| Coverage when someone is out | Weak | Weak | Strong for the server | Team coverage |
| Security patching and response | Depends on skills | Depends on the person | Server and network level | Defined in scope |
| Cost shape | Salary time, often hidden | Hourly or small monthly, spiky in emergencies | Bundled in the hosting fee | Fixed monthly, predictable |
| Main risk | Key person leaves | Availability | Plugin breakage is your problem | Quality varies, so vet it |
How werun.dev maintains and secures WordPress
Our tagline is the operating model: we don't launch projects, we run them. For WordPress that means two monthly engagements, described on the engagements page. The Care plan is monthly maintenance. The Retainer is monthly development. Either way, you deal with one team that knows your site.
The safe update workflow
Nothing we update touches production first. Every release follows the same sequence, whether it is a plugin patch or a major core version.
Snapshot and back up
We capture the database and files and confirm the copy is stored off the server.
Clone to staging
A copy of the live site becomes the place where the update is allowed to fail.
Update and test
We apply core, plugin and theme updates, then check forms, checkout, login and key templates.
Deploy with rollback ready
The tested batch goes to production with the snapshot standing by.
Monitor after release
We watch errors, uptime and performance until the next cycle begins.
The loop matters as much as the steps. Monitoring after release feeds the next cycle, so a regression found on Tuesday changes how the following batch is tested.
Safe update cycle
- 01Snapshot productionDatabase and files, stored off the server
- 02Clone to stagingThe update is allowed to fail here
- 03Update and testCore, plugins, theme, forms and checkout
- 04Deploy to productionRollback to snapshot stays ready
- 05MonitorErrors, uptime and performance
Safe WordPress update cycle: snapshot, staging clone, tested update, deploy and monitoring, with a rollback path to the snapshot
Care plan versus Retainer
The two engagements answer different questions. The Care plan keeps what you have healthy. The Retainer changes what you have.
- Care plan: updates tested on staging, backups, monitoring, security patching and support when something breaks.
- Retainer: monthly development capacity for new templates, Gutenberg blocks, integrations and performance work.
Many teams run both. A site that is only maintained stays stable but stops improving, and a site that is only developed accumulates unpatched risk.
What happens when an update breaks the site
Because updates meet staging first, most problems are caught before a visitor sees them. If something slips through, the order is fixed: roll back to the snapshot and restore service, then reproduce the failure on staging, find the cause and release a proper fix.
The cause might be a patch, a configuration change or replacing a plugin that no longer fits. You receive a plain-language account of what failed and what changed. The fix lives in your code and your accounts, so you are not locked in to us to keep it working.
If your site is already unstable, we start with an audit of versions, plugins, PHP, users and backups before proposing a scope. You can see how we approach the platform on our WordPress page.
How to vet any maintenance provider
Whoever you choose, test the provider against the same criteria. Our questions to ask a web development agency covers the broader hiring conversation. The checks below focus on maintenance specifically.
Questions to ask before signing
Good providers answer these without hesitation and in specifics. Vague answers are an answer too.
- Do you test every update on a staging copy before production?
- When did you last restore one of your client backups, and how long did it take?
- What are your response times, and through which channel do I reach you?
- Is the scope written down, including what counts as maintenance and what counts as development?
- Do I own my hosting, domain, repository and admin accounts?
- How do you handle a plugin that has been abandoned by its author?
- What do you report each month, and can I see a sample?
- Who responds if the site is compromised on a weekend?
Red flags in maintenance offers
Some offers sound complete and are not. Watch for these patterns:
- 'Unlimited everything' with no written scope.
- No mention of staging or of how updates are tested.
- Backups stored only on the same server as the site.
- No named person, only a ticket queue with no owner.
- Requests for shared admin passwords by email or chat.
- A pile of extra plugins offered as the fix for every problem.
- The provider holds your hosting or domain accounts.
- No monthly report of what was updated, found and fixed.
Where to start
You do not need to pick a provider this week. You do need to know the state of the site, because every provider will ask. Three actions get you there:
- Audit the current state. List WordPress, PHP and plugin versions, admin users and the date of the last backup restore. If you cannot produce this list, that is your first finding.
- Take a backup and restore it somewhere safe. Do this before anyone touches the site again, including us.
- Define the scope in writing. Decide which parts of the site make money, who needs to respond to an incident and what you expect each month.
If you want a team to take it from there, read how we run WordPress projects and the Care plan and Retainer, then contact us with the audit in hand. We will tell you honestly which option fits, including when it is not us.
Frequently asked questions
Why does my WordPress site break after every update?
Because updates change code that other plugins or your theme depend on, and they are usually applied straight to the live site with no testing. Version gaps in PHP and core make it worse. Testing on a staging copy first catches most breakage before visitors see it.
How much does WordPress maintenance cost per month?
It depends on the number of plugins, whether you run WooCommerce, how fast you need responses and how much security work is included. Maintenance is usually a fixed monthly fee, while emergency fixes are billed per incident. Ask for the scope in writing before comparing prices.
What does a WordPress maintenance plan include?
A solid plan includes updates tested on staging, backups with restore tests, uptime and error monitoring, security patching, user access review and support when an update breaks something. New features are usually separate development work.
Can I just turn on automatic updates in WordPress?
You can, and minor core security releases already update automatically by default. But automatic updates run on the live site with no testing and no rollback, so a conflicting plugin update can take the site down. They are a useful layer, not a replacement for a tested process.
Who can fix my WordPress site after a failed update?
A WordPress developer or a specialist agency with access to your hosting and backups can restore the site and find the cause. Roll back to the last good backup first, then fix the conflict on a staging copy. Ongoing, a maintenance plan gives you a named team to call.
Is a security plugin enough to protect my WordPress site?
No. A security plugin scans files and filters some traffic, but it does not patch vulnerable plugins, remove abandoned ones or review who has admin access. Real protection combines fast patching, two-factor access control, monitoring and an incident plan.
