Launch day gets all the attention. The client sees the new site, everyone is pleased, the invoice goes out. Then the developer moves on to the next project, and the two days that decide whether the launch actually worked pass without anyone watching.
Most of the problems I get called about on a site someone else built are not design disagreements. They are things that broke silently in the first couple of days after going live and were never noticed, because the checks that would have caught them are not part of most people's launch routine.
Here is the routine I use, in the order the failures tend to appear.
Hour zero: confirm the thing you are looking at is the thing visitors get
The single most common launch-day mistake is checking the site in the browser you have been building in. You have cached assets, a logged-in session, possibly a hosts file entry pointing at the old server. What you are looking at is not what a stranger sees.
Open the live URL in a private window on a device that has never seen the site. This takes ten seconds and catches an embarrassing proportion of everything below.
While you are there, check that only one version of the site is reachable. The naked domain and the www version should not both serve content: one should redirect to the other, in a single hop, and every internal link should point at the winner. Split them and you have divided your own search signals between two addresses that each look like a partial copy of the other.
Hour one: make sure you have not blocked the search engines
Staging sites are usually blocked from indexing, and the block frequently ships to production because it is set in an environment variable, a CMS toggle, or a robots file that nobody thought to change.
Check three things. The robots file should not disallow everything. No page should carry a noindex directive that is not meant to. And the canonical tags should point at the live domain rather than the staging one, which is the version of this mistake that survives longest because it looks fine to a human and quietly tells search engines the real page lives somewhere else.
Then submit the sitemap and request indexing on the homepage. This is also the moment to confirm the sitemap lists live URLs rather than staging ones.
Hour two: test the money paths on the real site
Not on staging, where the payment provider is in test mode and the mail service is intercepted. On production, as a member of the public would.
Send a message through the contact form and confirm it arrives somewhere a human reads, then reply to it and confirm the reply reaches the sender. Complete a booking or a purchase and check that both parties get their confirmations. Ring the phone number as written on the page rather than the one you have in your contacts.
Email is where launches quietly fail. A new domain sending its first messages, often through a new provider, is exactly the profile spam filters distrust. Confirm the authentication records are in place and then confirm delivery empirically, because the records being correct and the message arriving are two different claims.
Hours three to six: the redirects, if this is a rebuild
If the site replaced an existing one, every URL that had value needs to land somewhere sensible. Not all of them on the homepage: that is technically a redirect and practically a dead end, and search engines increasingly treat a homepage catch-all as a soft error.
Export the old URL list from analytics or the search console, map each meaningful one to its closest equivalent, and test them in bulk rather than by hand. What you are looking for is a single hop to a page that answers the same question, with no chains and no loops.
Missing redirects are the most expensive launch error there is, because the damage compounds daily and the recovery takes months. It is also the one nobody notices immediately, since the new site looks perfect to anyone who visits the homepage.
Day two: watch for what only appears under real traffic
Some faults need strangers to surface them. Check the error logs for anything appearing repeatedly. Check the search console for crawl errors, which start arriving within a day or so and are the fastest external signal that something is structurally wrong.
Look at the site on a real phone on mobile data rather than on a simulated viewport on office wifi. Field performance and lab performance are different measurements, and the gap between them is where the real experience lives.
Finally, put the recurring checks in place while you still remember what matters: uptime monitoring, certificate expiry alerting, and a scheduled test that submits the real contact form and verifies the message arrived. That last one is unglamorous and has caught more silent failures for us than everything else combined, which is part of the standard maintenance routine on every site we look after.
The checklist
- The live URL renders correctly in a clean private window on an unfamiliar device
- Only one of www and non-www serves content, the other redirects in one hop
- No stray noindex, no blanket robots disallow, canonicals point at production
- Sitemap submitted and listing live URLs
- Contact form delivers to a monitored inbox, and replies reach the sender
- Transactional email is authenticated and confirmed arriving, not merely configured
- Old URLs redirect individually to their closest equivalent, no homepage catch-all
- Error logs and crawl errors reviewed on day two, under real traffic
- Uptime, certificate and form monitoring scheduled before you move on
None of this is difficult and all of it is boring, which is precisely why it gets skipped. A launch is not the moment the site becomes visible. It is the moment it starts being load-bearing, and the two days afterwards are when you find out whether it holds.
Jack Warner is the founder of WebDev Wales, a web development studio in Glynneath, South Wales, building sites for small and medium businesses with Next.js.
Top comments (0)