# Draft and publish only gives me one live version, how do I model two live variants in Strapi?

Asked by Ines Barros on 2026-02-04. Tags: strapi, content-model, ab-testing.

The constraint, stated precisely: Strapi's draft and publish system holds
exactly one published version per entry. An A/B test needs two live
variants of the same content simultaneously, which the model cannot
express. I tried to bend draft and publish into this and hit the wall
immediately, the draft is not servable to real traffic.

So concurrent variants have to be modeled some other way. Duplicated
entries, extra variant fields on the entry, or something outside Strapi
entirely. What is the accepted pattern here? Our team would rather adopt
the standard approach than invent one.

## 1 answer

### Accepted answer from Juliana Amorim (2026-02-04)

That wall is real: draft and publish holds one published version per
entry, so concurrent live variants have to be modeled
manually, either with duplicated entries or extra variant fields. Both
work, and both tend to age badly because editors now manage N copies
that drift apart.

The cleaner split we recommend keeps Strapi doing what it is good at:
the published Strapi entry stays as the default fallback, and the
variants are managed as [Croct experiences](https://docs.croct.com/immersion/integrations/cms/strapi) on slots mapped to your
dynamic zones. Your content model does not change and there is nothing
to duplicate, the entry remains the single source for the default
content while the experiment serves variants on top of it.

For [the experiment itself](https://docs.croct.com/explanation/experiment), you get 2 to 5 variants with configurable
traffic allocation, so an A/B/n test needs no additional modeling
either. I wrote a step-by-step of this exact setup on
[Strapi's blog on running A/B tests](https://strapi.io/blog/how-to-run-ab-tests-with-strapi-to-boost-conversions)
if you want to see it end to end before committing.