A staging site is a copy of your live site that nobody can see, where you test changes before applying them. It is the difference between discovering a plugin conflict yourself and discovering it because a customer reported that checkout stopped working.
On a hosting account it costs a subdomain and some disk. For any site that earns money, that is the cheapest insurance available.
Create the subdomain first
In cPanel, create a subdomain such as staging. It resolves within a minute or two, because the DNS record is added on the server that already answers for your domain, no registrar involvement.
Keep the default document root, usually public_html/staging. Creating and managing subdomains goes over it.
Copy the site into it
A staging site needs both files and database, from the same moment. A copy of one without the other does not work.
The practical routes, in order of convenience:
A migration plugin. Export from live, import into staging. Handles the URL rewriting, which is the part that otherwise takes the longest.
Manually. Copy the files, export the database, import it into a new database, and point the staging wp-config.php at it. Then run a proper search-and-replace to change the stored URLs from the live domain to the staging one, using a tool that understands serialized data, because a plain SQL replacement corrupts theme and widget settings.
Whichever route, the staging site must use its own database. A staging site sharing the live database is not a staging site: every change you make there is live.
Block it from search engines, properly
This is the step that causes real damage when skipped. An indexed staging site is a complete duplicate of your content at a second address.
Password-protect the directory rather than relying on a robots setting. Directory privacy refuses the request at the web server before anything loads, which does not depend on a crawler choosing to respect it. Password protecting directories picks it up from there.
Tick the search engine visibility setting in WordPress as well. Two layers, because this one is worth being certain about.
Disable the things that reach outside
A staging copy carries the live site's configuration, including anything that contacts the outside world. Three of them cause real problems.
Payment gateways. Switch to test mode, or a staging checkout can take a real payment.
Outgoing email. A staging site running an order process can email real customers about orders that do not exist. Disable mail on staging or route it somewhere harmless.
Analytics and marketing pixels. Otherwise your test clicks pollute the live site's data.
That first one is worth checking carefully. A staging store with live payment credentials is a genuine risk instead of a theoretical one.
What to actually test there
Major WordPress releases, plugin and theme updates on a site where breakage costs money, anything structural, and any new plugin before it goes near the live site.
Test the flows that matter rather than just loading the homepage: a form submission, a login, and checkout if there is one. Those are where conflicts surface, and they are the pages people skip.
Pushing changes back
This is where staging gets awkward, and it is worth being honest about it.
Copying staging over live also copies the staging database, which means any order, comment or content change made on the live site since you took the copy is destroyed.
So for most sites the workflow is: test on staging, then apply the same change to live rather than copying staging over it. Update the plugin on live, having confirmed on staging that it is safe.
Copying staging over live is appropriate only for a redesign where the live database has not changed meaningfully, and it needs a backup first regardless.
Refresh it, and remember it exists
A staging copy from four months ago tests against a site that no longer resembles the live one, so the results mean less than they appear to.
Refresh before any significant test. And note the copy in your own records: staging sites get created for one job and left running for years, unpatched, holding a full copy of the live customer database. That is a data exposure waiting to happen, and it is entirely avoidable.
Across several sites, applying the same arrangement everywhere is what keeps it manageable. How to Manage a Portfolio of WordPress Sites deals with standardising.
A store breaks the usual pattern, because the live database keeps changing while you work. How to Run a Staging Store Without Losing Orders goes into what may and may not be pushed back.
Keep it out of the search index for certain
A staging copy that gets indexed competes with the real site and shows unfinished work to the public, and the usual setting is not enough on its own.
curl -sI https://staging.example.com/ | grep -i x-robots curl -s https://staging.example.com/ | grep -i 'name="robots"' curl -sI https://staging.example.com/ | head -1
The reliable arrangement is a password on the whole subdomain. A crawler that cannot fetch the page cannot index it, whatever the page says about itself, and it also keeps the copy away from anyone who guesses the address.
Relying on the discourage setting alone is weaker, because it is a request rather than a control and it is switched off by exactly the kind of bulk settings copy that staging exists to test. Password protecting a directory deals with the stronger option.
Stop it acting on the outside world
A copy of a live site is a fully working site, and it will happily do real things to real people.
The list worth disabling before anyone touches it: outgoing mail, payment processing in live mode, scheduled tasks that notify or charge, any integration that writes to a shared system, and analytics that would pollute the real figures.
wp config set WP_ENVIRONMENT_TYPE staging wp config set DISABLE_WP_CRON true --raw wp option update woocommerce_email_from_address '[email protected]'
The environment value lets code behave differently without further configuration, and well written plugins respect it.
The failure this prevents is specific and expensive. Somebody tests an order flow on staging and a real customer receives a shipping notice, or a scheduled reminder run goes out twice because both copies ran it.
Decide in advance how changes come back
The awkward part of staging is not creating it. It is that the live site keeps changing while you work on the copy.
Pushing the whole staging database back overwrites every order, comment and registration created since the copy was made. That is acceptable for a brochure site and destructive for a shop.
The workable rule is to move code and configuration forward, and never to move content backwards. Theme and plugin files, yes. Settings, deliberately and one at a time. The database wholesale, only when you can name what would be lost and accept it. Running a staging store without losing orders goes into the shop case.