Skip to main content

PrimerUpdated October 20264 min read

Testing a Website: A Beginner's Checklist

A practical checklist for testing a website before it launches: links and navigation, forms, browsers and devices, accessibility, speed, content, search basics, and security basics, with the free tools that make each check fast.

  • Web Development
  • Software Testing
  • Beginner
  • Start Here
  • Checklist

Launching a website is the moment its problems become public. Broken links, forms that fail on one browser, pages that cannot be used with a keyboard, and images that take ten seconds to load all erode trust and cost visitors. This step in our building for the web learning path is a checklist you can use on any site, from a school club page to a company store.

It builds on How Websites Work and What Makes a Good Website. For the testing fundamentals behind it, see What Is Software Testing?

Before you start: decide what matters most

Even a small site has more possible checks than time allows. Start by listing the pages and tasks that matter most: the home page, the most visited pages, and anything involving money, sign-up, or contact. Test those most thoroughly. This is risk-based testing in miniature: effort goes where failure would hurt most.

  • Every menu item, button, and link goes where it says.
  • No links lead to "404 Not Found" pages. A free link-checking tool can crawl a whole site in minutes.
  • Old addresses that people may have bookmarked redirect to the right new page.
  • The logo returns to the home page; the site has a useful 404 page for mistyped addresses.

2. Forms

Forms are where visitors give you something: an order, a question, an application. Test each one with:

  • Valid input. It submits, the visitor sees a clear confirmation, and the information arrives where it should (an inbox, a database, a CRM).
  • Invalid input. Missing required fields, a malformed email address, text where a number belongs. Each gets a clear message that explains how to fix it.
  • Boundaries. The shortest and longest allowed values, as covered in Your First Test Cases.
  • Double submission. Clicking submit twice does not create two orders.
  • Keyboard and screen reader use. Every field has a label that assistive technology can read.

3. Browsers and devices

Visitors use different browsers (Chrome, Safari, Edge, Firefox), operating systems, and screen sizes. Check the key pages and tasks on:

  • At least one phone from each major platform (iPhone and Android), in portrait and landscape.
  • A tablet, and a desktop at a common laptop width.
  • The current versions of the major browsers.

Look for text that is too small, buttons too close together to tap, content cut off at the side, and menus that do not open.

4. Accessibility

  • Navigate every key page using only the keyboard (Tab, Shift+Tab, Enter, Space). You can reach everything, and you can always see where you are.
  • Run a free automated checker on each page template. It will catch missing alt text, low contrast, and unlabeled fields.
  • Try a screen reader (built into every major phone and computer) on one important task, such as finding and submitting the contact form.
  • Confirm videos have captions and nothing flashes rapidly.

Automated tools catch only part of accessibility problems, so the manual checks matter.

5. Speed

  • Run each key page through Lighthouse or PageSpeed Insights and record the Core Web Vitals.
  • Test on a phone over a mobile connection, not only on fast office Wi-Fi.
  • Look for oversized images, which are the most common and easiest speed problem to fix.

6. Content

  • Spelling and grammar are correct; names, prices, phone numbers, and addresses are accurate.
  • No placeholder text ("Lorem ipsum") or test content remains.
  • Dates and "current" claims are actually current.
  • Every page has a clear title and a single obvious next step.

7. Search basics

  • Every page has a unique, descriptive title and meta description.
  • Pages that should be found are not blocked from search engines by mistake, a surprisingly common launch error.
  • The site has a sitemap file listing its pages.
  • Sharing a page on social media shows a sensible title, description, and image.

8. Security basics

  • Every page loads over HTTPS, with no browser warnings.
  • Default administrator accounts and passwords have been changed or removed.
  • Error pages do not reveal technical details about the server.
  • Forms are protected against spam bots.
  • Software, themes, and plugins are on current versions.

The cybersecurity basics learning path covers these in more depth, starting with How Software Gets Attacked.

Recording what you find

Each problem you find deserves a clear report: where it happened, the steps to reproduce it, what you expected, what actually happened, and which browser and device you used. A screenshot helps. How to Report a Bug So It Actually Gets Fixed shows how.

Try it yourself

Pick a small website, such as a local business, a club, or your own project, and work through sections 1, 2, 4, and 5 above. Limit yourself to one hour. Write up the three most important problems you found, each as a short bug report, and rank them by how much they would affect visitors.

The next level of this path looks at the bigger decisions behind a website: testing performance and mobile experiences under real conditions, and choosing and migrating platforms.

Rex Black Inc. · Since 1994 · Dallas, Texas

Keep reading

Related reading

Practices

Where this leads

Working on something like this?Talk to the people who wrote it.

Book a call