Guide Getting Started

How to create a staging copy of your site

A private copy of your site on a subdomain, so changes and updates can be tested somewhere that is not the live website.

iFastHosting Support Team Updated 26 August 2026 7 min read Intermediate

A staging copy is a private duplicate of your website, living somewhere visitors cannot stumble onto it, used for testing updates, design changes or new features before they touch the real site. Making changes directly on a live site and finding out something broke only after visitors do is the exact problem staging exists to avoid.

When it is actually worth setting up

Not every site needs a formal staging setup. A simple brochure site with rare, small edits is often fine to update directly, provided you have a recent backup. Staging earns its keep once changes carry real risk: a major plugin or platform update, a redesign, adding a feature that touches the database, or any site where downtime or a broken page has a real cost — an active store being the clearest example.

The judgement call is really about what happens if the change goes wrong while nobody is watching. A typo fixed on a live blog post costs nothing to correct. A plugin update that quietly breaks checkout on a store, discovered only once customers start abandoning it, costs considerably more — and is exactly the kind of change worth testing somewhere private first.

Setting it up on a subdomain

The most common approach uses a subdomain — staging.yourdomain.com — pointed at its own folder on the same hosting account, kept entirely separate from the live site's files and database.

Create the subdomain
See pointing a subdomain at a folder for the control panel steps. Give it its own dedicated folder, separate from the live site's.
Copy the website files
Duplicate the live site's files into the new folder. Your control panel's file manager can usually copy a folder directly on the server, which is faster than downloading and re-uploading everything.
Copy the database
If the site uses a database — WordPress and most content management systems do — export the live database and import it into a newly created database for staging, rather than pointing staging at the live database directly.
Update the staging copy's configuration
Point the copy at its new database rather than the live one, and update any setting that stores the site's own address, so links and assets resolve correctly on the staging subdomain instead of pointing back at the live site.
Restrict access
Password-protect the staging directory through your control panel, and add a setting to keep it out of search engine results. A staging site is meant to be private — an indexed or publicly discoverable one can leak unfinished content or dilute search visibility for the real site.

Never point staging at the live database directly

If staging shares the live database rather than a copy of it, any test change to content or settings affects the real site immediately, defeating the entire point of a separate environment. Always work from a copy.

Watch for outgoing email on a copied site

A copied database usually brings customer or subscriber records with it, and some plugins send real emails from any environment that runs them — an order confirmation, a password reset, a newsletter test. Disable outgoing mail on the staging copy, or point it at a test mailbox instead, before running anything that might trigger a message to a real address that was only ever meant to be data for testing.

Using staging properly

Make and test changes on staging first: a plugin or platform update, a design change, a new feature. Once everything checks out, apply the same change to the live site, ideally after taking a fresh backup of the live site immediately beforehand regardless of how well staging went. Backing up your website covers that step, and it is worth doing every time, not just when something feels risky.

Keeping staging useful over time

A staging copy is only useful if it reasonably reflects the live site. If staging was set up once and never refreshed, testing against it eventually tells you very little about how a change will behave on the real, current site. Refresh the files and database periodically, particularly before testing anything significant, so what you are testing against is close to what visitors are actually seeing.

An alternative: a temporary preview instead of permanent staging

If you only need to check a single change is safe rather than maintaining an ongoing test environment, a full staging setup may be more than the situation calls for. Testing a site before going live and a broader look at staging environments generally is covered in setting up a staging environment, which is worth reading if you are building this into a regular development workflow rather than a one-off precaution.

If you get stuck configuring a database connection or a file path while setting this up, contact support and we can check what your control panel currently has configured.