Playbooks

The launch checklist

Everything that has to be true before a site goes public and in the first week after, in the order it has to happen: the index block, the per-page rules, the redirects, the search consoles, and what to watch.

updated 15 Sept·One document, two Claude Code skills, a gate that runs in CI

When do you reach for The launch checklist?

Written for one person launching a site with an AI assistant and no SEO team. It assumes a framework that builds HTML, a host with preview deployments, and a repo the checklist can live in. It is the list this site went live on, and nothing is in it that was not done here.

What does the checklist cover?

Four phases, and the order between them is the point. Before the domain: the site is readable by anyone with the URL and invisible to every crawler. Every page: the set of things each route has to carry, enforced by a script rather than remembered. Launch day: flip, attach, redirect, submit, in that sequence. Week one: the three numbers that say whether any of it worked. The document is a single markdown file that a human reads once and an assistant reads every time it touches a launch.

Why block the index with a header and not a robots line?

A Disallow line asks a crawler not to fetch the page, so it never reads it and never learns it should be left out. A URL somebody links to can end up indexed with nothing but its address. A noindex header on every response is the instruction that keeps a page out, and it covers the sitemap, the card images and the llms.txt as well, which a meta tag in the HTML cannot. So the pre-launch state invites crawlers in and tells each response plainly not to index it. One flag turns that off, and flipping it is a deliberate act on launch day.

Why is the order on launch day fixed?

Because the domain is public the instant it is attached. On this site the preview hosts sat behind the host's authentication, so the custom domain was the first URL a crawler could reach. Attaching it before the flag was flipped would have published a site whose every response said noindex. Attaching it before the pages were finished would have let the first crawl see the gaps. So the flag flips first, the domain lands second, the redirects get verified third, and only then does the sitemap go to Search Console.

Where does the checklist live in a repo?

In docs/launch.md, as one file of its own. Not in CLAUDE.md, for the same reason as every playbook here: that file is read at the start of every session, and a launch list loaded into work on a button component costs context for nothing. Save the block below as the playbook, then add one line to CLAUDE.md: "Launch or domain work: read docs/launch.md first." The launch-check skill does the verifying, the schema audit does the rewriting when the structured data is wrong, and the checklist says when each of them runs.

Which skills does The launch checklist run on?

2 skills, in the order the playbook runs them. Each one has its own page with the block to copy.

What you copy

One block, ready to paste. Nothing else to install unless the block says so.

1# Launch checklist
2
3What has to be true before this site goes public, in the order it has to
4happen. Read this file before any launch, domain or indexing work. The order
5is part of the rule: the domain is public the instant it is attached.
6
7## Phase 1 - before the domain
8The site is readable by a human with the URL and invisible to every crawler.
9
10- [ ] One constant holds the site name and canonical URL. Nothing else in the
11      code hardcodes the domain. Canonicals, sitemap, card images, JSON-LD
12      ids and utm_source all derive from it
13- [ ] A launch flag, off by default. While it is off, middleware puts
14      `X-Robots-Tag: noindex, nofollow` on every response, and robots.txt
15      allows crawling and advertises no sitemap. Do not use Disallow: a
16      crawler that cannot fetch the page never reads the header
17- [ ] Every preview and platform host (`*.vercel.app` or equivalent) is
18      behind the host's authentication. Share previews with a share link or
19      a password, never by opening the production URL
20- [ ] The legal pages carry the registered entity, address and contact, and
21      the analytics the privacy page describes is the analytics that runs.
22      An imprint with placeholder values goes noindex and out of the sitemap
23      until it is real
24
25## Phase 2 - every page earns its place
26Each public route carries this set. A script reads the built HTML and fails
27the build on any of it, and it runs in CI after the build.
28
29- [ ] Title: unique across the site, the subject in the first words
30- [ ] Description: hand-written, 140-160 characters, repeated nowhere, held
31      in its own field. The visible summary is not the description
32- [ ] Canonical: absolute, on the canonical origin
33- [ ] Exactly one H1
34- [ ] `og:image`: absolute, returns 200. A real card, on every route
35- [ ] JSON-LD: one connected graph. Organization and WebSite declared once
36      from the layout; every page below the home has a BreadcrumbList; one
37      node's `@id` is the page's own canonical URL; no id defined twice;
38      never Review or AggregateRating without real, visible ratings
39- [ ] Articles: author is a reference to a Person on an author page, dates
40      in the markup match the dates on the page
41- [ ] At least one internal link in and one out
42- [ ] When a page fails the gate, fix the page. Never widen the rule
43
44## Phase 3 - the site files come from one list
45- [ ] One route registry, derived from the content data. sitemap.xml,
46      robots.txt and llms.txt all read from it, so a new entry cannot be
47      missing from any of them
48- [ ] A check that walks the app directory against the registry, both ways:
49      a route file that is neither published nor excluded fails, and a
50      registry path with no file behind it fails
51- [ ] Routes kept out of the index are listed with the reason, in code
52- [ ] Sitemap dates are the day the content changed, never the build time
53- [ ] Outbound links go through a redirector: 302, `cache-control:
54      no-store`, `x-robots-tag: noindex`, disallowed in robots.txt
55- [ ] AI crawlers are allowed or blocked as a decision, named in robots.txt
56      with the reason in a comment
57
58## Phase 4 - launch day, in this order
591. Content ready, both gates green on main, canonical host decided (www or
60   apex) and set in the constant
612. Flip the launch flag in the production environment and redeploy. This is
62   a deliberate act, not a default
633. Attach the domain
644. Verify the host with plain requests: the canonical URL answers 200; the
65   twin host, both http variants and every preview host answer 301 or 308
66   to it in one hop; no response carries a noindex header; an unknown path
67   is a 404; the sitemap is a 200
685. Search Console: verify by DNS TXT record, not an HTML file, so it
69   survives every redeploy. Submit the sitemap
706. Bing Webmaster Tools: import from Search Console. Its index feeds ChatGPT
71   search. Add the IndexNow key so new pages are submitted on publish
727. Rich Results Test and the Schema.org validator on one URL per page type:
73   home, listing, entry, article, author
748. Analytics is receiving, and the referrer list is visible
75
76## Week one
77- [ ] Search Console Pages: indexed count against the route count in the
78      registry, and the reason given for every excluded URL
79- [ ] Search Console Queries: what the site is pulled up for. This is the
80      honest read on whether the pages answer real questions
81- [ ] Analytics referrers from chatgpt.com, perplexity.ai, claude.ai and
82      Gemini, recorded now as the baseline
83- [ ] After week one, monthly. Not daily
84
85## Standing rules
86- No slug ever changes without a redirect shipped in the same commit. Keep
87  the redirect map next to the content data, and add it before the first
88  rename, not after
89- The gate script grows when a new kind of gap ships. It never shrinks
90- A page that cannot earn a real description has a problem with the page,
91  not with the rule
92

Free to use in your own work, paid work included, no attribution required. Not for repackaging into a product you sell. Full terms.

Taggedpre-launchclaude codestructured data

More in playbooks

The CRO loop03 Sept

Back to every playbooks entry.