I was in the middle of writing a comprehensive SiteGround review when I found myself trying out their staging sites for the first time. I’ve had a great experience with their platform so far, but this is one area in which their managed WordPress hosting failed to live up to my expectations.
Keep in mind, I’m a web developer who manages multiple sites. The following frustration and critique of SiteGround’s staging sites is from a web developer’s perspective.
If you don’t need staging sites, or would never be logging into your hosting control panel anyway, SiteGround provides excellent performance & support for small WordPress sites on a budget.
But if you manage WordPress sites, and have the need for WordPress staging, let this post be a warning. SiteGround’s staging feature is not nearly as easy to use as staging on other WordPress hosts.
The Use of Sub-Domains
The problem with SiteGround staging starts with their use of sub-domains. They take your site’s domain and create a sub-domain of stagingX.escapecreative.com. (The X represents an incremental number.) This is where your staging site lives.
Now, this is easy to type into your address bar, and it certainly looks a lot nicer than escapecreative.staging.wpengine.com (which WP Engine uses for their staging sites), but it comes with a huge caveat.
You have to update your DNS records in order to access your staging site.
With that alone, I struggle to see the “managed” part of their managed WordPress hosting. Not to mention, SiteGround markets this feature as “one-click staging.” You don’t want to know how many clicks it took to get to the center of my WordPress staging site!
So, that’s problem #1.
I went ahead & created an A record for staging1.escapecreative.com, just as SiteGround’s documentation stated.
On to problem #2…
Invalid SSL Certificate
Through their integration with Let’s Encrypt, SiteGround generates a free SSL upon the creation of a staging site. In theory, this is great. In order to create a true staging environment, if your live site uses an SSL, your staging site should as well.
The problem lies in the fact that my live site redirects non-www traffic to www.escapecreative.com. SiteGround confirmed that if your live site uses www, your staging site will, too.
This means my staging site is actually located at www.staging1.escapecreative.com. However, the SSL was automatically generated for staging1.escapecreative.com (without the www).
These are two different domains. The version with the preceding www does not have an SSL certificate associated with it, but SiteGround’s server is still redirecting to it.
Google Chrome, one of the leaders in the push for a more secure web (https everywhere), makes it clear that no SSL certificate exists for the www-version of my staging site.
Now, this is only a staging site, so I could just click “proceed,” knowing that my site isn’t actually secure. I would have little concern for my own security (although I am still submitting a username & password to make changes in the WordPress Admin area). So sure, that is an option. But should it be this complicated?
Speaking of DNS propagation… problem #3.
Waiting for Propagation
Simply put, I shouldn’t have to wait for DNS propagation just to access my staging site. It’s 2017, and there’s definitely a better way.
There are countless sites that allow you to instantly spin up a sandbox site for testing WordPress themes, plugins & all manner of different online tools. There’s no reason why SiteGround can’t find a faster, more efficient way to setup a staging site.
While we’re on the topic of DNS…
Requiring someone to add a new A record to their DNS server is not “one-click.” In fact, for the beginning web designer, or the non-technical business owner, it’s outright dangerous. DNS records can take down entire websites, or an entire company’s email offline.
When DNS is managed elsewhere, SiteGround can’t offer much assistance. And with that being the recommended way to manage DNS+hosting, it leaves a lot of folks on their own to try and figure out how to create an A record when they have no clue what DNS even means.
Staging No Longer Needed
Another downside in all of this—when the staging site is no longer needed, I have to go back into my DNS and delete the A record(s).
Check that… I don’t have to, but I don’t love the idea of erroneous DNS records floating around. And I don’t see the point in leaving a staging sub-domain active if no one is using it.
At the end of the day, I got my staging site setup. It required a little extra effort on my part, and a 20-minute chat with SiteGround support, but it wasn’t a huge deal. It’s still not protected by an SSL certificate, but that’s also not the end of the world.
What I learned… and you should be aware of
If quick’n’easy staging sites are on your must-have list, you might want to look elsewhere.
You might have some clients who don’t give you access to their DNS. Imagine having to reach out to your client and ask them to create a temporary A record so you can make some updates to your site. Don’t they pay you so that they don’t have to be bothered with that kind of stuff?
Or if you have to create staging sites for a handful of clients, on a day where you’re applying a WordPress core update. If you don’t already have the DNS management logins for all those clients, you have to chase down those account credentials.
I realize these scenarios might not apply to all SiteGround customers. I’m not really sure how many others will agree with my frustrations. Are they warranted? Have you felt the same way when creating a SiteGround staging site? I’d love to hear your take in the comments.
And SiteGround, if you’re listening, I’d love to hear if you have any plans to improve your staging feature. In terms of value, you guys offer the best performance & support that 4 dollars/mo. can buy. There’s a lot to like about your product.
But several other WordPress hosts, especially those with custom control panels, clearly outperform your WordPress staging experience.