Create a staging copy of your site, test changes safely, and push approved work back to production with backups and conflict-aware protection.
StageBridge helps you create and manage a staging copy of your WordPress site from inside the WordPress dashboard. You can clone production to staging, sync production changes into staging, push staging changes without losing unrelated work added to your live site, and create backups before important operations.
/staging/staging.example.comYour live public website. This is the site your visitors use.
A private working copy of your website where you can test changes before publishing them.
Creates the staging site from production.
Pulls newer production changes into staging.
Sends tested staging changes back to production.
Pushes staging changes while keeping unrelated work added to your live site.
Go to StageBridge > Dashboard and click Create Staging.
You can choose subfolder staging, such as example.com/staging, or subdomain staging, such as staging.example.com.
Use sync when production has newer changes that should be copied into staging.
Sync can update selected files, selected database data, generated frontend files where supported, and staging metadata or configuration.
StageBridge compares changes so it can avoid copying unchanged files where possible.
Use push when staging changes are tested and ready for production.
By default, StageBridge uses Smart Push. In simple terms: push staging changes without losing unrelated work added to your live site.
Before push begins, StageBridge can create a safety backup. This option is enabled by default, but you can turn it off for a specific operation if you recently took a backup and understand the risk.
Force overwrite is an explicit push option. Use it only when you are sure staging should replace matching production data and files.
When WooCommerce is active, Smart Push keeps live store activity on production while allowing unrelated tested staging changes to move live.
StageBridge can create full backups, database-only backups, and files-only backups. Full and file backups are compressed when the server supports the required ZIP functionality.
Backups are stored on your server under wp-content/uploads/stagebridge/.
Known disposable log, scan, cache, and traffic tables are excluded by default, but you can include them manually. Automatic safety backups before sync, push, and restore remain enabled by default and can be turned off for a specific operation.
Use restore when you need to roll back from a saved backup. StageBridge restores a backup back to the environment it belongs to: production backups restore to production, and staging backups restore to staging. The restore confirmation modal names the target environment before you continue.
Before restore starts, StageBridge can create a full safety backup of the target environment. This checkbox is enabled by default, and the backup name includes the environment, such as Pre-Restore Production Safety Backup or Pre-Restore Staging Safety Backup.
During restore, StageBridge temporarily locks the target environment, restores large databases in resumable parts, and refreshes WordPress caches when restoration finishes.
StageBridge excludes common files and folders that usually should not be copied into staging or backups, such as cache folders, backup folders, archive files, log files, and non-WordPress folders at the site root.
*.log *.zip *.gz cache backups
Large sites can be limited by hosting resources such as CPU, memory, disk speed, disk space, request timeout limits, firewall rules, and file count or inode limits.
StageBridge runs long operations in resumable steps. It starts efficiently, slows down when the server pushes back, and resets retry attempts after successful progress. If your host still returns repeated 500 or 503 errors, reduce the batch size or increase retry attempts in StageBridge settings.
Example: example.com/staging. Subfolder staging is simple and works on many hosts without creating DNS records.
Example: staging.example.com. Subdomain staging may be better when premium plugins or services recognize staging subdomains differently from subfolders.
Try syncing production to staging. If generated CSS or frontend assets are missing, check whether a cache, optimization, page builder, or security plugin generated files after the clone started. Also confirm that custom exclusions are not excluding important folders.
Check the live log. If the error is temporary, StageBridge may retry automatically. If errors continue, reduce batch size or increase retry attempts in settings.
Smart Push may have detected conflicts and preserved production data. Review the operation log. If you intentionally want staging to replace production, use force overwrite with care.
Confirm that the subdomain exists in your hosting panel, points to the correct staging folder, and has a valid SSL certificate if using HTTPS.
No. StageBridge runs inside your WordPress site and does not send your site data to an external service.
Yes. Safety backups are enabled by default for push and sync operations. You can turn the option off for a specific operation, but only do this when you already have a recent backup and understand the risk.
No. Create subdomains in your hosting account first, then configure StageBridge to use that staging URL.
Use Smart Push, keep the safety backup enabled, review the preview and logs, and avoid force overwrite unless you are certain staging should replace production.
If you need help, include your WordPress version, PHP version, StageBridge version, staging type, the operation you were running, and relevant StageBridge activity log lines.
You can submit support requests on the official WordPress.org support forum: wordpress.org/support/plugin/stagebridge/