How to test a website before launch

Test a website in layers: first what every page has in common, then what only some pages do, then how it behaves under stress. Testing page by page from the top of the menu finds the same template bug twenty times and misses the checkout on a phone.

This is the order we recommend. For a ready list to tick off, download the website QA checklist.

1. List the page types

Most sites have a handful of templates: homepage, listing (category, search, blog index), detail (product, article, profile), forms (contact, sign-up, checkout) and static pages. Pick two or three real examples of each, including one with the longest content you have. Bugs live in templates; testing examples of each covers the site.

  • Titles, headings and text read correctly; no placeholder text, test data or “Lorem ipsum”.
  • Every link in the header, footer and menu works and goes where it says.
  • Images load, are sharp and are not stretched.
  • The 404 page answers with status 404 and offers a way back.

3. Layout on phones, tablets and desktop

Check each page type at about 320, 375, 768, 1024 and 1440 pixels wide (see how to test different screen sizes). Look for horizontal scroll, overlapping or cut-off text, buttons too small to tap, and banners that cover the content. Open the menu and every dialog at phone width.

4. Forms and interactive parts

  • Submit each form empty: does it say what is wrong next to the field?
  • Submit it with wrong data (an email without @, letters in a phone field).
  • Submit it correctly: is there a clear confirmation, and does the data arrive?
  • Fields use the right type, so phones show the right keyboard for email and phone numbers.
  • Buttons react on the first click, and double-clicking does not send twice.

5. Stress the layout

Real content is messier than the design. Try the longest product name, a translated label, a missing image and a very long word or email address. A layout that holds up with the content you have today can still break with next month's.

6. Speed

Run Lighthouse or PageSpeed Insights on each page type. Watch Largest Contentful Paint (when the main content appears) and layout shifts while the page loads. Large images and many third-party scripts are the usual causes.

7. Search basics

Every page has a unique title and description, one H1, a canonical tag, and no leftover noindex. robots.txt does not block the site, and the sitemap lists the real pages. See the technical SEO checklist.

8. Accessibility basics

You can reach and use everything with the keyboard alone, the focus is visible, images have alt text, text has enough contrast and form fields have labels.

9. Record bugs so they get fixed

For each bug write: what happened, where (URL), on which device and width, steps to reproduce, what you expected, and a screenshot. Use the bug report template to keep them in one sheet with a status for each.

Let a crawler do the repetitive part

Steps 2, 3, 5, 6, 7 and 8 are where automation helps most, because they repeat for every page. SignalCrawler crawls the site, tests sampled pages of every template in a real browser at many widths, stretches layouts with longer text, checks forms and menus, and hands you a bug list with screenshots. A tester then has time for what a tool cannot judge: whether the site makes sense.