What happens in launch week and the month after?

# What happens in launch week and the month after?

Less than you'd expect on the day, and more than you'd expect in the month after. Launch is a DNS change on a site that has been complete on staging for weeks: the redirects are tested, the forms have been submitted, the analytics gate has been watched with the network panel open. What follows is thirty days of reading reports, because the things a migration gets wrong show up in Search Console and in form receipts, not on launch day. The old host stays alive, quietly, until those reports have been clean for a month.

This chapter is the launch checklist from the starter's MIGRATION.md with the reasons attached. If you only read one section, read the last one: the one about what you're watching for afterwards.

What has to be true before launch week starts?

The site is finished on staging and three checks have passed there, so launch week is configuration, not building.

• The URL parity check exits clean against the preview. The starter's check-url-parity script reads the old site's sitemap and requests every path on the new host; anything that isn't a 200 or a permanent redirect fails it. This is the launch gate from chapter 4. Run it until it passes, then don't touch the redirect map again without running it again.
• Every form has been submitted with test data and landed where it should, and nowhere else, per chapter 5.
• Staging sign-off is in writing from everyone who had to approve, per chapter 8, including the compliance sign-off and the content owner's confirmation of the redirect map.

If any of those is still open, the launch date moves. A launch with a known-failing parity check is a decision to lose rankings on purpose.

What gets configured in launch week?

Seven settings, each of which quietly breaks something if it's wrong, which is why they're a list and not a memory.

• The production site URL. Canonicals, the sitemap, and every piece of structured data derive from one setting. If it still points at the preview domain, every page tells search engines its real address is somewhere else.
• The form receiver. Pointed at the real destination, with a test submission confirmed at the receiving end, and the receiver covered by a business associate agreement if it could ever see clinical text.
• Real bot-protection keys on the forms. The starter ships with test keys that always pass; leaving them in production means the forms are open to anything.
• The analytics id, and then the check that matters: a fresh browser profile, the network panel open, and nothing third-party loads before consent is given.
• The CMS's allowed origins include the production domain, or the Studio and live preview stop working the moment DNS changes.
• The revalidation webhook points at the production domain with its secret set, so publishing in the CMS updates the site in seconds instead of on the next deploy. The symptom when this is missed is an editor who publishes, sees nothing change, and stops trusting the tool.
• robots.txt and the sitemap render on the preview domain and list the right URLs, with no leftover "disallow everything" rule from staging.

None of these takes more than a few minutes. All of them have taken sites down for a day when skipped.

What happens on launch day?

Point DNS, wait for the certificate, run the parity check against the live domain, submit the sitemap, spot-check the rich results, and send a form from a phone.

The DNS change is the launch. The person who makes it was named in week one; if it's me, that authorization was in writing. Certificates on modern hosts issue within minutes; until then some visitors see a warning, which is why the change happens early on a quiet day, not Friday afternoon.

Then the same parity check that gated the launch runs against the live domain, because the CDN and host configuration can differ from the preview's. Then the new sitemap goes into Search Console, and the old property stays open: its data is the baseline for the next month's comparison. Then a spot check with the rich results test on one provider page, one location page, one FAQ page, and one post, because the structured data that earns a clinic its map result and a physician their profile card is the easiest thing to lose silently.

Last, a form submitted from a phone, on cellular, not the office network. It exercises the consent banner, the bot check, the receiver, and the notification email in one go, on the device most patients actually use.

The old site stays reachable at a private address. Nobody links to it; it's there so a missed asset can be found and copied over in the first week rather than reconstructed.

What are you watching in the week after?

Four things, daily for the first week and then weekly: 404s in Search Console, impressions against the baseline, form receipts, and Core Web Vitals as real traffic arrives.

• Coverage report, 404s. Each one is a URL the inventory missed, and each one becomes a row in the redirect map the same day. The first week is when the long tail of old URLs shows up: links from newsletters, PDFs, partner sites, bookmarks. Expect a handful. Expect zero after the second week.
• Impressions, week over week. A dip of 10 to 20 percent for a couple of weeks is normal; the engine is re-crawling and re-evaluating every page at its new address. A cliff, meaning half or more, is a redirect problem or a canonical pointing at the wrong domain, and it's found by reading the top pages report against the old property.
• Form receipts. Not "did the form work on launch day" but "is a submission arriving at the receiver every day it used to". A form that silently posts into nothing is the failure that costs a clinic patients without anyone noticing.
• Core Web Vitals in field data, which only exists once real visitors arrive. The lab numbers from CI told you the site could be fast; the field numbers tell you whether it is for patients on phones.

The weekly update from chapter 8 continues through this period, with the same four headings. Most of what's in it is "nothing to report", and that's the point of writing it down.

When do you retire the old host?

After thirty days of clean reports, and the redirects live for much longer than that.

Thirty days covers a full crawl cycle for most sites and at least one round of every scheduled email and campaign that might link to an old URL. After that, the old host is switched off. What isn't switched off is the redirect map: it stays in the new site indefinitely, because the links that point at old URLs are on other people's sites and they don't get updated. A redirect map that's removed after a year is how the second migration loses the traffic the first one preserved.

What does done look like?

Sixty days after launch, per chapter 8: the site is stable, the team is publishing without asking for help, search traffic has settled at or above the pre-migration baseline, and every form has a receipt trail. That's the end of hypercare. Anything after that is upkeep, which is chapter 10.

Checklist

The month after - [ ] 404s reviewed daily for a week, weekly after; each one added to the redirect map - [ ] Impressions compared to the baseline weekly; a cliff investigated the same day - [ ] Form receipts confirmed daily for a week - [ ] Core Web Vitals field data reviewed once traffic arrives - [ ] Old host retired after 30 clean days; redirects kept indefinitely Companion code in the Healthcare Sanity Starter: docs/MIGRATION.md (this checklist, in the repo), scripts/check-url-parity.ts (the launch gate).