The website launch checklist: 14 items ordered by what you cannot undo later

Most launch checklists run to fifty items and give all fifty the same weight, which is exactly the wrong shape for the one day they are meant to serve. On launch day nobody has time to work through fifty equal boxes. What a person needs at that moment is a much smaller question, asked in the right order: which of these can I still fix next week, and which one closes a door the moment I publish? Three of the items below cannot be recovered later at any price. Most of the rest can wait a fortnight without anyone noticing.

Quick answer

• Three items are irreversible. The record of what the old site ranked for, the starting numbers, and the redirect map all depend on the previous site still being live.
• Two failures are opposites and both are common: the test environment left open to search engines, and the site published still carrying the noindex from development.
• Verification belongs on the list. A site can be perfectly built in the folder and broken on the server, and only the served page tells you which.
• Most of the list is not urgent. Alt text and meta descriptions matter; they do not matter on Tuesday.

What should a website launch checklist cover?

A launch checklist covers three groups in order: what can only be captured while the old site is live, what must be verified in the hours after publishing, and what improves the site over the following weeks. A new domain skips the first group; a redesign lives or dies by it; a replatform adds the redirect map.

Why the fifty-item lists do not help

Length is what makes a launch checklist look thorough and what makes it useless. Fifty unranked boxes on a day when the client is refreshing the homepage every ten minutes produce the same outcome every time: somebody scans the list, ticks the easy visual ones, and the two or three that were actually load-bearing get skipped because nothing marked them as different.

The useful ordering is not by category, and not by effort. It is by reversibility. Alt text added three weeks late costs nothing but three weeks. A redirect map built three weeks late cannot be built at all, because the URLs it needed to map are gone along with the site that served them.

That single distinction reorganizes the whole thing, and it is the reason this list has fourteen items instead of fifty. The other thirty-six are real work, and they belong in the ordinary run of an SEO checklist for a business with no marketing team, not in the launch.

The three you cannot do afterwards

These depend on something that stops existing the moment the new site goes up. There is no version of these that can be recovered later.

1. The inventory of what the old site ranked for

Before anything is replaced, export every query and page that brings impressions today, along with its position. After launch, this is the only way to tell a normal settling period from a real loss, because without it every comparison is against memory.

The export takes ten minutes in Search Console and it is the single highest-return act on this entire page. If the property is not connected yet, that comes first: how to set up Search Console is a fifteen-minute job and it is the prerequisite for everything measurable that follows.

2. The baseline numbers, written down with their date

Impressions, clicks and average position for a fixed set of queries, on a stated date. Not a screenshot of a dashboard: a small table you can compare against in six weeks.

The reason this matters more than it sounds is that traffic after a launch always dips and always recovers unevenly, and without a baseline the recovery is indistinguishable from a decline. Reading that difference correctly is a discipline of its own, covered in why organic traffic drops.

3. The redirect map, URL by URL

If any address changes, every old URL needs a destination decided one at a time. Not a blanket rule to the homepage, which search engines treat as a soft error rather than a move, and which throws away the signals that URL had accumulated. On a catalogue the count stops being something a person can hold in their head, which is where SEO for ecommerce starts.

This applies to a redesign or a replatform. A genuinely new domain with no history has nothing to map, and the item drops off the list entirely.

The launch-day layer: the hours that decide what gets indexed

These are recoverable, but every day they stay wrong is a day of wrong pages in the index.

4. The indexing directive, checked on the live page

The most common launch failure in this group is the inverse of what people expect. Development sites carry a noindex so nobody finds them while they are half-built, and that directive travels to production more often than anyone admits. The site launches, everyone celebrates, and Google is being told to stay away for a fortnight.

The check takes seconds: load the published page, view source, look for a robots meta tag. If it says noindex, nothing else on this list matters until it does not. The full catalogue of reasons a page stays out of the index is in why a page is not indexed.

5. The test subdomain, closed properly

The mirror image of the previous item, and the more expensive one. Sites are usually built on a preview address, something like test.yourdomain.com or dev.yourdomain.com, and when the real site goes live that copy is often left exactly where it was: reachable, complete, and with a full sitemap of its own inviting search engines to crawl every page of it.

What happens next is that two identical sites compete, and there is no rule saying the real one wins. A preview subdomain can and does outrank the site it was a rehearsal for, taking the traffic with it, and the owner has no reason to look for the problem because the site itself is fine.

The fix is where most advice gets it wrong. The instinct is to add the subdomain to robots.txt, and that is the one move that does not solve it: a blocked URL can stay indexed if anything links to it, and blocking it stops search engines from reading the noindex that would have removed it. Two options work:

• HTTP authentication on the subdomain. A username and password. Nobody gets in, crawlers included, and the problem ends at the root. This is the right answer whenever the environment is still in use.
• noindex on the preview site, without blocking it in robots.txt, so the directive can actually be read. Slower, and only sensible if the environment must stay publicly reachable.

