Every backup conversation counts the copies: the live site, the nightly archive, the export sitting in a download folder. A staging environment quietly adds one more, and it is the copy nobody counts, because it was created for safety rather than for storage. A WordPress staging site for testing updates is a duplicate of your live database living on the same account, and the terms that govern it put the whole of its care on you.
This is an independent editorial review. Bluehost did not review or approve this article.
The terms quoted here are the United States agreement; a purchase made in another country may sit with a different contracting entity under a different governing law, so a reader outside the US should check which agreement their own account falls under before relying on any clause below.
You can check current options here:
Use case 1: Why a WordPress staging site for testing updates exists at all
The pitch is simple and correct. Bluehost describes staging as “a copy of your live site” that lets you try updates, plugins and design changes where visitors cannot see them, and notes that staging is “not publicly accessible” and that changes “do not impact the live website until you’re ready.” For anything beyond a text edit, that is the right instinct.
The interesting part is what happens at the other end. Publishing a staging site back to production is not one action but three, and the help documentation names them. Deploying all changes “overwrites both the database and the files on your live site.” Deploying files only moves themes, plugins and media and leaves the live database “completely untouched.” Deploying the database only moves tables and settings and leaves “your live site’s files completely alone.”
Sitting underneath those three options is one sentence that decides which to use: “any changes you make to the live site will NOT automatically sync to your staging website.” The copy is taken once. It does not keep up.
Put the two together and a familiar accident appears. You clone the site on Monday. You spend three days testing. On Thursday you deploy all changes. Every order, comment, form entry and new post that landed on the live site during those three days was in the live database and not in the staging one, and the live database has just been overwritten by a copy taken on Monday.
That is the whole argument for choosing the narrow deploy. A design or template change lives in files; content lives in the database. If the only thing you changed is the look, pushing files alone leaves three days of real activity exactly where it is.
Use case 2: A WordPress staging site for theme changes, which is the case it fits best
Running a WordPress staging site for theme changes is the cleanest version of this workflow. Appearance work is the cleanest fit for staging, because the thing being changed and the thing being protected sit in different places.
A theme switch, a template rewrite, a change to how a layout breaks on a phone: all of that is files. The posts, the pages, the customer records and the comments are database. Testing in a copy and then pushing only the files is the one workflow where the staleness problem described above simply does not arise, because you never send the old database anywhere.
The practical sequence is short:
- Clone the live site to staging, and note the date you did it.
- Make the appearance changes in staging and check them on a phone as well as a desktop.
- Deploy files only, so the live database is left alone.
- Check the live site immediately afterward, including a page that is generated from the database rather than from a template.
One caveat worth carrying. Theme settings do not always live where you expect. Some are stored in files, some in database options, and a theme that keeps its customizer settings in the database will not carry them across a files-only deploy. That is a thing to test in staging rather than to assume, which is exactly what staging is for.
Use case 3: A WordPress staging site for plugin updates on a site that takes orders
The argument for a WordPress staging site for plugin updates on a store is strong, and so is the specific risk underneath it. A store is where the copy stops being a technicality.
Cloning a shop clones more than code. Cloning a shop clones its orders, its customer names, its addresses and whatever the checkout saved along the way. That data is now in two places, and the second place is one nobody is monitoring.
Bluehost’s own terms are unusually direct about where responsibility sits. They state that “IT IS SOLELY SUBSCRIBER’S DUTY AND RESPONSIBILITY TO BACKUP SUBSCRIBER’S FILES AND DATA ON BLUEHOST SERVERS,” that “Bluehost is not responsible for the loss of any Subscriber Content,” and, in a line worth reading twice before cloning a checkout, that “the Services are not appropriate for the storage or control of access to sensitive data.” The same terms name Bluehost Inc. at 5335 Gate Pkwy, Jacksonville, FL 32256 and set Florida law as the governing law for the US agreement.
The Federal Trade Commission reaches the same place from the other direction. Its business guidance carries the heading “Don’t use personal information when it’s not necessary,” and summarizing the cases behind it the agency writes that “In both cases, the risk could have been avoided by using fictitious information for training or development purposes.” That is a rule about test environments stated as plainly as it can be: the copy you are testing against does not need to be made of real customers.
For a store, that turns into three habits rather than one. Test with sample data where the test does not require live records. Keep the staging copy for the length of the test rather than indefinitely. And before pushing anything, decide which of the three deploy options you need, because a shop’s database is where this morning’s orders are.
If the wider backup question is the one you are really asking, our guide to keeping a copy somewhere other than the server covers the off-site half of the problem.
Use case 4: A WordPress staging site for agencies handing work to a client
Running a WordPress staging site for agencies adds a party, and the parties do not share a dashboard. The client keeps posting while the agency builds, which means the two copies diverge from the moment the clone is taken, and the person who understands the deploy options is usually not the person adding the posts.
Bluehost documents a separate flow for its agency and cloud products, with their own create and promote steps, so the mechanics differ from the standard plugin route. The coordination problem is the same either way, and it is a scheduling problem rather than a technical one.
Things worth agreeing in writing before the clone is taken:
- A content freeze window, or an explicit acceptance that a database deploy will discard anything published during the build.
- Which deploy option will be used, named rather than assumed, because files-only and all-changes have opposite consequences for the client’s content.
- Who holds the backup, given that the host’s terms place that duty on the account holder rather than on the host.
- How long the staging copy survives after handover, since a forgotten clone is a second copy of the client’s data with no owner.
- What the rollback is, in one sentence, before anything is pushed.
Side-by-side by situation
| Your situation | What it actually needs | What to check first |
|---|---|---|
| Trying a new theme on a blog | A files-only deploy, so posts published meanwhile survive | Which of the two your theme stores its settings in, files or the database |
| Updating plugins on a store | Sample data where possible, and a narrow deploy | Which deploy option moves the database, and what is in it today |
| A build that runs for several weeks | A content freeze, or acceptance that live posts will be lost | The date the clone was taken, written down |
| Agency handing a site back to a client | An agreed deploy option and an agreed backup owner | That the host’s terms put backup duty on the account holder |
| Any site holding customer records | A staging copy that is deleted when the test ends | The clause stating the service is not for sensitive data |
Related Articles
- Website Builder for Small Businesses: Service, Store, or Blog
- Software Lifetime Deal for Freelancers: Whose Lifetime AppSumo Means
- Product Mockup Generator for Online Stores: What Placeit Does Not Clear
Frequently Asked Questions
These are the questions that decide whether a staging workflow helps or hurts. The answers quote the host’s own help documentation and terms, and the federal business guidance on test data, each read directly.
Will publishing my staging site delete the orders that came in while I was testing?
It can. The documented behavior is that deploying all changes overwrites both the database and the files on the live site, and that live changes never sync back to staging automatically. If the only thing you altered was appearance, the files-only option leaves the live database untouched.
Does the host back up my staging copy for me?
The terms say the duty sits with you, in capitals: backing up files and data on the servers is solely the subscriber’s responsibility, and the agreement states that the host is not responsible for the loss of subscriber content.
Should a staging copy of a store contain real customer data?
Not where the test does not require it. The federal guidance on this is to use fictitious information for development purposes, and the host’s own terms say the service is not appropriate for storing or controlling access to sensitive data.
How long should a staging site be kept?
For the length of the test. A clone left in place is a second copy of everything the live site held on the day it was taken, including anything personal, and it drifts further from the real site every day it survives.
You can check current options here:
Conclusion
Staging is worth using, and it is worth using with the deploy menu open rather than closed. The three options exist because files and database content fail in different directions, and the one that sounds most complete is also the one that can overwrite a week of real activity. Read the clone as what it is, a full second copy of the site including whatever personal data the site holds, keep it for the length of the test, and remember that the agreement covering it puts the backup, the retention and the cleanup squarely on the account holder.
