Preview URLs and staging sites are both useful when you need to work with WordPress without treating the public production site as your test environment. They are not, however, the same thing.
A preview URL is primarily an alternative way to reach a site before its normal public hostname is ready or appropriate to use. A staging site is a separate working copy of an existing site, with its own files and database, intended for changes that should not happen directly on production.
Preview changes how you reach a site. Staging changes which copy of the site you are working on.
Preview, staging and production at a glance
What is a WordPress preview URL?
A preview URL gives you another hostname through which to reach a WordPress installation. This is useful when a new site has been created but its real domain still points elsewhere, during a migration before DNS cutover, or when you simply need to inspect the destination without changing public DNS.
The important distinction is that a preview URL does not inherently create another copy of WordPress. You can be viewing the same files and database that will later serve the production hostname.
Preview URLs are useful for
- Checking a newly provisioned site before its real domain is pointed at the server.
- Validating a migration destination before cutover.
- Giving an authorised user a temporary route to a site while DNS is being prepared.
- Testing whether the destination application and hosting stack are responding correctly.
Because the underlying site may be the real destination, a preview URL should not be treated as permission to make risky changes without backups or another recovery path.
What is a WordPress staging site?
A staging site is a separate working environment derived from a production site. A useful staging implementation isolates the files and database so development work does not modify the live application while it is being tested.
That makes staging appropriate for plugin or theme changes, PHP compatibility work, significant content or layout changes, troubleshooting experiments and other work that should be proven before it reaches visitors.
A staging copy should be isolated
Copying a production site is only the beginning. A staging environment should also be prevented from behaving like production in ways that can cause side effects.
- Outgoing mail: staging should not send real customer notifications, password emails, order messages or contact-form responses.
- WP-Cron: scheduled jobs should not independently run from both production and staging unless that behaviour is deliberately required.
- Search indexing: staging should discourage indexing so a temporary copy does not compete with the real site in search results.
- Page cache: disabling full-page cache by default makes development changes easier to observe and avoids carrying production cache assumptions into the working copy.
Files and database both matter
WordPress is not just a directory of PHP files. Themes, plugins and uploads live in the filesystem, while posts, pages, options, users, plugin configuration and much application state live in the database.
A staging workflow therefore needs to understand both. Copying only the files can leave the staging application attached to the wrong data. Copying only the database does not reproduce the code and media that the database expects.
Refreshing staging from production
Staging environments drift over time. Production receives new content, plugin updates, configuration changes and user activity while staging accumulates its own experiments.
Refreshing staging from production deliberately replaces the working copy with a newer representation of the live site. This is useful before beginning a new piece of work, but it is destructive to changes that exist only in staging. A good workflow makes that consequence explicit rather than treating refresh as a harmless synchronisation button.
Take a snapshot before risky work
Isolation reduces risk to production, but it does not make staging disposable work unimportant. Before a large plugin update, code deployment or database-affecting experiment, a staging snapshot provides a quick way back to a known state if the test itself goes wrong.
The same principle applies even more strongly to production. A deployment process should establish the recovery point before making the risky change, not after discovering that it failed.
What does “push staging to production” really mean?
Pushing staging back is more complicated than creating staging because production may have continued changing while development work was underway.
A full replacement can be appropriate for a brochure site that was deliberately frozen while a redesign was completed. It can be dangerous for an active store, membership site or publishing workflow where new orders, accounts, comments or content have appeared in production since staging was created.
The right deployment method depends on what changed. Code can often be deployed independently. Selected files may be copied safely. Database changes may require a migration or a carefully scoped operation rather than replacing the entire live database.
“Push to production” should describe a controlled deployment decision, not an assumption that the staging database can always overwrite the live one.
DNS and hostnames: why staging sometimes fails before it starts
A staging environment needs a hostname that resolves to the platform serving it. There are several sensible ways to provide one.
A domain can have a wildcard DNS record so generated staging hostnames automatically resolve to the correct server. Where no wildcard exists, the platform can present an explicit hostname and A record for the administrator to create. A hosting platform with its own suitable wildcard hostname can also provide staging addresses under that domain, avoiding changes to the customer’s public DNS for every staging copy.
The important behaviour is predictable discovery: use an existing valid wildcard when available, otherwise explain exactly which DNS record is missing and what needs to be created.
Which one should I use?
Use a preview URL when…
- The site itself is already the copy you want to inspect.
- The real domain has not been pointed at the destination yet.
- You are validating a migration or new deployment before DNS cutover.
- You need temporary access through another hostname rather than a separate development environment.
Use staging when…
- You need to change or test an existing production site safely.
- The work could affect files, the database, plugins, themes or PHP compatibility.
- You want a repeatable refresh, snapshot and deployment workflow.
- You need development safeguards such as mail suppression and indexing protection.
How Webcore approaches preview and staging
Webcore treats preview and staging as separate workflows. Preview provides a way to reach the intended site when its normal hostname is not yet suitable. Staging creates an isolated copy with its own files and database for development and testing.
Staging safety controls suppress outgoing WordPress mail, disable WP-Cron, discourage indexing and disable page cache by default. The workflow supports refreshing staging from live and taking snapshots before risky changes, while production deployment remains a deliberate operation rather than assuming every staging database should replace the live one.
See Managed WordPress Hosting for the managed service, WordPress for Developers & Agencies for staging and deployment workflows, Webcore Panel for the control platform, or Webcore Documentation for product behaviour and operating guidance.