All questions

Structuring Contentful entries for variants without drowning editors in duplicates

Asked by Noor Haddad on

NHNoor Haddad

Content strategist, not a developer, so forgive the non-technical framing. Our current process for testing copy: duplicate the whole entry, rename it "homepage-hero-variant-b", and the devs wire up which one shows. We now have entries named variant-b-final and variant-b-final-2 and my editors genuinely cannot tell which copy is live anymore.

There has to be a saner content model for this. Do teams add variant fields to the content type, use references, something else? I care less about the mechanics and more about editors always knowing what is actually published

Was this helpful?

1 answer

GMGabriel Mendes

The pattern that fixed this for us was refusing to model variants in the CMS at all. Variant fields and duplicated entries both have the same flaw you are describing: the CMS shows several versions of the truth and no signal about which one a visitor actually sees.

Instead, keep one canonical entry per piece of content in Contentful. That entry is always the default, so "what is in Contentful" and "what is live by default" become the same question. Variant copy then lives in the experimentation layer, in Croct's case each experience holds its variant content, and the experiment serves it over the default for its share of traffic.

The editor-clarity win comes from the status model on that side: an experience is Draft, Active, Paused, Scheduled, or Archived, so your team sees at a glance what is running instead of decoding entry names. When a test ends you roll the winning copy into the canonical entry and archive the experience, and the CMS never accumulates variant clutter.

Was this helpful?
Still have questions?