Context: where content models go wrong
Every enterprise content model starts clean. Eight types, each modelling a real editorial concept, named clearly, validated tightly. Then year one happens. Marketing wants a special variant of Article for press releases, so a PressRelease type is born. Sales wants a CaseStudyVariantB for the partner programme. Brand wants HeroBlockV2 because the original HeroBlock doesn't support the new design. The legal team adds DisclosureContent, then DisclosureContentLong, then DisclosureContentLongRegional.
By year three the model has 34 content types, half of them near-duplicates, editors confused about which one to use, the front-end team unable to delete anything because something somewhere depends on it. The platform did not cause this. Absent governance, the platform allowed it.
This piece is the anti-drift pattern Dcrayons applies on enterprise headless CMS engagements. Contentful, Sitecore XM Cloud, Sanity, Storyblok, .NET ABP-based, anything that lets editors author against typed content. It covers four areas the public documentation under-foregrounds: the 12-type starter set that fits 80 percent of multi-brand needs, the governance rules that prevent drift, the deprecation discipline that lets the model evolve safely, and the migration playbook from a drift-laden legacy model.
The 12-type starter set
Multi-brand enterprise DXPs need fewer content types than teams expect. The Dcrayons starter set, locked at week 1 of any implementation:
1. Page. A composition of blocks. Holds: slug, title, SEO metadata, locale variants, scheduled-publish, sections (a typed list of block references). Layout decisions live HERE, not in the editorial entries below.
2. Article. An editorial concept (blog post, news item, press release, opinion piece). Holds: title, slug, body (rich text), excerpt, hero image, category reference, tag list, author reference, published date, reading time, SEO metadata.
3. Author / Person. A reusable people entry. Holds: name, role, bio (rich text), photo, social links. Referenced from Article + CaseStudy + TeamSection blocks.
4. Category. Editorial categorisation. Holds: name, slug, description, parent category (for hierarchy), SEO metadata. Used for filtering listing pages.
5. Tag. Cross-cutting tagging. Holds: name, slug, description. More granular than Category, used for /insights?tag=X-style filters.
6. Service / Product. What the business offers. Holds: name, slug, short description, full description (rich text), hero image, features (typed list), pricing tier reference, SEO metadata.
7. Case Study. Customer success narrative. Holds: customer name, vertical, problem statement, approach (rich text), outcome (with metrics), hero image, gallery, customer logo, customer reference (Person entry), SEO metadata.
8. Site Setting (singleton). Global cross-page configuration. Holds: site name, primary logo, secondary logo, primary nav reference, footer references, default SEO metadata, social links, contact email, contact phone, GTM ID, GA4 ID. ONE entry per site, enforced.
9. Navigation Block. Reusable menu structure. Holds: label, children (recursive list of links). Used by header + footer + page-local sub-nav.
10. Hero Block. Page composition primitive. Holds: title, subtitle, eyebrow, CTA button, background image / video, variant (which renderer to pick).
11. Section Block. Reusable page section. Holds: title, subtitle, body (rich text), CTA, image, variant. The catch-all block for editorial sections that don't fit a specific shape.
12. Media Asset. Image / video / document with metadata. Holds: file reference, alt text, caption, copyright, source URL, focal-point coordinates for art-direction. Referenced from every other type that holds visual assets.
Optional 13th + 14th: FAQ Item + FAQ Group, Redirect (URL-to-URL mapping for migrations). Beyond this, every new type requires explicit content-model review with the customer's editorial leadership before creation.
Governance rules that prevent drift
The 12-type set works only with governance. Four rules:
Rule 1: model around editorial workflow, not page layout. A press release IS an Article with category=press-release + a specific tag. It is NOT a PressRelease type. The Article body field handles the text; the Page composition handles the layout differences (different hero variant, different sidebar config). Resist the urge to create a new content type whenever the layout is slightly different.
Rule 2: reference fields over duplicated content. Author reference on Article means changing the bio once updates every article that author wrote. Duplicating author name + bio per article means 200 manual edits when the bio changes. This sounds obvious; in 60 percent of inherited CMS implementations the reference is missing.
Rule 3: validation rules at the model level, not the front-end. Required fields, character limits, regex validation, link-type restrictions. all enforced at the CMS content model level. The front-end is the last line of defence; the CMS is the first.
Rule 4: deprecation, not deletion. Old content types are marked deprecated (renamed with a [DEPRECATED] prefix in display name) rather than deleted, until all references are migrated. Deletion of an in-use content type breaks the front-end at publish time. the worst possible failure mode for editorial confidence.
Rule 5 (the meta-rule): every new content type requires sign-off. A documented review: what need does this type serve, why can't an existing type carry it, who is the editorial owner, what is the deprecation criterion if it doesn't work out. Without this rule, the 12-type set inflates to 34 within 18 months.
Multi-brand variation: when one model serves multiple brands
For DXPs serving multiple brands (the holding company with 5 D2C brands, the agency with multiple client tenants, the regional roll-up with brand-per-country), the content model should accommodate per-brand variation without forking.
The Dcrayons multi-brand pattern:
Single content model + brand reference field. Every editorial entry carries a brand reference. Service "skincare-routine" exists once in the model; its body, hero, gallery, and pricing tier are brand-scoped via the reference. The front-end filters by brand at request time.
Brand-specific defaults via reference resolution. A Hero Block can carry a brand reference; when rendered, the brand reference resolves to brand-specific defaults (primary colour, accent font, logo). The Hero Block doesn't need to be duplicated per brand.
Brand-specific overrides at the Page level. A Page composition can override at the section level: "use the standard Hero Block, but with this specific copy for this brand-region". Overrides flow through composition, not type proliferation.
Per-brand editorial roles. Editors are scoped to specific brands. A Brand-A editor cannot edit Brand-B content (which they cannot QA). For multi-locale + multi-brand sites, roles get even more granular: Brand-A en-IN editor + Brand-A hi-IN editor + Brand-A ar-AE editor.
Migration playbook: from drift-laden legacy to clean model
Enterprise customers reach a clean content model from drift-laden WordPress, Drupal, Sitecore XP, or homegrown CMS implementations. The Dcrayons migration playbook compresses what's typically a 12-month programme into a disciplined 4-6 month window.
Phase 1: content audit (weeks 1-4). Inventory every content type + every entry in the source CMS. Cluster the types into editorial concepts: which are real distinct types, which are near-duplicates that collapse into one, which are layout artifacts (collapse into Page composition).
Phase 2: target model design (weeks 5-8). Draft the 12-type starter set + any documented brand-specific additions. Sample-migrate 1-2 types full-scope. source export, target import, front-end render. to validate the model. Iterate before migrating the rest.
Phase 3: bulk migration + URL preservation (weeks 9-16). Full source export. Migration scripts with mapping tables (source field -> target field, source taxonomy -> target tag, source URL -> target URL). 301 redirect map generated: every old URL maps to a new URL. Front-end templates complete; staging environment serves the migrated content set. Side-by-side QA on critical URLs.
Phase 4: cutover + observability (weeks 17-20). DNS cutover with TTL lowered 48 hours pre-cutover. 301 redirect map deployed. Source CMS kept hot for 30-90 days as fallback. Editor team trained on the new authoring UI. Post-cutover analytics watched for traffic regression vs the pre-cutover baseline.
Production checklist: the rollout sequence
For an enterprise multi-brand headless CMS at the Rs 25 crore+ ARR scale:
- 12-type starter set locked at week 1, deviations require explicit review + sign-off
- Reference fields preferred over duplicated content (Author, Brand, Category, Tag references designed in from day 1)
- Validation rules at the model level (required, character limits, regex, link-type restrictions)
- Brand reference field on every editorial entry; brand-specific defaults via reference resolution
- Editorial roles per brand + per locale; documented role matrix
- Deprecation prefix convention agreed + applied to retired types
- Quarterly content-model review with the editorial leadership
- Front-end templates type-checked against the CMS model (schema-first types)
- Migration playbook documented if migrating from legacy; exit criteria per phase
- Preview + production environments separated; SSO-gated previews
- Webhook + revalidation pipeline so editor publish triggers front-end refresh within seconds
- Observability: CMS API usage monitoring, model-change audit log, editor activity dashboard
References + linked context
- Dcrayons glossary: content-modelling, dxp, jamstack, isr
- Dcrayons Contentful + Next.js reference architecture: see /learn?tag=cms-headless-web for the composable-DXP assembly pattern this content model fits into
If your enterprise content model has hit drift, governance gap, or migration paralysis, this is the pattern we deploy. Reach out via the contact form for a 30-minute review against your current setup.
