What to Check Before Delivering an AI-Built Small-Business Website

Short answer: Treat an AI-built website as an unverified draft until a person checks the customer’s content, every important user path, responsive behavior, accessibility basics, performance, measurement setup, and failure states. The goal is not to promise a defect-free site; it is to create a repeatable evidence-based handoff process that catches material problems before the site reaches its owner or visitors.

AI can accelerate layout, copy, and code generation, but generated output still needs human judgment. GitHub’s responsible-use guidance emphasizes understanding AI features’ purposes, capabilities, and limitations rather than treating them as substitutes for review [1]. Use the checklist below with authorization from the site owner, and record what you tested, on which environment, and what remains outside scope.

1. Start with an acceptance sheet

Before opening the site, write down the intended audience, pages, calls to action, supported devices and browsers, integrations, content supplied by the owner, and the definition of “ready for review.” This prevents a visually attractive homepage from distracting you from an incomplete contact flow or an incorrect service description.

Create one row for each requirement and give it a status: pass, needs evidence, fail, or not in scope. A useful record includes the URL, test date, browser and viewport, observed result, screenshot or log reference, severity, and owner of the fix. Do not paste private customer data into an AI tool merely to make testing easier; use representative test values where possible and follow the customer’s instructions and current primary rules for handling data.

2. Check truth, completeness, and consistency

Read the site as a customer would, not as the generator intended. Compare names, addresses, phone numbers, hours, services, prices or other commercial details, qualifications, locations, and calls to action against the source material supplied by the owner. Mark any AI-written claim that cannot be verified. Check that the page title, headings, navigation labels, buttons, metadata, and visible copy describe the same offer.

Look for common generation errors: invented testimonials, unsupported statistics, duplicated paragraphs, vague claims, placeholder text, incorrect local references, and inconsistent capitalization. Verify that every image has an approved purpose and that its caption or alternative text does not claim something the image cannot establish. Google advises focusing on accuracy, quality, and relevance when using generative AI, including for titles, meta descriptions, structured data, and image alternatives [2]. That is a quality-control instruction, not a promise about rankings or traffic.

3. Walk every critical path

Use the site’s primary tasks from start to finish. Open the navigation, visit every linked page, use the main call-to-action, submit the contact or booking form with authorized test data, and confirm the expected confirmation message or handoff. Test both a normal completion and a correction: leave a required field empty, enter an invalid email format, use a long name, and try unexpected but harmless characters. Confirm that errors are understandable, remain associated with the relevant field, and do not erase valid entries.

Inspect links for wrong destinations, accidental new tabs, broken anchors, missing downloads, and buttons that look active but do nothing. Test the logo, menu controls, phone links, email links, maps, embedded scheduling tools, cookie or preference controls if present, and any CMS preview or publishing path. If an integration is not available in the test environment, label it “needs evidence” rather than assuming it works.

4. Review mobile and responsive behavior

Resize the browser gradually instead of checking only one phone preset. At narrow widths, confirm that text remains readable, buttons have room to be operated, navigation can be opened and closed, images do not obscure content, and no important content is clipped or forced into horizontal scrolling. At wider widths, check that line lengths, spacing, and image crops still support scanning.

Repeat the critical path on a real phone when feasible. Pay particular attention to the first screen, sticky headers, menus, form controls, tap targets, keyboard behavior, orientation changes, and slow connections. A screenshot can hide a scroll, focus, or touch problem, so an interactive pass is essential.

5. Perform an accessibility pass

Begin with simple checks: a meaningful page title, logical headings, descriptive link names, visible keyboard focus, keyboard access to menus and dialogs, text alternatives for informative images, sufficient color contrast, and labels or instructions for form fields. Turn off images briefly to see whether the remaining text still communicates the page’s purpose. Use only color-independent cues for errors and status.

W3C’s Easy Checks are designed as an initial review and explicitly note that they are not a complete accessibility evaluation; more assessment may be needed for a definitive, comprehensive result [3]. Accordingly, record the boundary of your test. An automated checker can identify patterns, but it cannot replace keyboard use, zoom testing, or a careful human reading of labels and instructions.

6. Check speed and visible stability

Measure representative pages in a production-like environment, preferably more than once, and record the test conditions. Look for oversized images, unnecessary scripts, render-blocking assets, layout movement, slow third-party widgets, and interactions that appear frozen. Test a content page, the homepage, and the most important conversion or contact path rather than relying on one score.

Google describes Core Web Vitals as real-world measures of loading performance, interactivity, and visual stability. Its current guidance identifies Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, with “good” targets of 2.5 seconds or less, under 200 milliseconds, and under 0.1 respectively [4]. Treat these as diagnostic thresholds for a better experience, not as a guarantee of search visibility or business outcomes. Also check whether the page remains usable while assets are still loading.

7. Verify measurement without guessing

If analytics, search tools, pixels, forms, or call tracking are part of the authorized scope, verify that the correct property is connected, events fire once, and test submissions are distinguishable from real activity. Check that consent or preference behavior matches the owner’s approved configuration. Remove debug logging, test addresses, sample events, and temporary credentials before handoff.

Do not infer that measurement is correct because a dashboard contains numbers. Use a controlled test event, inspect the network or debugging view where appropriate, and document what was and was not verified. Questions involving personal data, consent, retention, or sector-specific obligations should be escalated to the site owner and qualified professionals rather than answered from a generic checklist.

8. Test failure and recovery states

Disconnect or throttle the network, reload a partially loaded page, submit a form twice, visit an invalid URL, and trigger a server or integration error in a safe test environment. Check for a useful not-found page, readable error messages, retry or recovery options, preserved form input where appropriate, and a way to return to a known page. Confirm that sensitive implementation details, stack traces, keys, and internal paths are not exposed.

Then inspect the delivery package: source repository or export, environment variables, domain and DNS instructions, image licenses or supplied assets, content approvals, backups, dependency versions, accessibility notes, test results, and a short list of known limitations. A handoff is clearer when it says exactly what was tested and what the owner must verify after deployment.

A transparent decision tool

Use this five-question gate for each critical requirement:

1. Observable: Can another reviewer see or reproduce the expected behavior?
2. Authorized: Did the test use an approved environment and harmless test data?
3. Complete: Did the check cover success, correction, and failure states?
4. Accessible: Can the task be performed with keyboard, zoom, and understandable labels?
5. Documented: Is the result recorded with conditions, evidence, and a clear owner?

Mark a requirement ready only when all five answers are yes. Mark it hold when a critical answer is no or unknown. A noncritical cosmetic issue can be logged for later, but a broken primary action, inaccurate customer information, inaccessible essential task, exposed secret, or unverified production integration should stop delivery until the responsible person resolves or explicitly accepts the limitation.

Final handoff sequence

Run the review on a clean build, fix and retest failed items, ask a second person to repeat the highest-risk paths, and export the acceptance sheet with the final version identifier. Give the owner a plain-language summary of completed checks, open issues, credentials or access they must control, and post-launch checks they should perform. Keep the distinction between “reviewed against this checklist” and “guaranteed to work everywhere.” No finite pre-delivery review can establish the latter.

Sources and further reading

1. GitHub, “Responsible use of GitHub Copilot features.”
2. Google Search Central, “Google Search’s guidance on using generative AI content on your website.”
3. W3C Web Accessibility Initiative, “Easy Checks – A First Review of Web Accessibility.”
4. Google Search Central, “Understanding Core Web Vitals and Google search results.”