---
name: Site Launch Checklist
slug: site-launch-checklist
category: Automation
description: Site Launch Checklist guides a pre-launch review for websites and web apps, covering DNS, TLS, analytics, SEO, security headers, accessibility, and launch monitoring. Use it before going live, during migrations, or when auditing readiness.
github: "https://github.com/samber/cc-skills/tree/main/skills/site-launch-checklist"
language: CSS
stars: 201
forks: 15
install: "npx degit https://github.com/samber/cc-skills/tree/main/skills/site-launch-checklist ~/.claude/skills/site-launch-checklist"
installs_to: ~/.claude/skills/site-launch-checklist
source_path: skills/site-launch-checklist/SKILL.md
collection_size: 21
category_size: 1956
collection_url: "https://dirskills.com/collections/samber/cc-skills"
added: 2026-09-05T05:30:32.397Z
last_synced: 2026-09-05T05:30:32.397Z
canonical_url: "https://dirskills.com/skills/site-launch-checklist"
---

# Site Launch Checklist

Site Launch Checklist guides a pre-launch review for websites and web apps, covering DNS, TLS, analytics, SEO, security headers, accessibility, and launch monitoring. Use it before going live, during migrations, or when auditing readiness.

**Install:**

```bash
npx degit https://github.com/samber/cc-skills/tree/main/skills/site-launch-checklist ~/.claude/skills/site-launch-checklist
```

## README

**Questions:** Ask the user through the environment's question tool — never as plain-text prose. One question at a time, 2–4 tappable options, wait for the answer. If the environment has no question tool, ask in prose with the same options, one at a time.

# Site Launch Checklist

Pre-launch audit and setup workflow for shipping a new website. Opinionated for Cloudflare DNS + Vercel hosting + PostHog + Legal context.

## Interaction style (READ FIRST)

This skill is intentionally interactive. Ask aggressively instead of assuming. The user will tap, not type.

**Always ask these questions at the start of a run** (one at a time, in this order):

1. Site type: `doc-site` | `marketing/lead-gen` | `SaaS-app` | `training/paid-course` | `personal-portfolio`
2. Migration: `greenfield-new-domain` | `migration-need-301-redirects` | `replacing-existing-on-same-domain`
3. Multilingual: `single-locale` | `en` | `fr+en` | `other-multi`
4. PostHog setup: `hogpost.samber.dev` | `set-up-new-proxy` | `skip-PostHog`
5. AI scraper policy: `use-default-for-site-type` | `customize-per-bot` | `block-all`
6. Browser tool available: `claude-chrome-extension` | `playwright` | `neither-skip-browser-checks`

**Ask again at every decision point throughout the phases**, including:

- Whether to install Sentry / BetterStack / Crisp (depends on site type, ask explicitly)
- www vs apex canonical preference (most sites: apex; ask anyway)
- Which AI bots to allow if user chose `customize-per-bot`
- CSP tightness level: `strict-default-src-none` | `balanced-allow-self` | `permissive-for-marketing`
- Whether to skip a phase entirely (e.g., skip Phase 3 if non-FR site)

Never proceed past a decision point without explicit user input. Verbose checklists without checkpoints are not the goal.

**Never install any MCP server or skill without explicit user confirmation.** Always ask via the question tool before running `npx skills add`, `claude mcp add`, or any equivalent install command — even when the skill selection workflow proposes a curated subset.

## How to use this skill

1. Run the start-of-session questions above.
2. Walk the user through phases 1-10 in order. For each phase: a. List items, ask if any should be skipped. b. For each remaining item, run the verification command (see "Verification tools" below). c. Report pass/fail. On fail, ask the user if they want to fix now or queue for later.
3. End with a status report grouped by phase, with blockers, recommended fixes, and optional improvements clearly separated.

## Companion skills

Six skill packs are useful for site launches. **Never install full multi-skill packs**. The actual subset to install is decided at invocation time based on the site type the user confirms.

### Pack inventory

