The homepage looks right. The navigation works. The contact form shows a success message. Then someone tests it on their phone and discovers that the submit button disappears behind the sticky footer.
Website testing has a habit of finding problems just when a project feels finished. For QA engineers and developers, the challenge is covering enough ground while keeping track of what passed, what failed and what still needs attention.
A website testing checklist in Excel gives that process a repeatable structure. It helps you document test cases, compare actual behaviour with expected results and keep unresolved issues visible before a release.
This guide covers the checks to include, how to use the free template and where visual feedback fits into your QA workflow.
Download the free website testing checklist Excel template to start with 60 editable checks across 10 testing categories.
What Is a Website Testing Checklist?
A website testing checklist is a structured list of checks used to assess a website’s functionality, usability, compatibility and readiness for release.
A useful checklist goes beyond instructions such as “check the forms” or “test on mobile”. It explains what to test and what a successful result looks like.
For example, testing a contact form should cover empty fields, invalid email addresses, successful submissions, duplicate submissions and delivery to the intended recipient. A confirmation message alone does not prove that the enquiry reached your team.
Your website QA checklist should also record the environment, build, browser and device used. Without that context, a passing result can be difficult to reproduce.
What’s Included in the Free Excel Template?
The downloadable template contains 60 starter checks across these 10 categories:
- Functionality: Navigation, forms, authentication, search and critical user journeys.
- Design and content: Visual consistency, content accuracy, media and component states.
- Responsive behaviour: Breakpoints, mobile navigation, touch interactions and sticky elements.
- Browser compatibility: Supported browsers, physical devices, native controls and routing.
- Accessibility: Keyboard access, focus, labels, contrast and assistive technology.
- Performance: Loading, responsiveness, layout stability and load testing.
- Technical SEO: Metadata, canonical URLs, indexability, sitemaps and redirects.
- Security and data: HTTPS, permissions, validation, sessions and sensitive information.
- APIs and integrations: Contracts, failures, retries, data persistence and external services.
- Release and regression: Fix verification, regression testing, configuration and release decisions.
Each row includes a test ID, test case, steps or scope, expected result, status, severity, owner, defect link and evidence field.
Status dropdowns help keep results consistent, while summary counts show how many checks have passed, failed, remain blocked or have not been run.
Use these cases as a starting point. Add project-specific scenarios and duplicate rows where the same check needs to run across several pages, roles or devices.
Before You Start: Define Your Testing Scope
Before working through the checklist, agree on what the release needs to support.
Record:
- Build and environment: The version being tested and whether it is on staging or production.
- Critical journeys: Actions such as submitting an enquiry, creating an account or completing a purchase.
- Supported browsers and devices: Include relevant versions and operating systems.
- User roles: Guest, registered user, editor, administrator or other permission levels.
- Acceptance criteria: The behaviour required for each feature to pass.
- Release criteria: Which defects block deployment and who can accept remaining risks.
Start with the journeys that carry the greatest business or user impact. A broken checkout deserves attention before a slightly misaligned decorative icon.
Website QA Checklist: 10 Areas to Test
1. Functionality Testing
Functional testing checks whether the website does what users expect.
Follow journeys from start to finish, including unsuccessful attempts and recovery paths. Test what happens when someone enters the wrong details, refreshes midway through a process or submits the same request twice.
Key checks:
- Primary navigation, footer links and contextual links reach the correct destinations.
- Forms handle required fields, invalid values and boundary inputs.
- Successful submissions create the correct record and reach the intended destination.
- Sign-in, sign-out, password reset and session expiry work correctly.
- Search and filters return relevant results and useful empty states.
- Critical conversion journeys complete with accurate saved data.
For each failure, capture the exact steps and actual result. “Form broken” gives a developer far less to work with than a reproducible example.
2. Design and Content Testing
Compare representative pages with the approved designs. Include shared components and different content lengths, rather than checking only the homepage.
Key checks:
- Typography, colours, spacing and alignment match the approved design.
- Headings, prices, contact details and calls to action are accurate.
- Images, videos and downloadable files load correctly.
- Hover, focus, loading, active and disabled states are clear.
- Long headings, missing images and empty lists have usable layouts.
- Error pages provide useful guidance and appropriate HTTP status codes.
Visual issues are easier to discuss when feedback points to the affected element. With ruttl’s website commenting tool, reviewers can leave contextual comments directly on live webpages.
3. Responsive Testing
A desktop layout can hide problems that appear immediately on a smaller screen.
Test the agreed viewport sizes, then resize between them. Problems often appear near breakpoint boundaries, where a layout has little room before switching to its next state.
Key checks:
- Content remains readable across supported screen sizes.
- Pages avoid unintended horizontal scrolling.
- Mobile menus open, close and navigate correctly.
- Forms remain usable when the on-screen keyboard appears.
- Touch interactions work without relying on hover.
- Sticky headers, banners and dialogs do not cover important controls.
Include physical mobile devices in your testing. Browser emulation is useful, but it does not reproduce every device interaction.
4. Browser Compatibility Testing
Define a browser matrix based on your audience and support commitments. Run the critical journeys across that matrix.
Key checks:
- Layouts, fonts and interactive components render correctly.
- JavaScript errors do not interrupt essential actions.
- Native date, select and file controls accept the correct values.
- Autofill does not break validation or layout.
- Refresh, back and forward navigation behave correctly.
- Direct links load the intended application route.
Record browser versions alongside results. “Works in Safari” is less useful than a result tied to a specific version and operating system.
5. Accessibility Testing
Build accessibility checks into each review round. Use automated checks alongside manual keyboard and assistive technology testing.
Key checks:
- Interactive elements are reachable and operable using a keyboard.
- Focus is visible and follows a logical order.
- Dialogs and menus manage focus appropriately.
- Inputs have meaningful labels and understandable errors.
- Images have suitable text alternatives where needed.
- Contrast, resizing and reflow meet the applicable requirements.
- Screen readers announce relevant names, states and dynamic updates.
Use the WCAG 2.2 quick reference to map your tests to the project’s required conformance level. These starter checks support an accessibility review; they do not establish conformance by themselves.
6. Performance Testing
Measure representative templates and journeys, including pages with large images, embedded media or substantial interaction.
Google’s Core Web Vitals provide useful targets for loading, responsiveness and visual stability:
- Largest Contentful Paint (LCP): Measures loading performance. Aim for 2.5 seconds or less.
- Interaction to Next Paint (INP): Measures responsiveness. Aim for 200 milliseconds or less.
- Cumulative Layout Shift (CLS): Measures visual stability. Aim for 0.1 or less.
Assess these thresholds at the 75th percentile of real visits, segmented by mobile and desktop. Use lab testing to investigate issues, and field data when available to understand actual user experience. See the Web Vitals documentation for measurement guidance.
Also check:
- Behaviour on slower networks and lower-powered devices.
- Image dimensions, compression and delivery.
- Unnecessary scripts and styles.
- Caching behaviour.
- Response times and errors under an agreed, authorised load.
7. Technical SEO Testing
A deployment can work perfectly for visitors while accidentally carrying staging restrictions into production.
Key checks:
- Important pages have appropriate titles and meta descriptions.
- Canonical tags reference the intended URLs.
- Production pages do not retain unintended
noindexdirectives. - Robots rules allow crawling where required.
- Sitemaps contain the intended canonical, indexable URLs.
- Redirects reach the correct destination.
- Missing pages return appropriate error status codes.
- Important content is available in the rendered page.
Remember that robots.txt controls crawling and does not reliably prevent a URL from appearing in search results. Follow Google’s robots.txt guidance when reviewing crawl and indexing controls.
8. Security and Data Testing
Include security scenarios that reflect the application’s features, data and permission model.
Key checks:
- HTTPS works without mixed-content problems.
- Restricted pages and records enforce authorisation.
- Server-side validation rejects invalid requests.
- Logout, session expiry and cookie settings behave as intended.
- Errors and responses do not expose secrets or unintended personal data.
- Applicable controls handle unsafe inputs, forged requests and file uploads.
Run security testing within an authorised scope. Use the OWASP Web Security Testing Guide to develop more detailed cases for the application.
9. API and Integration Testing
A website can show a success message even when the service behind it has failed.
For a web application testing checklist, cover both the interface and the underlying data flow.
Key checks:
- APIs return the expected schemas, status codes and errors.
- Timeouts and rate limits produce useful recovery behaviour.
- Retries and repeated webhooks avoid unintended duplicate operations.
- Saved data remains accurate after refresh or a new session.
- Emails, CRM records and payment events reach the correct destination.
- Analytics events fire correctly under the configured consent choices.
Use test accounts and suitable test environments for external services.
10. Regression and Release Testing
Retest each fix using the original reproduction steps, then check the affected features around it.
Key checks:
- Reported defects pass verification on the release build.
- Critical regression journeys still work.
- Production configuration is correct.
- Backup and rollback procedures have an assigned owner.
- Monitoring and alerts are active.
- Production smoke tests pass after deployment.
- The release owner reviews unresolved defects and untested scope.
A high pass count does not automatically mean a release is ready. One unresolved defect in a critical journey can outweigh dozens of successful checks.
How to Use the Website Testing Checklist Excel Template
1. Create a Copy for the Test Run
Enter the project, build, environment, QA owner and test date. Preserve previous runs so results remain tied to the version tested.
2. Adapt the Cases
Remove irrelevant assumptions and add missing scenarios. Duplicate cases for different roles, browsers, devices or URLs, recording the context in the evidence field.
Use N/A only when a case does not apply, and explain why.
3. Record the Result
Choose a status for each case:
- Not run: Testing has not started.
- In progress: Testing is underway.
- Pass: The observed result meets the expected result.
- Fail: The observed result does not meet the expected result.
- Blocked: A dependency prevents testing.
- N/A: The case does not apply to this project.
4. Link Failures to Defects
For failed checks, record severity, an owner and a defect link. Include reproduction steps, environment details and evidence in the linked report.
Keep severity separate from priority. Severity describes impact; priority determines when the team addresses it.
5. Retest Before Closing
After a fix, rerun the case on the updated build and record fresh evidence. Review nearby functionality for regressions before closing the issue.
Use Excel for Coverage and ruttl for Visual Feedback
Excel provides a practical record of planned checks and test outcomes. During website reviews, teams also need to explain exactly where an issue appears.
ruttl helps reviewers collect website feedback in context. QA engineers, developers and stakeholders can discuss a visible issue against the page itself, while clients can contribute through guest commenting without signing up.
For example, the checklist might record a failed mobile navigation test. The linked visual feedback can show the affected menu and explain how the problem appears during review.
Keep the checklist as your coverage record and connect it to the detailed issue discussion. Continue using your functional, automated, performance and security tests alongside that review process.
Try ruttl free to collect feedback during your next website review.
Wrapping Up
A useful website QA checklist gives every test a clear purpose, expected result and recorded outcome.
Start with the free Excel template, adapt it to your project and prioritise the journeys users depend on most. Keep blocked checks visible, link failures to actionable reports and verify fixes before closing them.
Download the free website testing checklist Excel template and use it for your next QA round.
