WordPress maintenance for high-stakes sites: patches, uptime, and compliance

WordPress maintenance is the suite of operational tasks that prevent downtime and configuration drift on production systems. That definition holds whether you run one brochure site or 400 revenue-bearing properties. What changes with scale is who carries the risk when a patch suddenly goes wrong.

Most “WordPress maintenance” content is written for someone who owns one site and clicks Update All. We’ve prepared this article for the person who has to sign a change record. We’ll cover what belongs in an enterprise maintenance checklist, how to patch production without a maintenance window, what WooCommerce changes about the whole exercise, and where a managed host’s coverage ends and yours begins. We’ll also say plainly when an agency care plan is the better fit than a platform.

Contents:

What is WordPress maintenance, and what does it actually include?

WordPress website maintenance covers six workstreams. Each one has a failure mode that shows up as an incident, not as a warning.

Patching: WordPress core, plugins, themes, PHP, and the OS and services underneath. Unpatched plugins are the most common route into a WordPress site we see, and the gap between disclosure and exploitation is often days, not months.
Backups and restores: A backup you have never restored is a hypothesis. Maintenance means proving the restore path on a schedule, with a measured recovery time.
Performance tuning: Cache hit ratio, TTFB (time to first byte – how long before the server returns the first byte of the response), PHP worker saturation (a PHP worker is one process that can handle one request at a time), slow query review, and asset weight.
Database and cron hygiene: Autoloaded option bloat, orphaned postmeta, expired transients, and a WP-Cron queue that silently stops running.
Monitoring and alerting: Synthetic uptime checks, real 5xx rates, error logs, and queue depth, so you learn about a problem from a graph, not from sales.
Compliance evidence: A change record for every production change: what shipped, who approved it, where it was tested, and how to roll it back.

Skip any one of these for a quarter and nothing happens. Skip them for a year and you get an emergency: a PHP version that reaches end of security support, a plugin two major versions behind that can’t be updated without a code change, and a database that no longer restores inside your recovery objective.

What changes about maintenance at enterprise scale?

At one site, maintenance is a task list. At scale, it’s release engineering with a different name.

Three things change. First, blast radius. A plugin update that breaks a template on a small site is an inconvenience; on a site taking orders it’s revenue, and on a regulated site it’s an incident report. Second, change control. Someone outside engineering now needs to see that changes are tested, approved and reversible, typically to satisfy SOC 2, ISO 27001 or PCI DSS obligations. Third, concurrency of ownership. Core and plugins belong to your developers or agency; PHP, the web tier, the database, the WAF and the OS belong to your host. Maintenance failures cluster at that boundary.

So the useful question for a platform evaluation isn’t “do you handle maintenance?” It’s: which layers do you patch, on what cadence, with what notification, and what do you do when a patch you applied breaks my code? Ask for that in writing. A host that answers it precisely is telling you something about their engineering; a host that answers it with the word “fully” is telling you something too.

DIY vs managed maintenance: who carries which risk?

Nobody gets to skip maintenance. You only get to choose who does it and who is accountable when it fails. This table is the honest version of that split.

Workstream	DIY (in-house)	Agency care plan	Managed hosting for WordPress
OS, web server, PHP builds	You patch and test; needs a sysadmin on call	Usually out of scope	Host patches; you test app compatibility
Core minor/security releases	You schedule and verify	Typically included	Often applied or offered as a managed policy
Plugins and themes	You own it	Typically included, with code fixes	Usually yours; the host doesn’t know your business logic
Custom theme and plugin code	You own it	Included; this is their strength	Out of scope
Backups and tested restores	You build and prove it	Plugin-based backups, variable retention	Platform backups; restore path is the host’s responsibility
WAF, bot and DDoS mitigation	You buy and tune it	Rarely	Included at the edge and host level
Performance tuning at the infrastructure layer	You size and scale it	Rarely	Host’s core competency
Compliance evidence for infrastructure	You produce it	No	Host supplies reports and change records for their layer
Accountability at 3 a.m.	Your on-call	Business hours, usually	Host’s engineers, per the support terms

