Editing live is the default and it should not be
Most WordPress sites are changed directly on the live site, including plugin updates that can break checkout or a contact form.
That works most of the time, which is exactly why it persists. The occasions it does not are expensive and always badly timed.
What staging is for
- Testing plugin and core updates before they touch the live site
- Building new sections without publishing half-finished work
- Reproducing a problem safely
- Testing a restore, which proves your backups
Keeping staging useful
- Refresh it from live regularly, or it stops representing reality
- Block search engines from indexing it, always
- Protect it with a password
- Point it at test payment and email settings, never live ones
A staging site sending real emails to real customers is a mistake people make exactly once.
Version control for the code
Themes and custom plugins belong in version control. That gives you a history, a review step and a reliable way back.
Content stays in the database and moves the other way — live to staging, not staging to live.
A simple deployment routine
| Step | Why |
|---|---|
| Refresh staging from live | Test against reality |
| Apply changes on staging | Nothing live is at risk |
| Check key pages and forms | The usual breakages |
| Back up live | A known-good point to return to |
| Deploy, then verify | Confirm rather than assume |