A website QA checklist for a calmer launch

Website quality assurance is the process of checking that the finished site behaves as intended before and after release. A practical QA pass covers visitor journeys, content, forms, navigation, responsive layouts, accessibility, performance, and search visibility. Each finding needs evidence, an owner, and a clear verification step. The checklist is a guide to investigation, not a certificate that nothing can ever go wrong.

Start with the tasks that matter most. If a service business relies on enquiries, test the full enquiry journey before debating decorative spacing. If visitors need to compare plans, check that the comparison is understandable and the selected action leads to the correct place. A launch can survive a slightly imperfect illustration more easily than a contact form that sends requests into the digital equivalent of a cupboard.

Define the release scope

List the pages, features, and environments included in the release. Identify the version being tested and any known unfinished work. Without this boundary, reviewers may report defects against old pages or assume a feature is ready when it is explicitly scheduled for later. Keep the scope visible to everyone involved in approval.

Create a short list of critical journeys. Include the starting page, the intended visitor, the expected outcome, and any prerequisites. A journey might begin on a service article, continue to a consultation page, and finish with a confirmed enquiry. Testing only the destination page misses the links and context that lead people there.

Assign owners for content, functionality, design, and release decisions. A developer may confirm that a form submits, while the business owner confirms the recipient and message content. These are different checks. Make responsibility explicit so nobody assumes that a successful technical test proves the business process is correct.

Check public content and page identity

Read the live-facing copy rather than relying on the design file. Verify business names, service descriptions, prices, contact details, locations, and important claims with the responsible owner. Remove placeholders and internal notes. Check image captions and alternative text where the image communicates meaningful information.

Inspect the page title, main heading, and social preview for important pages. They should describe the actual page rather than repeating an unrelated homepage message. Confirm the favicon and brand mark are correct. A browser tab labelled with the original template name makes a finished site feel unexpectedly unfinished.

Check dates and authorship where relevant. Do not update article dates merely to make content look fresh. Confirm that references still support the associated statements and that external links lead to the intended sources. Content QA includes accuracy and usefulness, not just spelling and punctuation.

Follow navigation and links

Open the primary navigation, footer links, cards, buttons, and contextual links. Test both desktop and mobile menus. Check links that jump to page sections and links that open in a new tab. The visible label should match the destination or action closely enough that the visitor knows what to expect.

Test a few invalid URLs and confirm that the site shows a useful not-found page with an appropriate response status. A missing page should not silently appear as a successful copy of the homepage. If pages have moved, verify the intended redirects and make sure internal links use the final destinations.

Look for orphaned content. Important articles and service pages should be reachable through normal navigation or a resource hub. A sitemap can help discovery, but it does not replace a usable linking structure. A visitor should not need to know the exact address of a useful guide before discovering that it exists.

Test forms and confirmations

Use safe test submissions to check required fields, invalid values, success messages, and delivery to the intended recipient or system. Coordinate production tests so they do not create confusion for staff or trigger unwanted workflows. Remove test records through the approved process where necessary.

Check that errors explain the problem in plain language and remain associated with the relevant fields. Confirm that correcting one field does not erase unrelated entries. Test the submit button during slow responses and ensure the interface communicates progress without encouraging accidental duplicate submissions.

Verify the complete outcome. A success banner does not prove that an email arrived or that a record was stored correctly. Equally, a stored record does not prove that the visitor received a clear confirmation. Test both sides of the interaction with the appropriate access and responsible people.

Review responsive behaviour

Inspect narrow, medium, and wide layouts, then complete the core journeys on a real phone. Look for horizontal overflow, clipped headings, awkward image crops, and controls covered by fixed banners. Test forms with the on-screen keyboard open. Check that navigation remains usable after changing orientation or returning from another screen.

Review long content, not only ideal examples. Long names, multi-line labels, empty states, and validation messages can expose layout weaknesses. A component that looks perfect with a short sample may behave badly with realistic data. Include representative cases without using private customer information unnecessarily.

Use focused screenshots to report defects. Record the viewport or device and the exact state. A note saying “the footer overlaps the button after the keyboard closes” gives the developer a reproducible target. A general complaint about mobile friendliness leaves too many possible interpretations.

Include manual accessibility checks

Navigate important pages with a keyboard. Confirm that focus is visible, controls can be reached in a sensible order, and dialogs can be closed without a mouse. Check that form labels are meaningful and that the page heading structure reflects the content. Decorative text inside a mock interface should not confuse the real document outline.

