WordPress Rocks. Let me say that right off the top of this article. The fact that ¾ of the CMS-driven sites on Earth run WordPress backs that up. But like any great product, sometimes things can and do go wrong — like a site crash.

Whether it’s due to neglect or because something new (bad updates) or someone (hackers, malware) affects our site, the reality is, the longer your site operates, the higher the odds you will experience some sort of disruption to your site. Being proactive about an eventual problem with your site is prudent, saves you money, and might even save your business (or your job).

Avoiding temptation of ‘autopilot’ thinking, and using good site management discipline. Two ways to head off many WordPress Site Crashes

Let’s face it: site maintenance is not everyone’s bag. So the option to have plugins and themes update automatically is really tempting. Set it. Forget it, right? Wrong. Plugins come from a variety of sources, and sometimes an update can cause conflicts and crashes. You won’t know about the problem until you visit the site, try to use a function, or try to log into the WP (WordPress) dashboard and can’t. All leave a really sick feeling in your stomach, like walking out to see your car has a flat tire, or won’t start, or is just gone-stolen. Ugh!

So if automatic updates to plugins are not a good idea, NOT updating plugins is worse. Outdated plugins leave your site more open to hacking, cause conflicts with other plugins that you might add or update, or can be incompatible if you upgrade your WordPress to current versions to gain improved security and added features.

I don’t disagree with the opinion that a WordPress site that’s working well doesn’t need updating (not broke, don’t fix it). BUT, drilling down into details, I would add the caveat that while a site THEME doesn’t need updating to meet security threats that pop up, Plug-ins and the WP framework software should be kept up-to-date and monitored by a human who is taking a methodical approach to updating.

Adjust mindset. Adjust budget, too.

The task of maintenance is not something a lot of developers really want to try to focus their business on. Creating new things are more exciting. Also, many clients don’t want to pay for the stop and start time needed for making these updates as they come in, and paying per hour to have maintenance done.

Updates and improvements and upgrades follow no schedule, and days could go by with nothing, then a smattering of little touches will be needed. The only part of prevention that can be scheduled is backing up your site (more about that below).

Unfortunately for many smaller site owners, they don’t have someone in-house who will follow a methodical, efficient approach, done with human oversight and background in WP issues to avoid as many issues as possible, and quickly recover from them when the issues do come up. Some providers offer maintenance plans suited to smaller sites. Specialized firms offer services on a retainer basis for maintaining larger sites. The bottom line is that no matter who does the work, site maintenance is cheaper in the long run than having your site go down. Suck it up, and write a smaller check now instead of a larger one later.

What should you be doing BEFORE you have a WordPress Site Crash?

Establish a plan. Figure out what your strategy will be to deal with problems that threaten your site operation or compromise security of information. You can keep things simple using the “IF/FIRST/SECOND/THEN” format:

“IF I discover my site is hacked, FIRST I will/Second I will/THEN I will…”

“IF my site goes down after a plugin update, FIRST I will/Second I will/THEN I will…”

“IF a function of my site is no longer working, FIRST I will/Second I will/THEN I will…”

By this point, you get the picture. You need to think ahead about each scenario you could be facing with your site. What’s important is that you work using a preplanned disciplined process. I didn’t share specifics, because there are hundreds of scenarios and every site is different, and it’s why money is paid to set up a plan if you can’t or won’t do it yourself.

Backup Early, Backup Often. Backup Regularly. Memory space is cheap. And there are some great premium backup plugins for WP websites to help you restore your site files and site database if you have a WordPress Site Crash. But they don’t work their best unless you are being diligent about establishing a regular backup routine.

Whether you backup daily, weekly, monthly or longer, you should be storing the backups offsite to protect them. And make and download a backup before any major update or multiple plugin updates.

11 things to do: the WordPress site crash equivalent of having a spare tire and tools

Here are things I recommend that every WordPress site owner have ready or take steps to do, whether part of a large organization, or a small one-person operation. Just like tools to deal with a flat tire or breakdown, you want these things in place when things go wrong.

