Every change made directly on a live site is a change tested on your customers. A staging copy costs a subdomain and removes that entirely - as long as three things are handled, because a careless staging site can do real damage.

1. Keep it out of search results

A staging copy indexed by Google competes with the real site for its own content, and customers land on a half-finished page. Block it before it exists, not after.
# nginx, on the staging server block only
add_header X-Robots-Tag "noindex, nofollow" always;

Password-protect it as well - it is the only method that also stops a link being shared by accident.

2. Stop it sending mail

A staging copy with a live order table will email real customers about test orders. Point mail at a catcher, or disable sending entirely.

# WordPress: a tiny must-use plugin
add_filter('pre_wp_mail', '__return_false');

3. Point payments at the sandbox

Test keys, always. A staging site with live payment keys will take real money from a real card during a test.

Going live

  1. Back up the live site first — Files and database. This is the undo button.
  2. Push files, not the database, if content changed on live — Otherwise you overwrite orders and comments made since the copy.
  3. Push the database only if content did NOT change on live — Then search and replace the staging URL for the live one.
  4. Clear every cache — Application, server and CDN. A page cache will serve the old site for hours.
  5. Walk the critical path — Log in, add to basket, check out, receive the mail.
wp search-replace 'https://staging.yourdomain.com' 'https://yourdomain.com' --all-tables
Never push the database over a live shop. Deploy code, and make content changes on live. Which direction each kind of change travels is the whole discipline.