The beetroot stain protocol: An approach to website troubleshooting

On the back of a recent feast of roast beetroot, I thought I’d shoot this short article to you with some rules of thumb I use for my approach to website troubleshooting.

While it is true we typically only discover problems with our WordPress websites or other systems when disease or injury strike, sometimes we can waste time and energy responding to false alarms.

I call my approach to avoiding false alarms the beetroot protocol because the first time I discovered the joys of freshly roasted beetroot, I was shocked to see the red, blood-like colour of certain bodily excretions. I instantly dreaded the worst and my health professional was amused when explaining to me how persistent the red dye in beetroot can be. Phew!

And that’s what today is about: showing you how I quickly apply the beetroot protocol when checking a WordPress problem to avoid unnecessary and time-consuming investigations.

The “is it really a problem” approach to website troubleshooting

Since I began working with HTML and websites in 1996, I have learned how ephemeral the internet is and how it is given to all sorts of glitches due to it being a series of connections between computers.

This means there is always scope for interruptions to occur that happen on an ad hoc basis and disappear.

So my first approach to website troubleshooting is to try to replicate the issue.

For example, one of my colleagues sent me a screenshot a person took of an error message they received when trying to sign up for our newsletters using the Mailchimp widget on the right-hand side of this page.

It said there was a timeout with no data sent, in bold, red writing. Ironically, the same colour as beetroot dye!

Here’s what I did (and it’s what you could do, too, if you wanted to double check issues before paying for us to investigate for you).

Replicate, test, report

Before investing time digging through settings and error logs, I wanted to replicate the experience our user had.

To this end, I went to a new browser window (one where I was not logged in as a user of our website) and tried filling in the form. It worked perfectly.

This told me the connection between our WordPress website and Mailchimp was sound.

So, I had failed to replicate the issue and, better still, was able to register a new user without issue as I tested the system.

This left me with the final step of reporting this back to the user so they could try again to confirm the status of the problem.

Had you been able to follow this simple series of steps BEFORE calling for help, you would then either have:

  • Avoided spending money or support that you didn’t need to because there was no permanent problem
  • Got confirmation back from your client that the problem was persisting, enabling you to then call in the big guns so we could help crack the code, knowing your money was being spent wisely

Prevention is better than a cure, understanding is better than unnecessary treatment

What I would like you to take away from this article is the mindset that website problems do need to be responded to quickly but a little burst of replication, or attempted replication, can be prudent.

Obviously, getting your website made well in the first place and putting an on-going maintenance plan into place (like our WordPress Maintenance Plans) greatly diminish the need for you to read today’s article, but be that as it may, feeling empowered to get your hands a little dirty can save your time and resources for use in proactive marketing activity, rather than chasing phantom faults.

So as you get to know the quirks of the various web tools being used on your website (just like my familiarity with the quirks of various vegetables in my diet), you will be able to quickly diagnose reports of website problems and know when you can rest and relax and when you need to call the webmaster ambulance.


Image: Beetroot red I by Till Westermayer via Flickr. CC BY-SA 2.0