SayCraft

← Blog

Website Testing Checklist for a Confident Release

By SayCraft Team · 2026-09-06 · 4 min read

Before launching a website, test the critical user journeys, forms and errors, navigation, content and metadata, responsive layouts, keyboard and screen-reader basics, performance, browser coverage, analytics, privacy controls, security boundaries, and deployment evidence. Record the build and environment, assign every failure, and separate passed, failed, blocked, and not-run checks. A checklist supports a release review; it is not a substitute for an accessibility audit, penetration test, or legal review where those are required.

Community signal: Prelaunch discussions often collapse into a request to check everything. The practical need is a finite, risk-based list tied to an identified build and evidence. This checklist keeps common website failures visible while stating where specialist assurance is still needed.

Release setup before the first check

Identify the exact build, target environment, test accounts, supported browsers, device widths, and critical journeys. Use synthetic data unless the test explicitly requires protected data and an approved process exists. Confirm that the environment points to the intended dependencies before trusting results.

Create one result row per check with status, evidence link, tester, defect link, and retest result. Do not mark a blocked or untested item as passed. Decide in advance who can accept residual risk and which failures stop release.

  • Record commit or build identifier and deployment time
  • List critical journeys and the expected observable outcome
  • Name supported browsers, viewport sizes, and assistive technology coverage
  • Prepare accounts for anonymous, normal, restricted, and expired states
  • Confirm analytics and consent testing will not pollute production reporting

Functional and content checklist

Run each critical journey from a clean starting state. Test normal completion, validation errors, back navigation, refresh, duplicate submission, slow responses, and dependency failure. Verify authorization on the server boundary rather than assuming a hidden button protects an action.

Read every high-value page as a visitor. Confirm titles and headings describe the page, links reach the intended destination, images have appropriate alternatives, downloadable files open, contact information is current, and error messages tell the user how to recover.

  • Navigation, logo, search, primary calls to action, and footer links work
  • Forms preserve safe input, reject invalid input, and prevent duplicate actions
  • Authentication, logout, password recovery, roles, and forbidden routes behave correctly
  • Empty, loading, success, partial, and error states are understandable
  • Page title, meta description, canonical URL, headings, and social preview are intentional
  • Robots rules, sitemap entries, redirects, and not-found responses match the release plan

Responsive, accessibility, and browser checklist

Test meaningful layouts, not only named devices. Resize from narrow mobile widths to large desktop widths and check text wrapping, navigation, tables, dialogs, sticky elements, images, and touch targets. Rotate a real mobile device when the product supports orientation changes.

Use the site without a mouse. Confirm visible focus, logical focus order, keyboard operation, useful labels, heading structure, readable zoom, sufficient contrast, understandable errors, captions or transcripts where required, and no motion that blocks use. Automated scanners can find some issues, but manual checks and user testing remain necessary.

  • No unintended page-level horizontal scrolling appears in the intended viewport range
  • Keyboard users can reach, operate, and leave every interactive element
  • Focus moves into and returns from dialogs predictably
  • Text remains usable when zoomed and controls are not obscured
  • Screen-reader names communicate the purpose of controls and landmarks
  • Critical flows work in every browser version the product promises to support

Performance, analytics, privacy, and security checks

Measure representative pages on realistic networks and hardware. Investigate oversized media, render-blocking resources, layout shifts, slow server responses, and repeated third-party calls. Keep the measurement URL, device profile, tool version, and date with the result so later comparisons are meaningful.

Trigger each important analytics event once and inspect its payload, consent state, and destination. Verify that secrets and personal data are not exposed in client code, URLs, logs, or analytics. Check transport security, cookie settings, authorization, input handling, dependency ownership, and rate limits at the appropriate boundaries. Escalate to specialist reviews when the risk requires them.

  • Core pages load and remain interactive under the agreed performance budget
  • Analytics fire once with the intended name, parameters, and consent behavior
  • Cookie and privacy controls match the product's current policy and implementation
  • Client bundles and public configuration contain no private credentials
  • Restricted data and actions remain restricted through direct requests
  • Monitoring can distinguish a healthy release from a partial dependency failure

Close the test with release evidence

Summarize what was tested, the exact build, the environments, failed and blocked checks, open defects, residual risks, and the recommended decision. Attach screenshots, recordings, logs, or reports that let another reviewer verify the important claims. A green total without scope and exceptions is not useful evidence.

If the website is still a concept, a running prototype can make the checklist concrete. SayCraft builds a live web-app preview while the team talks, so reviewers can identify the journeys and responsive states that need coverage. Test the eventual production implementation separately; prototype behavior is not production assurance.

Sources and discussion

Community posts describe individual experiences and questions; they are not treated as universal proof.

Related resources

Build the next step with SayCraft

Open your prototype in a SayCraft meeting, agree on the critical journeys while everyone can see them, and use this checklist to turn that shared view into a release test record.

Start building live →