AI Website Review Checklist Before Publishing

Why AI-generated sites need a review pass

An AI-generated website draft can look finished before it is ready. A button can overlap the text on mobile. A chart can use invented numbers. A testimonial can quote a customer who does not exist. An image can have the wrong crop. The agent can fix the bug that you showed it, but break a different page.

This checklist makes the review a fixed routine. Write a brief and examine the result in a browser. Take screenshots and correct the problems. Share a private preview and approve it. Then publish and run a final smoke test (a short test of the main functions).

Start with the basics. Before you look at details, make sure that the page loads and that the first screen shows the main message.

Step 1: Give the agent a brief you can check against

Ask Claude Code, Codex, ChatGPT or a different agent for a first version. Include these items in your request:

• The purpose of the site and the one action that you want visitors to take
• The intended audience
• The required pages or sections
• The real data files, text and images to use, and an instruction not to invent any
• Your expectations for mobile screens
• The publishing target: the host, and the folder that holds the finished files

Save the brief in the project, for example as BRIEF.md. In step 2, you compare the result with the brief. Treat the first result as a draft, even if it looks polished.

Step 2: Run the checklist in a real browser

Review the built site, not the code. Serve the output folder through a local web server. Do not open index.html from the disk, because some path and routing problems show only over HTTP. If the output folder is dist, run this command:

python3 -m http.server 8000 --directory dist

Open http://localhost:8000 and test the site as a visitor. Click everything and change the size of the window. For phone widths, use the device toolbar in Chrome DevTools. The Chrome documentation calls device mode a first-order approximation (a rough copy of a real device). Also test the final version on a real phone.

For the content, make sure that these statements are true:

• The site has no placeholder text, such as lorem ipsum, “Your Company” or example.com addresses.
• The site has no invented statistics, customer logos, testimonials or awards.
• Prices, dates, contact details and legal text match your sources.
• Charts and tables show the values in the real data files.

For the layout, make sure that these statements are true:

• The first screen says what the site is and shows the main action.
• At phone width, nothing overlaps or goes past the edge of the screen. Images are not cropped or stretched.
• Text has enough contrast against its background.

For links and files, make sure that these statements are true:

• Every navigation link and button goes to a real destination.
• No images, fonts or downloads are missing.
• A nested page (a page in a subfolder) loads when you open its URL directly.

For forms, menus and buttons, make sure that forms submit and show a success or error message. Also make sure that the form data arrives at the correct destination. Menus, tabs and sliders must work with a mouse, on a touch screen and with the keyboard.

For technical problems, make sure that these statements are true:

• The DevTools Console shows no errors.
• A Lighthouse run from the Lighthouse panel in DevTools shows no serious problems with performance, accessibility, SEO or best practices.
• Each page has a real title and description. If you want the site in search results, no page has an old noindex tag.

Write down each problem when you find it. Do not start to fix problems during the review. If you do, you lose track of the items that you already reviewed.

Step 3: Turn each problem into a screenshot and one instruction

Screenshots make the review precise. Do not write “the layout is weird”. Show the exact section and say what you expect.

This is good feedback:

On mobile (390px wide), the CTA button overlaps the pricing text. Keep the button below the paragraph with at least 16px of spacing. Do not change the desktop layout.

This is bad feedback:

Fix the design.

Name the page, the screen width, the problem and the result that you expect. Send one numbered list of issues, with a screenshot for each visual problem. Ask the agent to reply with the number of each fix. Specific notes stop the agent from changing pages that were correct.

After each round, test again the pages that the agent changed and the pages next to them. A fix to a shared stylesheet or component often changes screens that you already approved.

Step 4: Share a private preview for approval

When the local version passes your checklist, put it on a real URL that only reviewers can open. A hosted preview shows problems that a local server hides. Examples are fonts from other domains and forms that need a backend (server code).

On Vercel, a push to a branch other than the production branch creates a preview deployment. After the project has its first production deployment, a vercel CLI run without --prod also creates a preview deployment. Standard Protection and Vercel Authentication are available on all plans under Settings > Deployment Protection. With these settings, only people with access to the project can open previews (docs).

To show a preview to a client who has no Vercel account, open the deployment. Select Share and choose Anyone with the link. When the review ends, change it back to Only people with access (docs). On Hobby, you can create one shareable link for each account.

Other hosts work in the same way. Netlify has Deploy Previews with password protection on a paid plan. Cloudflare Pages has previews behind Cloudflare Access (read our Cloudflare Pages access guide).

Use a private preview for these tasks:

• Client review
• Internal approval
• Founder or executive sign-off
• Compliance and copy review
• Tests of generated dashboards or reports with real data

Step 5: Publish the approved version and run a smoke test

Approval must refer to one specific deployment. Publish that version, not a new build with more changes. Merge the reviewed branch, or run vercel --prod from the same commit.

Then open the live URL in a private window and run a short smoke test. Make sure that these statements are true:

• The home page and the two or three most important pages load.
• The navigation and the main call to action work.
• Images, fonts and downloads load from the production domain.
• Forms send data to the real destination, not to a test inbox.
• The phone layout is still correct.
• Review banners, test data and old noindex tags are gone.
• Preview URLs are still protected after launch.

If a problem gets through, roll back to the previous production deployment. Let the agent work on a fix. Then run the checklist again on the fixed version.

Keep the checklist with the project

Save this checklist next to the brief, for example as REVIEW.md. Before your own review, ask the agent to test the items that it can test itself. Examples are broken internal links, missing alt text and console errors. You must do the items that need human judgment. For example, decide if a claim is true and if the page speaks to the right audience.

The safest workflow is not “generate and ship”. The safest workflow is to generate, examine, take screenshots, fix, preview privately, approve and then publish.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.