Skip to main content
Rehearsal area on the left, live presentation on stage on the right
Staging = rehearsal, Production = showtime

When a staging website is boring, predictable, and locked down, marketing moves faster and the live site stays safe.

If it’s confusing, inconvenient, or full of half-baked work, people quit using it and mistakes are more likely to end up on your live site.

Staging for marketing sites: keep it simple!

Quick note: This is for marketing websites, not web applications that may contain personally identifiable information (PII). If you have strict approval workflows or operate in a regulated industry, your needs will be different. I typically run my own VPSs, but if you are on a managed platform, they may already have staging tools you can take advantage of.

Two common reactions to staging websites

In my experience, I’ve noticed that people fall into one of two camps when it comes to staging websites.

Anxious Andy
Andy treats staging like a bomb. He tiptoes around, scared he might “break something.” He doesn’t realize breaking stuff in staging is the whole point. Staging is supposed to be the safe place to experiment and practice.

Burned-out Brianna
Brianna has lived through staging sites that are inconvenient to use or full of half-baked work. Eventually she quits using staging and YOLOs it straight to the live site because staging feels like friction.

Both behaviors come from the same issue: staging is overcomplicated and underexplained.

My staging philosophy: two simple rules

1. Password protect staging (Basic Auth)

Put a simple username and password on the staging site using Basic Auth. It is a standard feature on every server and hosting platform, and it keeps staging private without adding friction.

Basic auth screen asking for user/pass
Basic auth screen asking for user/pass

I do not generate a complex password for staging. I usually set it to something obvious like:

brandname / brandname

The goal is not to secure sensitive data. The goal is to keep Google and random people out.
This is a marketing website, not a customer portal.

Yes, you should still use noindex, remove staging from your sitemap, and avoid linking to it publicly — that is all good practice. But relying only on those settings is fragile. Metadata, robots tags, and sitemaps are easy to forget, especially when staging is supposed to behave like production. Basic Auth is the simple forcing function: everyone knows staging is gated.

Bonus: QA tools like Screaming Frog, Sitebulb, and others can pass Basic Auth credentials, so you can still crawl staging without exposing it publicly.

Basic Auth keeps staging private, predictable, and easy to think about.

2. Do not push staging to production

Code flows through staging to production. Content does not.

Staging is a rehearsal space. Its job is to help you preview pages, test forms with fake data, and make sure things look right before publishing on the live site.

You can pull production data into staging when it helps you test layouts or large collections. I often move content in a clockwise flow: production → local → staging. That gives you enough real data to validate without risking anything.

What I avoid is pushing staging into production. That is where things go wrong. Staging can contain half-finished drafts or temporary content. If you push staging into production, you can overwrite the live site or accidentally trigger CRM workflows. Production should remain the single source of truth.

Staging is where you practice. Production is where you publish.

⚠️
Warning for devs: Keep staging content clean (this includes code comments). Jokes or profanity have a way of ending up on the live site. Ask me how I know.

If you use managed hosting (WP Engine, Vercel, etc.)

If you are on a managed hosting platform, check their docs. Most of them include staging environments as part of what you are paying for. They usually offer one-click staging creation, preview builds, and a workflow that is already wired into their platform.

Use those tools if they fit your flow.

You are paying for:

  • built-in staging environments
  • previews for pull requests
  • automated deployments

So take advantage of them.

I typically run my own VPSs and configure staging myself, but if your platform provides staging, start there and keep it simple.

When in Rome....

The point of staging

Staging gives marketers a safe place to practice and gives developers a place to validate changes without touching the live site. It does not need to be perfect or identical to production, it just needs to be predictable.

Keep staging boring. Keep production sacred.