How to tell if a website was made with AI (or vibe coded)

More and more websites start life as a prompt. Tools such as Lovable, Bolt.new, v0, Replit, Base44, Manus, Emergent, Rocket, Readdy, Google AI Studio, Firebase Studio, Dyad and Hostinger Horizons turn a sentence into a working site in minutes. That’s not a problem in itself: plenty of honest businesses use them. But if you’re about to buy from a shop, judge a competitor or hire an agency that says it builds everything by hand, it’s fair to ask how a site was made.

Here’s the honest answer up front: you can often prove that an AI builder was used, but you can never prove that one wasn’t. Builders leave traces, and traces can be found. Their absence proves nothing.

Builders sign their work, most of the time

An AI site builder doesn’t just write the page. It also hosts it, adds its own scripts and tags, and fills in defaults that people forget to change. Each of those leaves something you can see from the outside, without logging in anywhere.

The traces fall into five places. Work through them from strongest to weakest.

1. The address

Many AI-built sites live on the builder’s own hosting, at least at first. The address gives it away:

This is the strongest trace there is: the site is literally served by the builder. It disappears as soon as the owner connects their own domain, which is why it only catches a share of sites.

2. The page source

Open the page, press Ctrl+U (or Cmd+Option+U on a Mac) to view its source, and search with Ctrl+F. You’re looking for things the builder wrote, not the owner:

• Scripts from the builder. Many Lovable sites load a small script from cdn.gpteng.co, a leftover from the days when Lovable was called GPT Engineer, or a script ending in /~flock.js. Softgen’s starter loads cdn.softgen.ai/script.js on every page, Rocket’s pages load static.rocket.new/rocket-web.js, Emergent’s load assets.emergent.sh/scripts/emergent-main.js (with a “Made with Emergent” badge), and Manus writes a script with the id manus-runtime into every page it builds. Apps made in Google AI Studio load their libraries from aistudiocdn.com.
• Meta tags. Look at the <meta> lines near the top. <meta name="author" content="Lovable"> is a clear signature, and so is a generator tag that says v0.app or Hostinger Horizons.
• Default text. Builders fill in a description and a title, and people often forget to change them. “Lovable Generated Project”, “Created with v0”, a title of “v0 App”, “Generated by Firebase Studio”, “A product of emergent.sh”, “Readdy Site” and a title of dyad-generated-app are all defaults.
• Asset addresses. Images and files uploaded through the builder often keep its storage address: gpt-engineer-file-uploads for Lovable, media.base44.com for Base44, cdn.durable.co for Durable, api.tempolabs.ai/proxy-asset for Tempo, readdy.ai/api/search-image for the pictures Readdy picks. Be careful with uploads: an owner can link the logo they uploaded to a builder from a site they made elsewhere, so on its own an upload is a hint, not proof.

One caution: pages drawn by JavaScript can look almost empty in the source. That’s normal for app builders. The traces are usually still in the <head>, which arrives before any JavaScript runs.

3. The response headers

Every page arrives with headers the visitor never sees. In Chrome or Firefox, open the developer tools (F12), go to the Network tab, reload, click the first request and read Response headers. Some Bolt-hosted sites answer with an x-powered-by header that starts with Bolt.

Headers are hard to fake by accident, which makes them strong evidence when they’re there.

4. Markup the builder adds

Some builders tag the elements they generate. Pages made with Lovable can carry attributes named data-lov-id, which its editing tools use. Searching the source for data-lov-id is a quick check.

5. Design patterns: weak on their own

AI app builders tend to use the same building blocks by default: the shadcn/ui component library (you’ll see many data-radix- attributes) and the Lucide icon set (many elements with lucide classes). An untouched starter title such as “Vite + React” is another hint of a quickly generated project.

The problem is that thousands of developers use exactly the same tools by hand. So treat these as weak signals: worth noting, never enough on their own.

How strong is each trace?

Why “none found” never means “made by a person”

A clean result is not a certificate of hand-made work. Plenty of AI-made sites leave no traces at all:

• Coding assistants such as Cursor, Claude Code and GitHub Copilot write ordinary code in an ordinary project. Nothing in the result points back to them.
• Exported projects. Several builders let you export the code and host it anywhere. Hosting traces vanish, and many script traces go with them.
• Clean-up. Owners remove badges, rewrite default text and change titles, often precisely because they don’t want the builder to show.
• Builders change. What a builder adds today may not be what it added last year.

That’s why a careful answer has levels rather than a yes or no. On a CheckAnySite result you’ll see High when clear traces of a builder were found, Medium when only weaker traces of one builder were found together, and None found otherwise. Shared building blocks (component libraries, icon sets) are listed as context, but never raise the level on their own, with a reminder that none found is not proof of anything.

How well does this work in practice?

We measure it. On 4 October 2026 we ran our detector against 2,312 websites we had labelled from public evidence: 1,278 built with 34 AI builders and 1,034 not, most of them hand-made projects on the same stack AI builders use, 883 of them started before any AI site builder existed. Every site it flagged really was AI-built (100% precision), and it caught 83.4% of the AI-built ones; on the 265 sites of our previous test set, 89.4%. On a separate set we never used to tune our rules, made mostly of projects exported from their builder and hosted elsewhere (the hardest case), it caught 68.2% and flagged none of the others. The full report, misses included: we tested our AI website detector.

The misses are instructive. Builders that write their name into every page, or serve the sites they build, are easy: we caught every Hostinger Horizons, Gamma, Floot and Softgen site in the test set. Projects exported from a builder are not: a Firebase Studio or Same project moved to Vercel often keeps nothing of its builder, and we catch 81% and 49% of those, the first mostly by the icon its starter ships, the second by the runtime its editor leaves in the page. We’d rather miss a site than accuse one wrongly, so we don’t guess. The full breakdown is in our accuracy study.

A quick checklist

1. Does the address end in a builder’s domain?
2. In the source, any builder scripts, author or generator tags, or default descriptions?
3. Any builder storage addresses in images and files?
4. Any builder headers in the Network tab?
5. Only shared building blocks? Note them, but don’t conclude anything.
6. Nothing found? Then you simply don’t know, and that’s the honest answer.

Try it: the AI Website Detector runs all of these checks in one go and shows each trace it finds, with the exact line.