A staging site is a separate copy of your website where you test updates and design changes. It needs separate files and a separate database so testing cannot alter live content. The available cloning tools and site allowance depend on your hosting plan.
The Control Center's WordPress tab is an inventory, without cloning controls. Review the service's shared website allowance first. Use Add a website if you need a permitted separate destination, or use Virtualmin's supported cloning tools. Any resulting additional site still shares the hosting owner and resource allowance.
Prepare a protected copy #
- Check that your plan has enough storage and permits the additional website or sub-server. Take a production backup first.
- If your host provides WP Workbench, open the site's management view and review its Clone options. Cloning to a sub-server requires the corresponding account permission. Otherwise, use an application-supported migration tool or ask your developer to copy the files and database. Virtualmin WP Workbench
- Choose a distinct address and directory, such as a permitted staging subdomain. Confirm that the copy uses its own database credentials.
- Protect the site with host-supported authentication or access restrictions. A search-engine indexing preference alone does not keep the copy private.
- Disable or replace outbound email, live payment credentials, subscription jobs, webhooks, and external integrations before anyone tests the copy. Use test services and remove customer data when it is unnecessary.
For WordPress, use a migration method that understands stored URL data. A broad text replacement in a database dump can damage serialized settings. WordPress migration guidance
Verify separation #
Make a harmless change on staging and confirm that production stays unchanged. Test the sign-in and purchase paths using test credentials, then confirm that no real customer received a message or charge. Compare PHP versions and other relevant settings so the test environment represents production.
Put tested changes live #
Record exactly which files, settings, or content must change. Back up production again before deployment. On a store or membership site, do not overwrite the live database with an older staging copy: that can erase intervening orders and accounts. Ask your developer to deploy the intended changes without replacing current transaction data.
Troubleshooting #
If the staging URL redirects to production, review application URL settings and caches. If both sites change together, stop testing and inspect their database and filesystem configuration. Remove an obsolete staging copy only after confirming its files and database belong to staging.
Related: additional websites, WordPress updates.
Leave a Reply