A staging site makes testing updates easier—but copying your live site can also bring along customer emails, payment credentials, and background automations. Without safeguards, your tests can reach real customers.

Start by identifying the environment. Add this line to your staging site’s wp-config.php, above the “That’s all, stop editing!” comment:

define( 'WP_ENVIRONMENT_TYPE', 'staging' );

If WP_ENVIRONMENT_TYPE is already defined, change its value to 'staging' instead of adding another definition.

This tells WordPress and compatible plugins that the site is staging. Because it’s stored in a file rather than the database, it survives database refreshes from your live site. Alok Jain’s article explains the approach.

That line alone won’t stop outgoing emails or payments. Pair it with a few safeguards:

• Block customer emails or redirect them to a test inbox.
• Use test payment credentials and review connected services.
• Pause background automations unless you’re testing them.
• Restrict access and keep staging out of search results.

For email specifically, Jain shares a small must-use plugin that blocks messages sent through WordPress outside production. Plugins that send directly through an email service’s API need separate controls.

Prefer a ready-made option? Staging Superpowers recognizes the staging setting and bundles protections for email, connected services, scheduled tasks, indexing, and more.

After each refresh, verify your safeguards with a test form submission or order. A staging site should give you room to experiment without surprising your customers.