# The AI Website Go-Live Checklist Everything to check before an AI-built site goes public: search, performance, accessibility, and being readable by the models people now ask instead of Google. Made by [Flowlabz](https://www.flowlabz.com) · Brandon Watkins · brandon@flowlabz.com Free to use, share and adapt. If it saves you a bad launch, that's the point. --- ## How to use this Work top to bottom. Anything in **Blocking** will cost you traffic, money or trust on day one. Everything else can follow in the first week. Each item says how to check it, not just what to check. A checklist you can't verify is a wish list. --- ## 1. Blocking: do not go live without these - [ ] **The site is actually reachable.** Load the production URL in a private window, signed out, on a phone on mobile data. Not localhost. Not your laptop with the cache warm. - [ ] **`robots.txt` does not say `Disallow: /`.** Staging sites are usually built with crawling switched off, and that line ships to production more often than any other mistake on this list. Check the live file at `/robots.txt`, not the one in your repo. - [ ] **No `noindex` left anywhere.** Check both places it hides: a `` in the HTML, and an `X-Robots-Tag` response header. Verify the header. It is invisible in View Source: curl -sI https://yoursite.com | grep -i x-robots-tag - [ ] **Password gates and holding pages are gone**, and every environment variable that drove them is unset. - [ ] **One canonical hostname.** Pick `www` or bare, 301 the other, and make sure every internal link and the canonical tag agree. Two live hostnames split your ranking in half. - [ ] **HTTPS everywhere**, with HTTP redirecting to it, and no mixed-content warnings in the console. - [ ] **Forms deliver to a real inbox.** Submit the live form yourself and confirm the email arrives. AI tools scaffold forms that validate beautifully and post nowhere. - [ ] **404s return 404.** A single-page app that answers `200` with an empty shell teaches search engines that every wrong URL is a real page. - [ ] **Nothing secret is in the deploy.** API keys, `.env` files, database URLs, internal docs, design files, client work under NDA. Try fetching them by guessing the path. --- ## 2. Search engines ### Indexability - [ ] Every page you want found is linked from somewhere a crawler can follow: a plain ``, not a button that navigates with JavaScript. - [ ] `sitemap.xml` exists, lists only pages that return `200`, and is referenced from `robots.txt`. - [ ] No page is reachable at more than one URL. Watch for trailing slashes, `index.html`, query-string duplicates and upper/lowercase paths. - [ ] Every page has a self-referencing ``. - [ ] Submit the sitemap in Google Search Console and Bing Webmaster Tools, and use "Inspect URL" on your three most important pages. ### What the result will say - [ ] **One `

