Back to HTML Pub

Before You Send Paid Traffic: The 12-Point QA Checklist for Any Site Claude or ChatGPT Built

Michael Sacca•

(No live web search in this session, so treat tool names and spec thresholds below as tested-in-practice guidance rather than a fresh audit — but every item on the list maps to a failure I've personally watched an LLM-built page commit.)


You've seen the individual warnings scattered across this blog: pixels that don't fire, forms that vanish into the void, hosts that hold your files hostage. Those posts each cover one failure point. This post is the thing I wish had existed before I sent my first paid click to a page Claude built — one checklist, start to finish, of everything that goes systematically wrong with LLM-generated sites, with the exact prompt to fix each item before a single dollar of traffic arrives.

Why a checklist and not just "test it"? Because LLMs fail in patterns. They don't randomly produce bad sites — they produce the same bad sites, over and over, because of how they're trained and how they generate code. Once you know the pattern, you can check for it in minutes.

Why LLM-built sites fail in predictable ways

Claude and ChatGPT generate code left to right, optimizing for "looks complete" rather than "works correctly." That produces a signature set of errors:

  • They write markup for the happy path — one screen size, one browser, JavaScript enabled.
  • They invent plausible-looking links to pages they never created.
  • They default to desktop proportions, because most training examples are desktop layouts.
  • They skip invisible metadata — the stuff that doesn't render on screen but does determine whether your page loads fast, gets crawled, and previews correctly when shared.

None of this means the output is bad. It means the output is draft-grade until you QA it. Here's the twelve points, grouped into four phases.

Phase 1: Rendering — does the page look right everywhere?

1. The mobile breakpoint sweep

The single most common LLM failure. The page looks perfect in your desktop browser, then on a phone the nav collapses into nothing, the hero text overflows its container, or buttons stack into a vertical tower pushing your CTA below the fold.

The check: Open the page in Chrome DevTools, toggle device mode, and check at 375px (iPhone), 768px (tablet), and 1440px (desktop). Look specifically for horizontal scrollbars — if you can swipe sideways on mobile, something is overflowing its container.

The fix prompt:

Review this page for responsive bugs. At 375px viewport width,
check every element for horizontal overflow, text truncation,
and touch targets smaller than 44x44px. Fix by adding/removing
media queries. Give me the corrected full file.

2. Duplicate H1s

LLMs love to give every section a big heading, and they'll happily output two, three, even four <h1> elements in one page. Google treats H1 as a strong relevance signal; duplicates dilute it, and it usually means your heading hierarchy is a mess below that too.

The fix prompt:

Audit the heading structure of this page. Exactly one H1.
Every following heading must be an H2 or H3 nested logically.
Rewrite the heading tags only — don't change the copy.

3. Font and layout shift on load

Watch your page load with a clean cache. If text jumps, buttons move, or a flash of unstyled white appears before your CSS loads, you have a CLS problem — and ad platforms score landing pages partly on load stability. LLMs frequently load fonts without fallback sizing or stack CSS in an order that paints late.

The fix prompt:

This page has layout shift on load. Add font-display: swap with
size-adjusted fallbacks, preload the primary font, and ensure
hero dimensions are reserved in CSS so nothing reflows.

Phase 2: The invisible layer — metadata, sharing, crawling

4. Title and meta description

Shockingly often, an LLM-generated page ships with the title tag left as whatever was in the example it was imitating — or missing entirely. This is what shows in search results and at the top of the browser tab. If you're running paid traffic, it's also the first line of your ad-to-page message match.

5. Open Graph and Twitter Card tags

Paste your page link into Slack, iMessage, or a LinkedIn post. No image? No title? That's missing OG tags — and if you're paying someone to click, a link that renders as a bare URL in their feed is a conversion killer.

The fix prompt for both:

Add complete head metadata to this page: title (under 60 chars),
meta description (under 155 chars), Open Graph tags (og:title,
og:description, og:image, og:url), and Twitter card tags.
Use this copy: [paste your title/description]. Use [image URL]
as the OG image, sized 1200x630.

6. Favicon, canonical tag, and lang attribute

Small, dumb, visible-in-the-tab things. A missing favicon shows a generic globe icon. A missing canonical tag invites duplicate-content issues if the page is reachable at multiple URLs. A missing lang attribute trips accessibility checkers. Thirty seconds to fix, embarrassing to skip.

Phase 3: Links, forms, and the paths money travels

7. Dead internal links

This is the failure mode that makes LLM-built sites unique. The model will write <a href="/about"> because it knows sites usually have about pages — even though you never asked for one and no such file exists. Every multi-page AI-built site I've tested has at least one invented link.

The check: Click every link. Or automate it — ask your LLM to list every href in the output, then verify each one maps to a file you actually deployed.

8. The form destination

Forms deserve their own full treatment — we covered exactly how to verify submissions land where you think they do in The Page Deploys Fine. Your Leads Are Going Nowhere: Testing Where Form Submissions Actually Land on AI-Built Sites. The checklist item is simple: submit the form yourself, with your own email, and confirm the lead arrives. LLMs frequently wire forms to a placeholder action or an endpoint that was never provisioned.

9. Redirect chain and HTTPS

If your paid traffic URL bounces through two or three redirects before landing — http:// → https:// → www. → final — you're adding load time to every click and losing tracking parameters in some chains. Land the ad URL directly on the final HTTPS destination. (If your tracking pixel isn't firing reliably, that's the subject of The Pixel Test Your AI Agent Skips: How to Prompt Claude to Install Conversion Tracking That Actually Fires.)

Phase 4: Accessibility and performance — the stuff audits catch late

10. Color contrast

LLMs generate gorgeous low-contrast designs — pale gray text on off-white, pastel buttons with white labels. It looks designer-y and fails WCAG contrast minimums, which means a meaningful chunk of your visitors literally can't read your CTA.

The check: Run the page through any free contrast checker. Body text needs roughly 4.5:1 contrast against its background; large headings need at least 3:1.

The fix prompt:

Check every text/background color pair on this page against
WCAG AA contrast. Flag any that fail and darken the text or
lighten the background until they pass. Keep the visual style.

11. Alt text and keyboard navigation

Two more accessibility defaults LLMs skip: images with empty or missing alt attributes, and interactive elements that can't be reached with Tab/Enter. If your CTA is a <div> with a click handler instead of a <button>, keyboard users can't convert. This also happens to correlate with cleaner, more semantic markup that crawlers parse better.

12. The page-weight sanity check

LLMs will happily embed four fonts, a carousel library, and a full jQuery build to power one button. Open DevTools Network tab, reload, and look at total transfer size. If a static landing page is pulling multiple megabytes, ask for a trim.

The fix prompt:

Audit this page's dependencies. Remove any library whose
functionality you can implement in vanilla JS in under 20 lines.
Self-host or subset the fonts. Report the before/after page weight.

The one-prompt version

If you only keep one thing from this post, keep this — the full sweep in a single prompt you can paste back into Claude or ChatGPT after it builds the page:

Now QA your own output. Go through this checklist and fix
everything you find, then give me the corrected files:

1. No horizontal overflow or broken layouts at 375px, 768px, 1440px
2. Exactly one H1, logical heading hierarchy
3. No layout shift on load (font-display, reserved dimensions)
4. Complete title, meta description, Open Graph, Twitter tags
5. Favicon, canonical tag, lang attribute
6. Every internal href points to a file that actually exists
7. Form action points to a real, provisioned endpoint
8. Direct HTTPS URL, no redirect chain
9. WCAG AA contrast on all text
10. Alt text on every image, CTA is a real <button>, tab-navigable
11. No unnecessary libraries; minimal page weight

List what you found and fixed before giving me the code.

That last line matters. Making the model report its findings rather than silently rewriting forces it to actually check instead of replying "everything looks good."

The order to run it in

Don't QA linearly if you're on a deadline. The money-path items — 7, 8, and 9 (form destination, redirect chain, contrast on the CTA) — determine whether paid traffic can convert at all. Fix those first, then the rendering items, then the metadata polish. A page that converts ugly beats a page that previews beautifully and sends leads nowhere.

Run this list once before launch and once after your first hundred clicks — real traffic will surface the one thing you missed. It always does.

Keep Reading