WordPress maintenance is the work that keeps a site running after it is built: updates, backups, security, performance and the checks that catch a problem before a visitor does.
It gets skipped because a WordPress site keeps working for a long time without it. Then one update collides with one plugin, or a form stops sending and nobody notices for five weeks, and the cost of the skipped hour turns out to be considerable.
This is what the work actually is, how often each part needs doing, and which parts matter most if you only have an hour a month.
Why a Finished Site Still Needs Work
A WordPress site is not one piece of software. It is WordPress core, a theme, usually fifteen to thirty plugins, a PHP version, a database and a web server, all made by different people on different release schedules.
Every one of those moves. Plugins release fixes, core releases security updates, hosts upgrade PHP, browsers change what they accept. A site that is never touched is not standing still, it is drifting away from everything around it.
Two specific pressures make this urgent rather than theoretical. Known vulnerabilities in outdated plugins are published, which means an unpatched site is on a list that automated scanners work through. And an old PHP version eventually stops receiving security fixes, after which the host will move you whether you are ready or not.
The Weekly Checks
Fifteen minutes, and most of it can be automated into alerts so you only look when something is wrong.
Does the Site Load
Uptime monitoring is free and it catches the failure that costs the most. Check the homepage, but also one inner page and one that runs a query, because a site can serve a cached homepage long after the database has stopped answering.
Do the Forms Work
The most common silent failure on a business site. A plugin update, an SMTP token expiring or a host blocking mail is enough, and nothing visible breaks. Send a real test through every form that matters and confirm the message arrives in the inbox it should.
Plugin Updates, Reviewed Rather Than Clicked
Read what each update says before applying it. A security release goes on immediately. A major version that rewrites a page builder waits for a moment when you can test it.
Comments and Spam
Clear the queue so genuine comments are not buried, and watch for a sudden jump, which usually means a form or a login endpoint has been found by a bot.
The Backup Actually Ran
Not that it is scheduled. That it ran, and that the file has a plausible size. A backup plugin that has been failing quietly for two months is worse than no backup, because you believed you had one.
The Monthly Work
Core and Theme Updates
Minor core releases are safe and should not be left. Major ones are worth a staging test if the site is complex. Theme updates need care if the theme was customised, which is why those changes belong in a child theme rather than in the theme files. The WordPress documentation on updating covers the order and the rollback.
Clean the Database
Post revisions, expired transients, spam comments, orphaned metadata and tables left behind by plugins that were removed years ago. On an older site this is often the single biggest easy win, and a database that has halved in size backs up and restores faster too.
Broken Links and 404s
Internal links break when pages are renamed, and external ones break on their own. Pull the 404 report, fix the internal ones at source rather than with redirects where you can, and redirect the ones that have inbound links.
Performance
Measure the same three pages every month so you have a trend rather than a number. A site that slowly degrades over a year is the normal pattern, and it is usually caused by added plugins, uncompressed images and a database that nobody has cleaned.
Users and Roles
Check who still has an account and what they can do. The developer who left in March, the agency that finished last year, the subscriber account created by a bot. Everybody should have the lowest role that lets them do their job.
The Plugin Inventory
Count them, and for each one answer whether it is still used, still maintained and still worth the weight. A plugin with no update in two years and an open support forum full of unanswered threads is a liability waiting for its turn.
Quarterly and Yearly
The PHP Version
Check what your site runs and whether that version is still supported. The PHP project publishes its support dates, and running past them means security fixes have stopped. Test on staging before moving, because old code and old plugins are where the breakage lives.
A Real Restore Test
Restore the backup to a staging site and look at it. This is the task everyone skips and it is the only one that proves the rest of the backup strategy works. Do it once a quarter and you will find the problem on a Tuesday afternoon instead of during an outage.
Licences and Renewals
Premium plugins, the theme, the SSL certificate if it is not automatic, the domain. An expired plugin licence usually keeps working while quietly stopping updates, which is the worst possible failure mode because nothing appears to be wrong.
Content and Search Review
Which pages bring traffic, which ones have quietly died, what is out of date, and what the search console is complaining about. This is where maintenance stops being defensive and starts earning something.
Updates Are the Part That Breaks Sites
Almost every maintenance disaster is an update applied without a way back. The method that avoids it is not complicated.
- Take a backup first, files and database, and know where it is.
- Use staging for anything significant. Most decent hosts include a one click staging site, and it turns an irreversible action into a test.
- Update one thing at a time when you are being careful. If ten plugins go on together and the site breaks, you now have a second problem, which is finding out which one did it.
- Look at the site afterwards. Not the dashboard. The homepage, a product or post page, the checkout or the main form, in a logged out browser.
- Keep a rollback option. Knowing how to restore the previous version of a single plugin turns a bad afternoon into five minutes.
- Automate security updates only. Automatic minor core and security plugin updates are worth having on. Automatic major updates on a complex site are how people find out their builder changed.
One more rule that saves more sites than any of the above: never edit theme or plugin files directly. The next update overwrites the change and the bug appears weeks later with no obvious cause. Use a child theme or a small custom plugin.
Backups, Where Most Sites Are Weaker Than They Think
Almost every site has backups. Far fewer have backups that would survive the event they are for.
- Off the server. A backup stored on the same hosting account disappears with the account, and that covers a hack, a billing failure and a provider outage.
- Files and database together. A database without the uploads folder restores a site with no images. The two have to be taken as a pair.
- More than one generation. If a problem is found three weeks late, a single nightly backup has already overwritten every clean copy. Keep daily for a fortnight and weekly for a few months.
- Tested. A backup is a hypothesis until it has been restored.
- Known recovery time. How long it takes to get the site back is a business number, and most people have never measured it.
A reasonable target for a small business site is daily backups kept off site for thirty days, with a restore tested every quarter. That is not expensive and it removes the category of problem that ends companies.
Security Without the Theatre
Most WordPress compromises are not clever. They come through an outdated plugin, a weak password or a plugin downloaded from somewhere it should not have been.
- Two factor authentication on every administrator account. The single highest value change available, and it takes ten minutes.
- Limit login attempts and move or protect the login URL. Brute force traffic is constant and it is not personal.
- Least privilege. Most people writing content need Author or Editor, not Administrator.
- Remove what you are not using. Deactivated plugins and unused themes still sit on the server and still contain their vulnerabilities.
- Never use nulled premium plugins. The cracked version is the distribution method for the backdoor. This is not a moral point, it is how those sites get owned.
- A firewall or security plugin, but only one, and with its scanning scheduled rather than running on every page load.
- HTTPS everywhere, with mixed content fixed rather than ignored.
The WordPress project keeps a hardening guide covering file permissions and server level settings for anyone who wants to go further.
Performance Is a Maintenance Task, Not a One Off
Sites get slower by accretion. Nobody makes a decision to slow a site down, it just gathers weight.
- Caching, configured once and checked after major changes, because a stale cache causes its own support tickets.
- Images, which are the main cause of a heavy page. Correct dimensions, modern formats and lazy loading below the fold.
- Plugin weight. Measure what each one adds. A single slider or analytics plugin can cost more than everything else combined.
- Database size, covered above, and noticeable on sites with heavy post revisions or a shop.
- Hosting. There is a floor below which no optimisation helps, and cheap shared hosting with an overloaded server is that floor.
When Something Breaks
A short list covers most emergencies, and knowing it in advance is the difference between ten minutes and a ruined day.
A White Screen
Usually a fatal PHP error from a plugin or theme. Turn on debug logging to a file rather than to the screen, read the last error, and deactivate the named plugin by renaming its folder over FTP or the file manager if you cannot reach the dashboard.
A 500 Error
Often the server rather than WordPress. Check the host error log, and check whether a recent edit to .htaccess is the cause. Renaming that file and resaving permalinks resolves a surprising number of them.
Locked Out of the Admin
Reset the password through the database or create a user through a hosting tool. A security plugin that has blocked your own address is a common cause, and the block is usually cleared from the same plugin’s tables.
The Site Looks Broken After an Update
Clear every cache, including the plugin cache, the host cache and the CDN. If it persists, roll the plugin back to its previous version and report it to the developer rather than living with it.
Mixed Content Warnings
Something is loading over HTTP on an HTTPS page, almost always a hard coded image URL in old content. Fix it in the database with a search and replace rather than with a plugin that rewrites every page on the fly.
Doing It Yourself or Paying Someone
For a simple site with a handful of plugins, an hour a month is genuinely enough, and the checklist above is the hour.
It stops being enough when the site makes money, when downtime costs more than the fee, when there is a shop or a membership involved, or when nobody internally wants to be responsible for a restore at nine on a Sunday evening.
If you are buying it, the questions worth asking are specific:
- Where are the backups stored, how long are they kept, and have you restored one for another client this year?
- Do you test updates on staging, or apply them directly to the live site?
- What is the response time when the site is down, and does that include weekends?
- Do I get a monthly report that says what was actually done?
- If I leave, do I get the backups and the access, and in what form?
A plan that cannot answer the first and the last of those is selling an update button with a subscription attached.
Keep a Log
The least technical item here and the one that pays off most.
Write down what was updated, when, and what broke. Six months later it answers the only question that matters during an incident, which is what changed. It also makes handovers possible, and it turns maintenance from a vague obligation into a record of work that a client can see.
A dated list in a document is enough. The tool does not matter.
The Tools Worth Having
You do not need many, and adding more plugins to solve maintenance is its own problem. Five categories cover it.
Backups
One plugin or, better, a host level backup with off site storage. What matters is the destination and the retention, not the brand. If the only copy lives in the same hosting account, it is not a backup, it is a convenience.
Uptime Monitoring
External, so it is not running on the server it is watching. Set it to check more than the homepage, because a cached homepage can look healthy while everything behind it is failing.
A Staging Site
Most decent hosts include one click staging. If yours does not, that is a reason to look at the hosting rather than a reason to update live and hope.
Security
One plugin, not three. Two security plugins running scans against each other produce false alarms and a slow dashboard, and neither is better than one configured properly.
Something That Records What Happened
An activity log plugin, or just a document. When a site breaks, the first question is what changed, and a log answers it in seconds.
What the Hour Actually Looks Like
In practice, a monthly maintenance hour on a normal business site runs roughly like this.
- Five minutes. Confirm the last backup ran and check its size against the previous one.
- Five minutes. Read the update list, decide what goes on now and what waits, and apply security releases.
- Ten minutes. Push the rest to staging, update, and click through the five pages that matter.
- Ten minutes. Apply to live, clear caches, and check the same five pages logged out.
- Ten minutes. Send a test through every form, and check one page that depends on the database.
- Ten minutes. Database cleanup, 404 report, user list, and a glance at the performance numbers against last month.
- Ten minutes. Write the log entry and note anything that needs a decision later, such as a plugin that has not been updated in a year.
The reason it fits in an hour is that the heavy work happened once, when backups, staging, monitoring and roles were set up properly. Sites where maintenance takes a whole morning every month are usually sites where that setup was never done.
Looking After Several Sites
The approach changes once you are past about three sites, because doing the same hour five times stops being realistic.
- Standardise. The same backup tool, the same security plugin and the same host across the estate turns five problems into one.
- Use a management dashboard that shows updates and backup status for every site in one place, and keep the per site checks for anything it cannot see, such as whether the forms work.
- Stagger the updates. Apply a plugin update to the least important site first and leave it for a day. The least important site becomes your canary.
- Keep one list of what runs where. Which site has which premium licence, which PHP version, which host, which client owns it.
- Write down the recovery steps once and make them the same everywhere, so restoring a site is a procedure rather than an investigation.
That standardisation is also what makes the work sellable. A process that is the same on every site can be explained, priced and handed to somebody else.
Frequently Asked Questions
What does WordPress maintenance include?
Updates to core, theme and plugins, backups that are stored off site and tested, security checks, database cleanup, performance monitoring, broken link fixes and confirmation that forms and key pages still work.
How often should I do WordPress maintenance?
Weekly for uptime, forms, plugin updates and backup confirmation. Monthly for core and theme updates, database cleanup, 404s, performance and user accounts. Quarterly for PHP version, restore tests and licence renewals.
What happens if I never update WordPress?
The site keeps working until it does not. Known plugin vulnerabilities are published and scanned for automatically, so an unpatched site is a target, and eventually the host will move you to a newer PHP version that old code may not survive.
Should I turn on automatic updates?
For minor core releases and security fixes, yes. For major plugin versions and anything that touches a page builder or a shop, no, because those need a staging test and a way back.
How do I update plugins safely?
Back up first, use staging for anything significant, apply updates in small batches, check the live site logged out afterwards, and keep a way to roll a single plugin back to its previous version.
Where should backups be stored?
Somewhere other than the hosting account, because a backup on the same server disappears with the account. Keep files and database together, hold several generations, and restore one every quarter to prove it works.
Why has my WordPress site got slower?
Usually accumulation: more plugins, uncompressed images, a database full of revisions and expired transients, and a caching setup that stopped matching the site. Measuring the same pages monthly shows the trend.
What causes the white screen of death?
A fatal PHP error, almost always from a plugin or theme. Enable debug logging to a file, read the last error, and deactivate the named plugin by renaming its folder if you cannot reach the dashboard.
Can I edit theme files directly?
You can, and the next update will overwrite the change. Use a child theme for template changes and a small custom plugin for functionality so your work survives updates.
Is a maintenance plan worth paying for?
It depends on what downtime costs you. For a simple brochure site, an hour a month in house is enough. For anything that takes payments or generates leads, the fee is usually less than one lost day.
If you do nothing else from this page, do three things: get backups off the server, put two factor authentication on the administrator accounts, and send a test through your contact form. Those three cover the failures that cost the most and take about twenty minutes between them.
More from us: advanced copywriting techniques to boost your SEO.