The Routine: What to Check and How Often
A WordPress site needs a short set of recurring jobs: confirm it is up and its forms work, install updates in a sensible order behind a fresh backup, prove the backup restores, and prune users and plugins you no longer need. Most of it can run on a weekly and monthly rhythm, and the parts that cannot wait are the ones that touch money or leads.
This is for the person who owns a WordPress site for a business and wants a list they can actually follow, whether they do the work or hand it to someone. The first half is the routine. The second half is how to run it without breaking the site, and when it stops being worth doing yourself.
Open the Site and Use It Like a Customer
Uptime tools tell you the server answered. They do not tell you the contact form sends, the checkout button exists, or the phone number in the header is still there. Once a week, load the site in a private window, submit your own contact form with a real address, and check that the message arrives. Add a product to the cart if you sell anything. It takes five minutes and catches the failures that cost leads without ever showing an error.
If the form submits but the message never arrives, the problem is usually the mail path rather than the form, and finding the break in order is a separate job with its own steps.
Back Up First, and Know What the Backup Contains
WordPress's own documentation says a backup has two parts, the database and the files, and that you need both to restore a typical site. A files-only copy brings back your theme and uploads but none of your posts, orders, or settings. A database-only copy is the reverse. Many cheap backup setups quietly cover one of them.
The same page suggests weekly backups for a small site with few changes and daily backups for a busy one, always one before an upgrade, and keeping copies in more than one place. A backup that lives only on the server it protects disappears with the server. Check where yours is stored, how many days it goes back, and whether the database is in it. Those three answers matter more than the name of the plugin.
Update in an Order That Makes Problems Easy to Trace
Updates are where most maintenance risk lives, so they get a routine of their own. A pattern that holds up: take the backup, update plugins one or two at a time with the checkout and form tests in between, update the theme, then WordPress core. If something breaks after the second plugin, you know which one.
Know what WordPress does on its own. According to the upgrade documentation, existing installations receive minor core releases automatically by default, while plugins and themes update on their own only in special cases. That means the plugin that runs your forms is waiting for a human unless someone turned auto-updates on for it, and most owners never did.
Since WordPress 6.6, a plugin or theme that is auto-updated and then triggers an error is rolled back to the earlier version and the site owner is emailed, as described in a WordCamp Europe session on the feature. That is a useful safety net for fatal errors. It will not notice an update that leaves the site loading but with a broken layout or a form that no longer sends, which is why the weekly customer test stays on the list.
Pick a Day for Updates and Keep It Off Friday Afternoon
The day matters more than people expect. Run updates on a weekday morning when you will be at your desk for the rest of the day, not at five o'clock before a weekend. If an update goes wrong at 4:55 on a Friday, the site stays broken until Monday or someone gives up their evening. A Tuesday or Wednesday morning also leaves time to reach a plugin's support if the fix is not yours to make.
Look at Who Can Log In
Once a month, open Users and read the list. Remove accounts for people who have left. Check that only the people who need Administrator have it, since an editor can do most of what a content team needs. Old contractor accounts with administrator access are one of the commoner ways a site ends up with a stranger inside it. The security checklist goes further on passwords and roles; for maintenance, the habit is simply to read the list.
Delete What You Do Not Use
A deactivated plugin still sits on the server, and if it has a known flaw, the files can still be reached. Delete plugins and themes you have stopped using rather than leaving them switched off. Keep one default theme as a fallback, which helps when you need to rule your own theme out while debugging. Less code on the site means fewer updates to run and fewer things that can break at the same moment.
Keep the PHP Version on the Supported List
PHP is the language WordPress runs on, and each release stops receiving fixes on a published date. As of October 2026, the PHP supported versions page lists 8.2 and 8.3 as security-only, and 8.4 and 8.5 as still in active support. PHP 8.2 stops getting security fixes on 31 December 2026, so a site on it has a deadline.
Find your version under Tools, then Site Health, then Info. If it is on its way out, ask the host to move you, but do it on a copy first, because an old plugin written for a retired PHP version is the usual reason a site shows a white screen after the change. The white screen guide shows how to read the error if that happens.
Making It Stick Without Breaking the Site
The routine only works if updates are tested somewhere safe, restores are proven rather than assumed, and each visit leaves a note about what changed. Those three habits are what separate a maintained site from one that is merely updated.
Try Risky Updates on a Copy First
A staging site is a private duplicate of the live one where you can run an update and see what happens. Use one whenever an update touches something that earns money: a checkout or payment plugin, a booking tool, a page builder, or WordPress core itself. For a small brochure site with a simple theme, updating live behind a fresh backup is a reasonable trade. The rule of thumb is to ask what happens to the business if this breaks for a day, and stage the updates where the answer is a lot.
Staging has one catch. A copy does not receive live orders or form entries, so it will not show a problem that only appears with real traffic or real payments. It reduces risk. It does not remove it.
Practice a Restore Before You Need One
The WordPress backup page tells you to check automated backups by taking a manual one now and then. Go one step further: restore a backup to a staging copy at least once a year, and open the site. You are checking that the file is complete, that you know where to click, and how long it takes. A backup nobody has ever restored is a hope, and the first real restore should not also be the first time you learn the steps.
Check the Pages That Matter After Every Update
After each round of updates, open the five pages that matter to the business: the home page, the main service or product page, the contact page, the cart or booking page, and one blog post. Look for a broken layout, missing images, and an error banner. Then submit the form once more. A site can pass every automatic check and still have a menu that has collapsed on phones, so look at it on a phone as well as a desktop.
Keep a Plain Log of What Changed
One line per visit is enough: the date, what was updated, and anything odd. When something breaks three weeks later, that list tells you what changed around that time. A shared spreadsheet or a note in your project tool will do. The log also makes it easy to hand the site to someone else, because they can see what has been done and what you have been putting off.
Track Paid Plugin Licenses and Renewal Dates
A paid plugin stops updating when its license lapses, and the first sign is often a security fix that will not install. Keep a list of every paid plugin, where it was bought, whose email it is tied to, and when it renews. Licenses bought on a former employee's card and email are a standard way for this to fall through. If you want it handled for you, there is a premium plugin license service that buys and renews them.
Decide What Your Time Is Worth
Add the routine up honestly. Weekly checks, a monthly update round, user review, and the occasional restore test is a standing commitment, and it is the part that gets skipped the week a deadline lands. If the site earns real revenue, the cost of skipping it is a plugin conflict that sits unnoticed for a month. If it is a small brochure site, doing it yourself on a calendar reminder is entirely reasonable.
If you would rather not carry it, Managed WordPress Maintenance from Cascadia covers the same ground. Updates run on a schedule and are tried in staging, backups are taken every 24 hours and kept in the cloud for 180 days, a malware scan runs every 24 hours, and the site is monitored around the clock, with daily visual checks on key pages and form checks twice a day. The comparison page sets that against a maintenance dashboard tool. If the site is also slow, the speed diagnosis and managed hosting are the usual next reads.
