Do you offer any staging sites or environments?

Short answer: You can make use of third party staging apps for WordPress such as WP StageCoach or WP Staging, or more modern Git-based approaches such as WP Pusher or VersionPress. We also offer optional dedicated staging servers on our Superior and Enterprise Plans, which is done by setting up a new (2nd) cloud VPS server that is only for staging purposes, using a subdomain of your production domain. For example, if your company is example.com, then we setup a new server called staging.example.com. Why don’t we include this feature for all plans? The reason is simple: after several years, we found that 90% of our clients do not use or need staging sites, and/or tend to use them improperly when we did offer them in the past (leading to leftover files, database errors, unsafe environments, etc)… in other words, we discourage using staging sites. Plus, since we put every single client on their own dedicated VPS server (no other web host does this) in an effort to achieve market-leading performance and technical SEO, we have to mind our operating costs and avoid unnecessary “bloat” wherever possible. Advanced teams with higher traffic websites make more sense to be using dedicated staging servers.

Future blog post: Why Staging Sites Are Nearly Always Problematic

Longer answer: These days, the term “staging site” tends to mean many different things to many different people. Originally, like many “best practices” in web development, the concept really started with enterprise-grade applications and large agencies or in-house teams. In other words, large companies that have several concerns to keep in mind like legal compliance, in-house workflow, or stability of their high traffic application started to make use of a three-part “workflow” that included the following:

• Dev sites (local design and experimentation)
• Staging sites (ensuring the new design works correctly in the production environment)
• Production sites (the live server for the actual website)

However, in many cases that we are asked about staging sites, it is because one of our clients has a new web designer who is too cheap, or too lazy, to maintain their own “dev” environment. Yes, that is correct! Any professional web designer should be developing their new designs on THEIR OWN local dev environment, not abusing a so-called “staging” site because they don’t want to setup their own dev server.

What ends up happening all too often is that we see a client with e.g. a busy WooCommerce site that hires a new web designer, who then sets up WP Staging or otherwise, and continues working on the “staging” site for several weeks or months. At that point, the data in both sites is wildly out of sync (new orders, comments, etc) and merging the 2 sites becomes virtually impossible, leading to serious errors and panicked Support requests. Real staging sites are meant to briefly test new features and then “push” those features to the live site (files only, not database) after successful testing… they are NOT meant for long-term web design work, ever.

Admittedly, the “right way” to do web development could be an entire course (or several blog posts). But for the purpose of this FAQ article, we mean that your web designer should always have THEIR OWN web servers to design your website on (that is what you are paying them for, after all, and the liability for the design work is theirs, not ours); these are not “staging” sites in such a case, but rather just an online “dev” server in fact. And when the design is complete, the database should never be copied to the live site, only the FILES should be copied to the live site to avoid data loss. In fact, as part of any interview, you should be asking your web designer if they will be providing their own web design server(s) for your project, and ask if they understand how to copy files, and not the database, to your live website when the design is complete. Then, ask them if they understand that “staging” apps should only be used for brief testing immediately before making new features “live” on your production site. The only time that it is “okay” to overwrite the database on a live production server is if your website is entirely static, meaning that absolutely no dynamic data (e.g. comments, orders, etc) is being added to your database.

P.S. Another more recent trend for high tech teams is to use a single Git repo (such as GitHub) for each domain’s development work. For example, for example.com you could launch a new repo (public or private) and then create a “branch” for each “stage” in your dev workflow, such as A) dev B) staging C) production. From there you can use LittleBizzy server as your production server, and sync back and forth with your repo and/or staging server as appropriate. Do be aware that WordPress Core files are always managed by our system, and most of the time your plugins shouldn’t be included in your repo either (because they don’t get customized by your team). Instead, it has become a typical workflow to only keep your custom WordPress theme in the repo, along with any custom functions your site uses in functions.php (in your theme directory).