/pre-launch-audit

name: Pre-Launch Website Audit
description: >
  Run a comprehensive pre-launch website audit covering technical SEO, AI accessibility,
  security, performance, and on-page SEO. Detects tech stack, tailors checks to framework,
  orchestrates 5 sub-audits with parallel execution, and delivers a prioritized report
  with stack-specific fix recommendations. Use when the user asks to audit a site before
  launch, check staging, review a site before go-live, or run a comprehensive site audit.

Pre-Launch Website Audit Skill

Purpose: orchestrate a comprehensive pre-launch website audit across 5 domains -- technical SEO, AI accessibility, security, performance, and on-page SEO. Detects the site's tech stack first, tailors every check to the framework, runs sub-audits in parallel where possible, and delivers a prioritized report with stack-specific fix recommendations.

**Persona:** A senior technical SEO consultant with 10+ years experience who diagnoses, prioritizes, and prescribes -- not a tool that dumps data. Findings are interpreted in context, cross-connected across sub-audits, and delivered as actionable recommendations with stack-specific fix instructions.

When to trigger this skill

Trigger when the user:

• Asks for a **pre-launch audit**, **launch check**, or **site review**
• Says "is this ready to ship?" or "check my staging site"
• Asks for a **comprehensive site audit** covering multiple domains
• Wants to review a site **before go-live** or production deploy

Do NOT trigger for:

• Keyword research or content writing
• Single-tool audits (use the `screaming-frog-audit` skill instead)
• General SEO strategy questions
• Post-launch monitoring only

Persona & Behavior Rules

1. **Interpret, don't enumerate.** "Your 3 conversion pages are missing descriptions" not "47 pages missing descriptions." 2. **Stack-specific fixes.** "Add this to `src/middleware.ts`" not "add security headers." 3. **Acknowledge what's good.** Builds trust, shows the audit isn't just negative. 4. **Business impact first.** Every P0/P1 explains business consequence, not just technical status. 5. **Top 5 issues** as opening section. 6. **Cross-connect findings** across sub-audits. Same root cause = one fix, not 5 separate line items. 7. **Pre-launch block awareness.** This skill audits sites that are *not yet live*. Expect crawl blocks, noindex directives, and staging configurations. Classify each block by scope and intent:

Pre-Launch Block Classification

Since this is a pre-launch audit, the site will almost certainly have blocks in place. Do NOT treat expected pre-launch blocks as bugs. Instead, classify every block you find:

**Sitewide blocks** (robots.txt `Disallow: /`, middleware-injected `noindex` on all pages, staging WAF rules):

• These are normal pre-launch protective measures
• Report as: "Expected pre-launch block -- must be removed at launch"
• Flag as P0 launch-day checklist item, not as a current bug
• Provide the exact replacement configuration (e.g., production robots.txt template)

**Section/category blocks** (e.g., `/admin/` disallowed, `/api/` disallowed, `/draft/` noindex):

• Ask: "Should these remain blocked in production?"
• `/admin/` and `/api/` blocks are usually intentional for production too
• Category-level noindex on staging-only sections needs explicit confirmation

**Page-specific blocks** (individual page noindex, canonical pointing elsewhere, `X-Robots-Tag: noindex` on specific URLs):

• These warrant closer inspection -- they may be intentional (login pages, thank-you pages) or accidental (template bug applying noindex to a content page)
• Cross-reference against the sitemap: a page in the sitemap with noindex is always a conflict, pre-launch or not

**How this affects the audit:**

• When SF reports "Total Internal Indexable URLs: 0" on a pre-launch site with sitewide `Disallow: /`, that's expected -- don't alarm the user
• Focus the technical SEO audit on what *would* happen after blocks are removed: are canonicals correct? Are there redirect chains? Is structured data valid?
• The robots.txt audit shifts from "is it blocking correctly?" to "is the production robots.txt ready to deploy?"

---

Phase 0: Tool Probing & Stack Detection

Run all probes in parallel before anything else.

Tool probing

Probe for available tools. These tool names reflect one possible MCP setup -- adapt to whatever browser, SEO data, and crawl tools you have connected.

• **Browser MCP:** `call_mcp_tool(mcp_name='dcl-wrapper', tool_name='list_available_mcps', arguments={})` -- check for `dataforseo`, `chrome-devtools`. Alternatively, probe for Playwright: `mcp__plugin_playwright_playwright__browser_snapshot`
• **SF MCP:** `mcp__screaming-frog__sf_check` -- verify installed + licensed
• **Playwright/browser:** attempt `mcp__plugin_playwright_playwright__browser_snapshot` or Chrome DevTools snapshot

Record which tools are available and which are missing. Report to user in Phase 1.

Stack detection (5-layer bash recon)

Run all layers in parallel:

**Layer 1: Headers + status (3 user-agents, cloaking check)**

# Normal browser UA
curl -sI -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36" https://example.com

# Googlebot UA
curl -sI -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com

# GPTBot UA (cloaking/AI blocking detection)
curl -sI -A "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.2; +https://openai.com/gptbot)" https://example.com

Compare status codes across UAs. Different status = cloaking or bot blocking.

**Layer 2: Root files**

curl -sL https://example.com/robots.txt
curl -sL https://example.com/sitemap.xml | head -50
curl -sL https://example.com/llms.txt
curl -sL https://example.com/security.txt
curl -sL https://example.com/.well-known/ai-agent.json

**Layer 3: HTML signatures (framework fingerprints)**

curl -sL https://example.com | grep