Check an AI-Generated Website Before Launch
A successful deploy is not a launch approval. Before you send visitors to an AI-generated website, test the deployed build from a clean browser session, record what failed, and name the person who can reverse the release. This guide gives you a go/no-go record. It does not repeat the host setup in the static publishing guide or the DNS steps in the domain guide.
Set the scope first. Write down the production hostname, deployment or commit ID, date, reviewer, and the routes that matter. Include any new page, navigation target, form, download, and external conversion link. If the website replaces an existing one, add the old-to-new URL map and test the redirects. A homepage-only review misses deep-link failures.
What should the test matrix contain?
Use one row per page and one row per shared flow. Here is an illustrative acceptance sheet for a fictional three-page brochure site. It is a template, not a claim that we launched or measured this site.
| Route or flow | Desktop | Narrow mobile | Functional check | Search and access check | Result |
|---|---|---|---|---|---|
/ | Main content and images load | No clipped menu or sideways scroll | Service and contact links resolve | Title, heading, canonical, keyboard path | Pass or issue ID |
/service/ | Service details load | Prices and actions fit | Main action reaches the right target | Unique metadata, readable headings | Pass or issue ID |
/contact/ | Contact details load | Fields and buttons fit | Invalid, valid, and delivery states tested | Labels, errors, privacy link | Pass or issue ID |
Old /about-us/ URL | Redirect reaches intended replacement | Same result | No chain to an error page | Final URL is the preferred one | Pass or issue ID |
Replace these paths with real routes. Open each route directly in a private window; do not rely only on navigation from home. Record the final URL and whether it is the expected page. Test with JavaScript enabled and, when the site depends on scripts, check what a failed script would leave visible. Inspect the console and network responses for missing assets. A link can look active while it points to #, a preview address, or a nonexistent route.
Which failures block launch?
Treat these as no-go items: a broken main action, a form that falsely reports success, an inaccessible core task, a missing public page, sensitive content exposed by mistake, a wrong-domain canonical on a key page, an invalid HTTPS certificate, or email failure after DNS change. A draft testimonial, unverified price, fabricated review, or unsupported claim is also a stop condition. An AI tool can produce plausible text; the site owner must verify business facts.
Test forms with an invalid value and a real controlled submission. Confirm the message arrives at the intended destination without placing personal data in public logs. Check errors and confirmation text. If a form is not ready, replace it with an honest contact method rather than leaving a non-working control. The form guide covers implementation details.
For accessibility, run the issue-ledger audit before sign-off. At minimum, complete every key task by keyboard, verify labels and visible focus, and retest fixes in the deployed build. W3C's preliminary review shows why keyboard testing matters. A clean automated scan alone is not a pass. For search setup, run the page-level SEO sheet; check that important pages are public, linked, and not marked noindex. Neither check promises a search ranking.
How do I assess mobile and speed?
Use at least a narrow phone viewport and a wide desktop viewport, then inspect the widths where the layout changes. Look for clipped text, hidden actions, oversized images, overlap, and unwanted horizontal scroll. Test the actual mobile menu and forms by touch or device emulation. AI-generated CSS often looks complete at one width and fails between breakpoints.
Use a performance tool on the deployed URL, then inspect the problem it identifies rather than chasing one score. web.dev's measurement guide distinguishes field measurements from lab tools such as Lighthouse. A new site may not yet have enough field data. Record the tool, URL, test conditions, and observed issue. Large images, layout shifts, and slow interactions deserve fixes when they obstruct the page. Do not state a performance improvement without a before-and-after measurement.
Who makes the go/no-go call?
Write a final record with four fields: release ID, open issues, decision owner, and rollback trigger. Mark each issue as fixed and retested, accepted with a reason, or blocking. Only the owner can accept a remaining risk. Save the previous working deployment and its domain records. Define how to restore it and what the rollback does not restore, such as submitted form data or an external database. For a domain cutover, keep the old host available until HTTPS, routes, and mail pass on the new address.
After approval, monitor the first real visits and form deliveries. Check the public URLs again once DNS caches settle. If the go/no-go record changes because new content or code ships, run the affected rows again. Figment's prompt tool can help turn a failed row into a scoped change request. The AI editor page gives current access status; Figment does not presently promise public editing, DNS control, or custom-domain setup through that tool.
Sources and access date
W3C's preliminary accessibility review and web.dev's Web Vitals measurement guide were accessed 2026-09-23.
