Draft and publish only gives me one live version, how do I model two live variants in Strapi?
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
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 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, 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 if you want to see it end to end before committing.