The Problem with SiteGround’s Staging Sites

SiteGround Staging Sites

Disclosure: This page contains affiliate links. If you purchase a product using one of our links, we might receive a commission. Rest assured, we only recommend products we truly believe in. Learn More

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.

In fact, their intro level plan doesn’t even offer staging, and is available at 60% OFF, for just $3.95/mo.

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.

I’m using one of my sites,, as the example throughout this post.

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 (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 (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!

SiteGround's one-click WordPress staging

If you manage your domain/DNS with SiteGround, your DNS will be updated automatically. However, most people (myself included) agree that you should never manage your DNS & hosting with the same company, for numerous reasons.

So, that’s problem #1.

I went ahead & created an A record for, 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.

It’s not clear whether a certificate is always generated for staging sites, or only when the live site is using https. We should all be serving our sites over https now anyway, so I’m going to assume you’re in the https boat.

The problem lies in the fact that my live site redirects non-www traffic to SiteGround confirmed that if your live site uses www, your staging site will, too.

This means my staging site is actually located at However, the SSL was automatically generated for (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.

Browser Warnings

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.

Google Chrome certificate not valid warning
Google Chrome’s “Your connection is not private” warning

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?

Firefox & Safari browsers originally showed internal server errors, but after some time (and DNS propagation), they provide the same warnings as Google Chrome.

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…

DNS Changes

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.

I should also mention that I had to create two DNS entries. One for staging1, and another for www.staging1.

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.

Wrapping Up

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.

10 Commentson "The Problem with SiteGround’s Staging Sites"

  1. /

    Hi Dave, I stumbled across your article when looking for advice on updating the WP core whilst a staging environment is in place.

    I’ve only tinkered with the SG staging environment a few times but I’m yet to experience the concerns you have above? I have one live at present and am able to make access the staging platform and make changes without touching DNS in any way.

    I would take the same attitude to SSL as you and just wing it, but in looking at the Let’s Encrypt section of cPanel I can see that an SSL certificate has been issued automatically, hence I don’t get any warnings from my browser.

    I’m very much the target market for your article: intermediate knowledge of WP and hosting = just enough to be dangerous, haha!

    Looking forward to hearing your thoughts…

    → Reply
    1. (Author) /

      Hey Greig — I really appreciate you chiming in here, and offering up your own example. Would you be willing to provide the domain you are referring to, as well as the staging sub-domain that you’re using?

      I’d like to test the staging site out on my end (to test the SSL), as well as look at the public DNS records. I will then try to provide my thoughts on your situation, and how/why it might be different from my experience.

      If you’d rather keep this info between me & you, you can email me instead: [email protected].

  2. /

    I’ve not had any of these problems either, but that’s because I use Sitegrounds name servers. I assume you host your email elsewhere in which case that’s fine. But in that case you have to update your a records. If you use name servers then you do not have to do that. Or wait for propogation.

    I think the Let’s Encrypt thing is fixed now because I don’t have that issue either.

    I don’t know what the better solution is that you talk of. Can you tell us?

    → Reply
    1. (Author) /

      Hi Eoin,

      What’s your website’s address? Are you using www or no www?

      You are 100% correct that if you use SiteGround’s DNS, you won’t need to create any A records, or wait for propagation.

      However, as I mentioned in the article, I don’t think anyone should manage both DNS and hosting with the same provider (read some of these). Essentially, if their service gets hacked or platform goes down, EVERYTHING goes down (your website, email, everything). But if your hosting company has an outage, and you manage your DNS elsewhere, you can update your DNS to point to another hosting service (and email service), and prevent additional downtime for your website, and still use your email.

      The Let’s Encrypt issue was present because my main site redirects to the www version. If yours does not use www, then you will not experience any issue with the SSL.

      As for the better solution… there really isn’t any other way to set things up using SiteGround staging. If you manage many sites for your clients, and staging is an integral part of your development workflow, you might find yourself changing a ton of DNS records.

      The only solution at that point would be to choose a different host–one that makes staging sites easier to deal with (Kinsta or Flywheel are my recommendations there).

  3. /

    Thanks for your article – have had some of the same issues regarding the dns.

    My question is in regards to pushing changes from staging to live – I have been working on a staging site for awhile and there have been fairly substantial changes to custom post types, field groups etc. I’m wondering if anybody has experienced any issues when pushing changes live? Are there things to watch out for as far as structural site changes? Thanks for any input

    → Reply
    1. (Author) /

      Hi Richard — Unfortunately, I don’t have any first-hand insight. I only tried out the staging-to-live push one time, and it was one simple text change to a test site. Like you, I would also be nervous to push a large amount of changes.

      The advice I can give you is this:

      • Make a reliable backup right before pushing your changes. I recommend using UpdraftPlus, BackupBuddy or VaultPress, as they all have reliable restore options if something goes wrong.
      • If you allow for user-generated content (blog comments, forum posts, etc.), put a maintenance page up before you push your changes, that way no new content can be added that might get lost when you push. I recommend SeedProd’s Coming Soon plugin.
      • Push the changes during your lowest traffic day/time. Hopefully you have some analytics installed so you can check that.

      If you decide to go for it, best of luck, and I’d love it if you would come back and share a brief description of how it went for you. That could help others have confidence in SiteGround’s staging platform when they go to push a lot of changes.

  4. /

    Thanks for the well-written article, Dave! It was a good read. I just tried setting up my first staging site at Siteground before coming here, and had some of the issues you’ve raised. However, after reading your article and launching Support chat, the staging site was up and running perfectly. hehe :) They should probably give a heads up to grab a cup of coffee while the magic happens.

    Perhaps other WP-hosts have a better solution for this, but having never done anything like this before, it was very intuitive and fast. The 10min wait is totally negligible, compared to having to pay eight times (ish) more for hosting at at WP Engine.


    → Reply
    1. (Author) /

      Thanks for taking the time to comment, Kay. I appreciate it.

      I completely agree with you. My intent with this article was not to discourage people from using SiteGround. I was a WP Engine user for 4 years, and am now currently using SiteGround. My thoughts are the same as yours. An extra 10 minutes to chat with support is totally worth the reduced service cost. And SiteGround’s chat support is fantastic.

      Glad you got it all figured out. Happy staging!

  5. /

    SG staging system is super buggy. We have had to completely give up on pushing changes from staging to production, there will be bugs! For example Some of the URLs on production get changed to the staging subdomain! I guess the search and replace worked when creating a staging but not when pushing to production, the URLS were in the footer and widgets (search and replace is sometimes weird in widgets).

    The most you can do is use the staging to test changes and collaborate, then manually move those changes over to production, very sub optimal.

    After using many staging sites for a decent amount of dev work its clear the staging sites are kept in a staging environment with some different configurations to production sites, this defeats the purpose of staging as the environment should be the same as production.

    In the 2 years I have been with SG they have made various improvements to their products and systems but not to their staging feature, it has stayed the same and badly needs an overhaul.

    → Reply
    1. (Author) /

      I really appreciate you sharing your experience. I’ve been afraid to push to live, and have also manually moved my changes over. Thankfully, I haven’t made any huge changes yet, so it’s just been a few files here and there, which is manageable.

      Staging is the one area where I think SiteGround badly misses the mark, especially in terms of “WordPress hosting.” Their performance and support is as good, if not better, than most other shared hosts, but the staging could definitely use some improvement.

What Are Your Thoughts?

All fields are required. Your email will not be published.

You can use standard <code> and <pre> tags to post code examples, or a service like