Website Testing Checklist: What to Test Before Launch

Before launching a website, test the tasks visitors need to complete, the templates they will use, and the experience on the devices and browsers your audience relies on. Check forms with realistic data, review accessibility with both tools and people, inspect performance, and confirm analytics and monitoring work. An automated audit can surface issues, but it cannot give the site a complete readiness verdict.

Use this checklist as a risk-based review: prioritize the pages and actions that matter most to your site, record problems and owners, fix launch blockers, and rerun the relevant checks after changes.

1. Define what must work at launch

Start with the site’s purpose and the people who will use it. List the most important tasks from the visitor’s first page through completion. Examples might include finding a service, comparing options, submitting an inquiry, creating an account, or locating support. These examples are prompts, not a universal launch standard.

Identify the highest-priority visitor tasks and the pages involved in each.
List the templates in use, such as landing pages, articles, product pages, and forms.
Choose representative desktop and phone sizes, browsers, operating systems, and input modes based on your audience.
Assign someone to each issue and agree how the team will record severity, status, and retest results.

This risk-based setup keeps the review focused. A site with a critical inquiry form should spend more review time on that form and its confirmation path than on a rarely used decorative page.

2. Walk through core journeys, links, and content

Test each important journey from entry to completion, using the actual site and realistic visitor behavior. Check that the promised next step is clear and that every control does what its label suggests.

Open the site from likely entry points, including the home page and representative landing pages.
Use the main navigation, menus, calls to action, buttons, and in-page links.
Follow links to internal and external destinations; look for missing, incorrect, or unexpected destinations.
Check that page headings, instructions, prices or service details, and contact information are accurate for the launch.
Complete the task and verify the next step: confirmation, receipt, account state, or contact route.
Repeat with keyboard, mouse, and touch where those input methods are relevant.

Do not only inspect pages in isolation. A page may look correct while the path into it, the action it offers, or the result after submission is broken.

3. Test forms with varied, realistic input

Forms deserve a full pass on desktop and phone. Check labels, required fields, validation, error recovery, successful submission, and the confirmation or next step. The web.dev guide recommends testing forms across devices, browsers, operating systems, and input modes, using varied realistic values and watching real people use them. Read web.dev’s form testing guidance.

Submit with required fields empty and confirm that errors identify what needs attention.
Enter valid values and submit; verify that the intended result is recorded and a useful confirmation appears.
Try realistic variations such as long names, different address formats, optional fields left blank, and values with punctuation where appropriate.
Test invalid formats and boundary cases relevant to the fields, such as an incorrectly formatted email address.
Use keyboard navigation and touch input. Make sure the keyboard does not obscure fields or the submit control on a phone.
Correct an error and resubmit. Confirm that valid entries are retained and the error clears.
Check the result from the visitor’s point of view: is the next action obvious, and is the message understandable?

Whenever possible, ask a person who did not build the form to complete it without coaching. Their confusion can reveal unclear labels or steps that a code review will miss.

4. Check responsive layouts and browser coverage

Review representative pages at the sizes and in the browsers your audience uses. Look for content that is clipped, overlaps, becomes too small to use, or changes order in a way that obscures the task. Test navigation, forms, menus, and important buttons with touch as well as mouse and keyboard.

Check at least a representative desktop and phone layout; include other sizes important to your audience.
Review the operating systems and browsers that matter to your users.
Inspect long headings, images, tables, menus, and form errors at narrow widths.
Check orientation or zoom behavior when it is relevant to the page.
Record the browser, operating system, viewport, and input method with each issue so another person can reproduce it.

Local devices and browsers are useful for direct debugging. If the team does not have access to the relevant combinations, a hosted cross-browser service such as BrowserStack is one option for widening the test matrix. Choose coverage based on your audience and workflow; no single device matrix guarantees that every visitor’s setup has been covered.

5. Review accessibility with tools and people

Make an introductory pass for image alternatives, heading structure, contrast, text resizing, keyboard access and visible focus, form labels and errors, moving content, media alternatives, and page structure. These checks can uncover issues, but they do not establish that a site conforms to accessibility standards.

