Staging is where you learn that a plugin update breaks checkout before customers do. On WPHost, staging on Pro and above is a persistent copy — an environment you can keep, deploy to, and test on. It is not marketed as a one-click “clone production including database and rewrite all URLs for me” appliance. If you want production content on staging, you copy the database (and fix URLs). That honesty is the product.

Starter ($9, 1 site, 2 GB) is production-only. Pro ($30, 3 sites, 10 GB) is where staging enters for most people. Scale ($65) and Business ($130) continue the ladder — pricing.

What staging is for

  • Plugin and core updates (we do not auto-update — you still click, just safer)
  • Cache plugin experiments — fast
  • Theme / page builder redesigns — designers
  • PHP-related compatibility checks on 8.4
  • Training clients without touching production

What staging is not: a backup system, a CDN, or a substitute for off-site UpdraftPlus backups — SSL and backups.

Persistent copy, not a fantasy clone button

Expect roughly:

  1. A staging environment tied to the site on Pro+.
  2. File deploys to staging as you iterate.
  3. A separate database (or the need to import into one) when you want real posts/products.
  4. URL differences: staging hostname ≠ production hostname.

To rehearse with production content:

  1. Take a fresh production backup (files + DB).
  2. Deploy matching files to staging.
  3. Import the DB into staging’s database.
  4. Run serialized-safe search-replace from production URL to staging URL — same discipline as migrations.
  5. Update wp-config.php on staging for staging DB credentials.
  6. Disable or redirect emails (SMTP to a blackhole or staging flag) so clients do not get duplicate “order” mail.
  7. Test. Then plan production apply separately — do not “sync back” casually without a plan.

If you skip the DB copy, staging still helps for theme file work and empty-install plugin smoke tests — just know you are not seeing real content edge cases.

Cron, caches, and search engines

On staging:

  • Discourage indexing (plugin or headers) so Google does not treat staging as duplicate production.
  • Cache plugins: fine to test; purge often; remember logged-in and cart bypasses — Woo, membership.
  • Cron: Pro+ has real cron capability for production needs; keep staging schedules from spamming — managed features.

Deploy history versus staging

Deploy history restores previous file releases on an environment. Staging is a parallel environment. Use both: history for “undo that zip,” staging for “try that zip safely.” Neither replaces MySQL backups.

Agency workflow

Agencies should standardize: update on staging weekly, client UAT link, then production. Document that DB clone is a procedure, not a mythic button — agencies. GitHub connections are per-person; staging deploys follow the same constraint.

Freelancers on Pro get staging without needing Business — freelancers.

Promoting changes to production

There is no universal “push staging to prod” that always merges databases correctly (content written on production while you staged will conflict). Common patterns:

  • Code/theme/plugin only: deploy the same file release to production after staging passes; run updates in wp-admin on production after backup.
  • Content redesign: maintain a change list; re-apply carefully; or schedule a freeze window and copy DB directionally with eyes open.

If your process needs sophisticated content sync tooling, that tooling is yours to run. We will not invent it in marketing copy.

Domain names and HTTPS

Staging has its own HTTPS URL. Do not point the public brand domain at staging. When production uses a custom domain, keep siteurl/home correct there — custom domain. After importing prod DB to staging, rewrite URLs or staging will redirect to production (the classic footgun).

Security on staging

Staging often has weaker passwords and copies of real user emails. Protect it:

  • Strong access controls
  • Noindex
  • Anonymize data for client demos when appropriate
  • Do not leave staging wide open with production customer PII forever

Security baseline: secure.

When you do not need staging

Personal blog with two plugins: monthly backup + careful updates may suffice — blog. The day you install a page builder and Woo, staging starts paying rent.

What we still do not include

No Softaculous, no auto updates, no email, no built-in CDN, no cPanel, no nonprofit coupon, short trial ~1 day. Managed infrastructure, not concierge — what is managed.

Data hygiene when cloning production

Production databases contain real emails, orders, and sometimes unpublished drafts. On staging:

  • Consider a plugin or script to anonymize personal data for long-lived staging
  • Turn off live payment gateways; use test keys
  • Redirect outbound mail or use a mail catcher so members do not get “your order” duplicates
  • Wipe staging periodically and re-import rather than treating it as a second production

Agencies: put PII handling for staging in your internal wiki — agencies.

Content freeze windows

When redesigning on staging with a DB copy, production writers may keep publishing. Plan a freeze or accept that promoting design files without re-merging content will drop posts. There is no universal merge button for WordPress MySQL. Communicate the freeze in Slack before you start.

Plugin license keys on staging

Some premium plugins count staging as a site against activation limits. Use the vendor’s staging-license rules. Hosting cannot invent activations. Keep license keys out of public git; env vars help — setup.

Smoke-test script worth repeating

Every staging cycle: home, one deep page, wp-admin login, form submit to a test inbox, one Woo path if applicable, one membership path if applicable, PHP log quiet. Fifteen minutes now beats a weekend outage — how to launch for production parallels.

Naming and bookmarks

Call staging staging in your browser bookmarks. Clients clicking a staging link from an old Slack thread after cutover is a classic support ticket. Expire UAT links. Prefer password protection on staging when your toolset allows.

Treat staging credentials as production-sensitive when the database holds real customer data.

Staging without the “clone everything” myth

Pro ($30) and higher include staging. Treat it as a rehearsal room, not a magic twin. Files can be staged; content and settings live in MySQL — copy the database when you need real pages, orders, or builder data. Skipping the DB copy is how people “test” an empty theme and still break production later.

Workflow: backup production, copy files + DB to staging, update plugins there, click through as a subscriber and as an admin, then repeat carefully on production. We do not auto-update plugins on either environment. Deploy history on production restores files if a push goes wrong; it will not un-migrate a bad database edit.

DNS and URLs on staging

Keep staging on its hostname; do not point your public apex at staging. Search-replace tools must understand serialized PHP data when URLs change. After experiments, do not leave staging indexed — discourage crawlers. Custom domain certs still follow DNS verification on whatever hostname you attach — custom domain.

FAQ

Is staging available on Starter?

No. Upgrade to Pro or higher.

Does staging automatically stay in sync with production?

No. Persistent means it persists — including drift. Re-copy DB when you need fresh production content.

Can I use staging as my only backup?

No. Take off-site backups. Staging can be overwritten by your own tests.

Why does staging redirect to my live site?

Imported database still has production siteurl/home. Search-replace to the staging URL.

Do you offer one-click push to production?

Not as a full content-aware magic button in this product story. Deploy files deliberately; handle DB with care.