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.
Peter
Hi,
thank you for the post. I’m a really happy ManageWP-User. 🙂
At the moment i’m looking for a solution, to easily setup a staging version of my websites.
I understood, how easy it is to clone my website. But – how can i perform it the other way round? Lets guess, i made some changes on the cloned staging environment und i got a Go from my client. How can i merge the changes to my live website?
Thank you for a short hint. 🙂
Peter
Marko Tanaskovic
Hi Peter,
We’re currently planning to develop a solution that will do exactly what you’re asking. But until we have the ‘merge’ solution, copying/cloning from staging to Live is the way to go.
Peter
Really nice news! I’m looking forward to it.
Peter
Sorry, one more question: Any hints about when this new feature will be rolled out?
Marko Tanaskovic
Right now it’s in the planning stage so there is no ETA. Once we have a reliable estimate, we will add it to our roadmap (https://managewp.com/roadmap).
Tammy
I bought a Learndash plugin for an online school. As a novice, I followed all the instructions provided on Learndash and the WPclone plugin completely broke my site and Learndash seems to have taken over my URL. My original site seems to have been deleted.
Do you have any idea if there is a way to restore my site and delete this plugin? I do not have access to the admin page of my site due to the Learndash ambush. Please help me.
Nemanja Aleksic
Log into your website via FTP > go to https://s42013.pcdn.co/wp-content/ > rename the /plugins directory
This will deactivate all plugins on your website. You can then rename the folder back to its original name, and start fixing your website.
In the future always have a backup available – ManageWP offers a free monthly backup to the cloud, so it doesn’t cost you anything to have it for rainy days.
Tammy
Hello Nemanja,
Thanks for your prompt reply. I will update comments with the success of your instructions.
The site is managed by a friend who knows a little more and have assured me in the past that we have back up in place. I am praying ? that URL is not able to be transferred to Learndash with just activating this WPclone plugin. I am remaining hopeful that he can restore with your steps.
Tammy
Hello,
The steps helped to give me back access to my admin page but my credentials are not being recognized. Also after the plugins folder was deactivated my site went to the white screen of death. Any additional steps I can take to restore my site please?
Nemanja Aleksic
If you have the backup archive that you mentioned in the previous reply, use it to restore your website. Alternatively, you could ask your hosting company to restore it for you, since a lot of hosts do backups on their own. This is now troubleshooting territory, so if you don’t have experience troubleshooting WordPress, I recommend getting someone experienced to do it for you.
appmarsh
Well, I have another question by this topic – What should I do if someone else cloned my wordpress blog?
Nemanja Aleksic
Nothing really. If someone copied your content and style, they will be penalized by Google for duplicate content, and won’t show up in the Google search results.
Kasa
Great post, really like film references. I must admit, I too belong to lazy cowboy mode.
Nemanja Aleksic
We all do, from time to time 🙂
David McCarthy
To start with, we insist on hosting sites we build … at least for the first year (clients can move after that, but no one has).
We always build on-line to ensure what we build will work. It also allows us to give the client access to see how things are progressing, how it looks and how it works.
We have a reseller hosting account (but we don’t ‘sell’ space to anyone unless it’s to run a site we’ve built) using WHM/cPanel. cPanel has a nice ‘Protect Directory’ feature, so we can give the client access but no one else (including any bots) can see the site.
Redeveloping when a site is live and has changing data is tricky, and we don’t have a perfect solution for that.
Nemanja Aleksic
An excellent point! Having your own host is a great way to avoid 95% of the problems you’d encounter when cloning a website.
The next best thing is to recommend 2-3 hosting options to your client, so you’d be familiar with the server setup and know what to expect when the website goes live.
JPUSER
Orion’s cloning is nicely working so far. I have live and staging sites connected to Orion, but one huge problem is, when I update plugins/themes on staging sites and clone it to live site, update logs are only available for staging site and not live site and client reports on live site can’t include updated plugins/themes which were done on staging site.
Nemanja Aleksic
This is a legitimate problem, since you’ve practically updated the plugin on the live site, even though you haven’t actually clicked the update button.
For now I’d recommend adding a note to the report explaining this, or maybe including the staging website in the report.
In the long run, what would be an ideal solution for you? Track the difference between plugin versions? Or maybe introduce the option of adding both the staging and live log as one in the report?
JPUSER
Umm…perhaps a simple check box to include plugin/theme and other updates history from staging site (another site connected) would just be fine.
Thomas
Our main concern isn’t about the cloning process itself which can be done safely with the techniques mentioned, but with data synchronization between the production and staging sites when it’s time to launch. For example, if a client continues to update a production site with new content while you’re building out new features on a staging site. Then, when it’s time to launch, you have consider how to merge the two databases together.
We’ve come up with a number of less-than-ideal solutions to this, I’d be interested to hear what other people are doing.
JPUSER
If ManageWp Orion will allow to choose which file (plugin/theme/database) to be cloned to live site from staging, it would be great. For now, I love Orion’s S3 uploads and auto backups, but for selective file sync, I use BackupBuddy’s deployment feature.
tex77
@Thomas — I struggle with exactly this issue — merging of Dev and Prod. If only a handful of simple content changes were made by the client on Production (since it was cloned to Dev), I’ll redo those changes on Dev, and push the entire site to Prod. And, I’ll install an event-tracking plugin (like Stream, WP Security Audit Log, etc) on Production, to help find those changes. But this doesn’t work with active sites — that take user comments, orders, or received any form entries. Tricky stuff. In that case (which unfortunately is usually the case) I’ll need to re-implement all my changes from Dev, onto Prod. And fairly quickly. That’s a lot of stuff to meticulously track. Theme files are easy. But WP-Admin is tough — core settings, plugin settings, new plugins added, new CPTs, reconfigured Pages, etc. How about you- what strategies do you use? Have you learned anything new since your post here?
sağlık olsun
So, thanks 🙂
Donna Cavalier
I have an irrational fear of cloning a site for all the reasons you mention. I’m even hesitant to use the Orion clone, even though I believe it to be a good choice. I just now noticed this tooltip you use when giving the choice to clone to a new site or an existing one. ===The easiest way to use the clone tool is to clone over an existing site that is already added to your ManageWP Dashboard. This can be for example your staging site or a clean WordPress installation.=== I hadn’t noticed that tip before, and now that I have, the two choices make more sense to me. I was always confused about the wording of using an existing site. But now I get it, and putting a clean wp install into the ManageWP Dashboard and then cloning to that … I would probably not be nearly as paranoid. Explanations are good things. 🙂 So, thanks! Both for the tool itself, and the tooltip. 🙂
Nemanja Aleksic
The tooltip is a relatively recent addition. We’re stepping up our game with explanations and onboarding since there’s a lot of useful bits and pieces on the ManageWP dashboard that could use an explanation.
We’ll also publish more articles that will explain how ManageWP could make your life easier, so stay tuned 🙂