| Pack | What it covers | Typically useful for |
| --- | --- | --- |
| `AgriciDaniel/claude-seo` | SEO + GEO + schema + hreflang + sitemaps audits, parallel sub-agents | All site types |
| `addyosmani/web-quality-skills` | Lighthouse, Core Web Vitals, accessibility, performance, best practices | All site types |
| `trailofbits/skills` | Security audit (OWASP, headers, dependencies) | All site types |
| `aaron-he-zhu/seo-geo-claude-skills` | 20 SEO+GEO skills, CORE-EEAT + CITE frameworks, `/seo:` slash commands | Content-heavy sites, competitive niches |
| `coreyhaines31/marketingskills` | ~30 marketing skills (CRO, copywriting, ads, popups, email, paywalls, etc.) | `marketing/lead-gen`, `SaaS-app`, `training/paid-course` |
| `jonathimer/devmarketing-skills` | 33 developer-marketing skills (persona, docs-as-marketing, technical tutorials, etc.) | `doc-site`, `SaaS-app` for developers |

### Skill selection workflow (run at session start)

After the user confirms site type, for **each pack relevant to that site type**:

1. **List available sub-skills**: `npx skills add owner/repo --list`
2. **Propose a curated subset** based on site type and the phases this skill will execute. Match each phase's needs to specific sub-skills the listing returns.
3. **Confirm with the user.** Use multi-select when the proposed list has more than 3 items, single-select (`install-as-proposed` | `let-me-modify` | `skip-this-pack`) otherwise.
4. **Bulk install the agreed subset**: `npx skills add owner/repo --skill A B C`

Rules:

- Sub-skill names live in the pack, not in this SKILL.md. Always query `--list` for the current state. Pack contents change.
- Never run `npx skills add owner/repo` without `--skill` (that installs everything).
- Site type → packs mapping (which packs to enumerate, sub-skills still selected per workflow):
  - `doc-site`: claude-seo, web-quality-skills, trailofbits, seo-geo-claude-skills, devmarketing-skills
  - `marketing/lead-gen`: claude-seo, web-quality-skills, trailofbits, seo-geo-claude-skills, marketingskills
  - `SaaS-app`: all six
  - `training/paid-course`: claude-seo, web-quality-skills, trailofbits, marketingskills
  - `personal-portfolio`: claude-seo, web-quality-skills, trailofbits, seo-geo-claude-skills (lightweight subset)
- If the user later requests a phase that needs a sub-skill not yet installed, run the workflow again for that single sub-skill rather than re-installing the whole subset.

This avoids importing 80+ skills the user does not need, avoids going stale on sub-skill names, and avoids overfitting to a single pack version.

When delegating during a phase, do not duplicate work this skill orchestrates. Call the specialist with a narrow scope (e.g., "run only the security headers sub-audit on URL X").

## Phase 0: Launch Readiness Gate

**Run this BEFORE any other phase.** Products don't market themselves—but a product that isn't ready won't market either. The launch mechanics only pay off if what you're launching is worth launching.

Two failure modes kill launches from opposite ends:

- **Stealth Mode** — launching too late. "Procrastination in a fancy suit." You keep polishing in private, waiting for the product to be perfect. It never ships, and nobody learns you exist.
- **"Just One More Feature"** — never launching. Every proposed launch date gets pushed for one more thing. The scope creeps forever; the launch never comes.

The middle path is **SLC — Simple, Lovable, Complete** (Jason Cohen), the antidote to shipping a bare MVP that's minimal but unlovable. Don't launch a stub nobody wants; don't wait for a bloated everything-app. A launchable v1 is:

- **Simple** — it does _one_ thing. Not many things poorly. One clear job, done well.
- **Lovable** — people _want_ to use it, not just tolerate it. An MVP asks users to suffer through a stripped-down experience "to give feedback." SLC gives them something they'd choose. If nobody would be sad to lose it, it isn't lovable yet.
- **Complete** — it's a _whole_ experience for that one thing, not a stub with obvious holes. Complete at its chosen scope, not a teaser of a bigger promise.

**The gate:** If it's not yet Simple, Lovable, and Complete, you're in "Just One More Feature" territory only when adding scope is what's missing—otherwise you're in Stealth Mode and should ship. Cut scope until one thing is lovable and complete, then launch that. SLC gives you a real launch now instead of a perfect launch never.

**Quick check before running the phases:**