The honest read: a managed host removes infrastructure maintenance and the 3 a.m. problem. It does not remove application maintenance. If your plugin stack is heavy and your developers have moved on, you still need someone to own plugins, themes, and custom code; that’s an agency care plan or an internal engineer, not a hosting plan. Teams that assume “managed” covers their custom code are the ones who discover a plugin four major versions behind during an incident.

For the cost side of that tradeoff, our notes on cutting your WordPress hosting bill are a reasonable place to start, because overprovisioning is often a substitute for maintenance that nobody has time to do.

What belongs in an enterprise WordPress maintenance checklist?

Organize by cadence, not by task type, so it maps onto someone’s calendar. Every item below is something a practitioner can run and record.

Cadence	Task	How you verify it
Continuous	Uptime and 5xx monitoring with alert routing	Synthetic check from at least two regions; alert on error rate, not just ping
Continuous	Vulnerability feed matched against your plugin inventory	Diff your inventory CSV against a vulnerability database daily
Daily	Backup completion and off-site copy	Job status plus a checksum or size sanity check
Daily	Cron queue depth and failures	`wp cron event list --due-now --format=count`
Weekly	Plugin, theme and core minor updates through staging	Dry run, then staged deploy, then production
Weekly	File integrity check	`wp core verify-checksums` and `wp plugin verify-checksums --all`
Weekly	Slow query and PHP error log review	Top 10 slow queries; new fatal errors since last review
Monthly	Restore test into a throwaway environment	Record the measured time from request to working site
Monthly	Cache hit ratio and TTFB trend	Compare against the previous month at the same traffic band
Monthly	User and role audit; remove dormant administrators	Export users with `administrator` role and reconcile against HR
Quarterly	Plugin inventory review: remove, replace, or accept	Decide per plugin; record the owner
Quarterly	PHP version and major-version upgrade planning	Check your version against the upstream security support window
Quarterly	Disaster recovery exercise against your RTO and RPO	RTO: how fast you must be back. RPO: how much data you can lose
Annually	Change-control and access review for audit	Pull the year’s change records and spot-check five

Start the inventory step with one command, because everything else depends on knowing what you run:

wp plugin list --fields=name,status,version,update_version,auto_update \
  --format=csv > plugins-$(date +%F).csv
wp theme list --fields=name,status,version,update_version --format=csv \
  > themes-$(date +%F).csv

Keep those files in version control. Six months of them is a drift report, and it’s the artifact auditors ask for when they want to know what changed.

How do you patch production WordPress without downtime?

Lead with the sequence, then the reasoning.

Classify the patch: Emergency (actively exploited, or unauthenticated privilege escalation or remote code execution), high (requires authentication or an uncommon configuration), routine (features, minor fixes), or major (core major release, PHP major version, plugin major version with breaking changes). Each class gets a different path.
Dry run: wp plugin update --all --dry-run tells you exactly which versions would move. Nothing changes.
Apply on staging that matches production: Same PHP version, same object cache, same plugin set, representative data volume. Staging that differs from production produces false confidence.
Run your checks: Homepage, login, search, checkout or lead form, one authenticated admin path, and any integration that signs requests. Automate the top five; a smoke test you run by hand gets skipped under pressure.
Deploy with a rollback ready: Database snapshot immediately before, and the exact downgrade command written out: wp plugin install acme-widget --version=1.4.2 --force.
Watch for 15 minutes: 5xx rate, PHP fatals, PHP worker saturation, and cache hit ratio. Most bad patches declare themselves inside the first few hundred requests.

