The big wordpress maintenance experiment: 2 MONTH REVIEW

A little over 2 months ago I set up a test website with no intention of maintaining it. I posed the question, “Will it get hacked? Will it end up selling dodgy pharmaceuticals or will it just soldier on forever?”. Now, 2 months on, I’ve got some data and insights for you. I Expected the experiment to fall in favour of maintenance, but I wasn’t entirely prepared for the results that I would get so early on.

To make the results of the experiment useful to you, the test site has been built to be a close approximation of the ‘average’ business website with commonly used plugins and construction methods as suggested when I polled a forum of over 2000 web professionals.

If you haven’t read or listened to the original blog post explaining the experiment you can find it here.

Jump to content

1. Some context
   
   • Why does it matter?
   • Will this skew the results?
   • How long has the experiment been running?
     
2. What insights have been provided by the experiment to this point?
   
   • WordPress Core
   • Themes
   • Plugins
   • Attacks
   • Critical errors
     
3. Lessons learned so far
   
4. Conclusions
   
5. Get ongoing updates and the final report when the experiment concludes

Some Context

Before we dive into the results of the first two months of this experiment it is worth us considering the context of the experiment which will in no doubt have some impact on the results.

Once I got this experiment running it hit me. Although this website is typical in as many ways as is reasonable, it is completely atypical in the sense that:

• the site is not actively marketed
• no SEO has been conducted
• there is no existing user or client base
• no active work has been conducted to get this site indexed by search engines

Why does this matter?

Well, although the site has many features and functions of a typical business website, it does not enjoy the marketing, exposure and therefore the traffic that you would expect of a ‘real’ website. 

Although this has nothing to do with how quickly software/plugins may require patching or how many vulnerabilities are introduced by neglecting maintenance requirements, the exposure to real threats from hacking and server loading is reduced by many times.

Will this skew the results?

Yes, but for the most part, no. I can still report back to you about how many core, plugin and theme updates get missed etc. I can provide lots of useful data about the software and the effects of a zero maintenance approach but the threat of hacking is much reduced.

In a real-world application of a no-maintenance approach, you may well find that the number of login attempts and blocked logins would be much higher, as would the number of attempted hacks by humans. The flip side of this is that it will be really illuminating to see how many attempts are made to gain access to this website considering that it isn’t on the radar. The assumption being that if the site isn’t being marketed, has no real search engine presence and isn’t used by an existing user base, any attacks are likely to be automated and from bots.

How long has the experiment been running?

The test website has been live now for 9 weeks and has already given some useful data that will help you work out how frequently you should keep your own website maintained.

Let’s cut to the chase: What insights have been provided by the experiment to this point?

Although the final report will be the most valuable in terms of data and analysis ( I encourage you to sign up to receive it ), I can draw your attention to some interesting findings which have occurred in the first 2 months. The insights are best split into areas:

WordPress Core

Within the first week of the experiment, there was 1 missed update to WordPress core. By week 5 of the experiment, there were 2 missed updates to WordPress core and that situation persisted until the writing of this document in week 9.

Themes

The website uses 1 theme which is live, and then has the three other standard bundled themes, namely 2020, 2021 and 2022.

Normally I would only retain the live theme and any parent theme it may rely upon and one alternative theme (normally one of the bundled WordPress themes) to use as an alternative during troubleshooting and as a fallback. However, I so commonly find these themes the first time I log into a client website that I have left them in place in this instance.

• By the end of week 1, three of the four themes on the site had one or more updates outstanding. This persisted until week 5 when the number rose to all four themes having missed updates.
• By end of week 8, all four themes were missing a total of 5 updates between them.

Plugins

This is where it starts to get interesting. One of the big areas of threat to a WordPress website is errors or vulnerabilities that are introduced in the software that extends the functionality of the website or changes its appearance in some way.

Due to the nature of how they work, it is common for a website to leverage multiple plugins to extend its functionality. It may be a contentious point, but you could argue that the less skilled the person that built the website, the larger the number of plugins that may be used.

For this test website, we use a total of 16 plugins to provide features such as spam comment protection, maintenance tools etc. It is worth mentioning, however, that it isn’t uncommon for me to find upwards of 20-30 plugins when I first log into a client site. I do (worryingly) on occasion see websites with 30-40 plugins with these most often being websites built in-house or by someone whose primary role is not in web design and development.

