Guide5 min read

How to QA a Website Before Launch: SEO, Accessibility, Security & Performance Checklist

A practical pre-launch website QA checklist — SEO metadata, broken links, accessibility, security headers, responsive config and performance — plus what automated QA can and can't verify.

A laptop and notebook on a desk, ready for a pre-launch review

Shipping a site is the easy part. Shipping one that search engines can read, screen readers can navigate, browsers can trust, and phones can render — that's the part people skip under deadline pressure. This is a pragmatic pre-launch QA checklist you can run in an afternoon, plus an honest note on what automated tooling can and can't confirm for you. Where it helps, you can run these checks on any public URL with the Web QA Playground.

Why website QA matters

Most launch bugs aren't dramatic. They're a missing meta description, an H1 that never made it into the template, a form input with no label, a Content-Security-Policy nobody set, or an internal link that 404s because a slug changed. Individually minor; collectively they cost rankings, lock out users relying on assistive tech, and erode trust. A short, repeatable checklist catches them before your users do.

1. SEO metadata

Every indexable page needs a unique, descriptive <title> (roughly 15–60 characters so it isn't truncated) and a <meta name="description"> in the 50–160 character range. Add a <link rel="canonical"> to consolidate duplicate URLs, and confirm you haven't left a stray <meta name="robots" content="noindex"> from staging. Open Graph and Twitter Card tags control how the page looks when shared.

2. Headings and structure

Use exactly one <h1> that reflects the page's primary topic, and keep heading levels sequential — don't jump from <h2> to <h4>. A clean outline helps both search engines and screen-reader users understand the page.

A single renamed route can strand a dozen internal links. Crawl your own site and check every internal link resolves, and watch for orphan pages that nothing links to. The Web QA Playground includes an opt-in same-origin crawler that maps internal pages and flags broken links and orphans without hammering your server.

4. Accessibility

Automated checks catch the common, mechanical failures: images without alt text, buttons and links with no accessible name, form controls with no <label>, a missing lang attribute on <html>, duplicate ids, and a missing <main> landmark. Fix those first — then test manually with a keyboard (can you reach and operate everything?) and a screen reader. Automated tools find maybe a third of real accessibility issues; they never replace manual testing.

5. Security headers

Serve everything over HTTPS and set the headers that harden a page: Strict-Transport-Security, X-Content-Type-Options: nosniff, a framing defence (X-Frame-Options or a CSP frame-ancestors), a Content-Security-Policy, Referrer-Policy and Permissions-Policy. Avoid leaking exact server versions. These are response-header checks — non-destructive and quick to verify.

6. Responsive configuration

Confirm the page has <meta name="viewport" content="width=device-width, initial-scale=1"> and doesn't disable zoom (blocking pinch-zoom is an accessibility barrier). Note the distinction: checking the viewport configuration is not the same as rendering the layout at every device width — see the limitations section below.

7. Performance you can measure statically

Some performance signals are observable from a normal fetch: time to first byte (TTFB), HTML document size, and the number and type of resources the page references (scripts, styles, images, fonts). Bloated JS bundles, dozens of separate script requests, and oversized HTML are worth trimming before launch.

8. What automated QA can — and cannot — verify

Be clear-eyed about the boundary. Static analysis of HTML, CSS and headers can verify metadata, structure, header configuration, alt text, labels and internal-link health. It cannot measure field Core Web Vitals (Largest Contentful Paint, Cumulative Layout Shift), confirm how the layout actually renders at 320px on a real device, or judge whether your copy is any good. Those need a real browser, real devices, and a human. Any tool that reports device-verified vitals from a plain fetch is guessing — good tooling says "not available" instead.

9. How Web QA Playground performs its analysis

It fetches the public page through a server-side proxy that only reaches public hosts, forwards no cookies or credentials, and returns the HTML plus safe response headers. Your browser then runs deterministic checks over that HTML and produces an explainable 0–100 score per category — the score comes from documented, per-finding penalties, never from AI. Metrics that genuinely require browser rendering are shown honestly as "not available." Nothing you test is uploaded or stored.

10. How to interpret the findings

Treat findings as evidence, not verdicts. Each one shows the element or value it's based on, so you can decide whether it's a real problem or an intentional choice. Fix criticals (no HTTPS, missing viewport, broken structure) first; weigh warnings against your context. A perfect score isn't the goal — an understood site is.

11. Reverse-engineer the visual layer too

QA is technical health; consistency is visual health. If you want to audit a site's colors, typography, spacing and component patterns — and spot near-duplicate values or inconsistent buttons — run it through Website → Design System, which extracts the observed design values with evidence for each. It pairs naturally with a QA pass.

12. The pre-launch checklist

  • Unique <title> and meta description on every indexable page
  • Canonical set; no leftover noindex from staging
  • One <h1>; sequential heading levels
  • All internal links resolve; no unintended orphan pages
  • Images have alt; controls have labels; <html lang> is set
  • HTTPS everywhere with HSTS, nosniff, framing defence, CSP, Referrer-Policy, Permissions-Policy
  • Viewport meta present; zoom not disabled
  • Reasonable TTFB, HTML size and resource count
  • Manual keyboard + screen-reader pass
  • Real-device spot check at a few widths

Run the automated portion on any URL with the Web QA Playground, read the honest FAQ for exactly what it does and doesn't do, or browse the rest of the free tools. QA is a habit, not a one-off — the checklist gets faster every time you run it.

Edit PDFs & images in your browser — free, private, no upload.

Everything runs in your browser. Nothing leaves your device.

Explore the tools