The pre-launch checklist before a site goes live

The pre-launch checklist is a technical, supplier-run verification that happens after client approval and before the domain is actually switched over. It is a separate go/no-go covering things a client would not usually know to check, because they concern how the site is connected to the rest of the internet rather than how it looks or reads.

Why client sign-off is not the same thing

What client testing confirms, and what it never touches

Client user acceptance testing, covered on the client user acceptance testing page, confirms the site does what was agreed from the client’s point of view. None of that testing typically touches DNS configuration, redirect mapping from an old site, analytics tracking installation, or backup arrangements. All of those have nothing to do with whether a page looks or reads correctly. They have everything to do with whether the launch itself goes smoothly. A site can pass client testing completely and still launch badly if this separate checklist is skipped.

The pre-launch checklist: SEO settings, images, alt text and site title, working correctly

Item	Why it matters
DNS records configured correctly	A wrong or incomplete DNS change is the most common cause of a site being unreachable after launch
Redirects from old page addresses	On a redesign, old addresses that are not redirected return errors to anyone with an old bookmark or search result
Analytics and tracking installed	Measurement should start from day one, not be added weeks after launch once someone notices it is missing
SSL certificate active	A site without a valid certificate shows visitors a security warning instead of the homepage
Backups configured	A working backup taken before launch, and a schedule for ongoing backups afterwards
Forms tested one final time on the live-ready environment	A form that worked on staging can behave differently once real domain and email settings are in place
Search engine indexing settings checked	A staging site is normally set to block search engines; that block has to be deliberately removed at launch, not left on by accident
Site title, meta descriptions and favicon set correctly	Basic SEO and browser-tab settings left on placeholder text are an easy, embarrassing miss to catch before launch rather than after
Images carry genuine alt text	Missing alt text is a common, checkable accessibility and SEO gap that costs nothing to fix before launch

The last row deserves particular attention, because the failure mode is invisible and silent: a site accidentally left with search engines blocked simply does not appear in results, with no error message anywhere to alert anyone that something is wrong.

Redirects, specifically, on a redesign

Why the redirect map is one of the highest-stakes items on the list

If this project is replacing an existing website rather than building a new one from nothing, mapping every old page address to its new equivalent is one of the highest-stakes items on this list. Search engines have already indexed the old addresses, and other websites may already link to them. Every old address that is not redirected returns an error instead of sending that visitor, or that search ranking, to the new page. This is frequently where a redesign loses search visibility that took years to build — not because the new design is worse, but because the technical connection between old and new addresses was never properly made.

Why this stage is where rushed launches fail

Every item feels minor in isolation, until several are skipped at once

Under deadline pressure — often a client-driven date, such as wanting to launch before a specific event or the start of a financial year — this checklist is the stage most likely to be compressed. Every individual item on it feels minor in isolation. A missing analytics tag does not stop the site from working. A missing redirect does not stop the new page from loading. Each one, on its own, looks like something that could be fixed after launch rather than before it. The cumulative effect of skipping several of them at once, however, is a launch that looks fine to the business owner checking the homepage. It quietly loses traffic, tracking data and search visibility in ways that are much harder to notice and fix after the fact.

What a business owner can reasonably ask before launch

Before a supplier switches the domain over, it is fair to ask for a straightforward confirmation against a list like the one above. Has DNS been checked? Are redirects from the old site in place and tested? Is analytics installed and confirmed working? Is a backup of the finished site taken before anything is switched? A supplier running a mature process will have this as a standard, repeatable checklist, rather than something assembled from memory for each project. If cost or budget questions arise around what any final adjustments at this stage should reasonably cost, the cost calculator tool on this site provides a general, indicative sense of typical figures — genuinely final invoice reconciliation should still come from the supplier directly.

Who should actually run through the checklist

The supplier’s responsibility, with specific items a client can still confirm

This checklist is properly the supplier’s responsibility, since most of its items — DNS, SSL, indexing settings — are technical configuration a typical client would not know how to verify independently. That said, a client can still meaningfully participate by confirming the items that touch their own business directly. That means the analytics account connected is one the business itself owns and can access afterwards, the backup taken belongs to the business rather than only existing in the supplier’s own systems, and any legal or policy pages due to go live — terms, privacy policy — reflect the final, reviewed wording rather than an earlier placeholder draft.

What a rushed pre-launch checklist commonly misses first

The items skipped first are the ones with no immediately visible consequence

When this stage is compressed under time pressure, the items skipped first tend to be the ones with no immediately visible consequence: setting up a backup schedule, confirming analytics is genuinely tracking rather than just installed, and removing a staging-only search engine block. Each is invisible at the moment of launch and only becomes a problem weeks later — a lost month of analytics data that can never be recovered, or a site quietly absent from search results with no error to flag it. Treating these as equally non-negotiable to the more obviously visible items, such as a working homepage, is what separates a genuinely complete checklist from one that only covers what would be embarrassing to get wrong in front of the client on launch day itself.

Where this website launch checklist sits in the sequence

Once this checklist is cleared, the site is ready to actually go live. See launch day for what happens when the domain is switched over, and what to watch for in the hours immediately afterwards.