Vibe Coded Website Checklist: What to Audit Before You Launch (and After)

The reason most vibe-coded websites don't appear in AI answers is straightforward: they were never structured for AI understanding. The tools that build them optimise for what you can see. The infrastructure that makes a site discoverable—schema, crawler access, entity signals, content structure—is invisible during development and absent at launch.

This checklist exists to fix that. Think of it as your AI website launch checklist and vibe coded site audit in one. Run it before you go live. Run it again 30 days after. It takes less than an hour and covers 90% of the structural issues that keep a vibe coded site invisible.

Why vibe-coded sites need a different pre-launch checklist

A standard website launch checklist asks: does the site look right, load fast, and work on mobile? That's necessary but not sufficient.

A vibe coding SEO checklist needs an additional layer: the infrastructure layer. Because the tools that built the site didn't check any of these things, and the person guiding the prompts likely had a knowledge gap that meant they didn't either. Most vibe coding SEO issues are invisible in a browser. You can't see missing schema. You can't see a robots.txt that's blocking AI crawlers. You can't see content that's present to humans but invisible to every crawler that matters.

The four sections below cover technical infrastructure, schema and entity signals, content structure, and post-launch monitoring. Work through them in order, technical first, because there's no point fixing schema on a site crawlers can't read.

Part 1: Technical infrastructure (before you go live)

This section determines whether search engines and AI crawlers can reach and read your site at all. Everything else depends on this.

□ Disable JavaScript and check your content. Open your site in Chrome, go to Settings → Site Settings → JavaScript → Block, and reload every page. If your content disappears, you have a client-side rendering problem. AI crawlers—GPTBot, ClaudeBot, PerplexityBot—don't execute JavaScript. They see what you're seeing now. Fix this before launch by configuring server-side rendering or static site generation in your framework.

□ Confirm robots.txt exists and explicitly allows AI crawlers. Go to yourdomain.com/robots.txt. If the file doesn't exist, create one. If it exists, confirm it explicitly names and allows the major citation crawlers: OAI-SearchBot, Claude-SearchBot, PerplexityBot, ChatGPT-User, Claude-User. A wildcard Allow: / permits them in theory but doesn't protect against accidental blocks from other rules. Explicit is better. If you want to block training crawlers while staying citable, add explicit Disallow rules for those.

□ Confirm sitemap.xml exists, is dynamic, and is referenced in robots.txt. Go to yourdomain.com/sitemap.xml. If it doesn't exist, generate one. If it does exist, confirm it's dynamically generated—meaning it updates automatically when you add or remove pages—rather than a static file that was exported once at launch and never updated. Most modern frameworks (Next.js, Astro, etc.) generate sitemaps dynamically when correctly configured. A static sitemap on a growing site tells crawlers about pages that may no longer exist and misses pages that do. Add Sitemap: https://yourdomain.com/sitemap.xml to your robots.txt. Without a referenced sitemap, crawlers discover pages through links alone, which means some pages may never be found.

□ Check your Cloudflare AI bot settings, and understand the three categories. If your site is behind Cloudflare, go to your dashboard → Security → Bots (or AI Crawl Control). As of July 1, 2026, Cloudflare now classifies AI crawlers into three separate categories you can manage independently: Search (bots indexing content for AI-powered search result—allow these), Training (bots collecting content to train AI models—block if you prefer), and Agent (bots acting on behalf of users in real time, like ChatGPT browsing—allow these if you want AI citation).

From September 15, 2026, new domains onboarding to Cloudflare will have Training and Agent blocked by default on pages displaying ads. If your domain is already on Cloudflare, your settings won't change automatically, but check them anyway.

One critical trap: if you block Training crawlers, Cloudflare will also block mixed-purpose crawlers that combine Search and Training, including Googlebot, Applebot, and BingBot. Blocking Googlebot kills your Google Search rankings. If you're blocking Training, opt out of the new mixed-crawler default in Security settings before September 15 to protect Search functionality.

□ Add llms.txt at root. Create a plain-text file at yourdomain.com/llms.txt. List your key pages with one-line descriptions and state your attribution preference. It's an emerging standard—not a ranking signal—but it signals intent and costs 20 minutes.

Part 2: Schema and entity signals (before you go live)

This section helps with entity SEO and determines whether search engines and AI engines can identify who you are. A site that's crawlable but has no schema is visible but anonymous.

