For years, fake testimonials were easy to spot. They were short, generic, written in the same three or four templates, and submitted in bursts from a handful of IP ranges. The pattern was so consistent that most testimonial pipelines did not need real moderation — a half-page of regex and a rate limiter caught nearly everything that mattered.
That is over. The submissions our customers now flag for review look real, sound real, and are sometimes indistinguishable from a genuine customer's reply on a first pass. They are LLM-authored, often refined through several iterations, sometimes paired with a believable persona profile and a stock photo that survives a reverse image search. The old signals catch almost none of them.
This is the pipeline we now recommend. It is structured in four stages — submission, content, identity, and post-publish — so that each stage can fail closed without forcing real customers through more friction than they are willing to tolerate.
Why a single-stage filter no longer works
The temptation, once teams realize the old filter is broken, is to bolt on a heavier filter at the same stage. The submission form gets a CAPTCHA. Then a longer CAPTCHA. Then a required phone number. Then a required corporate email domain.
This is the wrong direction. Single-stage hardening trades real customer conversion for a marginal improvement against the sophisticated end of the threat. A real customer who was happy to leave a one-paragraph quote on your site will not bother to switch phones to receive an SMS verification code, and the LLM-driven attacker has cheap workarounds for every barrier you put at the front door. You make the gate taller and discover that almost no one walks through it, including the people you wanted.
Multi-stage filtering inverts this tradeoff. Each stage does only what it is good at. Friction is distributed so that no real customer experiences enough of it to drop out, while a synthetic submission has to pass independent checks that look at different things. The attacker who optimizes for one stage often fails at another.
Stage one — submission signals
The first stage looks at metadata around the submission itself, not at the content. It is the cheapest and the least controversial. None of these signals is decisive on its own, and none of them should ever block a submission outright. They contribute to a score that determines how the next stages treat the submission.
Useful submission signals include the request fingerprint — browser, timezone, language headers, and whether those three are mutually consistent — the path the user took to reach the form, the time elapsed between form load and form submit, and whether the form was filled in a humanly plausible order or in a way that suggests automation. A submission from a browser whose declared timezone is Tokyo but whose accept-language header is en-US with no ja fallback is not automatically suspicious, but combined with a form completion time under three seconds it starts to look unlike a normal customer.
Two anti-patterns to avoid at this stage. Do not block on IP reputation alone — a substantial fraction of legitimate customers come from VPNs and shared corporate networks, and IP-based blocking will quietly tank your collection rate from privacy-conscious users without you noticing for weeks. And do not use submission speed as a hard cutoff — some real customers really do submit quickly because they pasted text from another draft. Use speed as a feature in a score, not as a gate.
Stage two — content signals
The second stage looks at the testimonial text itself. This is where the LLM detection problem lives, and it is the stage where teams get the most wrong because the obvious approaches are obsolete.
The obvious approach is to run a commercial AI-detection classifier on the text. Two years ago this worked reasonably well. Today the classifiers have a meaningful false-positive rate on human-authored text — particularly text written by non-native English speakers, which disproportionately punishes international customers — and a meaningful false-negative rate on LLM text that has been even lightly post-edited. A classifier score is useful as a feature, but it is not a decision boundary.
The signals that have held up better are not about whether the text was written by a machine but about whether the text is grounded in the specific product. A real testimonial almost always contains a verifiable detail — a feature name, a workflow step, a number that the customer would only know if they had used the product. A synthetic testimonial, even a sophisticated one, tends to stay at the level of generic praise that could apply to any product in the category. "Cut our review time by 40 percent" is a generic claim. "Cut our average time-from-form-submission-to-published-card from eleven days to under three" is a grounded claim that an attacker without product access cannot easily fabricate.
A practical implementation at this stage is a grounding check that compares the testimonial text against a list of feature names, plan names, and workflow vocabulary specific to your product. A testimonial with zero matches is not automatically fake — some real testimonials are genuinely brief and generic — but combined with an above-threshold submission-stage score, it routes the submission to human review rather than auto-approval. For the broader credibility logic behind which specific details actually move buyer trust, see our testimonial card with use-case specificity and jobs-to-be-done attribution credibility impact guide.
A second content signal worth tracking is internal consistency. LLM-authored text sometimes contains small contradictions that a human author would catch in their own draft — claiming both that the implementation took two weeks and that the team has been using the product for "years," or naming a role that does not exist in the company size the submitter claims. These are not common, but when they appear they are a strong signal, and they are cheap to check with a simple second-pass prompt that asks an LLM to look for contradictions in a piece of text. Using an LLM to catch LLM-generated inconsistencies is unintuitive but works because the writing model and the auditing model are optimizing for different things.
Stage three — identity signals
The third stage looks at who the submitter claims to be and whether that identity holds up under modest scrutiny. The principle is progressive verification — you only ask for the next identity check if the previous stages produced a non-trivial risk score.
For low-risk submissions, identity verification is a single low-friction step like a confirmation email to the address on file. For medium-risk submissions, you escalate to checks that are slightly heavier but still do not require active customer effort — a domain check against the company name, a LinkedIn presence check, a cross-reference against your own CRM to see whether this person is actually a customer. For high-risk submissions, you escalate further to a manual review step where a human moderator looks at the full record.
The point of progressive verification is that the friction is invisible to the customer whose submission scored low. They go through the same flow they always went through. The customer whose submission scored medium gets one extra email, which most are willing to handle. Only the high-risk submissions hit human moderation, which keeps the moderation team's caseload small enough to actually look at each one carefully.
A common failure mode at this stage is asking for identity verification before any signal has been gathered. A required corporate email at the front door is a stage-three check applied universally, which is the same as having no stage-one or stage-two filter at all and just turning the friction dial up. For more context on consent and verification mechanics that hold up against this kind of synthetic-submission pressure, see our how to verify testimonial authenticity guide.
Stage four — post-publish monitoring
The fourth stage is the one most teams skip and it is the one that catches the submissions that got through the previous three. Synthetic testimonials, once published, sometimes get flagged by readers — a sales rep who notices a quote attributed to a customer they have never heard of, a real customer who reads a similar quote and notices an unusual phrasing, a search engine spider that surfaces the same paragraph appearing on a competitor's site too.
A post-publish stage means treating published testimonials as still mutable for a moderation window — typically thirty to ninety days — with a low-friction internal flagging mechanism and a rapid takedown path. It also means periodic sweeps that re-run the stage-two content checks against published testimonials, because attackers sometimes succeed on the first pass and the only way to catch them is to look again later with better signal.
Two metrics to watch in this stage are takedown rate — what fraction of published testimonials are pulled within the moderation window — and takedown latency — how long from publication to takedown when a flag is raised. A takedown rate that is very low could mean your pipeline is excellent or it could mean nobody is flagging, which are very different situations. A takedown latency above a few days suggests the post-publish stage exists in name only.
What this pipeline is not designed to do
This pipeline is not a guarantee against sophisticated, well-resourced fraud. A determined attacker with access to a real customer's identity, the ability to manufacture grounded product detail, and the patience to evade rate limits will get through any reasonable filter. The pipeline is designed to make the unsophisticated attack uneconomic — the high-volume, low-effort LLM-driven flood that is currently the dominant threat — while keeping the friction on real customers low enough that your collection rate does not collapse.
For the threat model where a competitor specifically targets you with hand-crafted fake testimonials, the pipeline does not solve it. What solves it is a small human moderation team that knows your product well enough to spot the kind of grounded-but-wrong detail an outsider cannot fake — a mention of a feature that was sunset last quarter, a process step in the wrong order, a job title that does not exist at the company size claimed. That kind of judgment cannot yet be automated. But the pipeline reduces the moderation queue from "every submission" to "the small fraction that scored above the human-review threshold," which is the only way a moderation team of any practical size can keep up.