Staging gives you a separate copy of your WordPress website for testing changes before you apply them to the public site. Where the feature is enabled, our NabWP Staging & clone tools help create that copy and make it easier to work through a redesign, update or technical adjustment in a controlled setting.
IN THIS ARTICLE
01 Prepare the staging copy and test your change
- Create and identify the test copy. Start with a current backup, then open the selected website's staging tools and review the proposed destination. Wait for the copy operation to complete and confirm that the address you are editing is the staging address. Keeping live and staging browser tabs clearly labelled can prevent accidental changes to the wrong website.
- Review visibility and copied integrations. Review privacy and visibility settings on the copy. Use the available password protection where appropriate and check search-engine visibility. A staging label by itself should not be treated as proof that a site is inaccessible to visitors. Also review integrations copied from the live site, including email sending, payment gateways, fulfilment connections and scheduled tasks. Use test settings or pause effects that should not run from a test copy.
- Test the affected customer journey. Test the customer journey that your proposed change could affect. For a design update, inspect mobile navigation and key page layouts. For a plugin change, test forms, login, search or checkout as relevant. Keep a clear record of the changes you want to take live.
02 Plan how the tested change will reach the live site
Staging is a separate working copy, so changes and new records on the live website do not automatically appear there. Before deployment, review the direction and scope of any copy operation, especially database replacement. We can help you plan a release that preserves current live data. Availability and resource usage depend on your service, so check the controls and limits shown in your own workspace.
03 Example: isolate a copied store before testing its new theme
A store copied to staging.example.com can retain working payment, email and fulfilment credentials. Before opening checkout tests, use the relevant integration controls to establish and verify the following test state. These are outcomes to check, not assumed automatic NabWP toggles.
Access: restricted to the authorised test team.
Payments: the gateway's sandbox credentials and callbacks.
Mail: an approved test inbox or verified delivery interception.
Fulfilment and accounting: disabled or isolated test connections.
Scheduled work: reviewed before copied jobs can run.
Deployment: theme/code changes only unless a data merge is planned.Keep the live store receiving new orders while you test representative products, navigation and sandbox checkout on staging. Record every intended change and review its file or database scope before any copy-back operation.
Expected result: The new theme works without contacting real customers or dispatching real orders. The live database’s newer orders remain intact when the reviewed design is deployed.
Can a staging copy still send mail or run live business actions?
- Identify the staging address and apply the available access protection and search-visibility settings.
- Review copied payment, outgoing-email, fulfilment and scheduled-task settings before testing.
- Keep a record of the changes made on staging and review their file/database scope before any live deployment.
A staging copy can still contact external services unless its settings prevent that behaviour. Its label does not guarantee privacy or payment isolation. Live orders and user registrations continue independently, so do not replace the live database with an older staging copy without a deliberate data-preservation plan.