Website QA Checklist: 70+ Checks Before Launch (Free Template)

A website QA checklist is the list of checks you run on a site before it goes live, so the client and their visitors don't find the broken form, the 404 or the missing cookie banner for you. The checks are grouped into twelve areas and come as an Excel and Google Sheets template for your project tool. The last sections cover the QA round with clients and testers, so it doesn't end in thirty emails and screenshots without context.

What is a website QA checklist?

A website QA checklist is a structured list of quality checks that a team runs on a website before launch to confirm that pages load, forms deliver, layouts hold on real devices, search engines can index the site and legal requirements are met. QA stands for quality assurance; the checklist makes it repeatable, so nothing depends on someone remembering what to test.

It is not the same as a client review. QA is the team checking its own work against the specification; the client's acceptance comes afterwards, in user acceptance testing. Running QA first means the client reviews a site that already works and only has to judge whether it's right.

How do you use a website QA checklist?

Don't hand one giant list to one person. Split it by area, test on a staging site that matches production, log every issue in one place with a screenshot and the page URL, then fix and re-test only what changed. Mark items as not applicable instead of deleting them, so the list stays reusable for the next project.

1. Assign each area to a person: the developer takes functionality and performance, a designer or PM takes responsive layout and content, someone outside the project takes forms and user flows.
2. Test on staging with production settings: same theme, same plugins, real content, real email delivery. Testing on placeholder text hides half of the problems.
3. Log every issue in one place: with a screenshot, the page URL and the browser. More on that further down.
4. Fix, then re-test what changed: plus a quick pass over forms and checkout, where fixes tend to break other things.

What should a website QA checklist include?

It covers twelve areas: functionality, forms, links, responsive layout and devices, browsers, performance, SEO basics, accessibility basics, content and copy, legal pages and cookies, analytics, and platform checks for WordPress or whichever CMS the site uses. The lists below are the same ones in the downloadable template.

1. Functionality

• Every page in the sitemap loads without errors
• Main navigation and footer links go to the right pages
• Search returns sensible results (and handles "no results")
• Logins, password reset and account pages work
• Shop: add to cart, change quantity, coupon, checkout, payment (test mode), confirmation email
• Booking, calculators, filters, sliders and other interactive elements work
• 404 page exists, is styled and links back to the site
• Favicon and site icon appear in the browser tab

2. Forms

