The short answer
Look for a pattern cluster, not a visual cliché
Rounded cards, gradients, oversized headlines and familiar dashboard layouts are common across the modern web. Seeing one of them tells you almost nothing about authorship. The useful question is whether multiple independent parts of the delivered site show the same kind of unedited default thinking.
Start with direct public traces, then move through implementation conventions, design repetition, product-specific content and operational polish. Confidence should decrease—not increase—as you move from a direct marker toward subjective visual impressions.
- Separate observation from interpretation in your notes
- Record at least one credible non-AI explanation for every signal
- Treat quality, security and authorship as different questions
Signal strength
An evidence ladder for public websites
The levels are ordered by how directly they describe the delivered surface. Even the strongest public evidence usually supports a narrow statement, not a complete origin story.
Direct public markers
Builder names in generated comments, asset paths, metadata or publicly delivered manifests.
Implementation conventions
Repeated class-token patterns, unusual inline-code volume, component structures or framework defaults across several pages.
Design pattern clusters
The same card rhythm, gradient treatment, icon style, spacing errors and interaction gaps recurring across unrelated sections.
Content and product fit
Generic promises, placeholder proof, inconsistent terminology or pages that do not answer the buyer’s obvious questions.
Operational quality
Broken states, missing metadata, weak headers, inaccessible controls or poor mobile behavior.
Decision matrix
Common signs and their false positives
Use the final column before drawing a conclusion. It turns a resemblance into a testable next step.
| Observation | Possible vibe-coding explanation | Plausible alternative | Best next check |
|---|---|---|---|
| Every section uses rounded cards | A default component recipe was repeated | A deliberate design system uses one container primitive | Check whether hierarchy, spacing and behavior vary meaningfully with the content |
| Copy sounds polished but vague | Generated copy was accepted without product editing | The team has not completed positioning work | Ask whether a specific audience, mechanism and proof are named |
| Class names resemble a popular UI stack | Generated code selected that stack | A human developer intentionally uses the same library | Look for direct markers and consistent engineering conventions, not the library alone |
| Desktop looks complete; mobile feels improvised | The initial prompt focused on one viewport | Normal delivery pressure cut responsive QA | Test navigation, forms, overflow and reading order at several widths |
| Security headers are incomplete | The generated deployment omitted hardening | Infrastructure was configured manually but incompletely | Review the separate security baseline and the actual deployment configuration |
Repeatable process
A ten-minute assessment you can repeat
Use the same sequence for every site. Consistency makes your notes more useful than a first impression.
- 01
Define the claim
Write the exact question you are trying to answer: visual similarity, public builder traces, launch quality or code authorship.
- 02
Walk the real journey
Use the navigation, a form, one error path and a mobile viewport. Do not judge only the hero screenshot.
- 03
Collect independent signals
Record signals from at least three different domains such as design, content and delivered implementation.
- 04
Challenge each signal
Name an ordinary template, library, deadline or design-system explanation that could produce the same result.
- 05
State a bounded conclusion
Describe resemblance and review priorities. Avoid claims about hidden source code or authorship.
Applied example
Worked example: a polished SaaS landing page
A landing page has a gradient headline, three rounded feature cards, generic transformation copy and a familiar pricing table. Its forms work, mobile spacing is consistent and no direct builder marker is visible.
- The design motifs are common, but they are applied consistently.
- The content lacks product-specific proof, which is an actionable content weakness.
- No direct public marker identifies an authoring tool.
- The mobile and interaction quality argues against calling the page an unreviewed output.
Plain answers
Questions people ask after the first review
What is the biggest giveaway of a vibe-coded website?+
There is no universal giveaway. A direct public builder trace is narrower and stronger than a visual impression, while a cluster of unrelated weak signals is more useful than one fashionable design motif.
Can browser developer tools prove that a site was vibe coded?+
They can expose delivered markers, libraries and implementation conventions. They cannot reconstruct private prompts, repository history, authorship or the share of generated code.
Does a high Vibe-Footprint mean the website is bad?+
No. It means the measured public patterns show stronger similarity to the reference corpus. Concrete design, content, engineering and security findings must be reviewed separately.