How to Tell If a Website Is Vibe Coded (and What Matters More)

Sign 1: The Builder's Badge and Address

The main AI app builders publish to a default subdomain first, and most add a small badge until you pay to remove it. This is what each one's documentation says, checked on 24 October 2026:

Sources: Lovable publishing and plans, Bolt's publishing and hosting plans, Replit's publishing and Starter plan, Base44 and v0.

Read the table both ways. A badge or a builder subdomain is strong evidence, but its absence proves little: paid plans hide the badge and a custom domain hides the address. A vercel.app address on its own says nothing about v0, because that domain belongs to Vercel.

Sign 2: Leftovers in the Page Source

We read the raw HTML of six public sites on these default addresses on 24 October 2026. Builders leave fingerprints in the parts visitors never see:

• Bolt: a published site loaded https://bolt.new/badge.js and still used Bolt's default preview image, bolt.new/static/og_default.png.
• Lovable: Lovable's own academy site carried the badge markup, a link tagged utm_source=lovable-badge. A user's Lovable app loaded scripts from paths such as /~flock.js, with a token naming a Lovable project ID that starts with lovp_. Lovable's docs add that, unless you set one, the preview image is the latest screenshot of your app.
• Replit: an example app from Replit's docs still had the template description, ending "Update this description to reflect the app."
• Base44: two apps served their preview images from a path containing base44-prod, and one kept the alt text "Base44 link preview".

None of the six had a generator meta tag, so do not count on one. You can run the same check on any site from a terminal:

# Look for builder leftovers in a site's HTML
curl -sL https://example.com | grep -ioE "lovable[^\"' ]*|bolt\.new[^\"' ]*|replit[^\"' ]*|base44[^\"' ]*"

# Check the description and preview image people see when the link is shared
curl -sL https://example.com | grep -iE 'name="description"|property="og:image"'

Sign 3: Design Clichés, the Weakest Evidence

Design creators on social media keep a list of visual tells, such as this one: purple-to-blue gradients, emoji in headings, the Inter font everywhere, glassmorphism cards and untouched shadcn components.

Each of these can appear on a site a person built by hand, so treat them as hints, not proof. If they bother you on your own site, they are a design fix, not a security one.

If You Have the Code: Signs in the Repo

With access to the repository you can look past the surface:

• Git history. Some coding agents add trailers such as Co-Authored-By: Claude to the commits they write.
• Packages that do not exist. AI tools sometimes import a package name nobody ever published. Our guide to hallucinated imports shows how to catch them.
• Writing habits. Justin McKelvey's field guide lists tells such as comments that narrate each line, calls to APIs that do not exist, naming that drifts between files, copy-pasted logic and "ceremonial" error handling.

Why AI Code Detectors Cannot Settle It

AI-code detectors give a probability, not a verdict, and McKelvey's guide opens bluntly: "The Detector You Want Doesn't Exist. The Skill Does." Even a perfect detector would answer the wrong question. A score that says 80% of a file came from a model tells you nothing about whether its login checks the right user, whether a secret key ships to the browser, or whether the database lets one customer read another's records.

That is the question most people asking "is this vibe coded?" really have: can I trust this site with my data, or can I ship mine?

What Matters More Than Who Built It

Whether a person or a model wrote the code, the same checks decide whether a site is safe to use:

• Who can read the data. Missing access rules let one user read another's records. See Supabase Row Level Security and the Lovable BOLA breach.
• Secrets in the browser. Keys prefixed for the frontend end up in the bundle anyone can download. See client-side secret exposure.
• Headers and certificates. See missing security headers and SSL certificate issues.
• The basics a visitor sees. A privacy policy and terms page, no console errors, no broken links.

The leftovers from Sign 2 belong on this list too. A template description or a builder's default preview image is what search results and link previews can show when someone shares your site.

How to Fix It on Your Own Site

If you built your site with one of these tools, a few minutes removes the most obvious marks:

1. Open the site in a private window and look for the builder's badge. Remove it in the builder's settings if your plan allows.
2. Connect your own domain, so the builder's subdomain is not the address people share.
3. Replace the template description and preview image with your own.
4. Then check what visitors cannot see: access rules, keys in the bundle, headers and legal pages.

<!-- BAD: the template text is still in the page head -->
<meta name="description" content="... built on Replit. Update this description to reflect the app.">
<meta property="og:image" content="https://bolt.new/static/og_default.png">

<!-- GOOD: your own words and your own preview image -->
<meta name="description" content="Invoice tracking for freelancers. Free for your first 20 clients.">
<meta property="og:image" content="https://yourdomain.com/og-image.png">

Tools like VibeDoctor's Vibe Check (vibedoctor.io) automatically scan your live site and your repository: security headers, SSL, console errors, SEO tags, privacy policy and terms, and secrets in the code, with specific file paths and line numbers. Free to sign up.

FAQ