Downtime during patching comes from three places, and each has a fix. Core’s own updater writes a .maintenance file and serves an HTTP 503 for the duration—seconds, usually, and avoidable entirely if you deploy code as an atomic release rather than updating in place. Database schema migrations are the second source: wp core update-db and wp wc update can run long on large tables, so run them deliberately, off-peak, with a snapshot in hand. The third is cache: clearing the full-page cache on a high-traffic site sends every request to PHP at once. Warm the cache or purge by path.

For core-release specifics and our stance on minor versus major updates, see best practices for WordPress updates.

How do you make WordPress patching defensible for compliance?

Auditors don’t ask whether you patch. They ask you to prove it, on a timeline you committed to, with evidence you didn’t write the night before.

Four artifacts carry most of the weight:

An inventory: A current list of core, plugins, themes, PHP and services, with versions. This is the WordPress equivalent of a software bill of materials. The CSV commands above produce it.
A patch policy with named windows: For example: emergency patches applied within 24 hours outside the normal window; high within five business days; routine in the weekly window; majors in a scheduled release. Pick numbers you can actually meet and then meet them. A policy you miss is worse evidence than a looser policy you keep.
Change records: One per production change: ticket, description, versions before and after, test environment, approver, deploy time, rollback plan, outcome. Generate them from your pipeline so they can’t drift from reality.
Exception register: The plugin you can’t update because a template depends on its old filter. Write down the compensating control (WAF rule, restricted access, scheduled replacement) and review it quarterly. Auditors accept documented, mitigated exceptions. They don’t accept surprises.

PCI DSS and similar frameworks specify a maximum window for critical and high-severity patches; confirm the exact wording for the version you’re assessed against with your auditor rather than relying on a blog. The operational point stands either way: your window has to be shorter than the time between disclosure and mass exploitation, which for popular WordPress plugins is frequently a matter of days.

When a patch can’t ship in time, virtual patching at the WAF buys you hours or days by blocking the request pattern before it reaches PHP. It’s a bridge, not a fix. Our write-up of common WordPress security issues and how to resolve them covers the categories that show up most often in these exception registers.

How do you avoid emergency maintenance on production WordPress?

Emergency maintenance is usually deferred routine maintenance with interest. Six practices reduce it measurably.

Keep the delta small. A site two weeks behind on updates is a routine release. A site 18 months behind is a project with its own budget. Weekly beats quarterly, because each individual change is small enough to attribute when something breaks.

Hold staging at parity. Same PHP minor version, same object cache, same cache rules, representative data. If staging runs PHP 8.1 and production runs 8.3, staging is testing a different application.

Deploy immutably, with one command back. Atomic releases and a symlink switch mean rollback is a symlink switch, not a restore. That single capability converts most would-be emergencies into a two-minute blip.

Freeze around peak. For retail, that means a code freeze before the holiday peak, with a short, documented path for security-only changes. For media, it means not shipping during an election night or a product launch. Put the freeze dates on the engineering calendar in advance so marketing sees them too.

Alert on symptoms you can act on. 5xx rate, PHP worker saturation, cache hit ratio drop, database replication lag, cron queue depth. CPU alone tells you very little on a cached WordPress site.

Set a plugin budget. Every plugin is a dependency with its own release cadence, its own CVE history and its own opinion about your database. Reviewing them quarterly and retiring two or three a year keeps the maintenance surface flat instead of compounding.

And one structural note: if a site is so fragile that routine patching feels dangerous, the problem usually isn’t the patch. It’s a stack that can’t be tested or reversed. That’s an architecture conversation, and sometimes it’s a migration conversation. Advanced strategies for a smooth WordPress migration covers how we sequence that work without a long freeze.

What’s different about WooCommerce maintenance?

WooCommerce maintenance is WordPress maintenance plus a transactional system that can’t be wholly cached and mustn’t lose writes. Five items get their own line in the runbook.

1. Order storage

