Skills

Launch check

Run this against a site before it goes public and it tells you what would stop it being found: a missing description, a redirect that loops, a sitemap that lists a 404.

updated 15 Sept·Claude Code skill, reads the built pages and probes the live host

When do you reach for Launch check?

Runs the day before a launch and again the hour after the domain is attached, because the second run is the one that catches the host. It reads the pages your build produced, so it works on any framework that outputs HTML, and it probes the live URL with plain requests, so it works on any host. Pair it with the schema audit when the structured data itself needs rewriting rather than checking.

What does it check?

Six things per page and four things about the site, all of them read from what actually ships rather than from the source that was meant to produce it. That distinction is the whole point. On this site, fourteen entry pages passed typecheck, lint and build for a week with no description of their own, because nothing looked at the HTML.

Per page: one unique title, a hand-written description of 140-160 characters that no other page repeats, an absolute canonical, exactly one H1, an absolute og:image, and a JSON-LD graph with a node whose @id is the page's own URL.
Site files: robots.txt allows crawling and names the sitemap, every sitemap URL answers 200 on the canonical host with a real last-modified date, llms.txt lists the same pages, and an unknown path returns a real 404 status.
The host: the canonical URL answers 200, the apex or www twin and every preview host redirect to it in one hop, http goes to https, and no live response still carries a noindex header left over from the build phase.
Structured data: every block parses, the site declares Organization and WebSite once, every page below the home carries a BreadcrumbList, no @id is defined twice, and nothing emits Review or AggregateRating for ratings that do not exist.

What does it give back?

A list, worst first, in three grades. Blocking is anything that keeps a page out of the index or sends a visitor somewhere wrong. Fix before launch is the rest of the per-page set. Noted is what is fine today and will not be after the first change, such as a slug with no redirect map behind it. Every line names the route, the fault and what it costs in one sentence, so the person fixing it does not need to know the vocabulary.

Why does it end by writing a script?

A check that runs once is a check that gets skipped on the next launch. The last step turns the per-page rules into a small script in the project's own language that reads the build output and fails with a list, and puts it in CI after the build. The rule that goes with it: when a page fails, fix the page. Widening the rule so the build goes green is how a gate stops meaning anything.

What you copy

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