Before you write off all this as too much to do, use a little imagination. Whether your organization is large or small, you’ll find that all the items on this list of tips are scalable and can be assigned to yourself or others on your team:

1. A site manager with adequate WP knowledge should be in charge of 3 coordinated functions: Regular backups, Monitoring alerts and warnings, and implementing plug-in updates
2. Site backups and backup file transfers to an offline drive should be done and verified on a regular schedule. Weekly, Monthly at the least on a busy site.
3. All WordPress, WordFence and other security plugins should be directed to send alert emails to that site manager (and maybe a backup person)
4. When warnings and alerts are received, the site manager should allow 24 hours to pass before starting action. With the large number of WP sites in the world, and because you are already using WordFence, the odds of a hack happening to a site in the first 24 hours of a threat alert are extremely low. ONE EXCEPTION is if a warning is received that your site may already have malware. WordFence file scrubbing measures should start immediately.

5. When warnings and alerts for needed updates are received, and BEFORE any updates are done, the site manager should
   • Confirm what the change(s) are in the update by reading the WordFence alert and notice within the site dashboard,
   • Scan the plugin developer’s FAQ and change log pages and support/comments pages for any hints of problems with the new update
   • Search on the Web with the plugin name and version and ‘problems’ to see if any reports of issues are coming up for others
6. Before a session of one or more plugin updates are done, a backup should be manually run of the site and database
7. Updates to plugins should be done one by one manually (not automatically) and the dashboard and site checked for function related to the plugin is operating correctly, and to be able to identify early if a particular plugin update might be causing a conflict with another existing plugin
8. If an update does cause a plugin, the plugin should be restored to previous version or disabled and removed, and the issue reported to the developer. If needed, the plugin should then be replaced with a similar plugin that doesn’t cause the conflict.
9. Plugins and WordPress updates should be handled in separate steps
10. Before any WordPress update and after all plugins are updated, a backup of site and database should be made and downloaded. Then proceed with the WordPress update
11. Once WordPress is updated, a check of site functions should be made via visit to the site after log-off

Security deserves a complete article unto itself. There is not a one-size-fits all solution, so you need to find the tools that work with your site needs. But I’ll state that I’m an advocate of at least two levels of security. At the bare minimum, be sure you are using a product like WordFence, and not just running it in the background, but taking time to monitor and respond to messages it is sending to you.

Another layer of security comes from something a lot of people overlook—Hardened access. Create obscure usernames and passwords. Block directory browsing, and monitor and restrict file access, to block intruders early on and know where they’ve been if they do get in.

Don’t be scared, but be prepared

While a hack can happen any time of the day or night, realize when you are most vulnerable to a site crash. It is a triggered event.

Most crashes (the dreaded blank white screen instead of site or dashboard) happen right after an update. That is when your site troubleshooter can be called in to access files via FTP and extract the problem file (plug-in usually) and free up the site, before continuing on with a way of replacing or suspending use of the guilty plugin until the developers who authored it can create a new version. Depending on the quality of support, this could take just a few hours, to days, or even never. So always be ready to replace a plugin, and before you use plugins, carefully check who created them, and what the service history has been.

My RULE OF THUMB for approaching updates:

1. Update Plugins 24-48 hours from availability, but not before.
2. Update WordPress 3 days to 1 week, but not sooner than 24 hours.
3. Update THEMES only if there is a NEW feature you are sure you want to add, but no sooner than 3 weeks from when an update is published. Old themes run fine on newer WordPress, and with updated plugins. All you miss is any new WordPress Dashboard functionality. Nothing is lost for the visitor.

The bottom line to avoiding a WordPress Site Crash, or recovering from one is, set up a plan, work confidently following a process, and turn away from fear or denial. Like preparing for so many other unknowns in life, this works.

What do you have in place now to recover from a website crash? Please let me know in the comments below.

---

---

Save

Save