Creating a Private Staging Copy of Your Website

A staging site is a separate, restricted copy used to test changes before production. It needs separate files and a separate database. A second hostname pointing at the live database is another entrance to production, not an isolated test environment.

Build the boundary first

1. Choose an unused staging hostname and a distinct document root.
2. Create a separate database and credentials for the copy.
3. Restore a reviewed backup and update its database connection.
4. Protect access with hosting-level authentication or another appropriate restriction.
5. Disable real payments, outgoing customer messages, webhooks and scheduled production jobs.
6. Check application URLs and integration credentials before opening the copy.

A request not to index a site is not access control. Sensitive content still needs authentication. If possible, use reduced or anonymized test data rather than copying all customer records. Keep staging credentials separate from the production application.

Make the experiment repeatable

Record the starting version and one proposed change. Test important user journeys with an ordinary account, including an error case and a fresh browser session. Compare application logs before and after. Keep a short acceptance list so a visually correct homepage does not hide a broken form.

Decide what moves back to production

For a code or theme update, deploy the tested change using the application’s supported process. Do not automatically copy the entire staging database over production: live orders, comments and edits may have arrived since the copy was created.

If a full database replacement is genuinely required, arrange a write freeze and reconciliation plan. After release, rerun the acceptance checks on production and ensure staging remains private or is removed when no longer needed.

Use the backup and restore guide to build the copy and the PHP change checklist for runtime experiments.