• Every form submits and shows a clear success message
• Submissions arrive at the right inbox or CRM (check the client's address, not yours)
• Required fields and validation messages make sense
• Autoresponder emails are sent, with correct copy and sender name
• Spam protection (honeypot, reCAPTCHA or similar) is active
• Newsletter sign-up adds the contact to the right list
• File uploads accept the expected formats and sizes

3. Links

• No broken internal links (run a crawler or a broken-link plugin)
• No links pointing to the staging domain
• External links work and open where you intend
• Phone numbers use tel: and emails use mailto:
• Social icons point to the client's real profiles, not the theme demo
• Old URLs redirect (301) to the new ones if this is a redesign

4. Responsive layout and devices

• Check every template at mobile, tablet, laptop and wide desktop widths
• Test on at least one real iPhone and one real Android phone, not only browser dev tools
• Menus open and close on touch devices
• Text is readable without zooming; buttons are easy to tap
• No horizontal scrolling on mobile
• Images are not stretched, cropped badly or pixelated
• Popups and cookie banners can be closed on small screens

5. Browsers

• Latest Chrome, Safari, Firefox and Edge
• Safari on iOS (it behaves differently from desktop Safari)
• Any browser the client's audience uses a lot (check their current analytics)
• Fonts, animations and sticky headers behave the same everywhere

6. Performance

• Run PageSpeed Insights on the home page and the heaviest template
• Images compressed and served at sensible sizes (WebP or AVIF where possible)
• Caching and a CDN set up if the host supports them
• No unused plugins, scripts or fonts loading on every page
• Videos are not autoplaying large files on mobile

7. SEO basics

• Every page has a unique title and meta description
• One H1 per page; headings in a logical order
• "Discourage search engines" or noindex removed from the live site
• robots.txt allows crawling; XML sitemap generated
• Canonical URLs point to the live domain
• 301 redirects from old URLs in place (redesigns lose rankings without them)
• Open Graph image and title set for social sharing
• Site added to Google Search Console and sitemap submitted after launch

8. Accessibility basics

• Every meaningful image has alt text
• Text has enough contrast against its background
• The site can be used with the keyboard alone (Tab, Enter, Esc); focus is visible
• Form fields have labels, not only placeholders
• Link text says where it goes ("See pricing", not "Click here")
• The page language is set in the HTML

9. Content and copy

• No lorem ipsum or "Sample page" left anywhere (search the database or the export)
• Spelling and grammar checked, including buttons and error messages
• Prices, opening hours, addresses and phone numbers confirmed by the client
• Images are licensed and are the final versions
• Dates in the footer and blog are correct
• Translations complete on every language version

10. Legal and cookies

• Privacy policy, legal notice and terms published and linked in the footer
• Cookie banner shows before non-essential cookies load, with accept and reject options
• Forms include a consent checkbox or privacy notice where the law requires it
• Shop: returns, shipping and withdrawal information published

11. Analytics and tracking

• Analytics installed on the live domain and receiving visits
• Conversion events fire (form sent, purchase, phone click)
• Tags respect cookie consent
• Staging site blocked from search engines and excluded from analytics

12. WordPress and CMS checks

• WordPress core, theme and plugins updated; unused plugins and themes deleted
• No default "admin" user; every account has a strong password and the right role
• Debug mode off on the live site (WP_DEBUG set to false)
• Permalinks set to the agreed URL structure
• Automatic backups scheduled and one restore tested
• The client's editor account can edit the pages they will maintain

The accessibility list covers the basics; for the full standard, see the W3C's WCAG overview. For performance, PageSpeed Insights gives the same lab and field data Google uses.

How do you run the QA round with clients and testers?

Send testers a short brief with the staging link, the pages to check and a deadline; ask for one issue per report, each with the page URL, the device, what happened and what they expected; triage once a day into bugs, content changes and new requests; and close the loop by asking reporters to re-check only what was fixed.

The checklist tells you what to test. The part that usually goes wrong is how the issues get back to you: a 40-line email, two voice notes and a PDF with arrows drawn on a screenshot of the wrong page, followed by a morning of asking "which page?", "which phone?" and "what did you expect to see?". A better process:

1. Send a short brief with the staging link: which pages, by when and how to report. For example: "The new site is ready for review at staging.example.com. Please go through the home page, the services pages and the contact form by Thursday. When something looks wrong, click the Give Feedback button at the bottom of the page, draw on the screenshot and write what you expected. No account needed."
2. Ask for one issue per report: "the menu and the footer and the price" in one message is three tasks, and one of them always gets lost.
3. Make every report include the same facts: what happened, what they expected, the page URL, the device and browser, and a screenshot. Our bug report template is ready to share.
4. Triage once a day: label each issue as bug, content change or new request. New requests go to a separate list; they are scope, not QA.
5. Close the loop: mark issues as resolved and ask the reporter to re-check only those.

That is the job GiveFeedback.io was built for. You paste one script into the site's <head> (the install guides cover WordPress, Shopify, Wix, Squarespace, PrestaShop and Google Tag Manager) and a feedback button appears. Testers click it, the browser asks to capture the tab, and they draw on a screenshot of what they see with arrows, boxes, text and a highlighter. Each report arrives with the page URL, screen resolution, operating system, browser and version attached automatically.

Reports land in a dashboard where you filter by open, resolved or archived, or go straight to your project tool: an issue in Jira, a card in Trello, a task in ClickUp, Asana or Wrike, an item in monday.com, a page in Notion, a message in Slack or Discord, or an email to your team.

What can you automate in website QA?

Automate the mechanical checks: broken links with a crawler, performance with PageSpeed Insights or Lighthouse, SEO basics with a crawler or your SEO plugin, and part of accessibility with an automated checker. Keep people on what tools can't judge: real devices, real content, whether the copy and the prices are right, and how the site feels to the client.

Automated checks catch the mechanical errors fast. People catch the things that make a client unhappy: the wrong phone number, the photo of the old office, the button nobody understands.

What should you check in the first 48 hours after launch?

Re-run the form tests on the live domain, confirm SSL and the www redirect, check that analytics records real visits, submit the sitemap in Search Console, take a backup, and leave the feedback button on for a couple of weeks so the client can report anything they notice once real visitors arrive.

• Re-run the form tests on the live domain
• Check that SSL works on www and non-www, and one redirects to the other
• Confirm analytics records live visits
• Submit the sitemap in Search Console
• Take a backup
• Keep the feedback button on for a couple of weeks so the client can report anything they spot

Copy the checklist, delete the areas that don't apply to your project type and save it as your template. The second time you use it, QA takes half the time, because nobody has to remember what to check.