The Pre-Publish Checklist for AI-Built Websites That Do Not Look Vibe-Coded

What this checklist catches

An AI tool can make a good-looking landing page in minutes. The same speed leaves marks that visitors notice. Examples are a headline that fits any product, testimonials from people who do not exist and a layout that breaks on a phone. Another example is a contact form that sends nowhere.

This checklist finds those problems before launch. Use it on the built site, not in the preview of the tool. Fix each problem when you find it.

1. Check the first screen at desktop and phone widths

Most visitors decide from the first screen. Open the page in Chrome. Open DevTools and turn on the device toolbar. Try a narrow phone width, then a laptop width. Make sure that:

• The headline fits without awkward breaks or overlapping text.
• Buttons are readable, easy to tap and not cut off.
• The navigation works on mobile, including the menu button.
• Screenshots and product images are large enough to read.
• Nothing important is cut off at the edges.
• The page says who it is for and what it does before the reader scrolls.

Then do the same tests on a real phone. Emulation (a simulated phone in the browser) misses some font rendering and touch problems.

2. Rewrite copy that can belong to any product

Generated copy often follows the same patterns. Read every section. Look for these patterns:

• Headlines that promise a feeling (“work smarter”) and do not name the job of the product
• Feature cards with an icon, two words and a sentence that fits any software
• Benefit lists of three items with the same rhythm
• Statistics with no source (“teams save 40% of their time”)
• Testimonials, star ratings and customer logos that you cannot prove
• The same paragraph structure in section after section

Write the copy again around the product, the reader and one concrete use case. Replace each vague claim with an example. Say what the reader uploads, clicks or receives, and what happens next. If you do not have a real testimonial yet, remove the section. An empty spot is better than a fake quote.

Search the project for text that remains from the template. Look for lorem, ipsum, TODO, example.com, Your Company and Acme. Also look for placeholder phone numbers and copyright lines with the wrong year or name.

3. Clean the file set

AI tools and build steps leave extra files behind. Before you publish, open the folder that you will upload. Usually, this folder is the build output, such as dist/. Remove these files:

• Drafts, old exports and unused images
• Private screenshots and test data
• .env files, API keys and prompt files
• Notes or README files that are only for you

Anyone who guesses the path can download each file in the uploaded folder, even if no page links to it.

4. Test links, forms and buttons

A page can look finished and still fail at its main job. Test each of these items:

• For links, run the W3C Link Checker on the deployed URL. Turn on recursion, so that the checker follows internal pages. Fix every broken link and every button that points to #.
• For forms, a service must accept the submission, because a static site cannot receive form entries by itself. Examples are Netlify Forms, a server function or a form service. On Netlify, add data-netlify="true" and a name to the <form> tag. Then select Enable form detection under Forms. If JavaScript renders a form, the form also needs a hidden HTML copy, so that Netlify can find it (Netlify Forms setup). Submit a test entry, and make sure that it arrives where you expect.
• For email and phone links, click each mailto: and tel: link. Make sure that the address and the number are real.
• For downloads, open every PDF or file link from the live site.

5. Check contrast, keyboard use and alt text

Generated designs often use pale gray text on white or text on top of photos. WCAG 2.2 success criterion 1.4.3 asks for a contrast ratio of at least 4.5:1 for normal text. For large text, the minimum is 3:1. Large text is about 24px, or about 18.5px bold (WCAG contrast minimum).

To run Lighthouse in Chrome, open DevTools. Select the Lighthouse tab. Then click Analyze page load. Lighthouse reports on performance, accessibility, best practices and SEO (Lighthouse overview). For the live URL, PageSpeed Insights runs the same checks.

Automated checks do not find all problems. Also do these manual checks:

• Press Tab to move through the page. Make sure that you can see the focus (the marker on the active control) and reach every control.
• Give each meaningful image alt text that says what it shows. Leave the alt text of decorative images empty.
• Make sure that the headings are in order, so that the page makes sense to a screen reader.

6. Set titles, descriptions and share previews

Look at what search engines and chat apps will show. Make sure that these statements are true:

• Each page has a unique <title> and meta description.
• The favicon is yours, not the framework default.
• The site has an Open Graph image and title (the data for link previews), so that shared links look correct.
• No noindex tag from development remains on pages that you want in search results.

7. Review it privately on a real host

Deploy the site to the host that you will launch on. Review it there before anyone else sees it. Keep the review copy behind access control, not behind a password prompt that a script shows. Each host has its own options:

• On Cloudflare Pages, preview deployments are public by default, but they send X-Robots-Tag: noindex. To put them behind Cloudflare Access, turn on Enable access policy in the project settings. Reviewers then sign in with a code that they get by email (preview deployment docs). Production needs separate steps, which our Cloudflare Pages Access guide describes.
• On Netlify, a shared site password is available on Pro plans. Read our Netlify password guide.
• On Vercel, Standard Protection with Vercel Authentication protects previews on every plan. A shared password is a paid add-on on Pro. Read our Vercel guide.

Send the link to two or three reviewers with specific tasks. For example, ask them to sign up, find the price and send the contact form from a phone.

8. Watch what reviewers actually do

Turn on analytics before the review, so that you see more than the feedback that people write down. On Cloudflare Pages, turn on Web Analytics under Metrics in the project (setup). Web Analytics shows page views, and you can filter them by path, referrer, country and device type. Reviewers can spend their time on an unexpected page, or never reach the page that is important to you. In that case, the navigation needs work.

9. Publish the reviewed version

Launch the exact build that you reviewed, not a new export from the AI tool. A new build can change copy or layout that you already approved.

If you use Git, merge the reviewed branch into the production branch. If you upload files manually, deploy the same output folder to production. For example, use npx wrangler pages deploy dist on Cloudflare or netlify deploy --prod --dir dist on Netlify.

Then do the quick checks again on the live address. Look at the first screen on a phone, one form submission, one download and the share preview. Keep the previous deployment available. If a problem gets through, you can roll back (return to that earlier deployment).

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.