How the detector works

We send a request that mimics a real browser — the sameUser-Agent,Accept and language headers Chrome sends. This fools most servers into returning the full page rather than an empty or challenge response.

If the page is protected by a Cloudflare WAF or returns an error, we don't stop — we continue with the other checks below and flag the fetch failure in the result.

We scan the HTML for over 100 patterns that AI builders leave behind:

• →Generator meta tags — e.g. <meta name="generator" content="Lovable">
• →Script and asset paths specific to each builder — e.g. /lovable.dev/ CDN URLs
• →Data attributes injected by builder runtimes — e.g. data-lovable, data-slot=
• →Component library signatures — shadcn/ui, Radix UI, Lucide icons, cmdk
• →Visual design patterns in Tailwind classes — from-purple-500, backdrop-blur-xl, bg-clip-text text-transparent
• →Emoji density in headings — ✨ and 🚀 appear in a majority of Lovable/v0 landing pages

DNS runs in parallel with the page fetch — so even when a site blocks our crawler, we still get DNS data. We query five record types:

• →TXT records — platform verification strings like vc-domain-verify (Vercel), netlify-domain-verification, squarespace-domain-verification
• →CNAME records — reveal the hosting platform (e.g. CNAME pointing to herokudns.com)
• →NS records — nameserver patterns identify Cloudflare, Vercel, Netlify hosting

Response headers frequently reveal the platform even when the HTML is minimal. We check server, x-powered-by, x-vercel-id, x-nf-request-id (Netlify), and dozens more. When the main GET is blocked, a lightweight HEAD request often still returns these headers.

These files are rarely behind WAF protection. A sitemap URL like https://cdn.lovable.dev/… or a robots.txt disallow entry for /wp-admin reveals the platform without ever loading the main page.

We query the RDAP registry for the domain's registration date. Domains registered in the past year score higher — not because new domains are always vibe coded, but because the overwhelming majority of AI-built projects use freshly registered domains.

When both the live page fetch and HEAD request fail, we query the Internet Archive for the most recent public snapshot of the URL, reading the page as the Archive already stored it rather than retrying the origin. We strip the Wayback toolbar (using the id_ flag) so the result is clean captured HTML.

If a Wayback snapshot is used, the result card shows a blue banner noting that results may reflect an older version of the site.

Every signal has a weight. The final score is the sum, clamped to 0–100:

"Anchor" means a real build artifact or the full AI landing-page layout is already present. Without one, design flourishes and buzzwords alone score nothing — professional sites (Cloudflare, Stripe, and similar) use the same modern visual language and copy, so those signals only count as corroboration, never as the sole basis for a verdict.

Everything above is also exposed as an MCP (Model Context Protocol) tool, so an agent can call the detector directly instead of navigating a browser to this page.

• →Endpoint: isthatvibecoded.com/mcp (Streamable HTTP transport)
• →Tool: check_site(url) — same fetch, detection and scoring pipeline as the web form
• →Response: structured JSON — confidence score, detected builder(s) with evidence, full tech stack, domain metadata
• →OAuth protected-resource metadata: isthatvibecoded.com/.well-known/oauth-protected-resource

For agents that don't speak MCP, the same detector is documented as an Agent Skill and indexed in llms.txt.