Navigate pages and complete key tasks with a keyboard; confirm focus is visible and follows a useful order.
Check that images conveying information have useful text alternatives and decorative images do not add noise.
Review heading hierarchy, form labels, instructions, and error messages.
Check text resizing and contrast, and look for content that depends only on color.
Review moving content and provide alternatives for relevant audio or video.

W3C’s Web Accessibility Initiative says, “no tool alone can determine if a site meets accessibility standards.” Combine automated tools with knowledgeable manual evaluation and, where possible, feedback from people with disabilities. W3C’s evaluation overview explains the role and limits of evaluation tools. Its Easy Checks are intentionally a first review: a page that appears to pass may still have significant barriers.

6. Audit performance, SEO, and best practices

Use Lighthouse to identify potential performance, SEO, best-practice, and accessibility issues, then investigate the findings that matter for your pages. PageSpeed Insights reports performance and may provide both lab and field information where available. Lab data comes from a controlled test; field data reflects real-user conditions. Compare results before and after a change rather than treating one score as a guarantee. See web.dev’s testing guidance for the distinction between lab and field data.

Run an audit on representative templates and important landing pages.
Read the findings and identify the underlying issue; do not assume every recommendation has equal impact for your users.
Fix and rerun the relevant audit so you can see whether the change helped.
Use field information when available to understand real-user experience, alongside controlled lab results.

For a visual review, capture representative pages at the viewport sizes your team uses and compare them after important changes. A screenshot is useful for spotting layout shifts, missing sections, and unexpected visual differences; it does not replace interaction, accessibility, or performance checks.

7. Verify analytics and plan monitoring

If measurement is part of the site’s goals, confirm analytics is present and that important events can be observed. For example, complete a key form and check that its completion is measurable. Decide who will monitor real-user experience after release and how the team will investigate issues that only appear on particular devices or networks.

Confirm the expected analytics setup is present on representative templates.
Trigger important events, such as a form completion, and verify they are observable in the intended reporting workflow.
Document who will review post-release signals and how issues will be escalated.
Recheck real-user experience after release; controlled pre-launch checks cannot represent every real device and network condition.

8. Capture pages for a visual release review

Screenshots make it easier to review representative templates and compare how a page looks across viewport sizes or after a change. They are evidence for a visual pass, not a complete test result: a screenshot cannot tell you whether a form submits, keyboard focus works, or a page performs well.

Capture a page with Playwright

Install Playwright and its Chromium browser, save the following as capture.mjs, and run it with node capture.mjs https://example.com. It captures the page and writes a full-page PNG. Use a site you are authorized to review.

import { chromium } from 'playwright';

const target = process.argv[2];
if (!target) {
  throw new Error('Usage: node capture.mjs https://example.com');
}

const browser = await chromium.launch();
const page = await browser.newPage({
  viewport: { width: 1440, height: 1000 },
  deviceScaleFactor: 1
});
try {
  await page.goto(target, { waitUntil: 'networkidle', timeout: 60000 });
  await page.screenshot({ path: 'page-desktop.png', fullPage: true });
} finally {
  await browser.close();
}

Install and run:

npm install playwright
npx playwright install chromium
node capture.mjs https://example.com

Playwright supports a range of capture settings. Use a fixed viewport to make comparisons repeatable; set deviceScaleFactor when you need a different pixel density; use fullPage: true for a full-page image; or capture a specific locator when you only need one component. For example, replace the screenshot call with await page.locator('main').screenshot({ path: 'main.png' });. For interactive or delayed pages, wait for a meaningful selector with await page.locator('main').waitFor(); or use an appropriate delay. Avoid assuming that network idle means every lazy-loaded asset or application state is ready.

Capture the same page with cURL

For a one-off visual reference, take a screenshot using ScreenshotNeo’s API. Replace the target URL and API key with your own values. See the ScreenshotNeo API documentation for request options.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -o page.webp

Capture with Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://example.com"},
    timeout=90,
)
r.raise_for_status()
open("page.webp", "wb").write(r.content)

Capture with Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://example.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const bytes = new Uint8Array(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('page.webp', bytes));

Screenshot options and edge cases

