Quick answer: A staging site is a private copy of production where you test updates before they can break anything real. On a VPS: clone files + DB to a staging. subdomain, block indexing and search-replace the URL, test updates there, then apply the same updates on production — code flows up, content never flows down blindly.

Overview

Every serious incident that starts with “I clicked update…” is preventable with staging. On managed hosting it’s a button; on a VPS it’s a 10-minute clone you script once. The golden rule: changes move staging→production as repeated actions (the same update clicks), not as file copies — production content (orders, comments) must never be overwritten by stale staging data.

Before you start

  • A staging.example.com DNS record pointing at the VPS.
  • Disk headroom for a full copy (df -h).
  • WP-CLI installed; a current backup of production.

Step-by-step guide

  1. Clone files and database:
    sudo cp -a /var/www/example.com /var/www/staging.example.com
    sudo -u www-data wp --path=/var/www/example.com db export /tmp/prod.sql
    sudo mariadb -e "CREATE DATABASE wp_staging"
    sudo mariadb wp_staging < /tmp/prod.sql
  2. Point the clone at its DB (edit wp-config.php in the staging path) and rewrite URLs:
    sudo -u www-data wp --path=/var/www/staging.example.com search-replace \
      'https://example.com' 'https://staging.example.com' --skip-columns=guid
  3. Add a vhost + SSL for the subdomain, then protect it: discourage indexing (Settings → Reading) and add HTTP basic auth at the web server — staging leaking into Google is a classic SEO wound.
  4. Test on staging: run the pending core/plugin/theme updates, click through key journeys (front page, login, forms, checkout if WooCommerce).
  5. Apply to production: run the same updates there (wp-admin or wp plugin update ...), immediately after a fresh backup.
  6. Refresh staging from production before each testing round — stale staging gives false confidence.

Common issues

  • Staging emails real customers: disable/redirect outgoing mail on staging (a “stop emails” plugin or SMTP sink).
  • Search engines index staging: basic auth prevents it outright — robots settings alone are advisory.
  • Someone edits content on staging: it will be lost by design — staging is for code/config testing only.

When to contact support

Platform questions — disk space for clones, adding a subdomain to your setup — are ticket material; the staging workflow itself is fully in your hands on a VPS.

Frequently asked questions

What exactly is a staging site?

A private, up-to-date copy of your production site on the same or another server where updates and changes are tested first — breakage there costs nothing.

How do I move tested changes from staging to production?

Repeat the same actions on production (run the same updates, change the same settings) right after a fresh backup — never copy staging files or database over production content.

Why must staging be hidden from search engines?

An indexed staging clone competes with your real site as duplicate content and can leak unreleased work; HTTP basic auth blocks crawlers reliably, unlike robots.txt hints.

Related articles

Ready to get started? Order a WordPress VPS at Cloud2Y →

Was this answer helpful? 0 Users Found This Useful (0 Votes)