` per page**, and it describes that page, not the company. - [ ] **Titles under about 60 characters.** Beyond that, search results cut them off mid-word. - [ ] **Descriptions under about 155 characters**, written as a reason to click, not a keyword list. - [ ] Titles and descriptions are **different on every page**. Templated sites repeat the homepage's across the whole site. - [ ] **Open Graph and Twitter tags** with a 1200×630 image, so a shared link doesn't unfurl as a grey box. Test with a real post you delete after. ### Structured data - [ ] `Organization` or `LocalBusiness` on the homepage, with the name, logo, URL and `sameAs` links to your real profiles. - [ ] `BreadcrumbList` on inner pages. - [ ] `Article` on posts, with `datePublished` and a real author. - [ ] `FAQPage` wherever you show questions and answers, and make sure the schema says exactly what the page says. Invented answers in the markup are a manual-action risk, not a clever trick. - [ ] Validate everything at validator.schema.org and in Search Console's Rich Results test. --- ## 3. Being readable by AI This is the part most checklists still skip. People increasingly ask a model instead of searching, and the model reads your site through a crawler that is usually far less capable than Googlebot. - [ ] **Your content is in the HTML.** Fetch the page the way a crawler does and look for your actual words: curl -s https://yoursite.com/some-page | grep -i "a sentence from that page" If it isn't there, your page is invisible to most AI crawlers. Many run no JavaScript at all. This is the single biggest failure mode for sites built with AI tooling, which default to client-side rendering. - [ ] **Every article, product and case study is its own URL** with its own title, description and content in the HTML, not one page that swaps content from a query string. - [ ] **`robots.txt` allows the AI crawlers you want.** They are separate agents and are not covered by allowing Googlebot. Decide deliberately for each: GPTBot, OAI-SearchBot, ChatGPT-User (OpenAI) ClaudeBot, Claude-User, Claude-SearchBot (Anthropic) PerplexityBot, Perplexity-User (Perplexity) Google-Extended (Gemini training) Applebot-Extended (Apple Intelligence) CCBot (Common Crawl) Blocking training crawlers while allowing search crawlers is a legitimate position, just make it a choice rather than an accident. - [ ] **Add an `/llms.txt`.** A short Markdown file at the root saying who you are, what you do, where the important pages are, and how to get in touch. An `/llms-full.txt` can carry the long version. Keep them true: they are read as a description of you. - [ ] **State facts plainly in prose.** A model can quote "projects start at R30,000 and take three to six weeks". It cannot quote a price hidden in an image, a slider or a PDF. - [ ] **Answer real questions in real sentences.** An FAQ written the way someone would actually ask is the most quotable thing on most sites. - [ ] **Be consistent about your own facts.** Your location, founding year, service names and contact details should match across the site, your schema, your `llms.txt` and your public profiles. Models weigh agreement; contradicting yourself makes you unquotable. - [ ] **Dates on anything time-sensitive**, so a model can tell current from stale. --- ## 4. Performance Test on a throttled connection with a slow CPU, not on your machine. In Chrome DevTools: Lighthouse, mobile preset. Or: npx lighthouse https://yoursite.com --preset=desktop --view ### The three that are measured - [ ] **LCP under 2.5s**. The largest thing on screen. Usually a hero image or headline. Preload it; never lazy-load it. - [ ] **CLS under 0.1**, nothing jumps. The usual culprits: - images and videos with no `width` and `height` - web fonts that swap and re-flow the text - banners, cookie bars and ads inserted above existing content - [ ] **INP under 200ms**. The page answers a tap quickly. Look for long JavaScript tasks blocking the main thread. ### Getting there - [ ] **Images.** WebP or AVIF, sized to how they are actually displayed, with `srcset` for different screens, `width`/`height` always, `loading="lazy"` on anything below the fold, and never on the LCP image. - [ ] **Fonts.** Subset to the characters you use, `font-display: swap`, preload the one the first screen needs, and define a **metric-matched fallback** with `size-adjust`, `ascent-override` and `descent-override` so text doesn't re-flow when the real font lands. This is what turns a visible font swap into an invisible one. - [ ] **Don't let the font stylesheet block the first paint.** Preload it and apply it on arrival. - [ ] **JavaScript.** Ship less. Check what you actually use in DevTools → Coverage. Remove the animation library you used once. AI-built sites routinely carry five dependencies doing one job. - [ ] **Video.** Never autoplay a large file. `preload="none"`, a poster image, and play on interaction. - [ ] **Caching.** Long `Cache-Control` with immutable, hashed filenames for static assets; short for HTML. - [ ] **Compression** (Brotli or gzip) is on for text responses. - [ ] Re-run Lighthouse **against production**, not your dev server. Dev servers don't compress and don't cache, so the numbers are wrong in both directions. --- ## 5. Accessibility Not optional, not only for compliance: most of it is the same work as good search and good AI readability. - [ ] **Keyboard only.** Tab through the whole page. Can you reach and operate everything? Can you see where you are? Can you escape every menu and dialog? - [ ] **Visible focus** on every interactive element. Don't remove outlines without replacing them. - [ ] **Contrast**: 4.5:1 for body text, 3:1 for large text and for the visible edges of controls. Check the states too, placeholder text, disabled buttons and text over images fail most often. - [ ] **Alt text** that says what the image means. Decorative images get `alt=""`, not a filename. - [ ] **Labels on every form field**, properly associated. A placeholder is not a label. It disappears as soon as someone types. - [ ] **Errors are announced**, not just coloured red. - [ ] **Headings are in order** and describe structure. Don't pick a heading level for its size. - [ ] **Landmarks**: one `
`, a `