- [ ] Does it do one clearly-defined thing? (Simple)
- [ ] Would a target user _choose_ to use it, not just endure it? (Lovable)
- [ ] Is that one thing a whole experience, with no glaring stubs? (Complete)
- [ ] Are you polishing past this bar? → Stop. You're in Stealth Mode. Ship.
- [ ] Are you still adding new things to the scope? → Stop. You're in "Just One More Feature." Cut back to SLC.

**Directory submission readiness (from directory-submissions skill):** Ask these 9 questions. If any are "no", they're not ready — help them build the missing piece first.

1. Is the product publicly accessible (no password wall)?
2. Is there a pricing page (even "free while in beta")?
3. Are privacy policy + terms live?
4. Logo assets in PNG + SVG + square + favicon?
5. 5–8 real screenshots + 60–90s demo video?
6. Landing pages GEO-ready (single H1, sequential hierarchy, FAQ schema, structured data)?
7. At least 3 alternative pages and 3 use-case pages live and indexed?
8. Template gallery or lead magnet asset (if applicable to category)?
9. At least 20 beta/early users who could leave a review on G2?

A "no" on any of 1–7 is a hard block. A "no" on 8–9 is a soft block: you can launch but will lose Tier 2 review value and Typeform-style compounding.

**ORB Channel Strategy (from launch skill):** Structure your launch marketing across three channel types. Everything should ultimately lead back to owned channels.

### Owned Channels

You own the channel (though not the audience). Direct access without algorithms or platform rules.

- Email list, Blog, Podcast, Branded community (Slack, Discord), Website/product
- **Start with 1-2 based on audience:** Industry lacks quality content → Blog; People want direct updates → Email; Engagement matters → Community

### Rented Channels

Platforms that provide visibility but you don't control. Algorithms shift, rules change, pay-to-play increases.

- Social media (Twitter/X, LinkedIn, Instagram), App stores, YouTube, Reddit
- **How to use correctly:** Pick 1-2 platforms where your audience is active; Use them to drive traffic to owned channels; Don't rely on them as your only strategy

### Borrowed Channels

Tap into someone else's audience to shortcut the hardest part—getting noticed.

- Guest content (blog posts, podcast interviews, newsletter features)
- Collaborations (webinars, co-marketing, social takeovers)
- Speaking engagements (conferences, panels, virtual summits)
- Influencer partnerships
- **Be proactive:** List industry leaders your audience follows → Pitch win-win collaborations → Use tools like SparkToro or Listen Notes to find audience overlap

Pass the gate, then run the phases below.

## Copywriting voice and humanizer pass

Every site has visible marketing copy (hero, features, CTAs, meta descriptions, OG descriptions, blog posts, 404 page text). Two layers of polish are mandatory before launch:

### 1. Define `TONE.md` once per site

Ask the user: "Does this site already have a `TONE.md`?" (`yes-already-exists` | `no-create-from-template` | `skip-use-default`).

If creating: write it to `.agents/TONE.md` or repo root `TONE.md`. See `references/templates.md` (section "TONE.md template") for the structure.

TONE.md specifies: voice (terse, contrarian, etc.), forbidden patterns (e.g., "delve", "crucial", em dashes, AI-sounding openers), sentence length preference, audience reading level, examples of good and bad sentences from the user's own writing.

### 2. Run a humanizer pass in the matching language

After every drafting step (whether by a copywriting skill, by hand, or by Claude directly), run a humanizer to strip AI patterns.

Ask the user for the site's primary audience language at the start of the session if not already known:

- `english-global` → `npx skills add https://github.com/blader/humanizer --skill humanizer`
- `french` → use `samber/cc-skills@humaniseur-fr` (custom French humanizer) or equivalent French-tuned skill
- `other` → install matching humanizer if available; otherwise the skill writes a short language-specific anti-pattern checklist inline

Apply the humanizer to: hero copy, feature descriptions, CTA buttons, meta descriptions, OG/Twitter card descriptions, blog posts, email signup confirmations, 404 page text. Skip for legal pages (mentions légales, CGV) since they have rigid wording requirements.

### 3. Always reference TONE.md when invoking copywriting skills

