Overview

Run these phases in dependency order: HTTPS cannot be enforced before DNS resolves, and a sitemap cannot be submitted before the site is live. Each phase links to the page that covers it. Copy the checklist into the new repo’s TODO.md and tick it off.

The checklist

# Site launch checklist: <domain>
 
## 1. Repo
- [ ] Repo created; CLAUDE.md, TODO.md, .gitignore, LICENSE, README committed
- [ ] First build runs green locally
 
## 2. Deploy
- [ ] Deploy workflow live; default *.github.io (or *.vercel.app, *.workers.dev) URL serves the real site
 
## 3. Custom domain + DNS
- [ ] Domain added in host settings, then verified with a TXT record
- [ ] Apex A + AAAA records and www CNAME in place; dig confirms
- [ ] Enforce HTTPS checked only after apex AND www resolve
 
## 4. Discoverability files
- [ ] robots.txt, sitemap.xml, llms.txt, agents.txt, ai.txt at the root
- [ ] /llm-info page and the footer link on every page
 
## 5. Search registration
- [ ] GSC verified, sitemap submitted, homepage indexing requested
- [ ] Bing Webmaster Tools imported from GSC, sitemap submitted
- [ ] IndexNow key deployed and pinged after deploy
 
## 6. Structured data
- [ ] Organization + WebSite on the homepage; Article + BreadcrumbList on content pages
- [ ] Rich Results Test passes
 
## 7. Verify
- [ ] Every item in the Verify phase below is green

Phase 1: Repo first

The repo is the source of truth and the deploy pipeline keys off it. Confirm a clean local build before wiring deploy; a red build is cheaper to fix before DNS points at it.

Phase 2: Deploy to the default URL

Get the site serving on the host’s default URL before attaching the domain, so build failures and DNS failures are not tangled. For GitHub Pages, deploy through GitHub Actions rather than “Deploy from a branch”: deploy-quartz-site. For Cloudflare: deploy-a-static-site-to-cloudflare-pages.

Phase 3: Custom domain and DNS

Register the domain at the host, verify it with a TXT record, add the DNS records, confirm with dig, and enforce HTTPS last: point-a-custom-domain-at-github-pages. Registrar-level entry: namecheap-dns, cloudflare-dns.

Phase 4: Discoverability files

Serve these from the origin root; a project-subpath deploy hides them from crawlers.

Phase 5: Search registration

Verify Google Search Console, import the property into Bing Webmaster Tools, and add an IndexNow key with a post-deploy ping. Steps: submit-a-new-site-to-search-engines.

Phase 6: Structured data

Organization and WebSite on the homepage, Article and BreadcrumbList on content pages, validated in the Rich Results Test: add-jsonld-to-static-site.

Verify

for h in example.com www.example.com; do curl -sI https://$h | head -1; done   # both 200, valid cert
for f in robots.txt sitemap.xml llms.txt agents.txt ai.txt llm-info; do
  curl -s -o /dev/null -w "%{http_code} $f\n" https://example.com/$f; done      # all 200

Also check that a URL and its trailing-slash twin do not 404 against each other, that GSC shows the sitemap as Success, and run the audit in audit-checklist on the live URL.

FAQ

In what order should I launch a new site?

Repo, deploy to the default URL, custom domain and DNS, discoverability files, search registration, then structured data. Each phase depends on the one before; HTTPS cannot be enforced before DNS resolves.

Should I attach the custom domain before the first deploy?

No. Get the site serving on the host’s default URL first, so build failures and DNS failures are not tangled.

Does Google use changefreq and priority in sitemap.xml?

No. Google ignores changefreq and priority; ship a non-empty sitemap with <lastmod> from git history.

Can discoverability files live under a project subpath?

No. Serve robots.txt, sitemap.xml, llms.txt, and the rest from the origin root, because a project-subpath deploy hides them from crawlers.