Almost every post-launch disaster comes from the same short list. None of it is difficult. It is simply that launch day is busy and nobody owns the checks.
Before you switch anything
Back up the old site completely
Files, database, and an export of the content in a readable form. Store it somewhere that is not the old hosting account, because that account may be cancelled sooner than you expect.
Also record the old site's page titles and descriptions. You will want them if something ranks worse afterwards and you need to compare.
Map every existing URL
This is the step that protects your search visibility, and the one most often skipped.
Export a full list of the old site's pages. Search Console and any crawler will give you this. For each one, decide where it goes on the new site — the equivalent page, the nearest parent, or the homepage as a last resort.
Pay particular attention to pages with inbound links from elsewhere. Those links are hard-won and a 404 discards them.
Check what is currently ranking
Note your top twenty pages by search traffic before launch. If something drops afterwards, you need a baseline to compare against, and Search Console only shows you sixteen months.
On the new site, before going live
Remove the block on search engines
Development sites are normally hidden from search deliberately. Two places it hides: a Disallow: / in robots.txt, and a noindex tag in the page head. Check both. This single oversight has kept new sites invisible for months.
Test every form, and confirm delivery
Not just that the form submits and shows a thank-you message — that the email actually arrives, in an inbox somebody reads, and not in junk. Test from an external address rather than your own network.
If the site sends from your domain, this is also the moment to check your email authentication, covered in SPF, DKIM and DMARC explained. Forms silently landing in spam is a common and expensive launch failure.
Check SSL on every page
Not just the homepage. A single image or script loaded over an insecure connection produces a mixed content warning, and browsers are unforgiving about it.
Install analytics before launch, not after
Analytics and Search Console should be live from the first hour. A fortnight of missing data is a fortnight you cannot compare against later.
Look at it on real devices
An actual phone, an actual tablet, and at least one browser you do not personally use. Simulators miss things, particularly around forms and fixed headers.
Check the boring pages
Privacy policy, cookie notice, terms, company registration details in the footer. These are legal requirements for UK businesses and they are usually the last thing anyone reviews.
Launch day
- Go live at a quiet time — mid-morning midweek beats Friday afternoon, because somebody needs to be available afterwards.
- Confirm the domain is pointing correctly, and check from a device outside your office network.
- Test the redirects. Take ten old URLs, including three deep ones, and confirm each lands somewhere sensible.
- Submit the sitemap in Search Console.
- Submit the new site for indexing on the two or three most important pages.
- Complete a full enquiry or purchase yourself, from a phone, on mobile data.
Traffic lost at launch is almost always recoverable if caught within days. The businesses that never recover are the ones that noticed in month three.
The first fortnight
Watch the 404 report daily. Every 404 with traffic is a redirect you missed, and each one is a two-minute fix while it is still fresh.
Watch Search Console coverage. Pages should be getting indexed. If the count is not climbing after a week, something is blocking it.
Check that enquiries are arriving at the usual rate. A drop is more likely to be a broken form than a drop in interest, and it is worth ruling that out immediately.
Expect a short dip. Rankings commonly wobble for two to four weeks after a move while search engines recrawl. A dip that has not recovered after six weeks is a problem; a dip in week two usually is not.
What to do a month later
Compare traffic and enquiries against the pre-launch baseline. Check page speed on real visitor data rather than a laboratory test — see Core Web Vitals explained. And confirm backups of the new site are running and have been restored once.
Our web development team runs this checklist on every launch and keeps the redirect map as a deliverable rather than a working file. Discuss your requirements if you have a launch coming and would like a second pair of eyes on it.
