It's Wednesday afternoon. The launch is scheduled for Friday morning. The developers have flagged the build as ready, the content team has signed off on the copy, and the marketing emails are already queued in the sending platform. You open the staging URL one last time, and within thirty seconds you find two things that feel wrong.
That's the thing about shipping a website: every launch has a list of small issues no one noticed until the final review. Without a structured QA pass, half of them make it to production. With one, you catch them — but only if the checklist is actually actionable and the feedback you leave is clear enough to fix.
This is the pre-launch website QA checklist we use ourselves. It's opinionated, practical, and ordered by the cost of missing something once the site goes live.
Why a Structured Pre-Launch QA Pass Matters
Teams that skip structured QA don't skip QA — they just do it reactively, after real users find the bugs. The cost of that trade-off is rarely visible in the moment, but it compounds quickly: a broken checkout on launch day loses revenue, a missing meta description tanks your first week of SEO, a CLS issue on mobile ruins your Core Web Vitals before Google even indexes the page.
A structured checklist does two things at once. It forces you to look at the site through the lens of a user, not a builder. And it gives you a shared reference that non-technical stakeholders — clients, marketing, legal — can follow without needing to understand the codebase.
Rule of thumb: if you can't document a QA issue in a way a developer can fix without asking you questions, the issue will survive launch day.
The Pre-Launch Website QA Checklist
Go through these sections in order. Each one targets a different failure mode — content, layout, performance, accessibility, SEO, functionality, and legal. Don't skip ahead: the earlier categories catch issues that make the later ones irrelevant.
1. Content and Copy
Content errors are the most embarrassing bugs to ship. They're also the easiest to catch if you actually read the page instead of scrolling past it.
- No typos, grammar errors, or leftover placeholder text (watch for 'Lorem ipsum', 'TODO', 'Your headline here')
- All dates, prices, and statistics are current and accurate
- Author names, titles, and bios are correct
- Legal pages exist and are up to date: Privacy Policy, Terms of Service, Cookie Policy
- Contact information (email, phone, address) is correct everywhere it appears
- No broken or empty sections — every CMS field is populated
- Brand voice and tone are consistent across pages
2. Responsive Design and Layout
Responsive bugs hide between breakpoints. Don't just test the three widths your designer used in Figma — resize the browser continuously from 320px to 1920px and watch what happens.
- Mobile (320–480px): no horizontal scroll, no text cut off, touch targets at least 44x44px
- Tablet (768–1024px): navigation adapts correctly, images scale without distortion
- Desktop (1280px+): content doesn't stretch awkwardly on ultra-wide screens
- Between breakpoints: no layout shifts, overlapping elements, or collapsed gaps
- Images load at appropriate resolutions for each viewport (no 4000px hero on mobile)
- Forms remain usable at every width — labels visible, fields tappable, errors readable
- Fixed/sticky headers don't cover content when anchor links scroll to sections
3. Cross-Browser Compatibility
- Chrome, Safari, Firefox, and Edge on desktop
- Safari on iOS (iPhone + iPad) — this is where most CSS surprises live
- Chrome on Android
- Check font rendering differences — especially custom web fonts on Windows Chrome
- Test interactive elements (hover states, animations, modals) in each browser
4. Performance and Core Web Vitals
Google weighs Core Web Vitals directly in search ranking. A slow launch doesn't just feel bad — it actively hurts your visibility in the weeks that follow.
- Largest Contentful Paint (LCP) under 2.5 seconds on mobile 4G
- Cumulative Layout Shift (CLS) under 0.1 — no elements jumping as the page loads
- Interaction to Next Paint (INP) under 200ms
- Images are compressed and served in modern formats (WebP, AVIF)
- Hero images and above-the-fold content are prioritized (preload, fetchpriority)
- Fonts use font-display: swap to avoid invisible text during load
- No render-blocking third-party scripts above the fold
- Run Lighthouse on at least three representative pages and record the scores
5. Accessibility (a11y)
Accessibility isn't a nice-to-have. It's a legal requirement in many jurisdictions and a usability baseline for everyone else. These are the checks that catch the highest-impact issues fastest.
- Every image has meaningful alt text (or alt="" for decorative images)
- All interactive elements are reachable and operable via keyboard (Tab, Enter, Esc)
- Focus states are visible — never remove outlines without replacing them
- Color contrast meets WCAG AA (4.5:1 for body text, 3:1 for large text)
- Headings follow a logical order (h1 → h2 → h3, no skipped levels)
- Forms have associated labels and clear error messages
- Videos have captions, audio content has transcripts
- The page is understandable with a screen reader (test with VoiceOver or NVDA)
6. SEO and Metadata
- Every page has a unique, descriptive <title> tag (50–60 characters)
- Every page has a meta description (140–160 characters)
- Open Graph and Twitter Card tags are set — test them with the Facebook and Twitter validators
- Canonical URLs are defined for pages with query parameters or pagination
- robots.txt is present and correctly configured (not blocking production by accident)
- sitemap.xml exists, is up to date, and is submitted to Google Search Console
- No staging URLs, dev domains, or localhost references in canonical tags or internal links
- Structured data (JSON-LD) is valid for articles, products, or breadcrumbs
- Redirects from old URLs are in place (301s, not 302s, for permanent moves)
7. Functionality and Forms
- Every form submits successfully and sends the expected confirmation email
- Form validation shows clear errors for invalid inputs
- Every CTA and button routes to the correct destination
- Every internal link resolves — no 404s
- External links open with the correct target and rel attributes
- Search, filters, and pagination work end to end
- Authentication flows (login, signup, password reset) complete without errors
- Payment and checkout flows process test transactions correctly
- Error pages (404, 500) exist and look on-brand
8. Analytics, Tracking, and Consent
- Analytics (GA4, Plausible, Fathom, etc.) fires correctly on every page
- Conversion events are tracked on key actions (signup, purchase, contact form)
- Cookie consent banner appears for EU users and respects their choice
- Tracking scripts only load after consent where required by GDPR
- No leftover debug or test tracking pixels from staging
9. Security and Infrastructure
- HTTPS is enforced site-wide (HTTP requests redirect to HTTPS)
- Security headers are configured (CSP, X-Frame-Options, Strict-Transport-Security)
- No secrets, API keys, or .env variables exposed in the client bundle
- Rate limiting is in place on public forms and auth endpoints
- Backups are scheduled and a rollback plan is documented
- DNS, SSL certificate, and CDN are configured for the production domain
Running the Checklist: A Real Pre-Launch Walkthrough
A checklist only works if you can turn the issues you find into fixes. Here's how a typical pre-launch QA pass actually unfolds on a live staging URL.
You're reviewing a new marketing site two days before launch. You open the staging URL, resize the browser to 375px, and start scrolling. In the first three minutes, you spot five issues across the checklist categories:
Content — The pricing page still shows the old €29 tier instead of €39. You circle the price and drop a sticky note: "Needs to be €39/month per the new pricing sheet approved on April 10."
Responsive — On iPhone SE width (375px), the hero CTA button overlaps the nav on scroll. You draw an arrow between the two elements and annotate: "Sticky nav z-index covers the CTA when scrolling up. Needs 16px bottom padding on nav or z-index fix on CTA."
Performance — The hero image is a 2.4 MB PNG loading on mobile. You highlight the image and note: "LCP element. Convert to WebP and serve a 750px variant below 768px viewport."
Accessibility — Three feature icons have no alt text. You circle the icon row and add: "Add alt=\"\" for decorative icons, or descriptive alt if they convey meaning."
SEO — The About page title tag still reads "Untitled". You highlight the page and note: "Needs <title>About — [Brand Name]</title> and a meta description."
Each issue is visible where it lives — on the actual page, in the actual browser, at the actual viewport. The developer doesn't need to decipher a vague Slack message or recreate the context. They open the annotated page and see the problem in situ.
Why Visual Documentation Beats a Spreadsheet
Most pre-launch QA ends the same way: a spreadsheet or Jira list with rows like "Pricing page — button misaligned on mobile — fix." Two hours later, the developer opens the ticket and asks which page, which button, which breakpoint, and what misaligned means. The feedback loop starts over.
Visual documentation skips that loop entirely. Instead of describing an issue in text and asking the developer to find it, you pin a note directly to the element — on the real page, at the real viewport — and share the annotated view. There's no translation step, no ambiguity, no follow-up questions.
For a pre-launch QA pass specifically, this matters because you're usually documenting 15–30 issues under time pressure. Every second spent describing where a problem is instead of showing it is a second the developer won't have to actually fix it before launch.
Tips for Running QA Efficiently Before Launch
- Do the QA pass in a single uninterrupted session — context-switching between issues slows you down
- Start from the homepage and follow the user journey as if you'd never seen the site before
- Test on real devices, not just browser DevTools emulation — iOS Safari has quirks you'll never catch in Chrome's mobile view
- Review with caching disabled and in incognito mode — you need to see what a first-time visitor sees
- Have a second pair of eyes do an independent pass — you'll miss things you built yourself
- Keep a 'won't fix for launch' list — some issues aren't blockers and deserve a post-launch ticket, not a scramble
- Annotate as you go — never leave an issue in your head hoping you'll remember it in ten minutes
Ship With Confidence, Not With Crossed Fingers
A pre-launch website QA checklist doesn't guarantee a flawless launch. But it does guarantee that the issues making it to production are the ones you chose to accept — not the ones you didn't know about. That's the difference between shipping with confidence and shipping with crossed fingers.
Work through this checklist top to bottom on staging. Document every issue visually, where it lives. Hand the annotated pages to your developers with enough precision that they can fix without a single follow-up question. Then launch.
Running a pre-launch QA pass today? Try annotating this page right now — circle something, drop a sticky note, draw an arrow. In a few seconds you'll see how much clearer visual feedback is than a spreadsheet row.