A staging check should answer a concrete question: can this release perform the customer actions the current website supports? Prepare an isolated preview with the intended files and configuration, then test the actions that matter before switching traffic.
Define what must keep working
List the pages and actions the business relies on. A small brochure site may need working navigation and a delivered enquiry. An application may also need login, database writes or an external integration. Choose checks from those responsibilities, rather than trying to click every decorative element.
Record the release identifier and the current live version. Keep preview data and service accounts separate from production. An isolated preview should not accidentally email customers, change live records or process real payments.
Check the differences introduced by this release
- Open affected pages directly and refresh an inner route.
- Test the mobile navigation and the main contact or purchase action.
- Check changed configuration keys and asset paths.
- Verify database changes against a suitable isolated data set.
- Confirm existing links still reach their expected destinations.
If a change is limited to content or styling, keep the verification proportionate. If it changes authentication, data structure or a cross-service contract, include the dependent flows in the release plan.
Make the release reversible
Keep the previous files and the information required to restore them. If a database migration changes compatibility, a file-only rollback may be insufficient; review the migration's recovery process before release. Define the observation window and the specific failure that would trigger a rollback.
After publishing, repeat the most important checks on the actual public hostname. A preview cannot fully verify production DNS, certificates or environment settings. Record the result in one release note so the next maintenance task begins from a known state.