Review text contrast and avoid relying only on colour to communicate status. Check meaningful image descriptions and ensure decorative images do not create unnecessary noise for assistive technology. Use automated tools to find common problems, but recognise that a perfect automated score does not establish complete accessibility.

For formal conformance requirements, use the applicable standard and qualified review process. A general launch checklist cannot replace a detailed accessibility evaluation. Record what was actually tested and any limitations so the result remains useful and honest.

Measure performance without damaging the experience

Run PageSpeed Insights on the homepage and representative content pages. Review the measured issues rather than chasing a number in isolation. Large images, unnecessary scripts, render-blocking resources, and layout shifts may offer practical improvements. Preserve important visual quality and functionality while addressing the bottlenecks.

Distinguish lab results from field data. Lab tests simulate a particular device and network; field data reflects eligible real-user observations. New or low-traffic sites may not have enough field data. Google's current Core Web Vitals focus on loading, responsiveness, and visual stability through LCP, INP, and CLS, as described in the official Web Vitals documentation.

Retest after material changes and after publication. Hosting and production resources can differ from a local preview. Save the report URL and test date so later comparisons have context. Small score fluctuations are normal; focus on repeatable improvements and unresolved user-facing problems.

Check search visibility deliberately

Confirm that public pages intended for search can be crawled and contain their main content in a form search engines can process. Check canonical URLs, page titles, descriptions, and any structured data. Use the official domain consistently and exclude private or duplicate pages from the sitemap.

Inspect robots.txt and indexing directives. A staging noindex setting accidentally carried into production can undermine a launch, while private review pages should not become search results. Remember that noindex is not access control. Sensitive content still needs the appropriate authentication and authorisation protections.

Validate the XML sitemap and open its public URL. It should contain canonical, indexable pages and return XML rather than an application fallback. Google describes a sitemap as a discovery aid, not a guarantee that every listed URL will be crawled or indexed. Record submission and processing separately when Search Console is part of the release process.

Triage and retest findings

Separate blockers from improvements and identify the reason for each priority. A critical journey failure should not disappear among cosmetic notes. Assign an owner and a verification condition to each actionable issue. If a finding is a new feature request, estimate it separately instead of quietly expanding the release.

Use JotPins to keep visual findings connected to the affected page and preserve the discussion around each revision. A useful issue record contains the observed problem, impact, proposed outcome, and evidence. When the implementer marks it resolved, repeat the original test and check related behaviour before accepting the change.

Track accepted exceptions explicitly. An authorised decision to defer a minor improvement is different from a fix. Record the limitation, the reason, and who accepted it. This gives the launch decision a reliable basis and prevents future developers from inheriting a misleadingly perfect checklist.

Verify the public release

After deployment, open the official domain in a fresh browser session. Test redirects, secure loading, the main navigation, and the core conversion journey. Confirm that production forms reach the correct destination and that no preview-only assets or references remain where they should not.

Check a representative article, its social image, the sitemap, and the not-found response. If a domain or hosting change is involved, preserve the old URL structure and required redirects according to the migration plan. Do not assume that a successful deployment notification proves the public site is working everywhere.

Keep the final report concise: what was tested, what passed, what was fixed, and what remains limited or deferred. The evidence can live in the review system or a supporting report. The person approving launch needs a clear picture of readiness, not a wall of unexplained green ticks.

Frequently asked questions

Is QA the same as user acceptance testing?

They overlap but have different emphasis. QA checks quality and expected behaviour across the product, while user acceptance testing confirms that the agreed business needs are met. A release benefits from both technical verification and approval by the people responsible for the intended outcomes.

Does a 100 SEO score mean the website will rank first?

No. Automated SEO checks cover a limited set of technical basics. Rankings also depend on relevance, content quality, competition, links, and many other factors. Use the score as diagnostic evidence, not a promise of indexing, traffic, or a particular position.

Should launch wait until every issue is fixed?

Fix blockers and required acceptance failures before release. Other findings may be deferred through an explicit decision by the responsible owner. The important distinction is between a known, accepted limitation and an unnoticed or concealed defect that undermines a critical visitor task.

Where should the final QA record live?

Keep it somewhere the project team can access later, with links to the tested version and individual findings. A shared review project and concise release summary can work well. Avoid leaving essential decisions only in private chat messages or someone's memory.

Further reading

Use Google's sitemap overview and Web Vitals documentation to interpret technical checks accurately.