Relaunch day checklist: what to check in the first hour

The first hour after a website relaunch is when the faults that cost the most are cheapest to fix. A staging noindex found at minute ten costs nothing. The same noindex found three weeks later, when organic enquiries have dried up, costs three weeks of buyers and a slow recovery. This checklist covers what to test on the live site in that first hour, how to test it, and who should own each check.

It assumes the preparation in the website relaunch runbook is done: the redirect map is built and tested on staging, the production robots.txt is written, and the list of pages where noindex will be removed is ready. For the content and marketing assets around a launch, the launch day asset checklist covers a different set of items.

The first hour checklist

Run these checks in the order listed, because the early ones decide whether the later ones mean anything. Owners below are roles; replace them with names before the day.

Why the redirect and indexing checks come first

Redirect and indexing checks come first because they decide whether search engines can read the new site at all. If those fail, every other check is measuring a site nobody can find.

Google's site move guidance lists leftover noindex rules, robots.txt blocks, redirects to URLs that do not exist and outdated sitemaps among the common mistakes in a move. All four are invisible from the front end. A visitor sees a working site; Googlebot sees a site that asks not to be indexed. Check the page source and the HTTP headers rather than the rendered page.

For redirects, rerun against the live host the same script used on staging in the runbook, over the whole list rather than a sample. Browsers cache redirects and hide intermediate hops, so a script that records every hop is the reliable method. Pay particular attention to PDF catalogues and datasheets, which industrial sites often move to a new folder and which distributors and tender documents link to directly.

Sitemap, Search Console and Bing

Submit the new sitemap to Google and Bing within the hour, after confirming it lists only new URLs. A sitemap that still lists old URLs sends crawlers to redirects instead of pages.

Google's sitemap documentation asks for fully qualified absolute URLs and says a sitemap can be submitted through the Sitemaps report in Search Console or declared with a Sitemap line in robots.txt. Do both. Keep the old sitemap available as well: Google's site move guide says to submit both, and that pages indexed from the old sitemap should drop to zero over time.

In Bing Webmaster Tools, submit the same sitemap. If the site was added to Bing by importing it from Search Console, its sitemaps came across with it, but check that the new sitemap is listed rather than only the old one. If the site supports IndexNow, the IndexNow documentation says URLs submitted to one participating search engine are shared with the others, which makes it a quick way to notify several engines of the changed URLs at once.

Enquiry forms, tested end to end

An enquiry form is tested end to end when a message submitted on the live site arrives in the inbox sales reads, with every field intact. Seeing a thank-you page is not a test, because the page can appear while the email fails.

Redesigns often change how forms send mail: a new script, a new sending address, a new spam filter on the receiving side. Submit from every form, including the quote form on product pages, and check that the product name, quantity, phone number and email all arrive. Reply to the test enquiry from the sales inbox to confirm the reply-to address is the buyer's, not the website's. If the form also writes to a CRM, check the record appears there. SEOtop10's guide to building a quote form that gets enquiries covers the form design itself.

Cache purge and page speed

Purge every cache layer before running the final checks, or the checks will be reading the old site. A CDN or server cache can keep serving the old robots.txt, old templates or old redirects for hours after deployment.

After the purge, load the homepage and two product pages in a private window on a phone and confirm they load quickly and look right. A relaunch is a common moment for page weight to rise, from new hero images, sliders and scripts. For a wider look at the causes of slow pages and what to do about them, EbizIndia's guide to website performance improvement is useful further reading.

The rollback plan

A rollback plan is a written agreement, made before switchover, on what failure triggers a return to the old site, who decides, and how the return is done. It exists so that the decision is quick and not argued over at the worst moment.

Write three things down. The triggers: for example, enquiry forms not delivering with no fix in sight, server errors across the site, or redirects failing for a whole section. The decision maker: one person, reachable for the whole first day. The method: restoring the previous deployment or pointing DNS back to the old host, with the old site kept intact and running until the new one has settled. Google's guide to moving hosting notes that old infrastructure can be shut down once traffic to it reaches zero, so keep it running until then.

After the first hour

Once the first hour checks pass, the work moves from testing to watching. Check server logs for 404s and errors at the end of the day, look at the page indexing report in Search Console the next morning, and compare enquiries received each day of the first week with the same days a year earlier. The reasons to treat the whole switchover as a launch, with an owner and a measurement plan, are set out in a website relaunch is a launch.