How it is used
The developer copies the live site to staging, makes the change there (a major plugin update, a new booking system, a redesigned page), tests it on phones and browsers, and then either pushes the change to live or recreates it on the live site. Content changes made on live in the meantime are not affected, because staging is only a copy; it is not the other way round. Staging is also where a backup gets test-restored and where a redesign is built while the current site keeps running.
What to test on staging
- Major WordPress, WooCommerce or theme updates, and any update to a plugin that touches the checkout, forms or layout.
- New plugins or apps.
- Design changes, new templates and new sections.
- PHP or server upgrades from the host.
- Integrations with payment, booking, CRM or email systems, using their test modes.
Routine minor plugin updates on a simple site can be applied live with a backup first; the staging step is for changes that could break something people depend on.
Keeping staging safe
A staging site must not be indexed by Google, or it competes with the real site and leaks unfinished work; it should carry a noindex setting and ideally sit behind a password. It should use test keys for payments and not send real customer emails. And it should be refreshed from live before each round of testing so it reflects the current site. Staging is included in PrimaryDM's higher maintenance plans and is part of how we handle every redesign.