Before the switch
**Every form, submitted for real.** Not previewed — submitted, from a phone, and confirmed to arrive in the inbox that a human actually reads. Test the failure case too: a form that silently drops submissions looks identical to one that works. It is the most expensive bug in this business precisely because it is invisible.
**The redirect map, loaded and spot-checked.** Take twenty old URLs at random, including the ones that earn, and confirm each lands where it should. Twenty is enough to find a systematic mistake, which is the only kind worth catching before launch.
**Metadata on every page.** Titles and descriptions that are distinct and describe the page. Bulk-generated ones are how a new site launches with forty pages called “Home | Company”.
**The mobile pass, on a real device.** Not a resized browser window. Your own phone, on mobile data, from a cold cache.
On the day
Confirm the site answers on one host only. If both `example.com` and `www.example.com` return 200, search engines see two sites and split everything between them. One redirects to the other, permanently — this is the mistake we made on our own domain and only caught in Search Console weeks later.
Check `robots.txt` is not still blocking everything. Staging sites are blocked on purpose and the block travels to production more often than anyone admits.
Submit the sitemap in Search Console, and confirm the page count matches what you expect. A sitemap listing fifty pages on a site with eighty is a registry problem worth finding on day one.
Confirm analytics is recording, by loading the site yourself and watching it appear in real time. “We installed the tag” and “the tag is firing” are different statements.
The fortnight after
Watch the 404 report daily. Every URL that appears is a line missing from the redirect map, and each is cheap to fix in week one and expensive to notice in month three.
Expect a ranking wobble and do not react to it. Google recrawls and reassigns over two to six weeks for a small site, and the team that has not been warned will read week two as a disaster — moving without falling is the fuller version.
Check that a lead actually reaches a person. Not the form, which you tested — the whole chain, including whatever routes it onward. Forms deliver to systems that were configured months earlier by someone who has since changed a setting.
What not to do on launch day
Do not launch on a Friday. Not superstition: the two people who can fix a problem are least available for the next sixty hours, and every launch has one problem.
Do not change three things at once when something looks wrong. Change one, wait, look again. Compound changes make the cause unfindable, and most launch-day panics resolve on their own within an hour.
And do not turn the old site off. Keep it reachable somewhere you can still read it — the day you need to check what a page used to say is the day after you deleted it. That is also the difference between a handover that works and one that does not.
Questions we get asked
What should I check before launching a website?
Submit every form for real from a phone and confirm arrival, spot-check twenty redirects including the pages that earn, confirm every page has a distinct title and description, and view the site on a real device over mobile data.
What goes wrong most often at launch?
Redirects, forms and analytics — none of which are visible on the page. A form that silently drops submissions is the most expensive, because it looks exactly like one that works and nobody discovers it until enquiries have already been lost.
How long after launch should I watch for problems?
Check the 404 report daily for two weeks — each entry is a missing redirect, cheap to fix immediately and expensive to notice later. Expect a ranking wobble for two to six weeks and do not react to it; reacting is what prolongs it.