HPOS (High-Performance Order Storage) moves orders out of wp_posts and wp_postmeta into dedicated order tables, which changes query patterns, backup size and any custom code that touched post meta directly. If you’re mid-migration and running in compatibility mode, both stores are being written. Plan the cutover deliberately and verify data parity before you turn off synchronization. WooCommerce ships CLI commands for synchronizing and verifying order data; check the exact subcommands for your installed version before you script them.

2. Action Scheduler

WooCommerce queues background work in Action Scheduler tables. A backlog there is invisible on the front end and expensive at the end of the month. Watch pending action count as a first-class metric and make sure failed actions get retried or escalated, not just logged.

3. Cache boundaries

Cart, checkout, My Account and the REST endpoints behind them must bypass full-page cache; product and category pages should not. Session data in wp_woocommerce_sessions grows, and the cleanup job has to actually be running.

4. Database growth

Orders, order items, subscriptions, logs and scheduled actions all accumulate. Measure before you prune: wp db size --tables --human-readable tells you where the weight is, and retention decisions on order data are a legal question as much as a technical one.

5. Release timing

Never patch a store during peak hours, and never patch WooCommerce itself and a payment gateway in the same release. When a checkout breaks, you want one suspect.

Maintenance on a store is also where update policy gets uncomfortable. Auto-updating WooCommerce extensions on a live store is a bet that the vendor tested against your configuration. We generally recommend auto-updates stay off for commerce-critical plugins and on for everything low-risk, with the security exception handled by your emergency patch path.

Which database and cron tasks actually move the needle?

Most “WordPress maintenance tips” lists recommend database optimization without saying what to look at. Three checks produce almost all the value.

Autoloaded options. Everything marked for autoload is fetched on every single request. A few hundred kilobytes there shows up directly in TTFB.

SELECT COUNT(*) AS option_count,
       ROUND(SUM(LENGTH(option_value))/1024) AS kb_autoloaded
FROM wp_options
WHERE autoload IN ('yes','on','auto');

Note that WordPress changed the accepted autoload values in a recent release, so the IN clause above covers both the old and new conventions. Verify against the version you’re running, then find the offenders:

SELECT option_name, ROUND(LENGTH(option_value)/1024) AS kb
FROM wp_options
WHERE autoload IN ('yes','on','auto')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

Almost always it’s an abandoned plugin caching data in an option. Remove the plugin, remove the option.

Expired transients. wp transient delete --expired clears them. If a transient-heavy plugin is regenerating thousands of rows per hour, the fix is an object cache so transients live in memory, not in wp_options.

Cron. WP-Cron fires on page requests, which means a low-traffic site runs jobs late and a high-traffic site runs the scheduler constantly. On production we prefer a real system cron:

// wp-config.php
define( 'DISABLE_WP_CRON', true );

*/5 * * * * cd /path/to/site && wp cron event run --due-now --quiet

Then monitor it. wp cron test checks that the spawn mechanism works, and wp cron event list shows what’s overdue. A stopped cron queue is one of the quietest outages in WordPress: publishing keeps working, backups and renewals don’t.

How do you use WordPress maintenance mode and when should you not?

Maintenance mode shows visitors a holding page while you change something, and returns an HTTP 503 so search engines treat the absence as temporary. WordPress uses it automatically during core updates by writing a .maintenance file to the web root.

To toggle it deliberately with WP-CLI:

wp maintenance-mode status
wp maintenance-mode activate
# ... do the work ...
wp maintenance-mode deactivate

Three rules if you use it. Serve a genuine 503 with a Retry-After header, not a 200 with “be right back” – a 200 tells crawlers the holding page is your content. Keep it to minutes; a 503 that persists for days will cost you index coverage. And exclude your own office or VPN addresses so your team can verify the work while visitors see the notice.

The better answer at enterprise scale is to not need it. Atomic deploys, database migrations run online, and blue/green or rolling releases mean the site stays up through the change. We reach for maintenance mode in two situations: a long schema migration that can’t run safely under write traffic, and an incident where serving a holding page is kinder than serving errors. For routine patching, a maintenance window is a symptom of a deployment process, not a requirement of WordPress.

