Is It Dangerous to Clone a WordPress Website? - ManageWP

Is It Dangerous to Clone a WordPress Website?

clone a wordpress website

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.

jcvd double impact

…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.


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.

Nemanja Aleksic

Head of Growth at ManageWP. Marketing Manager at GoDaddy. WordCamp Belgrade organizer. But first and foremost, a father, a husband and a puck stopper.


  1. appmarsh

    Well, I have another question by this topic – What should I do if someone else cloned my wordpress blog?

    1. 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.

  2. Kasa

    Great post, really like film references. I must admit, I too belong to lazy cowboy mode.

    1. Nemanja Aleksic

      We all do, from time to time :)

  3. 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.

    1. 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.


    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.

    1. 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?

      1. 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.

  5. 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.

    1. 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.

    2. 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?

  6. sağlık olsun

    So, thanks :)

  7. 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. :)

    1. 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 :)

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Over 27,000 WordPress professionals are already using ManageWP

Add as many websites as you want for free, no credit card required. Sign up and start saving time!

Have questions? Get in touch!

Over 27,000 WordPress professionals are already using ManageWP

Add as many websites as you want for free, no credit card required. Sign up and start saving time!

Have questions? Get in touch!

Over 27,000 WordPress professionals are already using ManageWP

Add as many websites as you want for free, no credit card required. Sign up and start saving time!

Have questions? Get in touch!

Over 27,000 WordPress professionals are already using ManageWP

Add as many websites as you want for free, no credit card required. Sign up and start saving time!

Have questions? Get in touch!