Review AI-generated website code

Begin with the contract

Write down the user, task, required pages, content facts, technologies, accessibility requirements, and explicit exclusions. Review generated output against that contract before judging visual polish.

Reduce the surface

List files and dependencies. Remove packages whose behavior is not justified. Find network requests, storage, forms, trackers, and dynamic HTML because they cross trust or privacy boundaries.

Review in layers

1. Confirm source order, headings, landmarks, links, controls, labels, and content truth.
2. Check responsive layout, zoom, focus, motion, and failure states.
3. Validate all mutable endpoints and output encoding.
4. Measure asset sizes and client JavaScript.
5. Inspect metadata, canonicals, links, and public response status.

Run behavior, not just syntax

Open every important route. Use only a keyboard, block JavaScript, slow the network, force invalid input, and try direct deep links. Automated checks help find classes of problems but do not prove conformance or user success.

Ask for small corrections

Give the assistant one reproducible finding and request the smallest patch plus a regression test. Broad “make it better” prompts invite unrelated changes and hide whether the original defect was fixed.

How generated output actually fails

Generated code is a set of unverified claims. A polished interface may still reference missing files, invent an API, expose secrets in client code, erase native semantics, or report success before a request finishes. The assistant's confidence is not evidence about the repository, browser, deployment, or service account.

Start by resolving the real execution path. Identify the package manager, scripts, route files, content registry, environment parser, network boundaries, and deploy configuration. Read local instructions and inspect the working tree before editing. A generated answer may describe a framework version or file layout that does not exist in the checkout.

Separate static validation from behavioral proof. Type checking can show that values satisfy declared types; it cannot prove an endpoint accepts the payload. An accessibility rule can detect an unlabeled control; it cannot prove the task is understandable. A deployment status can show READY; it cannot prove the canonical domain points to that deployment.

Establish a review contract

Write the user outcome and non-negotiable constraints in plain language. Name the required routes, content facts, supported browsers, accessibility baseline, privacy boundaries, performance budget, security model, and explicit exclusions. Link each requirement to a verification method.

Turn vague phrases into observable acceptance criteria. “Responsive” becomes no page-level horizontal overflow at 320 CSS pixels, readable text at 200% zoom, and aligned reading and focus order. “Secure form” becomes server-side schema validation, origin and abuse controls, encoded output, bounded logs, and honest error recovery. “SEO ready” becomes successful canonical responses, unique metadata, registry-sitemap parity, and visible structured-data parity.

The contract also limits scope. If accounts, payments, file uploads, or user tracking are excluded, reject generated dependencies and UI claims that imply those systems exist. A smaller truthful feature is better than a decorative mock that crosses an unreviewed trust boundary.

Review structure and accessibility

Read the initial HTML or server-rendered output before judging CSS. Confirm one descriptive page heading, logical subsections, useful landmarks, real anchors for navigation, buttons for actions, persistent form labels, and honest status text. Disable CSS and JavaScript to expose source order and baseline behavior.

Inspect the accessibility tree for names, roles, descriptions, invalid states, and landmark labels. Complete the main task with Tab, Shift+Tab, Enter, Space, Escape, and required arrow keys. Test opening and closing every layer, returning focus, and recovering from invalid input. Repeat at 320 CSS pixels, 200% text zoom, reduced motion, forced colors, and a screen reader.

Generated code often adds ARIA to compensate for the wrong element. Prefer replacing a generic clickable node with a native button over adding role, tabindex, key handlers, disabled behavior, and focus styling by hand.

Review data, privacy, and security

Inventory every boundary where data enters or leaves: URL parameters, forms, headers, cookies, storage, clipboard, downloads, analytics, external scripts, API requests, webhooks, and logs. For each, name the schema, size limits, authorization rule, retention, and safe failure response.

Do not accept a client-supplied price, role, path, or ownership identifier as authority. Map public identifiers to server-controlled records. Verify signed webhooks from the raw request body, handle replay or idempotency, and keep secrets outside public bundles. Encode untrusted output and reject raw HTML in content systems unless a deliberately sanitized path exists.

Check dependencies for purpose, maintenance, license, vulnerabilities, and runtime placement. A package that should be server-only must not be pulled into a client component. Remove dependencies that duplicate a platform primitive or support a feature outside the contract.

Common review failures

• The reviewer starts with visual polish. Trust and behavior defects remain hidden behind a complete-looking screen. Begin with routes, data boundaries, semantics, and failure states.
• The full test suite passes but the feature is broken. Tests cover implementation details or mocks only. Add one contract-level behavior test and verify the real boundary when credentials allow.
• A broad refactor accompanies a small fix. The causal change is difficult to review. Isolate the minimal patch and add a regression before cleanup.
• Generated copy claims unsupported behavior. A demo form says “sent,” or a private feature writes to shared storage. Trace every public claim to an implemented, verified path.
• The assistant overwrites unrelated local work. The working tree was not inspected. Preserve user changes and scope edits to files required by the contract.
• A production claim relies on deploy output. The real endpoint and logs were never checked. Smoke the canonical service after promotion and record the deployment identifier.

Verify corrections

Reproduce the defect before changing code and capture the smallest observable failure. After the patch, run the focused regression, then the full local gate. Build from a clean dependency state when lockfile or build configuration changed. Review the diff for accidental copy, dependency, metadata, or generated artifact changes.

For browser behavior, test the exact route and state that failed in every required engine or device profile. For authenticated or external services, use the actual signed-in session and capture the callable response or provider log. For production, request the canonical URL, exercise the behavior, and inspect post-traffic errors. A local green result and a live green result answer different questions; preserve both.

What this guide does not cover

This guide does not certify code as secure, accessible, legally compliant, or factually correct. Those conclusions require domain expertise, appropriate testing, and sometimes independent review. It does not recommend sending private source, credentials, customer data, or unreleased business material to an external model. Follow the organization's approved data-handling policy and use the least sensitive context needed for the task.

Exercise and next step

Take one generated component and write a ten-line contract for it. Map each line to source evidence and a behavior check. Find one unsupported assumption, reproduce its consequence, request the smallest correction, and add a regression test. Then run the semantic-audit and accessibility-audit prompts independently and reconcile their findings with your own evidence.