It Is Hard to Believe How Poor SiteGround’s Support Documentation Is

From our experience people trust their web host to provide good advice on dealing with problems with their websites, but also from our experience, unfortunately, the advice is often useless and sometimes even harmful. Since most of that is coming from one-off exchanges with support personnel, it is hard to attribute that to a general issue with the web host. But with a recent instance involving SiteGround, the public advice they provide in their support documentation is so bad it is hard to understand how it exists in that form.

With a website we have been brought in to do some work, a problem needing to be dealt with was at least part caused by an ill-conceived action taken by the SiteGround, but in trying to resolve that our customer had tried to resolve another issue, a mixed content error. Mixed content refers to having content on a page being served over HTTP when the page itself is served over HTTPS. SiteGround provides instructions on dealing with that, on a page titled What Is Mixed Website Content Error and How to Fix It?. Under the heading “How to fix the mixed content error” they write this:

The fastest way to solve this issue is by using the functionality ‘Force HTTPS’ in the SG Optimizer plugin. It will redirect all the traffic for your website to HTTPS which should help avoid mixed content, except in some cases of remote resources still being pulled over HTTP.

Then the first step to do that is:

  1. Install the plugin by logging into the WordPress Admin > Plugins > Add New.

You can only log in to the WordPress Admin if your website is using the WordPress software, so these instructions are only relevant for WordPress websites, but that isn’t clearly noted. The first mention of WordPress is in step 1. After getting through all the instructions, they write this:

If you are not using WordPress or even after using SG Optimizer there is still mixed content on the website pages, then you can use this online tool to find which content is being served via HTTP. You would have to attempt to correct all of them to load over HTTPS manually, based on the specific elements.

Wouldn’t you want to note that the instructions are not relevant to websites not using WordPress before providing them, and not after?

It isn’t like that is something that you can only come across from their website with notice that it applies to WordPress. At the bottom of that page a related article, How to enable padlock on my site?, is listed. The totality of the information provided on that is, with a link to this page at the end:

  • Your SSL certificate is installed and valid.
  • The website is working over HTTPS.
  • There are no elements loaded over an HTTP connection (mixed content).


Leave a Reply

Your email address will not be published.