Every agency has that one project where something slipped through the cracks. A missing favicon. A staging robots.txt blocking the live site from Google. A contact form sending to an inbox nobody owns anymore. After years of shipping client websites, we’ve turned our pre-launch QA into a strict ritual, and this is the exact web design checklist before launch we use internally at isfuckingbrilliant.com.
Unlike the generic 50-point lists floating around, this one is built from real client launches in 2025 and 2026. It covers what designers actually forget, not what looks good in a blog intro.
Why a Pre-Launch Checklist Matters More in 2026
Core Web Vitals are stricter, accessibility lawsuits are climbing, and clients now expect AI-readable content, schema, and mobile-perfect rendering on day one. Launching without a structured QA pass is the fastest way to lose a retainer.
Our checklist is split into five working blocks: Design & UX, Content, Performance, SEO, and Accessibility & Security. Run them in order. Don’t skip ahead.
Block 1: Design & UX Verification (Items 1 to 6)
1. Cross-Browser Rendering
Open the site in Chrome, Safari, Firefox, and Edge. Pay special attention to Safari on iOS, which still handles flexbox gaps and custom fonts differently.
2. Responsive Breakpoints
Test at 320px, 375px, 768px, 1024px, 1440px and 1920px. Don’t trust DevTools alone, use a real device for at least one pass.
3. Favicon and App Icons
Include the full set: 32×32, 180×180 apple-touch-icon, and a maskable PWA icon if relevant.
4. 404 and 500 Pages
Custom designed, with a clear path back to the homepage or search.
5. Hover, Focus and Active States
Every interactive element needs visible states. Focus rings are non-negotiable for keyboard users.
6. Empty States
Empty cart, empty search results, empty blog category. Designers forget these constantly.
Block 2: Content QA (Items 7 to 10)
- 7. Proofread everything. Run Grammarly, then read it aloud. Client-provided copy almost always has typos.
- 8. Replace all Lorem Ipsum. Search the codebase for “lorem”, “placeholder”, and “TODO”.
- 9. Image alt text on every visual. Decorative images get an empty alt=””, not a missing one.
- 10. Legal pages live. Privacy policy, terms, cookie policy, and a working cookie banner that respects GDPR and the latest 2026 ePrivacy updates.
Block 3: Performance (Items 11 to 15)
Google’s thresholds for Core Web Vitals are tight. Here’s what we test and the targets we aim for before any launch.
| Metric | Target | Tool |
|---|---|---|
| LCP | Under 2.5s | PageSpeed Insights |
| INP | Under 200ms | Chrome UX Report |
| CLS | Under 0.1 | Lighthouse |
| TTFB | Under 600ms | WebPageTest |
- 11. Image optimization. Serve WebP or AVIF, lazy-load below the fold, set explicit width and height.
- 12. Minify CSS, JS and HTML. Enable Brotli compression on the server.
- 13. Font loading strategy. Use font-display: swap and preload your hero font.
- 14. CDN active. Cloudflare, Bunny, or your host’s edge network.
- 15. Caching layers configured. Browser cache, object cache, and full-page cache where possible.
Block 4: SEO (Items 16 to 20)
16. Unique Title Tags and Meta Descriptions
Every indexable page needs one. No duplicates.
17. robots.txt and Sitemap.xml
Remove any “Disallow: /” left over from staging. Submit the sitemap to Google Search Console.
18. 301 Redirects from Old URLs
If you’re replacing an existing site, map every old URL to its new equivalent. Never let old pages return a 404.
19. Schema Markup
Organization, LocalBusiness, Product, Article, or FAQ schema depending on the page type. Validate with Schema.org’s tool.
20. Open Graph and Twitter Cards
Test how the site previews on LinkedIn, X, WhatsApp, and iMessage. Generic previews kill click-through.
Block 5: Accessibility & Security (Items 21 to 25)
- 21. Keyboard navigation. Tab through the entire site. Every interactive element must be reachable and visibly focused.
- 22. Color contrast. WCAG 2.2 AA minimum. Use the Stark plugin or axe DevTools.
- 23. Form labels and ARIA. Every input gets a real label, not just a placeholder.
- 24. HTTPS everywhere. SSL valid, mixed content fixed, HSTS header set.
- 25. Backups and monitoring. Automated daily backup, uptime monitor (UptimeRobot, BetterStack), and a security plugin or WAF active.
The Final Pre-Launch Hour: Our Agency Workflow
Once the 25 items pass, we run a final 60-minute window before flipping DNS:
- Take a full site backup of staging.
- Push to production.
- Update DNS records and lower the TTL beforehand.
- Install the live SSL certificate and force HTTPS.
- Verify Google Analytics 4 and Search Console are firing.
- Submit the sitemap.
- Run Lighthouse one last time on the live URL.
- Send the client a launch confirmation with credentials and a 30-day support window.
What Most Checklists Get Wrong
The lists you’ll find on bigger publisher sites cover the basics, but they rarely address the items that break real client launches: forgotten staging noindex tags, broken transactional emails, unmonitored form spam, and missing consent mode v2 for Google Ads. Add those to your version of this checklist and you’ll already be ahead of 80% of agencies.
FAQ
What are the 7 C’s of website design?
Context, Content, Community, Customization, Communication, Connection, and Commerce. They map nicely to most of the checklist blocks above, especially content and UX.
What should be included in a website launch checklist?
At minimum: cross-browser testing, responsive QA, content proofing, image optimization, Core Web Vitals, SEO meta and schema, redirects, accessibility, SSL, backups, and analytics. The 25 items above cover all of this.
How do you test a website before launching?
Use a staging environment protected by HTTP auth, run Lighthouse and axe DevTools, test on real mobile devices, send the staging URL to two people who didn’t build it, and run all forms through to confirm the emails actually arrive.
How long should pre-launch QA take?
For a 10 to 20 page brochure site, plan one to two full working days of QA. For ecommerce, plan three to five days including transactional testing.
Can I automate this checklist?
Partially. Lighthouse CI, axe-core, and broken-link checkers can be scripted. But cross-browser rendering, copy QA, and design polish still need a human eye.
Final thought: a launch is not the end of a project, it’s the start of the maintenance relationship. The cleaner your pre-launch QA, the smoother the next twelve months will be for you and your client.