How do you check an AI-built website before publishing?

An AI assistant can create a convincing landing page or form in minutes. That speed is the appeal of vibe coding, but it also makes a preview easy to mistake for a finished product. A site may look complete while links point to the wrong place, form data disappears, failures remain unexplained, or a server action trusts values that visitors can change.

This release check uses a workshop signup as its example. A visitor selects a session, enters a name and email address, and receives confirmation. Seven gates separate the generated draft from a version you can responsibly publish. Each gate requires observable evidence, not a statement that the code “should work.”

1. Freeze the outcome and scope before testing

Write one sentence describing the required result: “On mobile and desktop, an interested visitor can select an available workshop, submit valid contact details, and receive an unambiguous confirmation.” Then list what this release does not include, such as payment, accounts, or calendar synchronization.

This boundary prevents the assistant from adding features during review and disturbing working behavior. A well-bounded prompt also names the affected area, what must remain unchanged, and the acceptance checks. Save the starting state in version control or as a named preview so the tested change remains identifiable.

2. Exercise the primary journey in a real browser

Open the site as a visitor rather than only reading its code. Start on the public entry page, navigate to registration, choose a session, complete the form, and inspect the outcome. Repeat after a refresh and at a narrow viewport. Links, focus, loading feedback, and confirmation all belong to the journey.

Playwright recommends testing user-visible behavior. Locate a button by its role and accessible name, then assert the visible success message. An internal CSS class does not prove that a person can find or understand the action.

The happy path is only one case. Test at least an empty, invalid, and technical failure:

• No session is available: the page explains the state and offers a useful next action.
• The email is invalid: the field receives understandable feedback and stays focusable.
• A double click or slow connection occurs: the signup is not stored twice.
• The server is unavailable: input does not vanish silently and success is not fabricated.

3. Protect both sides of the form boundary

HTML input types, required, sensible lengths, and immediate feedback help visitors correct mistakes. MDN also warns that client-side validation is not a complete security measure because a request can bypass the interface. The server must enforce the same business boundaries independently.

For the workshop signup, the server accepts only real session identifiers, limits field lengths, deliberately normalizes the email address, and rejects unexpected fields. It also verifies that a seat is still available. A hidden form value is not authorization.

Draw the data path: what leaves the browser, where it is stored, who can read it, and when it is removed. If the assistant cannot derive a clear answer from code and configuration, the release still has an unresolved risk.

4. Check keyboard use, semantics, and feedback

WCAG provides a shared standard for more accessible web content. You do not need to memorize the entire standard for a small release, but the primary journey must remain understandable and usable without a mouse. Navigate with Tab, Shift+Tab, Enter, and Space. Focus should never disappear or become trapped behind a dialog.

Review visible labels, heading order, contrast, text alternatives, and status messages. Zoom to 200 percent and use a narrow viewport. An automated audit catches many basic issues, but it cannot replace keyboard testing or a short screen-reader or user check.

5. Inspect security boundaries instead of trusting confidence

The OWASP Top 10 describes recurring web risks including broken access control, security misconfiguration, supply-chain failures, and injection. Translate those categories into questions for your site. Can a visitor read another registration? Is a secret included in the browser bundle? Does the server trust a role sent by the form? Are external packages and environment variables controlled?

Ask the assistant to identify evidence and locations before making changes. Authentication, payment, health information, or other sensitive data deserves an experienced review. Generated code is not automatically unsafe, but polished output can hide assumptions that were never verified.

6. Measure performance on relevant devices

web.dev lists LCP, INP, and CLS as stable Core Web Vitals for loading, responsiveness, and visual stability. They are useful signals rather than a universal pass button. Measure the actual page with its production images, fonts, scripts, and third parties.

Test at least one representative phone, a throttled connection, and a desktop browser used by your audience. Watch the largest image, blocking scripts, delayed controls, and layout movement during loading. Set a small budget, such as maximum image sizes and no new blocking third-party dependency without an explicit reason.

7. Prepare approval, observation, and rollback

Before launch, answer three operational questions: Who approves the version? Which signals reveal a failure? How do you return to the last working version? A controlled preview, like the one described in the ChatGPT Sites guide, is useful for final review when its audience and form data are deliberately chosen.

Publish a specific tested version, not an ambiguous “latest state.” Afterward, check the public URL, primary journey, server errors, and real submission events. Rollback becomes dependable only when the target version, owner, and procedure are known.

Compact launch checklist

• The goal, exclusions, and tested version are recorded.
• The happy path, empty state, invalid input, and server failure were tested in a browser.
• Browser and server validate input; authorization and the data path are understood.
• The primary journey works by keyboard, at zoom, and on a relevant phone.
• Secrets, environment variables, dependencies, and public endpoints were inspected.
• Performance was measured with real assets and critical regressions were fixed.
• Approval, monitoring, and rollback have a named owner.

These gates are not meant to remove the speed of an AI-assisted workflow. They protect its real advantage: moving quickly from an idea to a useful product whose behavior you can explain and own. When a gate lacks evidence, turn that missing proof into the next bounded task. The iteration stays fast without turning the launch into a gamble.