Push WordPress Staging to Live – free, host, & manual

Safe process (works with host tools, free plugin, or manual/CLI)

1. Back up both environments (files + DB). Keep zips and SQL exports.
2. Maintenance mode (or a short downtime window) to prevent new orders/comments during deploy.
3. Pick a path:
   • Host staging tool: use the “Push to live” flow in your panel.
   • Free plugin route: create a staging clone with a popular plugin; if “push back” is paid, deploy files manually + do DB steps below.
   • Manual/CLI: copy changed files and import a DB export from staging, then run search-replace.
4. Post-launch checks: clear caches/CDN, re-save permalinks, test logins, contact forms, and checkout.

Manual/CLI (free) — files + database

Files: copy only changed files from staging to live (theme/child theme/custom plugin/uploads created in staging). Avoid overwriting user uploads added on live during development.

Database (export on staging → import on live):

# On STAGING
wp db export staging.sql

# Transfer staging.sql to LIVE, then on LIVE:
wp db export live-backup-before-import.sql
wp db import staging.sql

# Replace staging URLs with live URLs (skip GUIDs)
wp search-replace 'https://staging.example.com' 'https://example.com' \
  --all-tables --skip-columns=guid --precise --recurse-objects

WooCommerce or active sites: if live has new orders/users since you created staging, a full DB overwrite will lose that data. In that case, deploy files only and migrate only what’s required (options/menus) or schedule a short maintenance window.

Maintenance mode (quick)

wp maintenance-mode activate
# deploy...
wp maintenance-mode deactivate

URL fixes without CLI (phpMyAdmin)

Use a serialized-safe search-replace tool when possible; avoid raw SQL for serialized data. If you must update only base URLs:

UPDATE wp_options
SET option_value = REPLACE(option_value,'https://staging.example.com','https://example.com')
WHERE option_name IN ('siteurl','home');

Post-launch checklist

• Clear page cache/object cache/CDN; purge browser cache for admin checks.
• Re-save Settings → Permalinks to refresh rewrite rules.
• Test: homepage, key landing pages, login, forms, search, and checkout.
• Re-enable cron/background jobs if you paused them.

Summary: free path = files + DB via backups and WP-CLI (or plugin + manual DB). For ongoing stores, prefer a short maintenance window or file-only deploy to avoid data collisions.

Push just the DB (with caveats)

1. Confirm no live edits will be lost: if your live site gets orders/comments/users, a full DB import will overwrite them.
2. Back up live DB:

wp db export live-backup-before-db-push.sql

3. Export on staging → import on live:

# On STAGING
wp db export staging.sql

# On LIVE
wp db import staging.sql
wp search-replace 'https://staging.example.com' 'https://example.com' \
  --all-tables --skip-columns=guid --precise --recurse-objects

Selective approach (safer for busy sites)

Import only needed tables (e.g., options) instead of a full overwrite:

# Export only specific tables on STAGING
wp db export staging-options.sql --tables=wp_options

# Then import on LIVE
wp db import staging-options.sql

4. Validate: clear caches, re-save permalinks, and test logins/forms/checkout.

Rule of thumb: a DB push is safest during a maintenance window; otherwise prefer files-only deploy and apply settings/content changes in admin.