How to Launch a Website Migration Without SEO Disasters: Noindex and GTM Gated on the Production Hostname
The staging site must stay invisible to Google and silent in analytics until the DNS flip. Instead of a launch-day checklist of things to remember, the agent made the production hostname itself the switch.
What was getting in the way.
Every website cutover carries two time bombs. Forget to remove the staging noindex at launch and the new site quietly falls out of Google. Let staging load production analytics early and weeks of test traffic pollute the client's data. The usual defense is a launch-day checklist, which fails exactly when launches get hectic. And the flips are coupled to DNS propagation, which does not happen at a single clean moment anyone can act on.
Context
A client cutting a large site over to a new platform with their search rankings and analytics continuity at stake. The pattern applies to any migration: if a launch step can be expressed as code gated on the production hostname, it should be.
How the work runs.
- 01
Gate noindex on the hostname.
A runtime check adds the noindex tag on every staging and preview hostname and removes it only when the page is served on the production domain. The DNS flip itself disables it; there is no delete-at-launch task.
- 02
Gate analytics the same way.
Google Tag Manager loads only on the production hostnames, so staging traffic never reaches the client's analytics, and launch needs no tag change.
- 03
Unit-test the host predicate.
The hostname check is tested against production hosts, www, preview domains, and platform hostnames, because a safeguard that misfires on an edge case is worse than a checklist.
- 04
Match the live site's redirect behavior before cutover.
The predecessor site 301s www to the root domain with paths preserved; the new stack was verified to do exactly the same, deep links included, before DNS moved.
- 05
Script the rest of the window.
TTL lowered 48 hours ahead, cutover checklist issued with owner per item, and cache warming planned for the flip, so the remaining human steps are few and named.
Evidence from the workflow.
Each system has a role.
the actual switch (the flip is the launch action)
DNS
hosting the gated runtime checks on staging and production hostnames
Lovable
gated so analytics only sees production traffic
Google Tag Manager
record of truth for the host predicate the safeguards depend on
Git + unit tests
Why this is Coworker.
Takes assignments and reports back. You hand it work, it prepares and returns a result.
- 01
All safeguards live in version control and went through the normal deploy pipeline. Live checks against the predecessor site are read-only. The DNS flip itself remains a human action on the client side, by design.
Impact / Outcomes
Two classic launch failures (shipped noindex, polluted analytics) became structurally impossible instead of procedurally avoided.
The hostname predicate shipped with unit tests covering production, www, preview, and platform hosts, so the safeguard itself was verified, not assumed.
Redirect parity with the live predecessor site (www to root, paths preserved) was confirmed by live checks before cutover, not discovered after.
The launch-day checklist shrank to the steps that genuinely need humans, each with an owner and a lowered-TTL window.
Find where a workflow like this fits.
Start with the systems, work, constraints, and authority already present in your operation.