White Label Sites California

Website QA checklist: what to check before a client site goes live

By Jeremy Kenerson, Founder and CEO of DeskTeam360

Last updated

A website QA checklist is the list of technical checks your team runs on a client site before it goes live: links, forms, phones, browsers, speed, images, access for people with disabilities and search basics. Someone who didn't build the site runs it, and the client sees the site only after it passes. Keep the list the same for every build, so nothing depends on memory.

What's on a website QA checklist?

A website QA checklist covers whether the site works: every link, form, page and feature, on the devices and browsers the client's visitors use. Each check gets a pass or a fail and a note.

CheckWhat to look for
LinksEvery link goes where it should, and none lead to an error page
FormsEach form sends to the right inbox and shows a thank-you message
Phones and tabletsPages read well, and buttons and menus work on small screens
BrowsersThe site looks and works the same in the browsers the client's visitors use
SpeedPages load without long waits, even on a phone signal
ImagesEvery image loads, has alt text and is sized for the web
AccessibilityText has enough contrast, and the site works with a keyboard alone
Search basicsEach page has a title and a description, and nothing blocks search engines
Access and backupsThe client's logins work, and a backup of the finished site exists

Testing is part of the build. DeskTeam360, as one build partner, says its team builds the approved site and tests it before the agency reviews it with its client. For where testing falls among the other stages, see the website development process.

The words and images get a check of their own. For checking the content itself, see the website content checklist.

What should a pre-launch website checklist cover?

A pre-launch website checklist runs every QA check, then goes deeper on two areas: the accessibility standard the site aims for, and whether search engines can find and read it. Plan both before launch day, since the search checks run once the site is live.

Accessibility

W3C, the group behind WCAG, says WCAG documents explain "how to make web content more accessible to people with disabilities". WCAG 2.2 has 13 guidelines, grouped under 4 principles. Each guideline comes with testable success criteria at three levels: A, AA and AAA.

A site built to WCAG 2.2 also meets 2.1 and 2.0, W3C says, and it encourages using the latest version. Agree with the client which level the site aims for, and test against it.

Search engines

Once the site is live, your team can check that Google can find it. Google's SEO Starter Guide suggests searching Google for the site with the site: search operator, and if results point to the site, it's in Google's index. If nothing shows up, the guide says to look at Google's technical requirements, to make sure nothing technical is keeping the site out of Google Search.

In Search Console, Google's URL Inspection Tool shows how Google sees a page. Google says that "if you're open to a little technical challenge," you could also submit a sitemap, a file listing the addresses on the site you care about, though it says this isn't required.

Google's guide to keeping up a site's SEO says to make sure the pages and files Google is meant to crawl, such as images and CSS files, are open to Google. That means no robots.txt rule blocks them, and someone who isn't logged in can reach them. The same guide says not to use robots.txt to keep a page out of Google's index, and to use the noindex tag or a login for that instead.

So if the test copy of the site sat behind a login or carried a noindex tag, take them off when the site goes live, then run these search checks.

Once your checklist turns up fixes, DeskTeam360's free template is one way to hand each task to a helper, and its list of uses takes in website builds. It's yours for an email address.

Get the free Task Delegation Template

Who reviews a site inside the agency before the client sees it?

Inside the agency, a person who didn't build the site should run the QA checklist, and your project lead should check the result against the requirements before the client sees anything. The builder's own check comes first, but it can't be the only one.

A simple order for the in-house review:

  1. The builder checks their own work and fixes what they find.
  2. A second person runs the full QA checklist and logs every fail.
  3. The builder fixes each fail, and the second person checks it again.
  4. The project lead compares the site with the signed requirements.
  5. Only then does the site go to the client for review.

If a white label partner builds the site, ask which of these checks their team runs, and which ones stay with you. For getting the client's sign-off, see the client approval process.

Can you keep a website QA checklist in Excel?

Yes, Excel works well for a website QA checklist, because each check can sit on its own row with a column for the result. Set it up once as a template and copy it for each new site.

Columns to include:

  • the check, worded as a yes or no question
  • the page or feature it applies to
  • the device and browser it was tested on
  • pass or fail
  • a note on what went wrong
  • who ran the check, and the date
  • the date the fix was confirmed

Freeze the top row, filter by fails, and keep a copy of the finished sheet with the project files as a record of what was tested.

A finished checklist turns into a list of fixes, and DeskTeam360 gives away a template for passing tasks like these to helpers, website builds included, when you share your email.

Get the free Task Delegation Template

More on Reviews, sign-off and launch

Sources

What changed

  • : Page first published.