□ Person entity—@id, name, jobTitle, sameAs. Your Person entity is the foundation of your entity graph. It must include: @id (a stable URL like https://yourdomain.com/#your-name), name, jobTitle, url, an image reference, sameAs links to your verified external profiles, knowsAbout topics, and worksFor pointing to your ProfessionalService entity's @id.

□ ProfessionalService entity linked via founder. Your ProfessionalService entity must include: @id, name, url, description, areaServed, logo, and founder pointing to your Person entity's @id. This link is what connects you to your business in the engine's entity model.

□ Service schema on each offering. Every service you offer should have its own Service schema block with name, description, url, and provider pointing to your ProfessionalService entity's @id.

□ FAQPage schema on every content page. Every article and service page with a FAQ section needs FAQPage schema. Each Q&A pair is a pre-chunked extraction target for AI engines—one of the highest-return schema types for AI citation.

□ Article schema on every content page. Every article needs Article schema with headline, author (pointing to your Person entity's @id), publisher (pointing to your ProfessionalService entity's @id), datePublished, dateModified, and url.

□ Zero errors in Google Rich Results Test. Go to search.google.com/test/rich-results and run your URL. Zero errors is the target. Warnings are usually acceptable. Errors mean the schema isn't being read correctly; fix them before launch.

For the full JSON-LD code blocks ready to implement, see Schema Markup for Founders.

Part 3: Content structure (before you go live)

This section determines whether AI engines can extract and cite your content. Crawlable, schema-marked content that's written for human narrative still won't be cited if the answers are buried.

□ Every page opens with a direct answer paragraph (40–60 words). The first paragraph of every page and article should directly answer the question the page is addressing. No preamble and no scene-setting; share the answer first. AI engines disproportionately extract from the beginning of content.

□ No key answer buried more than two paragraphs in. Read the first two paragraphs of every section. If the answer to the implied question isn't there, move it to the front. Content structured for narrative builds to a conclusion. Content structured for extraction opens with one.

□ FAQ section on every article and service page. Every article and service page should have a FAQ section with at least three standalone, citable questions. Pair with FAQPage schema from Part 2.

□ sameAs links consistent across site, LinkedIn, and all external profiles. Your name, job title, and business description should be identical across all places where your entity appears. Check: your website's about page, LinkedIn headline and bio, directory listings, podcast bios, and guest post bylines. Inconsistency prevents the engine from confidently resolving all these references to a single entity.

Part 4: Post-launch monitoring (first 30 days)

Launch isn't the end of the infrastructure work. The first 30 days tell you whether it's actually working.

□ Submit your sitemap in Google Search Console. Go to Google Search Console → Sitemaps → enter your sitemap URL → Submit.

□ Request indexing on key pages. In Google Search Console, go to URL Inspection → enter each key page URL → Request Indexing. Do this for your homepage, service pages, and first few articles.

□ Run the PRISM Platform Checker. Go to aimeeqdevlin.com/tools/ai-crawler-checker and run your domain. It checks six Platform-layer signals in one pass: AI bot access, robots.txt validity, sitemap presence, llms.txt presence, JavaScript rendering risk, and Core Web Vitals. Free, no login required. If anything flags, go back to Part 1.

□ Run a domain overview in an SEO tool. Enter your domain in Semrush, Ubersuggest, or Ahrefs' free site explorer. At launch, you'll see nothing; that's expected. Check again at day 30. You should see pages beginning to appear in the index and early impressions in GSC. Nothing after 30 days means the rendering or crawler access fix from Part 1 didn't take.

□ Check your AI visibility. Open ChatGPT, Perplexity, and Claude. Ask each: "Who is [your name]?" and "What does [your business name] do?" and "Who are the best [your service category] specialists?" At launch, you won't appear. Note what comes back. Check again at 60 days and 90 days. No appearances after three months means the entity graph from Part 2 needs attention.

□ Monitor GSC impressions for the first 30 days. In Google Search Console → Performance → Search results, set the date range to your launch date to 30 days later. Look for: impressions beginning to appear (even at position 80–100—this means Google has found and indexed the pages), non-branded queries surfacing, and click-through rate beginning to register. No impressions after 30 days is a crawl issue. Impressions but no movement is a content or schema issue.

Aimee Q Devlin is a Systems and Infrastructure Architect based in San Miguel de Allende, Mexico. She works with founders and operators of established businesses who are ready to rebuild their systems properly—including the infrastructure that makes those systems discoverable. The Infrastructure Audit is where most engagements begin.

→ The Infrastructure Audit

→ Your Vibe-Coded Website Looks Great. Here's Why Nobody's Finding It.

→ What Vibe Coders Get Wrong About SEO (And How to Fix It)