Either way, if pages were already indexed, the removal tool in Search Console shortens the wait from weeks to days.

6. One canonical host, everywhere

A site answering on https://, http://, www and non-www is four addresses serving one thing. Search engines resolve it most of the time and the point is not to make them guess. Pick one, redirect the other three to it, and make sure internal links use it.

7. Analytics and Search Console recording from day one

Both, verified by loading a page and confirming the visit appears. Data not collected on launch week cannot be collected retroactively, which puts this closer to the irreversible group than its position here suggests.

8. The sitemap submitted, and honest

It should list the URLs that exist and should be indexed, and nothing else. A sitemap that still lists the old structure teaches search engines the wrong map at the exact moment they are re-learning the site.

9. Verify on the served page, not in the folder

The item almost every list omits, and the one that catches the others.

A site can be correct in the repository and wrong on the server: a deploy that half-finished, a cached copy, a file that never uploaded. The folder tells you what was built and the URL tells you what is being served, and they disagree more often than anyone expects.

I get to say this with some authority because it caught me. Five of my own checking scripts spent weeks pointing at a folder path from before I moved the project to another drive. Every one of them reported cleanly, because a script that looks in the wrong place finds nothing wrong. One of them was the script that validates my content security policy before each deploy, so every clean result it gave me for weeks was clean about nothing. Nothing revealed it until a check contradicted something I could see with my own eyes.

So the last launch-day item is a loop, not a box: open the live URLs, in an incognito window, and confirm they serve what you think they serve.

The fortnight layer: real work, no urgency

These improve results and none of them close a door. Doing them the week after launch costs nothing but the week.

10. Titles and meta descriptions, written per page rather than generated from a template. 11. Structured data where it earns a rich result, which is a narrower set of pages than most plugins assume. 12. Image weight and loading speed, measured on a phone on a real connection rather than on a developer's laptop. 13. Alt text, which is an accessibility obligation first and an SEO detail second. 14. The internal link structure, which is worth more than all four above put together and is the one that gets postponed indefinitely. On a new site it is also the only lever that works before anyone links to you from outside, which is why what SEO is and what it is for puts it where it does.

If the business serves customers at an address, the local layer runs in parallel and has its own sequence, laid out in the local SEO checklist.

When a launch checklist is not what you need

When the site has been live for months. Then the question is not what to check but what to fix first, which is a diagnosis and not a list.

When there is no old site and no old URLs. Three of the fourteen items exist to preserve history, and with no history they are noise.

When the launch date is fixed and the content is not ready. Publishing thin pages to meet a date creates a problem that a checklist cannot solve, and no item here compensates for a site that has nothing to say.

When the site is a rebuild of something that ranks well. Then this list is the wrong tool and the right one is a migration plan, where the redirect map stops being one item among fourteen and becomes most of the project.

When the budget for the launch has consumed the budget for everything after it. A site that goes live with nothing behind it is the most common outcome of that arithmetic, and what the ongoing work actually costs is in SEO cost for a small business.

Mistakes that repeat

• Treating all fifty items as equal. The three irreversible ones get skipped along with the trivia.
• Launching with the development noindex still in place. Weeks of invisibility that nobody notices because the site looks fine.
• Leaving the preview subdomain reachable. A complete duplicate of the site, competing with it and sometimes winning.
• Blocking that subdomain in robots.txt and calling it solved. It stops the fix from being read while the pages stay indexed.
• Redirecting every old URL to the homepage. Search engines treat it as a page that no longer exists, and the accumulated signals are lost.
• Checking the build instead of the site. The folder is not the server, and only one of them is what people load.

Data and transparency

No figures on traffic loss after a migration appear here. The numbers circulating for that range from ten to sixty per cent depending on who is selling the recovery, and none I checked traces to a study with a stated sample. What is described instead is the mechanism, which is verifiable by anyone on their own site.

That a redirect of many URLs to a homepage is treated as a soft error rather than as a move, that a URL blocked in robots.txt can remain indexed when other pages link to it, and that a noindex directive must be crawlable to be obeyed, all come from Google's public documentation on crawling and indexing, checked on 26 August 2026.

The account of five checking scripts pointing at a path that no longer existed is my own, from this site, in August 2026. The observation that preview environments are frequently left reachable after launch is drawn from audit work across a portfolio recording more than 300 million impressions a year in Search Console; no client or third-party site is identified, and none of the specifics here belong to any single one of them. Verified as of August 2026.

Primary sources, opened on 26 August 2026: Google's documentation on crawling and indexing.

What this changes

The reason launch checklists fail is not that people are careless. It is that a list of fifty equal boxes, handed to somebody on the most rushed day of the project, is a document designed to be skimmed.

Sorting by what cannot be undone changes what gets skipped. The items that fall off are the ones whose cost is a delay, and the ones that survive are the ones whose cost is permanent. It also produces the uncomfortable realization that most launches go wrong before the launch: the evidence that would have proven the site was fine gets thrown away by the same act that put the new site live.

Frequently asked questions