How to Create a Staging Subdomain for Your Site

A staging subdomain — staging.example.com — lets you test changes on a real URL with real SSL before they hit your live site. This guide sets one up end to end: the DNS record, the web-server config, a certificate, and the crucial step of keeping search engines and the public out.

Step 1: Add the DNS record

Staging can live on the same VPS as production or a separate one. Point the subdomain at whichever server:

• Type: A, Name: staging, Value: 203.0.113.10, TTL: 3600

If it's the same box as production, that's the same IP. If you'd rather alias it, a CNAME to the root works too — see how to set up a CNAME record. The basics of subdomains are covered in subdomains explained.

Verify:

dig +short staging.example.com

Step 2: Configure the web server

Give staging its own server block pointing at a separate app instance or document root, so it's fully isolated from production:

server {
    listen 80;
    server_name staging.example.com;
    root /var/www/staging;

    location / {
        proxy_pass http://127.0.0.1:4000;   # staging app on its own port
        proxy_set_header Host $host;
    }
}

Running staging and production as separate processes on different ports keeps a broken deploy on staging from touching the live site. See how to point a subdomain to a different app or port for the pattern.

nginx -t && systemctl reload nginx

Step 3: Get SSL for the subdomain

Staging deserves HTTPS too, so it behaves like production. Certbot adds a cert for the subdomain in one command:

certbot --nginx -d staging.example.com

Or include it in a wildcard cert if you have many subdomains — free SSL for a custom domain and free SSL certificates with Let's Encrypt cover both.

Step 4: Keep Google and the public out

This is the step people forget. You do not want staging indexed (duplicate content) or crawled. Lock it down:

HTTP basic auth in Nginx:

location / {
    auth_basic "Staging";
    auth_basic_user_file /etc/nginx/.htpasswd;
    proxy_pass http://127.0.0.1:4000;
}

Create the password file:

apt install apache2-utils
htpasswd -c /etc/nginx/.htpasswd staginguser

Also add a blanket robots.txt on staging:

User-agent: *
Disallow: /

Basic auth alone keeps crawlers out (they can't log in), but the robots.txt and an X-Robots-Tag: noindex header are belt-and-braces.

Step 5: Keep staging in sync

Deploy to staging from the same pipeline as production, ideally from a staging branch, so what you test is what you ship. Use a separate database and separate config/secrets so staging never touches live data or sends real emails.

Copy production data safely

Staging is only useful if it resembles production, but you must never let it touch live data or send real emails. A safe refresh routine:

# dump production, restore into the staging database
pg_dump -Fc proddb > /tmp/prod.dump
pg_restore -c -d stagingdb /tmp/prod.dump

Then scrub anything sensitive — replace real customer emails with user+id@example.com, blank out payment tokens, and point the staging app at a fake SMTP (or a catch-all mailbox) so test runs can't email real people. A common horror story is a staging cron firing "your order shipped" emails at real customers because it inherited production's mail config. Route staging mail nowhere, or to a single test inbox.

Automate staging deploys

Wire staging into your pipeline so what you test is exactly what ships. A minimal Git-based flow:

git push origin staging     # triggers a deploy to staging.example.com
# verify, then:
git checkout main && git merge staging && git push origin main

Deploying staging from a staging branch and production from main keeps the two isolated but identical in process. If you run each on its own port behind a reverse proxy — the pattern in how to point a subdomain to a different app or port — a broken staging deploy can never take production down.

Belt-and-braces: keep it out of Google for good

Basic auth stops crawlers, but add two more signals so a stray link never leaks staging into search results:

# in the staging Nginx server block
add_header X-Robots-Tag "noindex, nofollow" always;

Plus the Disallow: / robots.txt from earlier. If staging ever *did* get indexed, the fastest fix is to keep the auth on (so Google can't re-crawl) and request removal in Search Console. Prevention beats cure — lock it down before the first deploy, not after.

FAQ

Should staging be on the same server as production?

It can be, on a separate port and document root, which is cheap and simple. For heavier isolation, use a separate VPS so staging load or crashes never affect live.

How do I stop Google indexing my staging site?

Put it behind HTTP basic auth so crawlers can't reach it, and add a Disallow: / robots.txt plus a noindex header. Auth is the reliable part.

Do I need SSL on a staging subdomain?

Yes if you want it to behave like production — mixed content, cookies and service workers all behave differently over HTTP. A free Let's Encrypt cert takes seconds.

Can I use a wildcard record for staging and other subdomains?

Yes — a * A record covers staging, dev, preview and more at once. See our wildcard subdomain guide for the DNS and SSL details.

Should staging be a subdomain or a separate domain?

A subdomain of your main domain is the standard, cheaper choice — staging.example.com needs only one DNS record and can share a wildcard SSL certificate with your other subdomains. The main reason some teams use a *separate* domain (like example-staging.com) is to guarantee no cookie, cache or SEO bleed between environments, since a subdomain shares the parent's cookie scope. For most projects that's overkill: a subdomain with basic auth, a noindex header and a separate database gives clean isolation. Reach for a distinct domain only if you have a specific reason to fully sever the relationship — for example, testing cookie behaviour that must never touch production's domain. Otherwise, keep it simple with a subdomain.

A staging environment is trivial when you have full root access. Spin up an NVMe VPS from Nxeon and run staging and production side by side, or host both on managed WordPress VPS hosting.