A production website is the environment the public uses: the real domain, live content, and live integrations. A staging website is a separate environment where you rehearse changes before they reach production. Staging exists so a broken layout or a test form does not become the company’s homepage.
Hosting size and server type are a different decision, covered in shared hosting vs VPS. This page is about the two environments and the gap between them.
What should differ
| Item | Staging | Production |
|---|---|---|
| Audience | Editors and developers | Customers and the public |
| Domain | A private hostname | The public domain |
| Search engines | Blocked from indexing | Indexable, if you want to be found |
| Payments and email | Test keys, mail trapped or redirected | Live keys, real recipients |
| Content | A copy, plus drafts | The approved site |
| Analytics | A separate property or none | The real measurement ID |
Staging should be close to production in software version and PHP or Node runtime. It does not need a copy of every customer email. Prefer scrubbed data. A staging site that emails real clients from a “test” button is not a sandbox.
Protect staging with a password or a network limit. A public staging URL with unfinished prices will be shared.
What a publish step includes
Moving code or content to production is a release, not a hope.
- Note what is changing: template, content, or configuration
- Confirm staging was checked on a phone and a laptop
- Take a backup you could restore, as described in backup restoration testing
- Deploy in a window someone can watch
- Check the public URL, a form, and one deep link after release
- Keep the previous version available until that check passes
Content approval can happen before this technical step. Roles for authors and reviewers are in content publishing workflow.
From staging check to live site
- Change is made only on staging
- Reviewers complete the affected tasks
- Backup and release window are confirmed
- The same change is published to production
- Public pages and forms are checked again
Configuration drift
Staging and production diverge when someone edits production directly “just this once.” The next staging refresh overwrites that fix, or the next release copies an old bug back. If an emergency edit happens on production, copy it back to staging the same day.
Also check environment-specific values: API URLs, payment mode, and “disallow indexing” flags. Shipping a staging robots rule to production will hide the site. Shipping a live payment key into a laptop config file is the opposite mistake.
A practical example
A new enquiry form is built on staging.example.com, which is password-protected and blocked from indexing. Submissions go to a test inbox. After the team submits it on a phone, the release copies the template to production, where submissions go to the sales mailbox. The first live submission is a real internal test, then the team watches the sales inbox. They do not develop the form on the public homepage.
Key takeaways
- Staging is for rehearsal. Production is the public site.
- Separate mail, payments, indexing, and access.
- Publish with a backup and a short live check.
- Copy emergency production fixes back to staging.
FAQ
Is a preview link the same as staging?
A preview of one draft page is useful for wording. Staging is a full environment when the change touches templates, plugins, or integrations. Use staging for those.
Can editors work directly on production?
For a typo in a low-risk page, some teams allow it if revisions exist. For layout, forms, and upgrades, use staging. Know which case you are in.
Should staging use the live database?
A recent copy helps you see real layouts. Strip or replace personal data and disconnect live email and payment. Refresh on a schedule so you are not testing on last year’s content.