How to check an AI built client website before launch

Start from the client's brief

Write down the intended audience, agreed service names, important calls to action and the exact page list. Compare the deployed site with that brief rather than asking whether it looks polished. Generated pages may use convincing sample content that the client never approved. Record an unsupported claim as a question for the owner; do not turn it into a testimonial or leave it in place because it reads well.

Identify the version being reviewed. A local preview and a deployed site can differ in paths, files or settings. Keep the deployment address and review date in the report, and repeat important checks on the final environment before handoff. Use a copy of this launch checklist to keep coverage explicit.

Check destinations rather than button styling

Follow each primary navigation item, logo, footer link and call to action. Read the destination heading after the click. Watch for a button that opens the wrong service, a link that still points at a preview domain, and a menu that hides the only contact route at a narrow width.

Open the important URLs directly as well as through navigation. A homepage can work while a deep link or download fails. Check images and files on the deployed site; an image shown in the builder's preview may not be included in the published output. Record the URL and visible result instead of assuming a missing asset is a hosting fault.

Do not ask an assistant to repair every suspected issue in one large rewrite. First isolate the observable failure, then verify the correction against the same steps. Keep a known working version available while changes are made.

Compare content across the whole journey

• Do the home page, service page and next-step page use the same offer name and scope?
• Are prices and renewal terms consistent with the owner's approved terms?
• Do contact details, business identity, policies and support links match?
• Are there invented people, sample reviews, empty case studies or placeholder statistics?
• Does every promised download exist and contain the intended material?
• Does a claim such as “works on every device” exceed the actual testing evidence?

For example, a service card can say “one-time” while a linked checkout says “monthly.” Record the exact pages and wording, then have the business owner resolve the conflict. Do not complete a purchase to investigate it.

Review layout with realistic content

At desktop and 390-pixel phone width, inspect long headings, repeated cards, image captions, menus, footers and any wide table. Check that a visitor can read the text and reach the next step without the whole page scrolling sideways. Review pages with real approved content; a short placeholder can hide a wrapping problem that appears after the client supplies a longer business name.

Keep engine and device claims precise. A narrow viewport is not a physical phone. Chrome documents the limits of device simulation. A separate WebKit run is evidence about that engine and version; Playwright explains its WebKit build and why it is not the branded Safari application. Do not report a browser or device you did not use.

Know where a safe review stops

A form's presence does not establish successful email delivery. A checkout link does not establish a completed payment. An account screen does not establish that sign-up, billing or cancellation works.

For ordinary public-page review, inspect visible pages only. Anything beyond that needs written site-owner authority, a non-destructive test plan and any required staging or test access. Use an owned test fixture for submission behavior; avoid real orders, messages and accounts. If the route cannot be tested safely, mark it untested and explain the missing prerequisite.

Give the developer a small reproducible record

Use one finding per distinct failure. Include its ID, effect on the task, exact starting URL, numbered steps, expected and observed result, browser version, viewport and timestamp. Attach a screenshot showing the issue. “The mobile version is broken” leaves the next person guessing; “at 390 × 844, the navigation covers the service heading after opening Menu” gives them a specific check to repeat.

Our synthetic sample report shows an intentionally planted wrong-destination link on our own fixture. It is a demonstration of evidence and retesting, not a client case or proof of customer outcomes. The report reading guide explains how to interpret that record.

After the fix, repeat the exact failing steps and the nearby journey that might have been affected. Record the new version and result. Release only against the agreed coverage and the client's decision about remaining issues; no short review proves that every state is correct.

Related resources

• Website launch QA checklist for small agencies
• How to read a website QA report