launch-gotchas

launch-gotchas

The stuff that usually only lives in someone's head after they've shipped a few sites and gotten burned. Read it before a launch so you recognize the trap, and during a launch when something won't verify. Stack specifics (Cloudflare / Yoast / Next.js / Semrush) are illustrative common-stack examples — each lesson states the underlying principle so it survives a stack swap.

The meta-lesson

"Done" is not "Verified." Most entries below are a variation of the same root failure: someone marked something complete, and the objective check was never run — or was run with the wrong tool. Every prevention here reduces to run the real check, independently, before closing the item.

---

Verification & audit-tool traps

Done-without-verification (the crown jewel)

What happened: A duplicate-canonical issue was marked Done. Two weeks later search-console validation FAILED — several URLs still affected. The redirect was working; the canonicalization wasn't. Root cause: A single user-visible symptom can have multiple independent mechanisms behind it: redirect rule + canonical tag + internal href + sitemap entry. Fixing one and seeing the symptom partly improve reads as "done." Prevent: Never accept "Done" without independent re-verification. Enumerate every mechanism that contributes to the item and verify each before closing.

Audit-tool blind spots

What happened: A crawler's default mode didn't execute JavaScript. On a JS-rendered site it reported false-positive missing H1s, low word count, and low text-to-HTML ratio on pages that were actually fine when rendered. Root cause: The audit tool and the browser see different DOMs. Prevent: Cross-verify any crawler finding against curl-rendered HTML and browser DevTools before escalating to engineering. Use a JS-rendered crawl if the tool supports it. Build the cross-check into the audit workflow.

Env-gated backend read as "fully static"

What happened: A site/scale audit read the code in a keyless/dev state and concluded "fully static, no backend, no DB — scales to 10k trivially." It was wrong: the site had a live env-gated Supabase backend (magic-link + Google OAuth, a CRUD table with share slugs, a telemetry table, an admin dashboard) plus a "static" /emulator route that actually proxy-rewrote to a separate deployment. The backend client only initializes when env vars are present and degrades to local-only when absent — so the keyless read saw a fallback and called it static. Root cause: "Static" is a delivery claim, not a code-only property. The same bundle is static in dev and backend-driven in prod, decided purely by which env vars are set; conditional init (if (SUPABASE_URL) createClient()) makes a live backend invisible to a keyless read. The audit graded the wrong state. Prevent: Never conclude "static / no backend / scales trivially" from code alone. Read .env* and trace the gating (populated keys = LIVE in prod); grep deps + src for backend SDKs even when usage is conditional (supabase/@clerk/firebase/prisma/drizzle/server SDKs); check vercel.json/netlify.toml/next.config.* for rewrites/proxies to other deployments; then, if a backend exists, audit the scale ceilings — auth/SMTP rate limits (the classic first failure for free magic-link), DB tier limits (connections/auto-pause/storage), and RLS / anon-key authorization. First-timer rule: if the site has a sign-in button, a save/share feature, or an admin page, it HAS a backend — open the .env and check. (Full required checklist: factory/playbooks/mvp-stage/security-checklist.md → Backend reality check.)