Test the facts, the customer’s main journey, and the deployed version before launching an AI-built website. Start with a realistic task such as requesting a quote from a phone. Verify what happens after each click, then check errors, keyboard access, page addresses, and the actual production domain. Ask AI for a test report, but independently confirm the business-critical outcomes.
What should you record before testing?
Write down the preview URL, the commit or deployment being reviewed, the primary customer action, and the person deciding whether the site is ready. Otherwise, you may approve one version and publish a later untested change.
Keep a short test record with four fields: the action, the expected result, the observed result, and pass or fail. For example: “Submit a quote request; expect one inquiry in the sales mailbox; received one message with the right reply address; pass.” A screenshot is useful for layout, but it cannot prove inbox delivery.
Use a preview environment for unfinished work. Do not put confidential business information into a public preview or use real customer details as convenient test data.
Did AI invent or change any business facts?
Read every page against your approved source material. Check the business name, service area, phone number, email, opening hours, prices, eligibility rules, and what is included. Search the project for placeholder text, example addresses, and unfinished links.
- Remove invented testimonials, client logos, qualifications, review counts, and project results.
- Verify photographs actually represent your work when the caption says they do.
- Check that every offer and guarantee is something the business has approved.
- Read confirmation messages and small print as carefully as the homepage.
Resolve missing facts before publication. A convincing sentence is not supporting evidence. The business website prompt guide can help you provide clearer source material before the next revision.
Can a customer complete the main task on a phone?
Open the site on a real phone as well as a desktop. Start at the homepage without assuming you know where the contact button is. Find the relevant service, open its details, and complete the next step.
- Open and close the mobile menu, then use a link and return with Back.
- Check that text and buttons fit without sideways scrolling or overlapping content.
- Try phone, email, booking, download, and quote links relevant to the site.
- Submit a labeled test inquiry and confirm it arrives at the intended destination.
- If there is a payment integration, use its supported test mode and verify the surrounding flow before any separately approved live transaction.
A contact form is not complete merely because its button responds. Use the contact-form delivery checklist to verify the system behind it.
What happens when something goes wrong?
Test the states people encounter when they make a mistake or lose connection. Leave required fields empty, type an invalid email, and repeat an action. In a safe test environment, simulate a failed request or unavailable service.
The page should explain what needs fixing, preserve useful input, and avoid claiming success when the server failed. Check whether a second click creates an unintended duplicate. After cancelling a dialog, verify that the page is still usable and focus returns somewhere sensible.
Open important pages by their direct URL, refresh them, and try a nonexistent URL. A working homepage does not prove that a deep link or missing-page response works. After a fix, repeat the failing case and the normal path so the repair does not break the original task.
Can people use the site without a mouse?
Use Tab and Shift+Tab to move through navigation and forms. Confirm that the focused element is visible, the order is sensible, and buttons and menus work from the keyboard. Read field labels and error messages without relying only on color.
Zoom the page and check whether text remains usable. Inspect image alternatives and heading order. The W3C’s Easy Checks explain useful first tests, while its evaluation guidance explains why automated checks alone cannot establish accessibility.
Run available accessibility and performance tools, then investigate their findings. A high score is useful diagnostic evidence, not a substitute for trying the site with real content and devices. Use the business website accessibility checklist for a deeper review.
Are the public pages ready for search discovery?
For each important public page, check one descriptive main heading, a unique title and description, and a canonical URL using the intended live domain. Confirm that the page is reachable through normal links and included in the relevant sitemap.
Production pages intended for search should not retain a preview’s noindex instruction. Private or unfinished pages should not be added to a public sitemap. Google’s robots metadata guidance and sitemap documentation explain the controls and their limits.
These checks support discovery; they do not prove Google has indexed a page, improve a ranking by a guaranteed amount, or guarantee inclusion in AI answers.
When is the website ready to launch?
Resolve failures that prevent contact, expose private data, publish incorrect claims, or make the core journey unusable. Record smaller issues with an owner instead of quietly treating them as passes. Identify the last known working deployment and how to recover.
After publication, verify the expected commit deployed successfully and repeat critical checks on the actual domain. Domain-specific settings, anti-spam rules, and environment variables can differ from the preview.
The BUILD • PUBLISH • OWN IT guide connects planning, building, publishing, and website testing in one walkthrough. Keep this checklist with your project so it can be repeated after meaningful changes, not just on launch day.
If the phone check uncovers sideways scrolling, overlapping cards, or an unusable menu, use the mobile layout repair guide to isolate the cause and test a targeted fix.
For the missing-page check, see how to build and verify a useful custom 404, including the HTTP status behind the visible message.
Build, check, and publish with a repeatable process
BUILD • PUBLISH • OWN IT is Colby Technologies’ 44-page PDF guide for $99.99 USD. It covers the ChatGPT, GitHub, and Cloudflare website workflow. Colby will personally assist if you get stuck following the guide. Additional hands-on work may carry a fee, with the scope and price agreed before work begins.
Applicable tax is shown at checkout. Third-party service charges are separate. Review the guide contents and purchase terms for the full details.