When delegating to any copywriting or content-writing sub-skill (selected at invocation per the skill selection workflow), include `TONE.md` in the prompt context. Pass voice constraints explicitly: "Follow `.agents/TONE.md`. Avoid the listed patterns. Apply the humanizer after drafting."

## Browser interaction preference

Many checks require a real browser (Lighthouse runs, securityheaders.com scan, opengraph.xyz validation, Twitter card validator, mobile viewport, screen reader smoke, Network tab inspection).

**Always prefer the Claude Chrome extension.** Fall back to Playwright only if the Chrome extension is unavailable. If neither is available, ask the user whether to skip browser checks entirely or wait until they enable one.

## Verification tools

Most checks are doable from the command line without third-party services. Use these tools inline at every phase. Don't trust panels in Cloudflare/Vercel/Google dashboards alone, verify with curl.

**DNS (Phase 1):**

```bash
dig +short A example.com                          # A record
dig +short AAAA example.com                       # AAAA (IPv6)
dig +short MX example.com                         # MX (mail)
dig +short TXT example.com                        # SPF + verification TXT
dig +short TXT _dmarc.example.com                 # DMARC
dig +short TXT default._domainkey.example.com     # DKIM (selector varies)
dig +short CAA example.com                        # CAA
dig +dnssec example.com | grep RRSIG              # DNSSEC active
```

**TLS / HTTPS (Phase 1):**

```bash
curl -sIL https://example.com | head             # follow redirects
curl -sI https://www.example.com                 # check www handling
openssl s_client -showcerts -connect example.com:443 < /dev/null 2>/dev/null | openssl x509 -noout -dates
```

**Headers (Phase 4):**

```bash
curl -sI https://example.com | grep -iE 'content-security-policy|strict-transport-security|x-frame-options|x-content-type-options|referrer-policy|permissions-policy'
# Full header dump:
curl -sI https://example.com
# External graders:
curl -s "https://api.securityheaders.com/?q=https://example.com&followRedirects=on&hide=on" -I | grep -i 'x-grade'
```

**SEO files (Phase 5):**

```bash
curl -s https://example.com/robots.txt
curl -sI https://example.com/sitemap.xml
curl -s https://example.com/sitemap.xml | head -40
curl -s https://example.com/llms.txt
# Schema (JSON-LD):
curl -s https://example.com/ | grep -A 50 'application/ld+json'
# hreflang:
curl -s https://example.com/ | grep -i hreflang
```

**Open Graph & social (Phase 6):**

```bash
curl -s https://example.com/page | grep -iE 'og:|twitter:|<title|name="description"'
```

**Favicons & manifest (Phase 7):**

```bash
curl -sI https://example.com/favicon.ico
curl -sI https://example.com/favicon.svg
curl -sI https://example.com/apple-touch-icon.png
curl -s https://example.com/manifest.json | jq .
```

**404 / 500 / redirects:**

```bash
curl -sI https://example.com/this-does-not-exist
curl -sIL https://example.com/old-url     # verify 301 chain
```

Always run the relevant command, paste the output to the user when reporting, then ask whether to fix immediately or queue.

---

## Phase 1: Domain & Infrastructure

Most of this is one-click via Cloudflare's dashboard if the domain is on Cloudflare.

Ask first: "Is the domain already on Cloudflare with the standard config from previous launches?" (`yes-standard` | `yes-needs-review` | `no-fresh-setup`)

Checklist:

- [ ] Cloudflare: proxy ON for apex + www, TLS 1.3 minimum, "Always Use HTTPS" enabled, HSTS preload enabled in Cloudflare SSL/TLS settings
- [ ] DNS A/AAAA or CNAME pointing to Vercel (verify with `dig +short A example.com`)
- [ ] MX records for Google Workspace (verify with `dig +short MX example.com`)
- [ ] SPF, DKIM, DMARC records (verify all 3 with the dig commands above)
- [ ] CAA records restricting cert issuance (verify with `dig +short CAA example.com`)
- [ ] DNSSEC enabled at registrar level (verify with `dig +dnssec`)
- [ ] Vercel: project linked to repo, prod + preview env vars set, custom domain attached, prod and preview aliases correct
- [ ] Decide www vs apex canonical, configure 308 redirect for the non-canonical (verify with `curl -sIL https://www.example.com`)
- [ ] Custom 404 page renders (verify with `curl -sI https://example.com/does-not-exist`)
- [ ] Custom 500 page exists (cannot easily verify without forcing an error, ask user)
- [ ] If migration: 301 redirect map for every old URL (loop verification with `curl -sIL` per URL)

