By the Brightcode team, a small web development agency in Delhi NCR. Reviewed by Gaurav Khokkar, Founder.

Pointing production DNS feels like progress. It is also the moment you discover the contact form still posts to staging, the sitemap still says localhost, and the client's old WordPress is serving a cached homepage beside your new one.

We treat "ready for DNS" as its own gate. Handover (accounts, secrets, runbooks) comes after. This list is what we run while the site is still on a staging host.

1. Freeze a written launch plan

Before anyone touches nameservers, write four lines somewhere the whole team can see:

## Launch - Staging URL: - Production domain: - Cutover window (IST): - Rollback: revert DNS / redeploy tag ___

If you cannot name the rollback in one sentence, you are not ready.

2. Environment parity (boring, necessary)

Staging should match production for:

  • Node / PHP / Python runtime version
  • Database engine and major version
  • Required extensions and ImageMagick / Sharp / GD
  • Cron or queue workers (even if they run against a copy of the data)

A launch that worked on staging on PHP 8.3 and dies on the host's 8.1 is still a failed launch.

3. Secrets and config: no staging keys in prod

Check .env / host env vars one by one:

  • Payment, SMS, email, and OAuth apps point at live credentials (or a clearly labelled live mode)
  • Debug flags are off (APP_DEBUG, WP_DEBUG display, Next.js expose markers)
  • Staging-only feature flags are disabled
  • Error reporting (Sentry and friends) uses the production project

Rotate anything that was pasted into Slack during build.

4. HTTPS, redirects and the old site

On staging we usually terminate TLS with a temporary hostname. Before DNS:

  • Confirm the production certificate path (Let's Encrypt, Cloudflare, host panel) and who renews it
  • Prepare the redirect map from the old URLs (www/apex, http to https, retired pages to new slugs)
  • Decide what happens to the old host the minute DNS moves: park it, 301 everything, or shut it down

If the old site stays up on the previous IP with no redirects, Google and bookmarks will split traffic for weeks.

5. Forms, mail and spam

Submit every public form on staging with a real inbox you control:

  • Contact, quote, newsletter, careers, checkout test mode if any
  • File uploads, if offered
  • Success and failure states (including mail server rejected)

Check SPF / DKIM / DMARC for the sending domain you will use in production. A pretty form that never arrives is worse than no form.

6. Auth, admins and leftover users

  • Remove staging seed users and shared admin passwords
  • Confirm the client has an owner/admin login that is not yours
  • For WordPress: delete default admin if it exists, kill unused plugins that create users
  • For app builds: confirm role checks on a non-admin account

7. Indexing switches

Search for:

  • noindex meta / X-Robots-Tag
  • WordPress "Discourage search engines from indexing this site"
  • robots.txt with Disallow: / left over from staging
  • Basic auth in front of production (fine for staging, fatal for launch)
  • Hard-coded staging hostnames in sitemap, canonicals, Open Graph URLs, and email templates

We keep staging noindexed on purpose. Production must flip the other way before DNS, or at the same minute, with a Search Console property ready.

8. Backups and a restore drill

Take a fresh backup of staging (code + database + uploads) and restore it once to a throwaway slot. "We have backups" without a restore is a wish, not a plan.

Note where production backups will live after cutover, and who gets the alert if they fail.

9. Analytics, Search Console and pixels

  • GA4 / GTM containers for production (not the staging debug container)
  • Search Console: client as verified owner on the Domain property when possible
  • Ads and Meta pixels only if the client asked for them, firing on the thank-you paths you tested
  • Remove leftover Hotjar / clarity projects that point at the staging hostname

10. Performance smoke test on a production-like build

Run the production build once (not next dev, not wp with debug bar):

  • Homepage, one service page, one blog post, contact, and the heaviest template (shop archive, dashboard)
  • Lighthouse or PageSpeed on mobile as a smoke check, not a trophy hunt
  • Confirm image CDN / cache headers exist for the stack you ship

11. The five-minute click path (human, not CI)

With JS on, cookies accepted, on a phone:

  1. Land on homepage
  2. Open the main service page
  3. Send the contact form
  4. Open a blog post or product
  5. Find phone / WhatsApp / email in the footer

If any step fails, DNS waits.

12. DNS cutover itself

When the checklist is green:

  • Lower TTL ahead of time if the old DNS host allows it
  • Switch records (A/AAAA/CNAME/MX as designed; do not clean up MX by accident)
  • Watch the staging host logs and the new host logs together for 30-60 minutes
  • Recheck forms and HTTPS on the live hostname
  • Submit the production sitemap in Search Console once the property sees the live site

Then do handover (accounts, secrets, runbook), which has its own checklist.

What we deliberately leave out of this list

Content sign-off, legal pages, and brand polish matter, but they are not DNS blockers. If the privacy policy is still draft, you can launch with a clear stub and replace it the same day. If checkout is unfinished, do not launch ecommerce at all. The checklist above is the technical gate: forms, HTTPS, indexing switches, backups, and a rollback you can explain in one sentence.

Also leave handover for later. Domain ownership, Search Console verified owner, and rotating deploy keys belong on the post-launch ownership list, not mixed into "can we flip DNS". Mixing them is how staging checks get skipped under time pressure.

Why we still use a staging URL

Skipping staging to "save a day" usually costs a week of emergency redirects and angry WhatsApp threads. A named staging host, even a simple one, keeps experiments off the domain your client already prints on invoices.

In our website development launches this gate sits right before go-live. For custom web apps we add queue workers, migration order, and a dry-run migrate on a copy of production data, because a bad migration is harder to undo than a bad homepage.

Brightcode is a web development team in Delhi NCR. After launch, we look after sites through managed hosting and care.