Staging Sites

Create staging copies of your live WordPress site, test changes safely, and push to production.

Overview

Staging lets you create an exact copy of your live WordPress site where you can safely test changes before applying them to production. Use staging to:

Test theme and plugin updates without risking your live site
Preview design changes and share them with clients for approval
Debug issues in an isolated environment that mirrors production
Try new plugins without affecting real visitors or customers

Your staging site is a fully functional WordPress installation with all your content, settings, and customizations — but completely isolated from your live site.

Creating a Staging Site

Open the Staging panel

In your WordPress admin, navigate to SafeGuard → Staging and click Create Staging Site.

Enter a descriptive name for the staging site (e.g., "Theme Redesign" or "WooCommerce Update Test"). This name appears in your staging site list and in the admin bar when you're logged into the staging environment.

Choose access type

Select how your staging site will be accessible:

Access Type	URL Format	Best For
Subdirectory (default)	`example.com/staging/`	Most sites — works on any host
Subdomain	`staging.example.com`	Cleaner URLs, requires DNS/wildcard setup
Custom path	`example.com/your-path/`	When you need a specific URL structure

Choose protection

Control who can access your staging site:

Password protected (default) — anyone with the password can view the site
Admin only — only logged-in WordPress administrators can access it
Public — no restrictions (not recommended for most use cases)

Set auto-delete

Choose when the staging site should be automatically removed:

7 days
14 days
30 days (default)
90 days
Never

Choose source

Select where the staging data comes from:

Latest backup — uses your most recent SafeGuard backup (fastest, no downtime)
Fresh snapshot — takes a new snapshot of your live site right now (most current)

Create

Click Create to start building your staging site. Depending on site size, this typically takes 30 seconds to a few minutes. You'll see a progress indicator and receive a notification when it's ready.

Quick vs Full Isolation Modes

When creating a staging site, you can choose between two isolation modes:

Quick mode shares the wp-content directory with your live site via symlinks. Only the database tables are isolated using a separate table prefix.

Fastest to create — no file copying required
Uses minimal disk space — themes, plugins, and uploads are shared
Best for content changes, settings testing, and quick previews
Trade-off — file changes (e.g., installing a plugin) affect the live site

Full mode creates a complete copy of the wp-content directory alongside the isolated database tables. This gives you full file and database isolation.

True sandbox — no shared files between staging and production
Best for theme development, plugin testing, and destructive experiments
Trade-off — takes longer to create and uses more disk space

Scoped Staging Roles

When you create a staging site, you can assign a staging role to each administrator. This controls what they can do on the staging environment without affecting their production permissions.

Available roles

Role	Description
Full Access	Same permissions as a production administrator. Can do everything.
Staging Developer	Restricted role designed for developers and content editors who need to build and test but should not change site-wide settings.

What Staging Developer can do

Edit, create, and delete posts, pages, and media
Activate and deactivate plugins
Switch and customize themes
Access the Customizer

What Staging Developer cannot do

Install or delete plugins and themes
Manage users (create, edit, delete, change roles)
Access WordPress Settings pages
Access SafeGuard settings or backups
Export or import site data

Assigning roles

In the staging creation modal, each administrator from your production site is listed with a role dropdown. Select Full Access or Staging Developer for each user.

Non-admin users (editors, authors, subscribers, etc.) do not need a staging role. Their production capabilities already limit what they can do, and those same restrictions apply on staging automatically.

Per-User Credentials

Each administrator you select during staging creation receives a unique username and password for the staging site. These credentials are displayed on the staging card in SafeGuard → Staging.

Click the copy icon next to any credential to copy it to your clipboard
Share credentials individually with team members — each person gets their own login
Credentials are generated automatically and are independent of production passwords

Accessing Your Staging Site

Once created, your staging site is available at the URL shown in SafeGuard → Staging. The URL format depends on the access type you selected:

https://example.com/staging/          # subdirectory
https://staging.example.com/          # subdomain
https://example.com/your-custom-path/ # custom path

If you chose password protection, visitors will see a password prompt before accessing the site. Share the password with clients or team members who need to review changes.

When you're logged in to the staging site, a colored banner appears in the admin bar to remind you that you're working on staging — not production.

Push to Live

When you're satisfied with the changes on your staging site, you can push them to production.

Choose push type

A full push replaces your entire live site with the staging version — database, themes, plugins, uploads, and all other files.

Use this when you've made sweeping changes across multiple areas of the site.

A selective push lets you choose exactly what to deploy:

Database only — content, settings, and options
Themes only — theme files and customizations
Plugins only — plugin files and configurations
Uploads only — media library files

You can combine multiple selections in a single push.

Review changes

SafeGuard shows a summary of what will be modified on your live site. Review the list carefully before proceeding.

Confirm and push

Click Push to Live to start the deployment. SafeGuard automatically creates a full backup of your production site before making any changes, giving you a safety net to roll back if needed.

Pushing to live replaces production data with your staging version. Always verify your changes on the staging site thoroughly before pushing. If something goes wrong, you can restore from the automatic pre-push backup.

Pre-Push Backup

Every time you push staging changes to production, SafeGuard automatically creates a full backup of your live site before any changes are applied. This backup:

Appears in the Backups tab with a label indicating it was created before a staging push
Includes the complete database and all files, just like a regular full backup
Can be restored at any time if the push introduces unexpected issues

If the push fails partway through, your production data remains safe because the backup was taken before the process started. You do not need to create a manual backup before pushing.

Auto-Expiry

Staging sites are temporary by design. The auto-expiry system keeps your server clean by removing staging sites that are no longer needed.

Configurable per site — set the expiry when creating the staging site, or change it later from the staging settings
3-day warning — SafeGuard sends an email notification 3 days before a staging site is scheduled for deletion
Extend or disable — you can extend the expiry date or set it to "Never" at any time from the staging management panel

Expired staging sites are fully removed, including their files and database tables.

Safety Features

SafeGuard automatically applies several safety measures to every staging site, preventing it from interfering with your live site or external services.

Emails blocked — all outgoing emails are intercepted and logged instead of sent, so your customers never receive test messages
Payment gateway calls blocked — Stripe, PayPal, and other payment processors are sandboxed to prevent accidental charges
Analytics scripts stripped — Google Analytics, Matomo, and other tracking scripts are removed so staging traffic doesn't contaminate your production data
Search engines blocked — staging sites are set to noindex with blog_public=0, keeping them out of search engine results
WP-Cron disabled — scheduled tasks (like publishing scheduled posts or sending newsletters) are paused on staging to avoid unintended side effects

Separate Database

By default, staging sites share the same database as your live site using a different table prefix. For complete isolation, you can use a separate database.

When to use a separate database

You're running heavy database operations on staging (imports, migrations)
You want zero risk of table prefix collisions
Your host provides multiple databases at no extra cost

How to configure

In the staging creation panel, expand Advanced Options and enable Use separate database. You'll need to provide:

Database name
Database user
Database password
Database host (usually localhost)

SafeGuard will create the necessary tables and copy your data to the separate database automatically.

Background Operations

You can safely close your browser during staging creation or push. The operation continues in the background on the server. When you return to SafeGuard → Staging, the UI automatically reconnects and shows the current progress or completed result.

Limitations

Multisite networks are not supported in v1. Staging works with standard single-site WordPress installations only.
Nginx with plain permalinks — if your server uses Nginx and your site uses plain (query string) permalinks, the staging subdirectory setup may require manual Nginx configuration. Subdomain access works without modification.