Why is the number of plugins important? Well, if you consider that every plugin is a potential vulnerability, the more plugins you have, the higher your potential risk. This isn’t a strictly linear relationship though as the level of experience of the person building the website will influence whether the plugins being used are vetted and reputable or whether they are added without consideration of risk.

With that bit of explanation out of the way, let’s look at some stats.

• In the first week, 37.5% of the plugins on the site had missed one or more updates. This is important because updates often include feature fixes, security fixes and changes to ensure compatibility with the latest version of WordPress.
• At week 4, 56.25% of all the plugins on the website had missed one or more updates.
• At week 8, 75% of the plugins on the website had missed one or more updates.

Attacks

As already discussed. The website has low visibility and isn’t marketed, having a much-reduced volume of traffic will reduce the chances of the site being attacked by humans. However, it is of interest that the site still seems to be attracting a number of likely non-human interactions such as trying to log in using common user names like ‘admin’.

Some login attempts happened with sufficient frequency to trigger a lockout.

• Notable stats include week 2 having 56 blocked login attempts and 14 lockouts.
• By end of week 4, the site had experienced 109 blocked login attempts and 27 lockouts.
• By end of week 8, this had risen to 261 blocked login attempts and 35 lockouts.

Login attempts seemed inconsistent with numbers fluctuating each week which may have more to do with the global rise and fall in attacks. It would be interesting to look for a correlation there but falls outside the purpose of this update.

In week 3 the plugin that blocks logins caused a critical failure. It is not clear if this is coincidental or if it was targeted. However, that failure resulted in no stats being recorded for week 3 for blocked logins or lockouts and causes an artificial dip in the statistics.

Critical Errors

At the date of writing, the site has suffered one critical failure which temporarily prevented the website from loading for visitors. The failure occurred in week 3 and was caused by a login security plugin. It does not appear that the site has been hacked or altered as a consequence. I am unable to easily ascertain if the failure was due to an attack or whether something went wrong because an update wasn’t applied.

Lessons learned so far

Industry professionals worth their salt will always recommend ongoing maintenance for websites which run on content management systems, with the added emphasis on the importance to any site that handles data and/or transactions. 

Despite routinely giving that advice most of us only have our experience to rely on as evidence. We know how many people contact us to recover, repair or rebuild a website that has been hacked, stopped functioning or been defaced in some way. We know that in almost all instances this occurs to websites that do not benefit from routine maintenance. This experiment is starting to provide some data to be able to cite and lend weight to this argument which I am hoping will help you or your clients avoid site failures.

What did surprise me is the sheer speed with which updates started to pile up:

• In week 1 we had a missed update to WordPress core, 37.5% of plugins with missed updates, 75% of themes on the site with missed updates and the site had already started seeing malicious login attempts.
• By the 1 month mark over half of all the software had missed one or more updates and the site was routinely experiencing malicious login attempts. 
• By the end of the second month over 75% of the software that runs the website had missed one or more updates and 229 malicious logins were blocked. 

Conclusions

I feel that the data gained from this experiment so far supports the assertion that I make to clients that site maintenance should be conducted every month at a minimum, potentially more frequently for higher-risk sites or those that hold sensitive data or are responsible for large amounts of generated sales or leads. Although we see that from week 1, software was requiring updates we can see that there is a tipping point from week 4 where the number of outstanding updates becomes unreasonable and in my opinion raises risk to an unacceptable level.

If you are considering your own website maintenance you are of course going to want to risk score your maintenance strategy and consider opportunity cost should something go wrong. Consider potential lost sales, lost leads and the potential for damage to your brand. In my experience, I find that those advocating infrequent maintenance either don’t fully understand why maintenance is carried out or are trying to save money. Ironically the quest to save money increases the chance of having to pay for disaster recovery, repair or rebuilding of a website. It is easy to demonstrate that the costs of repair outstrip the cost of maintenance by a significant amount, making this a self-defeating exercise.

Regardless of the final outcome of this experiment, it is clear to most that ongoing website maintenance is important. Not just from a preventative and disaster recovery perspective but so that a website owner can protect their users and demonstrate their commitment to data security should the ICO ever come knocking. 

If you have any questions about this experiment please feel free to get in touch via the contact page and if you would like to be notified of future updates and receive the final experiment report when it is produced, please sign up using the below form.

Thanks again for your time. Should you feel that your website would benefit from a health check and/or ongoing maintenance please give me a call on 01903 527927 and I will do my best to help.