One caveat worth knowing: plugin-based “coming soon” modes often aren’t 503s and sometimes cache. If you use one, verify the status code with curl -I https://example.com from outside your network before you trust it.

Do you need a WordPress maintenance service, and which kind?

There are three models, and they’re not competing so much as covering different layers.

Agency care plans cover application maintenance: plugin and theme updates, small content and code changes, visual regression checks, and often a monthly report. Best fit when you don’t have in-house developers and your site needs ongoing design or feature work. They generally don’t own your infrastructure, your WAF or your recovery objectives.

Maintenance tooling (update dashboards, monitoring and backup plugins) gives one person leverage across many sites. Best fit for agencies and in-house teams managing a portfolio. The tool doesn’t carry accountability; you do.

Managed hosting for WordPress owns the infrastructure layer: OS and PHP patching, backups and restores, scaling, caching, the WAF, and the on-call engineer when something breaks at the platform level. Best fit when downtime has a dollar figure attached and your compliance program needs evidence from the infrastructure owner.

For a site where an hour of downtime is measured in revenue or regulatory exposure, you generally need two of the three: a host accountable for the platform, and a team (internal or agency) accountable for the application. If you only buy one and it’s the application side, you own PHP upgrades and disaster recovery by default. If you only buy the host, nobody owns your plugin stack.

At Pagely, we run every site on dedicated AWS infrastructure and handle the platform layer with direct access to the engineers who know your stack rather than a ticket queue. We don’t maintain your custom theme code, and we’ll tell you so on the first call. If what you actually need is someone to rebuild a page template every month, an agency partner is the better spend, and we’re happy to point you at one.

If you’re mapping out who owns which layer before a platform decision, our enterprise WordPress hosting page sets out what we cover. Talk to an engineer about where the lines should sit for your stack.

Frequently asked questions

Is WordPress experiencing issues today?

WordPress is self-hosted software, so there’s no single global status page for your site. Check your host’s status page and your own monitoring first, then WordPress.org news for core or plugin-repository service issues. Most “WordPress is down” reports trace to one site’s plugin, PHP error or DNS change, not to WordPress itself.

Is WordPress outdated in 2026?

No. WordPress still ships regular core releases, and the block editor, REST API and headless patterns keep it viable for enterprise use. The real question is whether your installation is current. A site on an unsupported PHP version with plugins years behind is simply outdated. That’s a maintenance problem, not a platform problem.

How do you put WordPress into maintenance mode?

Run wp maintenance-mode activate with WP-CLI, then wp maintenance-mode deactivate when the work is done. WordPress serves an HTTP 503 while a .maintenance file exists in the web root. Keep it to minutes, include a Retry-After header, and exclude your own IP addresses so your team can verify the change.

What are the best WordPress maintenance services?

It depends which layer you need. Agency care plans cover plugins, themes and custom code. Portfolio tooling gives one team leverage across many sites. Managed hosting covers OS and PHP patching, backups, scaling and WAF. High-stakes sites usually need both a host accountable for infrastructure and a team accountable for the application.

How often should enterprise WordPress maintenance run?

Weekly for plugin, theme and core minor updates through staging; daily for backup verification, cron checks and vulnerability feed matching; monthly for a tested restore and performance review; quarterly for plugin inventory, PHP planning and a disaster recovery exercise. Emergency security patches follow their own path, outside the normal window.

What makes WooCommerce maintenance different from regular WordPress maintenance?

Stores carry transactional risk. You’re managing HPOS order tables, an Action Scheduler queue that can silently back up, cache rules that must bypass cart and checkout, and session and order data that grows continuously. Patch off-peak, never ship WooCommerce and a payment gateway in the same release, and freeze code around peak trading.

Team Pagely