When a website goes live it doesn’t mean that it’s “finished”. This applies even more strongly to websites that use WordPress as their content management system (CMS). WordPress websites, as a whole, form a large share of the web precisely because it is quick to set up and easy to leave alone. But “easy to leave alone” is where there is potential for trouble.
Most of the WordPress maintenance mistakes we see aren’t dramatic. They’re small omissions that sit quietly for months and then present a bill all at once: a day of lost sales, an afternoon of recovery work, a slow leak of search traffic, a customer who no longer trusts the contact form. Often we are called in only when things have gone dramatically wrong. At that point, it lands on our desk as a rescue project. By then the cheapest fixes are long behind us.
Here are the five issues that come up most often, and what they actually cost.
1. Treating updates as optional, or doing them blindly
WordPress core, your theme, and every plugin receive a steady stream of updates, and a good number of them patch security holes. There are two ways to get this wrong.
The first is never updating at all. Vulnerabilities accumulate, and at some point an automated scanner finds one. This may cause data breaches, the installation of backdoors, or various other problems, some of which can be real privacy nightmares if your website is home to a lot of users who put their trust in you to keep their data safe. Now you’re paying for a cleanup, possibly explaining to customers why the site served them something it shouldn’t have, and rebuilding trust you did not budget for.
The second is updating recklessly: clicking “update all” on the live site without making backups or having a second, safe domain to test what the updates do. The risk is that something, anything, such as a plugin conflict, can take the entire website down. We then have to trawl through the logs to find the cause of the issue in order to fix it. To prevent this from happening, back up all your data first, and try to apply the updates somewhere safe, like a staging domain, test, and then push these changes to your live website.
Aside from WordPress updates, it’s also imperative that you update your server. WordPress runs on PHP, a scripting language designed specifically for the web. New versions of PHP are released regularly. These new versions fix issues and vulnerabilities: running an outdated version of PHP on your server is both a security and a performance problem. Most hosts offer easy ways to update PHP at the click of a button, but this comes with its own assortment of risks: some WordPress plugins might not support the most recent version and can cause error. Again, backing up your data and testing somewhere safe before deploying to the live environment is the best way to go.
2. Trusting a backup you’ve never restored
Ask a business owner whether their site is backed up and the answer is almost always, “Yes, the host does that.” Sometimes that’s true. Sometimes it’s daily; sometimes it overwrites yesterday’s working copy with today’s broken one; sometimes, on the day you actually need the file, you discover you can’t get it.
A backup you have never restored is a hope, not a backup. The only way to know it works is to have used it once, deliberately, when nothing was on fire. Ideally backups are automated, stored somewhere other than the server they’re protecting, and tested at least once so you know the restore path end to end.
The day you really need a backup is the worst possible day to learn that it doesn’t exist.
3. Letting plugins pile up
Plugins are one of WordPress’s great strengths. Need to add some features to your website? There’s probably a plugin for that. However, plugins are also one of the easiest things to overdo.
Three habits do most of the damage.
The first is sheer volume: thirty active plugins where ten would do the job, each one adding weight and another thing that can break. For example, while most developers do their best to ensure that their code doesn’t interfere with other plugins, they cannot possibly account for all scenarios.
The second is abandonment: a plugin whose developer stopped shipping updates two or three years ago is an open door, no matter how well it still appears to work. If a plugin hasn’t been updated for several months, it might be time to evaluate if you still need it. If yes, you should try to replace it with a similar plugin that is still actively maintained.
The third is the deactivated plugin nobody removed; deactivated is not the same as gone, and the code is still sitting there to be exploited. Any plugins that are no longer needed should be deleted rather than just deactivated. If a plugin’s developer knows what they are doing, plugin deletion should also clean up whatever changes it made to the database.
None of this requires a purge every week. It requires an occasional, honest audit: what’s actually in use, what’s still maintained, and what can be deleted outright.
4. Editing the live website directly
Your website is the shop window. If you’re running WooCommerce, it’s also the till. Making changes straight on the live site – updating a plugin, adjusting the theme, a “quick” edit before lunch – means every mistake happens in public, in front of customers, sometimes with money attached.
A staging environment is unglamorous insurance. It’s a private copy of the site where you can break things, see what happens, and only then repeat the change on the live website with confidence. It’s the difference between “that update had a conflict, good thing we caught it” and “the shop has been down since Friday afternoon and nobody noticed until Monday.” For the cost involved, it’s one of the easiest wins on this list.
Of course, there is no reason to be overly cautious: fixing a typo in a blog post or a product description is not something that needs to be staged first. Anything that will not immediately harm the experience of the user should be fine. But it’s always better to be safe than sorry, especially when it involves larger and potentially more important changes.
And never, ever do anything on a Friday if you can avoid it!
5. Treating security as a one-time thing
Security isn’t something you set up once and then forget about. Security has to be a posture that you maintain over the long term. The recurring weak spots are familiar: reused or weak admin passwords, no two-factor authentication, unlimited login attempts for anyone who wants to guess, and cheap, oversold shared hosting carrying a website that’s outgrown it.
Hardening a site is ongoing work: strong authentication, sensible limits on login attempts, user accounts with only the access they actually need, a host that suits the site’s scale, and enough monitoring that you find out something is wrong before a customer tells you. Most of this is cheap; not implementing any of this could ultimately end up being very costly.
One of the easiest solutions to implement directly is to make sure that your admin account is secure. An obscure admin username is a good idea, but hardly sufficient in the current age. A strong password is a must, but do not underestimate the persistence of would-be hackers. The strongest defence remains two-factor authentication. And finally, use this account absolutely only when you need to; in all other instances, use lower level accounts to do things like edit texts or add products. And even those should be locked down as much as possible: consider two-factor authentication as the default, not a nice-to-have.
Don’t forget about server security either: your WordPress security is worthless if your FTP access is an easy nut to crack. Once someone has access to your server, it doesn’t matter how well you try to bolt things down on the website itself. One good way to lock down your server, is to limit FTP access to your office IP, provided that your internet provider assigns you a stable IP address.
The thread running through all five
None of these mistakes are exotic, and none of the fixes require a large budget. What they require is for the work to be owned by someone – a person with a checklist and a calendar – rather than left as everyone’s afterthought until the site breaks.
That owner can sit inside your business or it can be an agency on a maintenance contract; the model matters less than the fact that the responsibility lives somewhere. Maintenance is a process, not an event; the businesses that treat it that way tend to be the ones we never meet as a rescue project, which is how it should be.
If you’re worried about your website’s security, feel free to contact us for an audit.
