The Complete Pre-Launch Website Checklist (40+ Things to Check)

Most launch-day issues aren't exotic - they're the same handful of things nobody double-checked because there wasn't a launch checklist. Here's the one we use, grouped by the five areas that actually matter: performance, SEO, accessibility, security, and code quality.

Performance

Slow pages lose visitors before they see anything else - and since 2021, Core Web Vitals are also a direct Google ranking factor. See our Core Web Vitals guide for the deep dive on any of these.

• LCP under 2.5s on your key landing pages
• INP under 200ms on your main interactive elements
• CLS under 0.1 - no layout jumping as the page loads
• Images served in a modern format (AVIF/WebP) and properly sized
• Hero image or LCP element preloaded
• Fonts set to font-display: swap with a size-matched fallback
• Render-blocking CSS/JS out of the initial paint path
• Third-party scripts (analytics, chat, ads) audited for what's actually necessary
• Static assets and pages served through a CDN

SEO

Technical SEO issues are invisible to visitors and fatal to discoverability.

• Every page has a unique, descriptive <title>
• Every page has a unique meta description
• Canonical URLs set correctly, especially on any page reachable by multiple URLs
• Open Graph and Twitter Card tags present for social sharing
• robots.txt isn't accidentally blocking pages you want indexed
• sitemap.xml exists, is linked from robots.txt, and is actually current
• Structured data (JSON-LD) validates for any page type that supports rich results
• No orphaned pages - everything reachable is linked from somewhere
• Redirects (not dead links) in place for any URL that changed during the rebuild
• H1 present and unique on every page - not skipped, not duplicated

Accessibility

Accessibility issues are also usability issues for everyone else - and increasingly a legal exposure, not just an ethical one.

• Every image has meaningful alt text (or empty alt="" if purely decorative)
• Color contrast meets WCAG AA (4.5:1 for normal text) on every text/background combination
• Every interactive element is reachable and operable by keyboard alone
• Form inputs have associated <label> elements, not just placeholder text
• Focus states are visible, not stripped via outline: none with nothing to replace them
• Heading hierarchy is logical (no jumping from H1 to H4)
• ARIA attributes used correctly where native HTML semantics fall short - and not used where native elements would just work
• Page is navigable and understandable with a screen reader, not just visually

Security

See our security headers guide for copy-pasteable examples of each of these.

• HTTPS enforced everywhere, with HSTS set
• Content-Security-Policy configured, not left off entirely
• X-Frame-Options or frame-ancestors set to prevent clickjacking
• X-Content-Type-Options: nosniff present
• Referrer-Policy set to avoid leaking full URLs to third parties
• No secrets, API keys, or .env files accidentally exposed in client-side code or public repos
• Admin/staging routes not indexable or publicly reachable
• Dependencies checked for known CVEs before launch, not after
• Cookies set with Secure, HttpOnly, and appropriate SameSite flags

Browser Behavior & UX

The things that only show up when a real browser actually runs the page - see our guide to finding broken links and JS errors.

• Every internal link resolves - no 404s from nav, footer, or in-content links
• Every form actually submits and does what it's supposed to, tested with real input
• No console errors on any key page, not just the homepage
• Site checked on mobile viewport widths, not just desktop
• Critical third-party integrations (payments, auth, chat) tested end to end
• 404 and error pages exist and are actually helpful, not the framework default

Code & Dependency Quality

See our guide to automating this in CI so it doesn't rely on someone remembering to check.

• No known-vulnerable dependencies in production package.json/lockfile
• No abandoned packages with no maintenance in years sitting in the critical path
• License compliance checked, especially for anything closed-source
• Linting and type-checking passing in CI, not just locally
• No debug flags, verbose logging, or mock data left enabled in the production build

Running the Whole List

Working through 40+ items by hand once is doable. Doing it before every deploy isn't - which is the actual reason most of this drifts after launch instead of before it. Scanverra runs the performance, SEO, accessibility, security, browser, and code-quality checks above as four connected scans instead of a manual list, so this checklist becomes something you run, not something you remember.