# Staging sites and pushing live
Source: https://docs.webgee.com/en/wordpress-cloud/staging-sites









Staging sites let you rebuild, upgrade or experiment without touching a live
site, then promote the result. Applies to all WordPress Cloud packages, which
include a staging allowance separate from the production one.

## What a staging site is [#what-a-staging-site-is]

A staging site lives on `<label>.stg.webgee.space` rather than a domain of your
own. Create one from **Websites** → **Add website** by choosing **Staging
website**. See [Add a website](/en/wordpress-cloud/add-a-website).

<img alt="A staging site overview, showing the STG badge and the Push live button" src="__img0" />

Staging sites carry an **STG** badge throughout the panel and behave like
production sites in almost every respect — same container, same tooling, same
backups.

Two differences matter:

* **No mailboxes.** Email accounts require a production website. The **Emails**
  page reports "No websites exist" if all you have is staging.
* **Not indexed by you.** The `stg.webgee.space` domain is WebGee's, so search
  engine visibility is not yours to control. Do not park a real site there
  long term.

## Push a staging site live [#push-a-staging-site-live]

<img alt="The Push live menu, offering an existing website or a new website" src="__img1" />

Open the staging site and select **Push live**. Two destinations:

* **To an existing website** — overwrite a site you already have.
* **To a new website** — create a production site from this staging copy.

<img alt="The Push staging website live dialog" src="__img2" />

For a new website:

1. Choose the **Package** the production site will consume.
2. Enter the production **Domain**.
3. Leave **Perform a WordPress search and replace** ticked.
4. Select **Push live**.

<Callout type="warn">
  Pushing to an **existing** website replaces that site's files and database.
  Take a [backup](/en/wordpress-cloud/backups-and-restore) of the destination
  first — pushing live is not reversible from the push dialog.
</Callout>

## Why search and replace matters [#why-search-and-replace-matters]

WordPress stores absolute URLs throughout the database — in post content, in
widget configuration, and inside serialised option values. Copying the database
without rewriting them leaves the live site pointing at
`stg.webgee.space` for images, links and redirects.

The search and replace step rewrites those references from the staging domain to
the production domain, handling serialised data correctly. Leave it ticked
unless you have a specific reason not to, and if you untick it, expect to run
`wp search-replace` yourself afterwards.

## After the push [#after-the-push]

Pushing live consumes one production website from your package. Check
**Packages** to confirm the count moved.

Then verify on the production domain:

* The site loads over `https://` with a valid certificate.
* Site URL under **Apps** → **Toolkit** → **General** shows the production
  domain, not the staging one.
* Media files load — broken images are the usual symptom of a skipped search
  and replace.

The staging site is not deleted by the push. Keep it as your next working copy,
or remove it to free the staging slot.

## Related [#related]

* [Add a website](/en/wordpress-cloud/add-a-website)
* [Back up and restore a website](/en/wordpress-cloud/backups-and-restore)
* [Packages and limits](/en/wordpress-cloud/packages-and-limits)
