1-Click WordPress
Staging
WordPress staging makes a full copy of your live site on its own address, so you can break things where nobody is watching. One click to create it, one click to push it back. Included from £5.99 a month, and it does not use up a site on your plan.
WordPress staging works because the shape is known
Cloning a website is not copying files. It is knowing which values have to change on the way across, and where they live. That is the whole difference.
-
Credentials
wp-config.php -
Content
wp_posts, named and versioned -
Settings
wp_options, includingsiteurlandhome -
Uploads
wp-content/uploads/
Every value a clone has to find is in the same place on every WordPress site in the world.
- Credentials Could be in any file
- Content Any schema, any table names
- Settings No agreed table, no agreed key
- Uploads Any path, possibly hard-coded
A clone would have to guess, and a wrong guess produces a site that looks fine until it doesn’t.
Staging is not a feature we hold back from Linux customers. It is an operation that needs the platform to recognise what it is looking at, and only a managed application gives it that.
How the WordPress staging clone works
Your files are copied
Into staging_html rather than public_html. Same FTP credentials, different directory, so you can work on staging with the tools you already use.
Your database is copied
Into a new one prefixed SCSTAGING, with its own credentials written into the staging wp-config.php. Your live database is never touched, read from or shared.
Your uploads come too
Everything under wp-content/uploads/ comes across, so what you open is a working site with its images and media in place rather than an empty shell.
The site URL is rewritten
The step people get wrong by hand. siteurl and home are searched and replaced across the cloned database, so the copy knows its own address.
Create a staging area for example.com
- Clone live into Staging A copy of the site you already have
- Install Default WordPress An empty sandbox, nothing carried over
Two things to know about that subdomain
If you already use the staging. subdomain of your domain for something else, creating a staging site repoints it. Whatever was there stops being served at that address. Cancelling afterwards does not put it back, so move it first if you need it.
And if the staging. subdomain does not point at our platform at all, that gets detected during the clone and a temporary address is used for the staging site instead. You still get the staging site; it just answers on a different hostname.
Pushing your WordPress staging site back to live
Clone into Live replaces your live files and your live database with the staging copy. It does not merge them. Everything that landed on live while you were working is replaced, which is why the order below matters.
-
Put the live site into maintenance mode
Do this before you push, not after. The gap between your last staging change and the moment you push is where a new order, a form entry or a comment lands on the live site and is then written over. Closing that gap is the entire job of step one.
-
Export anything transactional from the live site
Orders, enquiries, subscribers, comments: anything that arrived after your staging copy was taken exists only in the live database. WooCommerce core exports products to CSV but not orders, so exporting orders is a plugin job. Advanced Order Export For WooCommerce does it, and at the time of writing it was on version 4.1.0, last updated 8 June 2026, with over 100,000 active installs.
-
Push, check the site, then take maintenance mode off
Tick the confirmation, run Clone into Live, and look at the real site before you let anybody else in. Check a page that uses the thing you changed, check checkout if you have one, then reapply anything you exported in step two.
Your clone is complete
I can confirm this will overwrite my existing, staging website data
You have not cloned to live yet
I can confirm this will overwrite my existing, live website data
Clone into LiveThere is no files-only push. Files and database move together in both directions, and the panel shows you the timestamp of your last clone from live so you can work out how big the gap has become.
Will Google index my WordPress staging site?
A staging environment created in My365i answers on its staging address with a blocking robots.txt you did not have to write. Fetch https://staging.example.com/robots.txt and you get two lines:
User-agent: *
Disallow: /That is the good news and it is worth having. Two qualifications go with it, because the reassuring half on its own would leave you with the wrong idea.
The robots.txt comes from the staging environment, not from the subdomain name
Create a subdomain yourself, call it staging.example.com, and put a copy of your site on it by hand, and you get none of this. It is an ordinary subdomain serving an ordinary WordPress site, so it serves an ordinary robots.txt, sitemap line and all, and it is as crawlable as anything else you publish. The protection belongs to the staging environment the platform made, not to the name. If you are unsure which kind you are looking at, point our Robots.txt Checker at it and read the answer rather than assuming.
A disallow prevents crawling, not indexing
Those two things sound identical and are not. Your staging pages are a copy of your live pages, which means they carry your live site’s index directive, because that directive came across in the database along with everything else. So if anything ever links to your staging address, from a client email that gets published, a forum post, a browser extension that reports URLs, Google can list that URL on its own without having read the page. And because the URL is disallowed, it can never fetch the page to find the directive that would have told it not to.
The practical guidance is one line: do not link to your staging address from anywhere public. That is the whole defence, and it is enough. To see the index directive a staging copy is actually carrying, run it through our free Meta Tag Checker.
Why Linux web hosting has no staging feature
Because a one-click clone needs to know what it is cloning, and on a Linux package it does not.
A WordPress install has a known shape. The database credentials are in wp-config.php. The tables are named and versioned. Uploads sit under wp-content/uploads/. The two values that must be rewritten when a site changes address, siteurl and home, are rows in wp_options and they are in the same place on every WordPress site there has ever been. A platform can copy that and fix it up in one click because it knows in advance where to look.
An application somebody uploaded to a Linux hosting package could keep its configuration in a PHP file, a YAML file, an environment variable or the database. Its tables could be called anything. It might hard-code absolute paths in half a dozen places nobody could predict. A clone tool pointed at it would have to guess, and the failure mode of a wrong guess is not an error message. It is a site that comes up looking correct and then behaves oddly in a way nobody traces back to the clone for a fortnight. We would rather not ship that.
You can still do it by hand, and plenty of people do. Create a subdomain, copy the files across with FTP, export the database and import it into a new one, then search and replace the old site address with the new one everywhere it appears. That last step is the one that bites, because serialised data in a database breaks if you edit it with a plain find and replace. If you get stuck on any of it, ask us. Our free tools will tell you what your DNS, headers and robots rules are doing while you work.
Where your WordPress staging site lives
Staging is in My365i, under WordPress Tools. Your site is served from a staging subdomain of your own domain, in the form staging.example.com, and each site gets one staging copy at a time.
A copy you can break
- Files
staging_html- Database
SCSTAGING-...- If you break it
- Your visitors never see it
Your live site, different door
- Files
public_html- Database
- Your live database
- If you break it
- You have broken your live site
The temporary URL is not a staging site
Every package is given a permanent temporary address, because a package has to be reachable before its domain points at us. For example.com that address is https://example-com.staging365i.co.uk/: your domain with the dots turned into hyphens, sitting under a domain of ours called staging365i.co.uk.
It is the live site on a second address. Same files, same database, same everything. A change you make there is a change to your live website. People read the word staging in the hostname and reasonably conclude the opposite, and the consequence is somebody experimenting on production in the belief that they are safe.
We will take the blame for that one. The domain is called staging365i.co.uk because we named it, and it invites exactly the misreading it gets.
Once your domain resolves to us, the temporary address simply redirects to your real one, and the robots.txt served on it says in plain words that it is a temporary URL and should never be indexed. That is the tidy case. On a package still being built before the DNS switch, the temporary address serves the site directly, which is the whole reason it exists, and that is exactly the moment somebody is most likely to mistake it for a safe place to experiment.
Both addresses are served over HTTPS by the free wildcard SSL certificate that comes with your plan, so neither of them throws a browser warning at you while you work.
WordPress staging questions
All four WordPress hosting tiers, from Personal upwards, plus Agency Hosting. Linux Web Hosting plans do not have it, and the reason is technical rather than commercial: cloning a site in one click means knowing where its settings live, and that is only knowable when the platform knows what the application is.
No. A staging copy does not count against your plan’s site allowance, which is why it works on Personal, the one-site plan. Each site gets one staging copy at a time.
A staging environment created in My365i answers with a blocking robots.txt on its staging address, so crawlers are told to stay out without you doing anything. Fetch https://staging.example.com/robots.txt and you get User-agent: * and Disallow: /. Note that this belongs to the staging environment rather than to the subdomain name: a subdomain you create yourself and happen to call staging serves an ordinary, fully crawlable robots.txt. There is also a gap worth understanding. A disallow stops crawling, not indexing. The cloned pages still carry whatever index directive your live site carries, because that came across in the database with everything else, so if anything ever links to your staging address Google can list the URL on its own, and because the URL is disallowed it can never fetch the page to read the directive that would have told it otherwise. The fix is short: do not link to your staging address from anywhere public. You can check both halves with our Robots.txt Checker and Meta Tag Checker.
No. The push is all or nothing: files and database together, replacing what is on live. There is no files-only option. That single fact is why the procedure on this page starts with maintenance mode rather than ending with a warning.
They are overwritten, unless you export them first. Your staging copy was taken at a moment in time. Anything that lands on the live site after that, an order, a form entry, a comment, a new subscriber, lives only in the live database, and the push replaces the live database with your staging one. Put the site into maintenance mode before you push, and export anything transactional taken during the work so you can reapply it afterwards.
The files go in staging_html rather than public_html, reachable over the same FTP credentials you already use, and the clone gets its own database prefixed SCSTAGING. So you can work on staging with the same tools you use on live, and nothing you do in staging_html touches the site your visitors are looking at.
No, and this is the one that catches people out. That address is your temporary URL: the live site on a second address, same files, same database. A change you make there is a change to your live site. Every package gets one, because a package has to be reachable before its domain points at us, and the address is your domain with the dots turned into hyphens under our own staging365i.co.uk domain. The word staging in it is our doing, not yours. Your actual staging site is at staging.example.com, on your own domain.
By Mark McNeece, Founder of 365i. Last reviewed 28 July 2026.
Editorial integrity: read our editorial standards.
Somewhere to break things
One-click WordPress staging is included on every WordPress plan from £5.99 a month, and on Agency Hosting at £32.99. It does not use up a site on your plan.
