We build an analytics tool. The entire pitch is that you should be able to trust the numbers you are looking at.
Then we audited our own marketing site, before launch, and found that every single number on it was made up.
This is the list. We are publishing it because the failure mode is common, mostly invisible, and much easier to catch once you know the shape of it.
What we found
| Claim on the page | Reality |
|---|---|
| ”Trusted by 10k+ Analysts” | Zero users. The extension had never been published. |
| Four circular avatars beside it | Solid Google-brand coloured <div>s. Not photographs of anyone. |
| ”Join thousands of marketers who save hours every week” | Same zero users. |
| ”Join 15,000+ data-driven marketers” (newsletter) | No list existed. The form was onsubmit="return false" — it discarded the address. |
| ”v2.0 Now Live” | manifest.json said 1.0.0. |
| ”Available on the Chrome Web Store” | Not submitted. No listing, no release. |
| Blog posts by Sarah Jenkins, David Chen, Marcus Sterling | Three people who do not exist, with three invented job titles. |
| A block quote in one post | An invented quotation, in quotation marks, with no source. |
| ”Version 2.4.0” on the privacy policy | A third version number, agreeing with neither of the other two. |
| ”Our legal team is here to provide clarity” | There is no legal team. |
| ”100% data sovereignty” | An invented percentage, in a legal document. |
Our terms of service also listed four product features — including “Cross-Account Syncing” — that the product does not have, and that directly contradicted our own privacy policy line: “We do not have any servers that receive your data.”
Two legal documents on the same site, disagreeing about whether we run servers.
Nobody had ever used the page
The fabricated numbers were embarrassing. The broken parts were more revealing.
All three “Add to Chrome” buttons pointed at href="#install", and no element with id="install" existed anywhere in the codebase. The single most important element on a marketing site scrolled nowhere, in three places, and had done since the day it was written.
Alongside that: no mobile navigation at all (the links were hidden md:flex with nothing behind the breakpoint, so the blog was unreachable on a phone), blog filter tabs with no handler, a topic cloud of <span>s matching none of the real tags, and a headline that got smaller as the window got wider because the type scale ran 44px → 60px → 56px.
There is a name for a page where every claim is confident and every interaction is dead: it was generated, reviewed by reading, and never once operated.
The bug that hid 70% of the page
One more, because it is genuinely interesting.
Section reveals were built on a CSS scroll-driven animation:
.g-reveal {
animation: g-fade-up linear both; /* from { opacity: 0 } */
animation-timeline: view();
}A view() timeline only advances while its scroll container actually scrolls. When the whole document fits the viewport — zoomed out to 33%, a very tall monitor, a full-page screenshot, a preview crawler — the timeline never progresses, the animation stays in its before-phase, and animation-fill-mode: both re-applies that first keyframe.
Result: roughly 70% of the landing page rendered at opacity: 0.
The trap inside the trap is that setting opacity: 1 on the base rule does not fix it. Fill-mode wins. The only robust fix is to never animate opacity on a scroll timeline at all:
@keyframes g-rise { /* transform only — no opacity */
from { transform: translateY(18px); }
to { transform: translateY(0); }
}Now the worst case is a section resting 18 pixels low, which nobody can see, instead of a blank page.
What we replaced the numbers with
We had no adoption figures, so we stopped claiming any. What went in instead is checkable by the reader without trusting us:
Free · no account of ours · reads the GA4 properties you can already see
And, more usefully, a card on the landing page headed “What it can’t do” — read-only, no Explorations, no custom funnels, no export beyond CSV, figures cached for up to a day. We checked those cache numbers against the source rather than against our own privacy policy, which turned out to be looser than the code.
A product with no track record cannot borrow trust from a user count. It can earn some by being specific about its own limits, which is the one claim nobody bothers to fake.
The checks we now run
Cheap, mechanical, and they would have caught nearly all of the above:
- Grep the built HTML for digits, plus
trusted,join,rated,used by,loved by. Every hit needs a source or it comes out. - Click every CTA. Or automate it: extract every
href="#…"and assert a matchingidexists. - Submit every form and confirm the data arrives somewhere. A form that discards input is worse than no form.
- Cross-check version strings across the site, the manifest, and the legal pages. Ours disagreed three ways.
- Diff the feature list against the product. Ours listed four features that did not exist.
- Render the page at full height, not just at viewport height. That is how the invisible-content bug surfaced.
- Confirm every byline is a real person who consented to it.
None of this requires tooling. It requires deciding that the marketing page is part of the product and gets reviewed like the product.
Why publish this
Partly because it is the kind of post we would have wanted to read. Mostly because we are asking you to trust a dashboard we built, and “here is the embarrassing audit of our own site” is a more honest opening than another statistic neither of us can verify.
If you want to see what the tool actually does, the install steps are here — including the part where it is not on the Chrome Web Store yet.
Questions people also ask
Each answer stands on its own, so it still makes sense quoted somewhere else.
What counts as a fabricated claim on a marketing site?
Any number, endorsement or credential that cannot be traced to a real record. User counts with no analytics behind them, subscriber counts with no list, testimonials from people who were never customers, author bylines for people who do not exist, and version or availability claims that contradict what actually shipped. The test is whether you could produce evidence if someone asked.
Why do AI-assisted marketing sites tend to invent statistics?
Because the genre expects them. A landing page template has a slot for social proof, and a generative model fills every slot it is given. Nothing in the process checks whether the claim maps to a real record, so plausible placeholder numbers survive into production looking exactly like researched ones.
How do you check a marketing site for fabricated claims?
Grep the built HTML for digits and for words like trusted, join, rated and used by, then require a source for each hit. Separately, click every call to action and confirm it resolves, and submit every form and confirm the data arrives somewhere. Dead links and forms wired to discard input are the clearest sign nobody ever used the page.
Does fabricated social proof hurt SEO or AI search visibility?
It creates risk on both. Invented author personas conflict with Google's guidance on demonstrable expertise and experience, and answer engines that quote a page attach your name to whatever claim they pull. A fabricated statistic repeated by an assistant is harder to retract than one sitting on your own site.
What should replace an invented statistic when you have no users yet?
A checkable fact about the product rather than about its adoption. Price, permissions required, what it stores, what it cannot do, and how long data is cached are all verifiable by the reader and all more persuasive than an unverifiable count. Stating a limitation is the strongest trust signal available to a product with no track record.
