WordPress maintenance that's tested, not just clicked
Pressing "Update all" isn't maintenance. Maintenance is knowing what changed, testing it somewhere safe, being
able to roll back in minutes, and keeping the server underneath on a version of PHP that still gets security
fixes.
Core, theme and plugin updates go to staging first, get checked against your key pages, forms and checkout,
then go live.
Backups are stored offsite and restore-tested. A backup you've never restored is a hope, not a plan.
We keep PHP on a supported branch. WordPress recommends PHP 8.3 or newer, and PHP 8.2 stops receiving
security fixes on December 31, 2026.
Plugins are where the risk is: Patchstack counted 11,334 new WordPress ecosystem vulnerabilities in 2025,
91% of them in plugins and only six in core.
When WordPress stops being the right tool for your site, we'll tell you and plan the move.
Who this is for
Businesses whose WordPress or WooCommerce site produces leads or orders, and who can't afford to find out it
broke from a customer. Typical clients:
Inherited a site from a previous developer and don't know what's installed or who has access.
Run 20+ plugins nobody fully understands, often including two page builders.
Have had at least one "the contact form stopped working three weeks ago" moment.
Sell through WooCommerce and need checkout tested after every update, not assumed.
Got a host email saying their PHP version is being retired and don't know what will break.
If your site is a handful of static pages that rarely change, paying for monthly maintenance may cost more than
moving it somewhere with nothing to patch. We'll say so in the onboarding audit.
What maintenance includes
Updates, staged and verified
Since WordPress 5.5, administrators can switch on automatic updates plugin by plugin and theme by theme, and
WordPress runs those auto-updates
twice a day by default. That's useful for small, low-risk plugins. For anything touching checkout, forms, page builders or
membership, we update on a staging copy first, run a smoke test, then deploy. Auto-updates also depend on
WP-Cron, which only fires when someone loads a page; on quiet sites or when cron is broken, updates quietly stop
happening, so we check Site Health every cycle and hook WP-Cron to a real server cron where the host allows it.
PHP and server health
WordPress
recommends PHP 8.3 or greater
and MariaDB 10.11+ or MySQL 8.0+. It will still run on PHP 7.4, but WordPress itself notes those versions are
past end of life and may expose the site to vulnerabilities. PHP branches get two years of active support and
two more of security-only fixes, per the
official schedule. The
full calendar is below. Upgrades are tested on staging because older plugins, not WordPress core, are what
usually break.
Backups you can restore
Daily database and file backups stored away from the web server, with retention long enough to recover from a
problem nobody noticed for a few weeks. Every quarter we restore a backup to staging to prove it works.
Host-level snapshots are a bonus, not the plan — they often live on the same infrastructure you're trying to
recover from.
Security hardening
Admin accounts reviewed: former staff and old agencies removed, least-privilege roles, two-factor login.
Dashboard file editing disabled with DISALLOW_FILE_EDIT, login attempts rate-limited, XML-RPC
restricted if you don't use it.
A web application firewall and CDN in front of the site — Cloudflare in most cases.
Security headers checked with our free Marketing Analytics Auditor,
which tests them alongside performance and tracking.
Malware scanning, with a clean-restore plan if something is ever found.
The plugin list checked against a public vulnerability database such as WPScan, so a known flaw isn't waiting
for the next scheduled window.
Plugin and theme audit
On day one we list every plugin with its last update date, whether it's active, and what it actually does.
Deactivated plugins still sit on disk; abandoned ones stop receiving security fixes; three plugins that all add
SEO meta tags will fight each other. Removing them is usually the single biggest improvement in both security
and speed. Premium plugins bought from marketplaces get extra scrutiny: Patchstack's
2026 report
attributes much of 2025's jump in high-severity flaws to premium components that fewer researchers can inspect.
Performance, uptime and forms
Page caching and image optimization tuned to your host, Core Web Vitals checked per template after updates,
uptime monitoring with alerts to a person, and a monthly test submission through every form, traced into your
inbox or CRM. Forms are the thing owners notice last and customers notice first.
WooCommerce specifics
Checkout gets tested after every update to WooCommerce, payment gateways, shipping and tax plugins.
WooCommerce's own update guide says to back up and test on a staging site whenever possible, and some releases
need a database update after the code is updated. Order emails are checked, and subscription renewals are
watched around plugin updates.
How it runs
Onboarding audit
Plugin and theme inventory, admin users, PHP and database versions, backup status, hosting, security
headers, form destinations. You get a written list of risks, ranked.
Staging and backups
A staging copy and an offsite backup set up before we change anything in production.
Cleanup sprint
Remove dead plugins, fix the PHP version, harden logins, repair broken cron and email delivery.
Regular update window
Staged updates, then a smoke test of the homepage, top landing pages, every form, search, login and
checkout. Critical security releases are applied out of cycle.
Monthly report
What was updated, what was tested, uptime, anything we deferred and why.
What we usually find on day one
Everything set to auto-update on production, with no staging and no tested backup.
Backups saved to the same server they're meant to protect.
A dozen deactivated plugins and a page builder layered on top of a theme with its own builder.
Administrator logins for people who left years ago.
PHP 7.4 running because "the site works."
Broken WP-Cron, so scheduled posts and updates silently fail.
Form notifications delivered to an address nobody reads.
A nulled premium plugin installed to save a licence fee, with no update path at all.
The post-update smoke test
After every update window, before we call it done:
Check
Pass means
Homepage and top five landing pages
Render correctly on mobile and desktop, no PHP warnings, no layout shift from a changed plugin
Every form
A labelled test submission arrives at the right inbox or CRM record
Checkout (WooCommerce)
A test order completes, the confirmation email sends, stock decrements
Search and filters
Return results; no broken archive or pagination templates
Login and accounts
Members and customers can log in and reset passwords
Tracking
Analytics and conversion tags still fire in real time
Site Health
No new critical issues; WP-Cron running
Error log
No new fatal errors or deprecation floods after the update
PHP support calendar
The dates that decide when your host has to move. "Security only" means critical fixes are released as needed;
after the end date there are none.
Most sites arrive with access scattered across people who may no longer be around. Before touching anything we
collect, and move into your name where needed: the domain registrar, DNS, hosting account, an administrator
login created for us (never a shared one), SFTP or SSH, any premium plugin and theme licences, the CDN or
firewall, and Search Console and analytics. Anything we can't get access to goes on the risk list in writing.
When to stop maintaining WordPress
Maintenance is the right call while WordPress is earning its keep. It stops being the right call when a mostly
static marketing site needs a stack of plugins and monthly firefighting to stay upright. That was the situation
at Squeaky Clean Turf: two WordPress installs, one running WooCommerce, with plugins, PHP updates and security
patches as a recurring cost. We moved them to a static Astro site with Shopify checkout, and the attack surface
went from WordPress core plus plugins on two sites to static HTML and four small serverless functions.
We won't push that on you. If WordPress fits your team, we'll maintain it properly. If it doesn't, our
migration service moves you without losing traffic.
Pricing and engagement
A flat monthly fee per site, set after the onboarding audit. It depends on plugin count, whether WooCommerce is
involved, and how often you publish. The cleanup sprint is quoted separately because some sites need an hour and
some need a week. Hosting stays in your name with your provider; we work on WP Engine, Kinsta, and most managed
and VPS hosts. No percentage fees and no long contract, as on our pricing page.
Platforms we work in
What we maintain and the hosts we routinely work on. We work in your hosting account rather than moving you to
ours.
Two WordPress installs, one on WooCommerce, replaced by a static Astro site with Shopify checkout. The
write-up lists exactly what recurring maintenance went away and what replaced it.
Our own site's performance and header fixes, including a duplicate cache header and render-blocking fonts —
the same checks we run after a WordPress update window.
Tests security headers, cookies, tags, accessibility and Core Web Vitals on any live URL. A quick way to see
what your current maintenance routine is missing.
For small, well-maintained plugins, often yes. For anything that touches checkout, forms, memberships or your
page builder, update on staging first. Auto-updates rely on WP-Cron, so if cron is broken they silently stop —
check Tools › Site Health.
What happens if an update breaks my site?
We roll back from the pre-update backup, usually within minutes, then work out the conflict on staging. That's
the point of updating on staging first: most breakages never reach production.
Which PHP version should my WordPress site run?
WordPress recommends PHP 8.3 or greater. PHP 8.2 loses security support on December 31, 2026, and 7.4 is
already end of life. We test the upgrade on staging because older plugins are what typically fail.
Is WordPress itself insecure?
Core is rarely the problem. Patchstack's 2026 report found only six core vulnerabilities among the 11,334 it
recorded for 2025, all low priority; 91% were in plugins. The risk is in what gets installed on top, which is
why the plugin audit matters more than any security plugin.
Do you include hosting?
No. Hosting stays in your account with your provider, so you're never locked in to us. We'll recommend a move
if your current host is the problem.
Can you take over a site built by another developer or agency?
Yes — it's the most common way clients arrive. The onboarding audit documents what's there, who has access,
and what's risky before we change anything.
Do you maintain WooCommerce stores?
Yes. Checkout, payment gateways, shipping, tax and order emails are tested after every relevant update, and
subscription renewals are watched closely.
Get a WordPress maintenance audit
Send your site URL, your host, and roughly how many plugins you run. We'll reply with what we'd check first.
John, Kristy, or Sandeep will reply.One of the three of us will respond personally within 1 business day. No SDR queue.
Message received.
One of us will reply directly within one business day. While you wait, run a free
Buddy audit on your account.
Top 25 references
The primary sources, standards, research, and tools we rely on for this work. Every link was checked on
2026-10-11. We aren't affiliated with these publishers unless noted.
Official documentation
Requirements— WordPress.org WordPress recommends PHP 8.3+ and MariaDB 10.11+ or MySQL 8.0+, and warns that older versions are past end
of life.
Plugins and themes auto-updates— WordPress.org Documentation How per-plugin auto-updates work and that WordPress runs them twice a day by default.
Updating WordPress— WordPress.org Documentation The official core update process, including the advice to back up before updating.
Site Health screen— WordPress.org Documentation What the Site Health status and info tabs check, including scheduled events and PHP version.
Security— WordPress.org How the WordPress security team handles core releases and why third-party plugins are outside its
control.
Hardening WordPress— WordPress Advanced Administration Handbook The official hardening checklist: file permissions, database users, admin access and disabling file
editing.
WordPress Backups— WordPress Advanced Administration Handbook What a complete backup includes (database and files) and why copies should be stored off the server.
Editing wp-config.php— WordPress Advanced Administration Handbook Reference for DISALLOW_FILE_EDIT, cron and debug constants we set during hardening.
Debugging in WordPress— WordPress Advanced Administration Handbook How to log PHP errors safely on staging without showing them to visitors.
Cron— WordPress Plugin Handbook Explains that WP-Cron only runs on page loads and how to hook it to a real system cron.
How to update WooCommerce— WooCommerce Docs WooCommerce's own staging-first update procedure and database update steps.
Wordfence— Defiant Endpoint firewall and malware scanner, plus threat intelligence on actively exploited plugin flaws.
WP-CLI commands— WordPress Developer Resources Command-line reference for scripted updates, database exports and search-replace on staging.
Query Monitor— WordPress.org Plugin Directory Developer panel that shows slow queries, PHP errors and hooks, used to find the plugin behind a
slowdown.
Communities & courses
Make WordPress Core— WordPress.org Where release schedules, dev notes and breaking changes are announced before each core release.
AI disclosure: This page was drafted with AI assistance and edited by a human. Third-party facts
link to the official source they came from (checked 2026-10-11); platform names and logos belong to their owners
and do not imply a partnership or endorsement.
