Having a staging version of your website is WordPress maintenance 101. You can tweak your staging website, perform updates and test new plugins, and not have to worry about crashing your live website. So why doesn’t everyone use staging websites? Mostly because we’re lazy and love to cowboy code, but sometimes it’s because we think that the danger offsets the benefit. We’ll talk about some of these dangers and how to minimize them, so you could make changes to your website, stress-free.
Duplicate Content Penalty
This is the most common concern for people who are getting started with web development. Search engines crawl all the publicly listed domains and index the content. Creating a duplicate of your website will cause one of them to be penalized for having duplicate content. This means that, as far as Google is concerned, your website does not exist.
This could be a big problem when you make publicly visible changes on the staging website. Once you make the same change on the live site, it will be penalized. I learned this the hard way when I was a kid, when my first HTML website did not show up on Google search for weeks because I did final tests on one of my domains that Google crawled.
Most people avoid this issue by developing websites locally, and there are plenty of tools like DesktopServer that make it easier to build a local website. But here’s the thing: Murphy’s Law guarantees that your website server configuration will differ from your localhost just enough for something to break. A 100% reliable staging environment needs to be on the same server as the live website.
So, you’ve got a staging and a live website, but you don’t want staging to be indexed. The simple solution is to turn on the Discourage search engines from indexing this site option on the staging website wp-admin dashboard (Settings > Reading > Search Engine Visibility). If your main concern is Google, this will be enough. The problem with this approach is that developers tend to forget to disable the Discourage option, so when you clone a website from staging to live, you also clone this setting. Your live website will no longer show up in the search results.
This is very bad.
…but still not as bad as Double Impact
A smarter and a more robust way would be to completely password protect your website with HTTP authentication. Preventing access is a more reliable way of stopping crawlers from deciding whether or not to honor your discourage request. It’s very easy to set up (they even have password generators now).
If you’re using ManageWP, just add the HTTP auth credentials in the Site Options and you’ll be able to manage and clone your website with ManageWP.
My Website Crashed
This is a legitimate concern for a lot of WordPress professionals. Let’s say you made a bunch of small changes on a staging website. The fastest way to apply the changes to the live website is to clone the staging website over it, but it’s also the riskiest move. Something goes wrong, and all of the sudden your live website is giving a 500 error and you’re in panic mode.
This is because 99% of the cloning solutions on the WordPress market are based on the same PHP cloning method: it’s simple, fast, takes a ton of site server resources and has considerable odds of failing. There are a number of reasons why the PHP clone scripts fail, but it comes down to one thing:
Website cloning as we know it is obsolete.
On one hand, websites keep growing, which means that website servers need to provide more and more resources to clone successfully. On the other, good hosting companies focus on performance and don’t take kindly to a script hogging all the site server resources.
On top of that, there’s a good chance that your favorite clone tool is wasting a huge percent of the resources it takes: let’s say you have a 500MB website, but you only tweaked a couple of files. So instead of cloning just these files, your clone tool goes full Rambo and overwrites everything, and possibly crashing your live website in the process because the hosting company terminated the script after 30 seconds.
-Adriaan! need more PHP memory!!
Some hosting companies like WP Engine have solved this problem by providing clone tools that work consistently on their web servers, but with a caveat: they work ONLY on their servers, and the benefit usually comes with a higher price tag (e.g. WP Engine charges $360/year for one WordPress website, although they do have a bunch of cool stuff to justify the cost).
This is why, when we started working on the ManageWP Orion Clone tool, we made sure to focus on reliability and optimization, regardless of the hosting configuration. We built a solution that’s able to clone to and from pretty much any website server, and more importantly, by implementing checks, we make sure that only the changed files are being cloned. So, if you take the earlier example, only those couple of files from the 500MB website will be cloned, which hugely increases the odds of successfully cloning your website.
Takeaways
- Having a staging version of your website is a huge benefit when testing changes and updates.
- Duplicate content is dangerous, but easily avoided by discouraging indexing or password protecting the entire staging website.
- Not all clone tools are the same. Choose a reliable clone tool, or choose a hosting company with a bundled cloning functionality.
Do you have other concerns about having a staging clone of your website? Do you use a different setup? Share your experience in the comment section.
Leave a Reply