seeking data labs

Guide

Pre-launch website QA checklist

What to check on a site in the last days before it goes live, and how to check each item, so the problems are found by your team and not by the client's first visitor.

Last reviewed: 27 September 2026

Run this list against the production build on its final domain, or on a staging copy that is identical to it. Checks made on a developer machine miss the problems that only exist on the real host: redirects, headers, caching and the certificate.

1. Content and placeholder text

No placeholder text survives

Look for filler copy, bracketed notes and draft markers in every page, including the legal pages and the footer, which nobody reads during design review.

HowSearch the built HTML, not the design file. Typical markers are lorem, TODO, TBD, XXX, to be completed, to be confirmed, example.com and any text in square brackets.

grep -rniE "lorem|todo|tbd|xxx|to be (completed|confirmed)|example\.com|\[[a-z ,&]+\]" dist/

From a Sightline run on our own site

On 17 September 2026 a Sightline run on seekingdatalabs.com filed this as a high-severity finding on https://seekingdatalabs.com/privacy/. The controller section of the privacy policy, the part that tells a reader who is responsible for their data, still read:

[registered legal entity & address, to be completed]

A placeholder in a legal page is easy to miss because the text around it looks finished, which is exactly why a mechanical search belongs on this list.

Names, numbers and contact details are consistent

The product or company name, the phone number, the email address and the opening hours should be spelled the same way on every page where they appear.

HowList every page that states a fact the client could change (address, phone, email, prices if the site shows them) and compare them side by side. Contact details copied into the footer, the contact page and structured data drift apart first.

Copy has been proofread on the page

Check spelling, repeated words, and headings that no longer match the section below them after late edits.

HowRead the rendered page, not the content management system's editor. Line breaks and missing spaces around links or bold text often only appear in the output.

Every internal link returns 200

No link should point to a staging host, a deleted page or a page that answers with a redirect chain.

HowCrawl the site from the home page with any link checker and export every URL with its status code. Treat anything other than 200 on an internal link as a defect, including a 301 to the same page with a trailing slash.

In-page anchors have a target

A link to #pricing or /#contact that points to a section which was removed or renamed does nothing when clicked, and a crawler reports it as fine.

HowFor each href containing #, confirm an element with that id exists on the target page.

The 404 page really returns 404

A friendly error page that answers with status 200 gets indexed as content.

curl -s -o /dev/null -w "%{http_code}\n" https://example.org/this-page-does-not-exist

Old URLs redirect to their new equivalents

If the site replaces an older one, every URL that had traffic or backlinks should answer 301 to the matching new page, not to the home page.

HowTake the old sitemap or an export of the most visited old URLs and request each one. Record the status and the final location.

3. Forms

Each form works end to end

Submitting a form should produce a visible confirmation and a message in the right inbox, and the message should contain what the visitor typed.

HowSubmit every form once with valid data on the production domain. Confirm the message arrives in the client's inbox, not a developer's test address, and that the reply-to is the visitor's address.

Errors are clear and keep the input

Submit each form empty, then with an invalid email address. The error should say what is wrong, sit next to the field, and leave the other fields filled in.

Fields have labels

HowClick each label: the cursor should move into its field. A placeholder inside the field is not a label, because it disappears as soon as the visitor starts typing.

Each page has its own title and description

Titles should be unique and specific. Search results usually cut titles at roughly 60 characters and descriptions at roughly 155, so the words that matter go first.

HowExport the title and meta description of every page from your crawl and sort by value. Duplicates and empty values stand out immediately. Count characters on the text as displayed: an & in the source is one character on screen.

The staging block is gone

A noindex tag or a Disallow: / in robots.txt left over from staging keeps the whole site out of search.

curl -s https://example.org/robots.txt
curl -s https://example.org/ | grep -i "noindex"

Canonical tags point to the live URL

Each indexable page should name itself as canonical, on the final host and with the same trailing slash convention as the internal links. A canonical that still names the staging domain tells search engines to index the wrong site.

The sitemap lists only indexable pages

Every URL in the sitemap should return 200, be allowed by robots.txt and carry no noindex. Login pages, thank-you pages and redirected URLs do not belong in it.

Sharing previews render

HowCheck that og:title, og:description and og:image are present and that the image URL is absolute and loads. Paste the home page URL into a private chat message to yourself and look at the preview.

5. Accessibility basics

  • One h1 per page, and headings in order. Use a browser extension or the accessibility tree in the developer tools to list the headings. They should read like an outline of the page.
  • Images have useful alt text. Decorative images have an empty alt=""; informative ones describe what the image shows.
  • Link text makes sense on its own. Several links called "Read more" or two identical labels that go to different places are hard to tell apart with a screen reader.
  • The keyboard reaches everything. Tab through the page from the top. Every link, button and form field should get a visible focus outline, in a sensible order, and menus and dialogs should close with Escape.
  • Text contrast is sufficient. Body text needs a contrast ratio of at least 4.5:1 against its background. Light grey on white is the usual failure.
  • The page language is set. The <html> element should carry a lang attribute that matches the content.

6. Mobile layout and performance

  • No horizontal scroll at 320 pixels wide. Set the browser's responsive mode to 320 pixels and scroll every page. Tables, code blocks, long URLs and wide images are the usual cause.
  • Tap targets are big enough. Links and buttons should be at least about 44 by 44 pixels and not packed against each other.
  • Images are sized for the screen. In the network panel, look for images several times larger than their displayed size, and for images without width and height, which make the layout jump while the page loads.
  • Static assets are cached. Fingerprinted CSS, JavaScript and fonts can be cached for a long time; HTML should not be, or a fix you deploy will not reach returning visitors.

7. Security hygiene

HTTPS everywhere, with one canonical host

Plain HTTP and the other host form (with or without www) should each redirect once, with a 301, to the canonical HTTPS URL.

curl -sI http://example.org/ | grep -iE "^(HTTP|location)"
curl -sI https://www.example.org/ | grep -iE "^(HTTP|location)"

Basic security headers are present

Look for Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy, and either frame-ancestors in the policy or X-Frame-Options.

curl -sI https://example.org/

Nothing private is reachable

Request the paths that deployments commonly leave behind and confirm each one answers 404 or 403: /.git/config, /.env, backup archives, database dumps, and any staging or admin path that should not be public. Also check the page source for API keys and for comments that describe internal systems.

  • The privacy policy names who is responsible. It should give the legal name and address of the organisation and a working contact, with no bracketed placeholders (see the example above).
  • Nothing optional loads before consent. Open the site in a private window, do not touch the banner, and look at the cookies and network requests in the developer tools. Analytics and advertising requests should not appear until the visitor agrees.
  • The cookie list matches reality. Compare the cookies the browser actually holds after accepting with the list on the cookie page.
  • Consent can be withdrawn. There should be a visible way to reopen the choice later, usually a link in the footer.

9. Keep the evidence

For each item, write down what you checked, on which URL, when, and what you saw: the status code, the header, the quoted text. A list of ticks proves nothing a month later. A dated record of what the site returned on launch day lets you tell a regression from something that was never right, and shows the client what was verified before they took the site over.