### Backups

If you don't configure backups at launch, you never will. Do it now.

Ask the user: "Which data stores does this app write to?" (`database-only` | `database-plus-file-storage` | `file-storage-only` | `stateless-no-persistent-data`). If `stateless-no-persistent-data`, skip this section.

**Database:**

- [ ] Automated daily backups enabled at the provider level (Neon, Supabase, PlanetScale, Railway, RDS — each has a one-click toggle). Verify by opening the backup panel and confirming the last backup timestamp is recent.
- [ ] Retention policy set to ≥30 days
- [ ] Point-in-time recovery (PITR) enabled if available (Neon, Supabase, RDS all support it)
- [ ] Off-site copy: if the provider stores backups in the same region as the primary, configure cross-region replication or a nightly export to a separate storage account (S3, R2, GCS)
- [ ] **Restore drill performed before launch**: pick a recent backup, restore to a staging database, verify row counts and a sample query. A backup you haven't tested is not a backup.

**File storage (if applicable — S3, R2, GCS, Cloudflare Images):**

- [ ] Versioning enabled on the primary bucket
- [ ] Cross-region replication or a scheduled sync to a secondary bucket. Backblaze B2 is a cheap, reliable option for off-site copies (significantly cheaper than S3/GCS egress). Use `rclone` to sync from S3/R2/GCS → B2 on a daily cron.
- [ ] Lifecycle rule: transition old versions to cheaper storage after 30 days, delete after 90 days (adjust to cost tolerance)

**Secrets / environment variables:**

- [ ] All env vars documented and stored in a secrets manager (1Password, Doppler, Vault, or equivalent). Not in a `.env` file on someone's laptop.
- [ ] Verify: if every engineer's machine burned tonight, could a new team member restore prod from scratch using only the secrets manager + git?

**Monitoring:**

- [ ] Set up an alert (email or Slack) if the daily backup job fails. Most providers support this natively; configure it before closing the backup panel.

---

## Phase 2: Analytics & Observability

Most third-party integrations are one-click via Cloudflare or Vercel.

**For the conditional tools (Crisp, Sentry, BetterStack), ask the user** to confirm per site type. See `references/decisions.md` for the observability tier matrix.

**Always-on:**

- [ ] Google Analytics 4: property created, measurement ID embedded, gated behind CNIL consent
- [ ] PostHog: based on user's earlier answer:
  - If `hogpost.samber.dev`: configure client with `api_host: "https://hogpost.samber.dev"` and verify CORS allows the new domain (test with browser console or `curl -H "Origin: https://newsite.com" -I https://hogpost.samber.dev/decide`)
  - If `set-up-new-proxy`: add path rewrite in `next.config.js` to `us.i.posthog.com` and `us-assets.i.posthog.com`, init client with `api_host: "/ingest"`
  - If `skip-PostHog`: skip
- [ ] Google Search Console: site verified (DNS TXT or HTML file), sitemap submitted
- [ ] Bing Webmaster Tools: site verified, sitemap submitted, IndexNow key file at `/{key}.txt` on root (verify with `curl -sI https://example.com/{key}.txt`)
- [ ] Ahrefs: site added to dashboard for tracking
- [ ] Add the site to the internal stats spreadsheet (PostHog properties registry + GitHub Sponsors tracking sheet if applicable)

**Brand monitoring (Google Alerts):**

For each alert, use these settings: **Frequency**: once a day | **Sources**: Automatic | **How many**: All results | **Region**: Any region

Set up one alert per keyword via alerts.google.com:

- [ ] Domain name (e.g., `example.com`)
- [ ] Brand or product name (quoted if multi-word, e.g., `"My Brand"`)
- [ ] Key feature or library names if the site documents a project
- [ ] Competitor brand names (optio
