Why launch day matters more than you think
A new website is rarely just a redesign. It usually involves a new CMS, new URLs, new page templates, new heading structures, and a different image strategy. Each of those changes a signal that Google has been reading for years. If the new site looks similar but reads differently to a crawler, rankings move. The point of the pre-launch checklist is to make sure the move is intentional. Treat this as part of any website migration workflow.
Two patterns often emerge. A recruitment business launching a multilingual replacement site discovers two weeks after launch that hreflang tags point at staging URLs and Google has been serving the wrong language page in three markets. A B2B services firm goes live with a beautiful new design but kept the old CMS's auto-generated meta titles, which now read Page | New Brand on every page. Both fixable. Neither should have happened on day one.
1. Crawl and compare. This is the foundation.
Run a full Screaming Frog crawl of the staging site. If the new site replaces an existing one, also crawl the current live site. Export both. Build a URL map. Every URL on the old site has a destination on the new site, and that destination is one of three things:
- The same URL (a like-for-like page)
- A 301 redirect to a different URL (renamed or restructured)
- A 410 (deliberately removed and not replaced)
If a URL does not fit any of those three buckets, a gap exists where ranking value disappears. Spot-check the redirect file by hand. Bulk redirect rules almost always have edge-case misses, usually around trailing slashes, query strings, or pages whose old slug does not follow the convention. Look out for redirect chains in particular; they bleed signal at every hop.
2. Indexing controls. The single most common launch-day disaster.
Check the robots.txt on staging. Does it still say Disallow: / from when developers wanted Google to leave the staging site alone? If yes, that line must come off before launch, or the new live site disappears from Google overnight.
Check the X-Robots-Tag HTTP header on the new server, especially if using a CDN that has been tested in noindex mode. Sample the meta robots tags on the top 20 URLs. Canonical tags must point to the new live URLs, not the staging URLs. This is the gotcha that hits multilingual sites hardest. Generate a fresh sitemap.xml from the new URL set. Submit it to Google Search Console as the first thing to do after DNS switches, not later.
3. Content quality baseline. Don't lose what was already working.
One H1 per page. Not three. Not zero. One. Templates in the new CMS often inject an H1 from the page title and then the page content adds another. Meta titles and meta descriptions on every page, not just the home page. If the new CMS auto-generates fallbacks, audit them: About Us | Brand is fine; page-12345 | Brand is not.
Image alt text on the in-content images. Decorative images can skip alt. Anything that conveys information needs it. Schema markup: Organization schema on the root domain, Article schema on blog posts, LocalBusiness schema if there is a physical location. If the old site had schema and the new one does not, a ranking signal has quietly been removed. Validate everything in Google's Rich Results Test before launch.
4. Performance baseline. Measure before regression.
Run PageSpeed Insights on the home page plus five key templates (a service page, a blog post, the about page, the contact page, and one product or case study). Capture the numbers, specifically Largest Contentful Paint and Cumulative Layout Shift on mobile. The point is not to hit perfect scores before launch. The point is to have the baseline written down, so when someone says the site feels slower two weeks after launch, whether it actually is can be shown.
5. Launch-day actions. The last 30 minutes.
Once DNS has switched and the new site is live, do these in order, immediately:
- Submit the new sitemap to Google Search Console. Submit it to Bing Webmaster Tools too if there is any presence there.
- Verify GA4 is firing on live, not still pointed at staging. Open the GA4 real-time view, load a few pages, watch them appear.
- Verify Google Tag Manager is loading on live. Load the page, open the Tag Assistant browser extension, confirm the container is active.
- Pull a fresh Screaming Frog crawl of the live site 24 hours after launch. Compare to the staging crawl. Any unexpected differences are the things to look at first.
Where to start
If you are three weeks from launch and reading this in a slight panic: start with section 2 (indexing controls). Half of all launch-day disasters are a robots.txt or canonical tag that did not get changed. Everything else can be tidied in the week after launch. Indexing controls cannot.
If you are at the start of a new build with time to do this properly, get an SEO into the information architecture stage, before the page wireframes are signed off. The cost of fixing structural decisions after the build is finished is roughly 10x the cost of getting them right in the brief. If you would like BrisTechTonic to run the pre-launch audit or sit in on the IA stage, book a discovery call.
Chris McDowell is founder of BrisTechTonic, an SEO consultancy in Bristol.