Our page generator produced 15 identical pages and scored them 82-95 on distinctiveness.

Summary: Across 15 consecutive production runs on 29–30 May 2026, our landing page generator returned the same 18 feature assignments every time. Every run logged kept=18 dropped=0 with an identical winner set. Our per-page evaluator scored these near-duplicate pages 82–95 on distinctiveness and 90–98 on hero fitness. The quality gate could not see the problem, because per-page richness and cross-page diversity are different properties and we were only measuring the first one.

If you are using AI to generate landing page variants, this is the failure mode to check for, and it is close to invisible from inside your own quality metrics.

What happened

Fifteen production runs, one brand, back to back. Each run is supposed to explore the design space — pick a hero treatment, a headline strategy, a CTA placement, a proof format, and so on — and produce a page meaningfully different from its siblings.

All 15 runs produced the same 18 feature assignments. Every single one logged kept=18 dropped=0 against an identical winner set. Fifteen pages, one design.

The generator did not error. Nothing was dropped. Every run reported success.

Why the quality gate did not catch it

Here is the part worth internalising.

Our evaluator scored these pages 82–95 on DISTINCTIVENESS and 90–98 on HERO_FITNESS.

Those scores are not wrong. Each page, considered on its own, genuinely was distinctive — a strong hero, a coherent layout, copy that did not read as boilerplate. Any single one of them would pass review.

The problem is that the evaluator scores one page at a time. Per-page richness is not cross-page diversity, and nothing in the system was measuring the latter. A metric that only ever sees one page cannot detect that it is looking at the same page fifteen times.

This generalises well beyond our stack. If your AI content pipeline scores each output independently — for quality, brand fit, readability, originality — you have no instrument for convergence. You can score 90/100 fifteen times and have produced one page.

The mechanism: argmax collapse

The root cause was a greedy per-dimension argmax on the explore path.

For each design dimension, the generator picked the variation with the highest posterior estimate. Early on, with diffuse posteriors, small random differences produce varied picks and the output looks diverse. As the posterior converges — as the system learns which hero treatment is doing well — argmax starts returning the same answer for every dimension, every run.

The failure gets worse as the model gets better. The generator was working exactly as specified. Its specification was wrong. And the symptom appears late, after the system has accumulated enough data to have opinions, which is also when a team has stopped watching the early-run output closely.

Two related failures surfaced in the same investigation. Product scope had frozen to 31 of 968 available products — the same narrow slice feeding every page. And the split/mobile generation path failed 15 out of 15 times, silently, without failing the run.

The fix

Three changes:

Temperature softmax replacing argmax on the explore path, at a default τ = 0.5. Instead of always taking the highest-posterior variation, sample in proportion to posterior weight. High-performing variations still get chosen more often; they stop getting chosen exclusively.

A cross-page diversity metric with a threshold, comparing briefs across a batch rather than scoring pages in isolation. Batch brief-diversity must clear 0.92 or the batch is rejected. This is the instrument that was missing.

Batch-level gating. Diversity is a property of a set, so it has to be enforced on the set. A per-page gate structurally cannot check it.

What to check in your own pipeline

Four checks, in order of how often they catch something:

Compare outputs to each other, not just to a quality bar. Take your last N generated pages and diff their structural choices — hero type, section order, proof format, CTA treatment. If the distribution is narrow, you are generating one page repeatedly regardless of what your quality scores say.

Look for greedy selection anywhere in the generation path. Any argmax, max(), "pick the best," or "use the winning variant" on an exploration path will collapse as its inputs converge. If you want exploration, you must sample, not maximise.

Check that your input scope has not silently narrowed. Ours had frozen to 3% of the available catalogue. Nothing reported this.

Verify that sub-paths fail loudly. A path that fails 15 out of 15 times without failing the run will not be discovered by watching for errors.

Why we are publishing this

Two reasons.

The counterintuitive result is genuinely useful: a high per-page quality score is weak evidence about a batch, and can be evidence of nothing at all. Teams adopting AI generation are building exactly the per-page evaluators we built, for the same sensible reasons, and inherit the same blind spot.

And the failure is structural rather than incidental. It is not "our prompt was bad" or "the model hallucinated." It is a specification error in how exploration interacts with learning — the kind that gets worse as the system improves, which is the worst kind to ship.

If you are generating landing page variants at any scale, run the batch diff. It takes minutes and the answer is occasionally fifteen.

---

Lutiq predicts, for every paid click, which on-brand page to show — and measures lift against a live holdout. Figures above are first-party unless attributed.