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 greenPhase 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.
robots.txt: allow all, aSitemap:line, explicit AI-agent policy. discoverability-filessitemap.xml: non-empty, with<lastmod>from git history. Google ignoreschangefreqandpriority. sitemaps-deepllms.txt: ship-llms-txt.agents.txt: agents-txt.ai.txt: ai-txt./llm-infoplus the sitewide footer link, per the llm-discoverability-standard, which also requires an/identitypage (identity-page). Verify against the built output and gate it in CI.
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 200Also 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.