1---
2name: launch-check
3description: Check a site before it goes public, the way a crawler will see it.
4  Reads the built pages for title, description, canonical, H1, og:image and
5  JSON-LD, probes the live host for redirects and stray noindex headers, and
6  checks robots, sitemap and llms.txt against each other. Use the day before a
7  launch and again once the domain is attached.
8---
9
10# Launch check
11
12Read what ships, never what was meant to ship. Passing typecheck, lint and
13build says nothing about the HTML a crawler receives. Every check below runs
14against built output or a live URL.
15
16## 1. Establish what is supposed to exist
17
18Before checking anything, find out:
19
20- the canonical origin, including the www or apex decision (one constant in
21  the code, a config value, or ask). Every absolute URL below is checked
22  against it
23- the list of public routes: the sitemap if there is one, otherwise the
24  route files or the content data. Note routes that are deliberately kept
25  out of the index and why (a redirector, an internal asset page, the 404)
26- whether the site is live yet, because a pre-launch site is allowed to
27  carry a noindex header and a live one is not
28
29Say which of these you had to guess. A wrong canonical host makes every
30other result wrong.
31
32## 2. Check every route from the built HTML
33
34Read the build output (`.next/server/app` for Next.js, `dist/` for Astro,
35`out/` or `build/` elsewhere), or fetch each live URL. Per page:
36
37| Check | Pass |
38|---|---|
39| `<title>` | present, unique across the site, the page's subject in the first words |
40| `meta description` | present, 140-160 characters, hand-written, not repeated on any other page, not the same text as the visible summary |
41| `link rel=canonical` | present, absolute, on the canonical origin, points at this page |
42| `<h1>` | exactly one |
43| `og:image` | present, absolute, returns 200 |
44| JSON-LD | every block parses; see step 5 |
45| Links | at least one internal link in from another page, one out |
46
47Routes kept out of the index still need a title and one H1, and are exempt
48from the rest. A description of 36 characters is a failure, not a partial
49pass. A description that falls back to the summary already on the page is a
50failure that the page's author has to fix by writing one.
51
52## 3. Check the site files against each other
53
54- `robots.txt`: allows crawling, names the sitemap with an absolute URL,
55  disallows only what is meant to be disallowed. If AI crawlers are
56  blocked, confirm that was a decision and not a default
57- `sitemap.xml`: every URL is absolute, on the canonical origin, answers
58  200 without a redirect, and carries a last-modified date that is the day
59  the content changed, not the build time. Every public route is in it.
60  Nothing that is noindex is in it
61- `llms.txt`, if the site has one: lists the same pages the sitemap does
62- a made-up path returns HTTP 404, not a 200 page that says "not found"
63
64The sitemap and llms.txt should be generated from the same list the pages
65come from. If they are maintained by hand, say so in the report: that is the
66fault that lets a new page ship without being in either.
67
68## 4. Probe the host
69
70Run these against the live site and record the status line and the headers
71that matter. Replace the host.
72
73```sh
74for url in \
75  https://www.example.com/ \
76  https://example.com/ \
77  http://www.example.com/ \
78  http://example.com/ \
79  https://example-project.vercel.app/ ; do
80  printf '%s\n' "$url"
81  curl -sI -o /dev/null -w '  %{http_code}  ->  %{redirect_url}\n' "$url"
82done
83
84curl -sI https://www.example.com/ | grep -i -E 'x-robots-tag|content-type|strict-transport'
85curl -sI https://www.example.com/no-such-page | head -1
86curl -sI https://www.example.com/sitemap.xml | head -1
87```
88
89Pass:
90
91- the canonical origin answers 200
92- the twin host (apex when www is canonical, or the reverse), both http
93  variants and every preview or platform host answer 301 or 308 straight to
94  the canonical URL, in one hop, keeping the path
95- no live response carries `x-robots-tag: noindex`. A launch flag or
96  middleware that added this before launch has to be off on the production
97  deployment, not just in the code
98- the unknown path is a 404 and the sitemap is a 200
99
100A redirect chain of two hops is a fail. A preview host that serves the site
101with a 200 is a fail: it is a duplicate of every page under a second origin.
102
103## 5. Check the structured data
104
105Parse every `application/ld+json` block on every route.
106
107- every block parses, and the page has at least one
108- `Organization` and `WebSite` appear once, declared with stable `@id`s,
109  and nothing restates them on a lower page
110- every page below the home has a `BreadcrumbList`
111- one node's `@id` is the page's canonical URL. Without it the page has the
112  site's graph and none of its own
113- no `@id` is defined twice
114- no `Review` or `AggregateRating` unless real ratings exist and a visitor
115  can see them on the page
116- articles: `author` is a reference to a `Person` node, not a string, and
117  `datePublished` plus `dateModified` match the visible dates
118
119For one URL per page type, run the Rich Results Test and the Schema.org
120validator and quote what they said. If the markup itself needs rewriting,
121hand over to the schema-audit skill rather than patching it here.
122
123## 6. Report, worst first
124
125Three grades, in this order:
126
1271. **Blocking** - keeps a page out of the index or sends a visitor to the
128   wrong place: a live noindex header, a preview host serving 200, a
129   sitemap URL that 404s, a canonical on the wrong origin, a redirect loop
1302. **Fix before launch** - the per-page set from step 2 and the graph
131   rules from step 5
1323. **Noted** - fine today, wrong after the first change: slugs with no
133   redirect map, sitemap dates that equal the build time, a hand-maintained
134   route list
135
136Each line: the route, the fault, and what it costs in one sentence a
137non-specialist can act on. "No canonical" is not a reason. "Without a
138canonical, the www and apex copies of this page compete with each other" is.
139
140## 7. Leave a gate behind
141
142Turn step 2 and step 5 into a script in the project's own language that
143reads the build output and exits non-zero with the list. Put it in CI after
144the build. It should fail on: no title, duplicate title, description outside
145140-160 or repeated, missing or relative canonical, H1 count other than one,
146missing og:image, JSON-LD that does not parse, no node at the page's own URL,
147any rating markup.
148
149When a page fails the gate, the fix is the page. Never widen the rule to get
150a green build.
151

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

Taggedclaude codepre-launchstructured data

More in skills

Schema markup audit02 Sept

QA pass03 Sept

Learnings check02 Sept

Test hypothesis02 Sept

Back to every skills entry.