How to check an AI-built website before launching it

Start with what the visitor came to do

My background is in software QA, so this is the part I naturally pay attention to. Before checking individual components, write down the main job of the site. For a service business, that might be: understand the offer, see relevant work, and send an enquiry.

Follow that path from a fresh browser window. Can you tell what is being offered without knowing the project already? Do the links lead where their labels suggest? After taking the main action, is the next step clear?

Keep a short record: what you tried, what you expected, what happened, and the browser or device. “The form is broken” is hard to investigate. “On my phone, submitting without an email clears the message and shows no explanation” gives you something to fix.

Check where the message actually goes

On a contact site, a success message is not enough. Send an agreed test enquiry containing only test information, then confirm that it reaches the intended inbox and that replying goes to the address entered in the form.

Try an empty required field, an invalid email address, and a longer message. Check that errors explain how to continue and that entered text survives a recoverable failure. In a test environment, check what the visitor sees when the delivery service is unavailable. The site must not claim that a failed message was sent.

A double click should not quietly turn one enquiry into two. Confirm the intended behaviour while sending, and keep a visible alternative contact method if the form cannot be used.

Use it on a small screen

Check the actual content on a phone as well as in a resized browser. Long headings, Romanian diacritics, email addresses, and multi-line buttons can expose problems that a short sample text misses.

Look for sideways scrolling, text hidden behind controls, and buttons that are difficult to tap. Open menus and dialogs, rotate the phone, and check a longer page all the way to the footer. If you publish in two languages, repeat the main journey in both. The language switch should take you to the equivalent page.

Put the mouse aside for a moment

Use Tab and Shift+Tab to move through links and controls. You should be able to see where focus is, activate controls with the keyboard, and leave a dialog without getting stuck. Check visible form labels and whether error messages identify the field that needs attention.

Also enlarge the text and check whether the layout stays usable. If the site has animation, check its reduced-motion behaviour. W3C’s Easy Checks is a useful starting reference for this first pass; these checks do not establish full accessibility conformance.

W3C: Easy Checks for web accessibility

Read the claims, not just the layout

Read the page as if you were about to hire the person behind it. Are the service descriptions clear? Are project statuses accurate? Does anything imply a result, qualification, or customer endorsement that you cannot support?

AI-generated copy deserves the same scrutiny as generated code. Remove invented statistics, vague promises, and examples that could be mistaken for completed client work. Check every contact address and external link. For translations, read for meaning and tone as well as spelling.

Give each page a clear identity

Check that each important page has a descriptive title, a useful main heading, and links from elsewhere on the site. Confirm that public pages are not accidentally blocked from indexing and that the sitemap lists the URLs you intend to publish.

For a bilingual site, verify the canonical URL and the links identifying equivalent language versions. These are ways to help search engines understand the pages; they do not guarantee indexing or rankings. Google’s SEO Starter Guide is a useful reference for the basics.

Google: SEO Starter Guide

Have a way back

Before release, keep the previous working version and know how to restore it. Check that private keys and internal documents are excluded from public files. If the website has accounts, payments, or sensitive data, the release needs additional checks tailored to those features.

After deployment, repeat the main journey on the real domain. Local testing will not tell you whether the live email settings, redirects, or language routes are correct. A launch is a good moment for a short, deliberate check.

• Can a new visitor understand the offer and complete the main action?
• Are failures visible, understandable, and recoverable?
• Does the site work on a phone and with the keyboard?
• Are both languages, public claims, and contact details correct?
• Can you restore a working version if the release goes wrong?