ScreenshotNeo supports full-page capture with lazy images loaded, CSS-selector element capture, dark mode, 12 device presets and custom viewports, retina scale, image formats including PNG, JPEG, and WebP, custom CSS and JavaScript, clicking an element before capture, hiding selectors, and waiting for a selector, delay, or network idle. It can also block ads, trackers, requests, or resource types; set headers, cookies, user agent, authorization, timezone, and geolocation; use transparent backgrounds; resize images; cache with a chosen TTL; create signed links for public image tags; run asynchronous jobs with signed webhooks; capture up to 100 URLs per bulk call; and expose usage and OpenAPI interfaces. Screenshot API parameter names used by other providers also work, which can simplify switching. PDF options include paper size, margins, landscape, and page ranges. See the docs for parameter details and request syntax.

For browser-based capture, a page may render differently based on authentication, consent state, network timing, fonts, or third-party scripts. Use representative state, wait for a stable page element when needed, and keep viewport and browser settings consistent when comparing captures. For repeated captures, consider whether caching is appropriate; refresh when you need to inspect the current page rather than a cached result.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. One GET request returns an image or PDF, and the same capture can support a visual review without installing a browser automation stack.

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://example.com \
  -o shot.webp

Cookie banners are accepted like a visitor would accept them, and 60+ known consent platforms, newsletter popups, and chat widgets are removed before the shot; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits cost nothing, and response headers say what the page verdict was and whether the request was billed. An MCP server gives AI agents tools to take screenshots, get page information, and capture PDFs. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for 1,000 free screenshots a month, with no card required.

9. Troubleshoot common review failures

Symptom	Likely cause	What to do
A form appears to submit but no confirmation arrives	The submission path, integration, or confirmation state may not be working as expected.	Repeat the task with valid data, inspect the user-facing result, and verify the intended event or outcome with the responsible team.
Errors do not explain how to fix a form field	Validation feedback may be missing, unclear, or disconnected from the field.	Review labels, instructions, and error messages; test keyboard navigation and correction after an error.
A page looks broken only on a phone or another browser	The layout or interaction may behave differently at that size or in that browser.	Record the viewport, browser, operating system, and input method; reproduce on a matching setup and retest after the fix.
An accessibility scan reports issues, or reports none	Automated results identify potential issues but cannot evaluate every barrier or establish conformance.	Investigate findings manually and include knowledgeable human evaluation; do not treat a clean scan as proof of accessibility.
A performance score changes between runs	Controlled test conditions and page state can vary, and lab results differ from field experience.	Compare like with like, inspect the underlying findings, rerun after changes, and consider field data where available.
A screenshot is blank, incomplete, or unexpectedly different	The page may need more time, a relevant selector, a particular state, or a consistent viewport; lazy content may not yet be ready.	Wait for a meaningful element or state, check the target URL and access conditions, and keep capture settings consistent. With ScreenshotNeo, inspect the page-verdict and billing headers; failed loads and blank pages are not billed.
An analytics event is not visible	The tracking setup or the event path may not be configured as expected.	Repeat the intended visitor action and confirm with the person responsible for analytics that the event is observable in the chosen reporting workflow.

10. Make the final release pass

Run the key visitor journeys on the actual site and representative templates.
Review the issue list, assign owners, and resolve launch-blocking problems.
Rerun checks affected by each change, including the journey or template that exposed the issue.
Record remaining known issues and the person responsible for follow-up.
Confirm the post-release monitoring plan and who will respond to problems seen under real user conditions.

This is a practical release review, not a formal universal gate. The right checks depend on what the site does and who relies on it.

Frequently asked questions

Can a Lighthouse score prove that a site is ready to launch?

No. Lighthouse can flag potential issues across several audit categories, but readiness also depends on user journeys, real form behavior, accessibility evaluation, and the site’s goals.

How many browsers and devices should I test?

Choose representative combinations based on your audience and the tasks your site supports. Include relevant desktop and phone layouts, browsers, operating systems, and input methods, then widen coverage if your users or risk profile call for it.

Should every page be tested manually?

Prioritize important journeys and representative templates, then check other pages for unique content or behavior. A shared template review does not cover a page with different functionality or content.

Do screenshots replace browser testing?

No. Screenshots help with visual review, while interaction, accessibility, submission behavior, and performance require other checks.

Is passing W3C Easy Checks enough?

No. W3C describes Easy Checks as an initial review; a page that appears to pass can still have significant accessibility barriers.