Custom Content Types in a CMS: What They Are and When You Need Them

"Custom content types" is one of those CMS phrases that means five different things depending on who's selling. To a Strapi user it's a full type builder. To a WordPress developer it's a custom post type. To someone shipping a marketing site it might just mean "a page that isn't a blog post." Before you pick a CMS on the strength of this feature, it's worth knowing what you actually need — because the answer is often less than the marketing implies. ## TL;DR A custom content type is a distinct kind of content with its own fields and behavior — a "Product," an "Event," a "Team Member" — separate from your blog posts and pages. You need them when your content has real structure that a generic post can't hold. But most sites need far fewer than they think: a blog, pages, and maybe one or two structured types. Reach for a heavy type-builder CMS (Strapi, Payload) only when your content model is genuinely complex. ## What a content type actually is A content type is a shape for your content. A blog post has a title, body, author, and categories. An event has a title, a date, a location, and a ticket link. Those are different shapes — different fields, different validation, different display. A content type is how a CMS lets you define and reuse a shape. Every CMS has at least two built in: **posts** (dated, categorized, for a blog) and **pages** (static, hierarchical, for an About or Contact page). The question is what happens when your content doesn't fit either. ## The three levels of "custom content type" Not all custom-type support is the same. There are roughly three tiers: ### Level 1 — Built-in types The CMS ships a fixed set of content types — post, page, maybe "landing" or "block" — and you use them as-is. You can't invent a brand-new type, but the built-in ones plus flexible fields cover a lot of sites. ### Level 2 — Fields on existing types You can attach custom fields to the built-in types. Add a "price" to a page, a "start date" to a post. Often done through a schemaless JSON field or a custom-fields plugin. Flexible without a full type system. ### Level 3 — Full type builder You define entirely new types from scratch — "Product," "Recipe," "Property" — each with its own field schema, relationships, and API endpoint. This is what Strapi, Payload, and Directus give you. It's powerful and it's the right tool for complex, relational content models. Most teams assume they need Level 3 and actually need Level 1 or 2. ## What UnfoldCMS gives you (honestly) UnfoldCMS sits at Level 1 with a dash of Level 2 — and it's important to be straight about that. It has **four content types** built in, via a `content_type` enum: `post`, `page`, `landing`, and `block`. That covers a blog, static pages, marketing landing pages, and reusable homepage blocks. On top of that, every piece of content has an `extra_attributes` field — schemaless JSON — where you can store structured data your template needs (a price, a date, a CTA URL, a variant flag). What UnfoldCMS does **not** have is a Level 3 type builder. You can't define a brand-new "Product" type with its own admin form and its own API endpoint the way you can in Strapi or Payload. If your project needs many distinct, relational content types with generated CRUD and dedicated endpoints, UnfoldCMS isn't the fit — and we'd rather tell you that up front than have you find out after migrating. So UnfoldCMS is a strong choice when your content is "a blog + pages + landing pages + some structured fields," and the wrong choice when it's "twelve interrelated content types with complex schemas." ## How to know which level you need Ask these questions about your content: 1. **Is it just a blog and some pages?** → Level 1. Any CMS works. Don't overbuy. 2. **Do a few pages need extra structured fields?** (a price, a date) → Level 2. Built-in types plus a JSON/custom-fields field cover it. 3. **Do you have several distinct kinds of content that relate to each other?** (Products that belong to Categories that have Brands) → Level 3. You want a real type builder. The mistake is jumping to Level 3 for a Level 1 site. A type builder is more admin, more schema to maintain, and more setup — worth it only when the content model earns it. ## Content types vs custom fields — don't confuse them These get mixed up constantly: - A **content type** is the whole shape (a "Product"). - A **custom field** is one attribute of a shape (a "price" on a Product). You can often get what you want with custom fields on an existing type instead of a whole new type. Need to mark some blog posts as "featured" with a priority number? That's a field, not a new type. Need a completely different admin form, list view, and API endpoint? That's a type. Choosing the smaller tool keeps your CMS simpler. ## Comparison: content type support by CMS | CMS | Level | New types from scratch? | Custom fields | Best for | |-----|-------|------------------------|---------------|----------| | **UnfoldCMS** | 1 + partial 2 | No (4 built-in) | JSON `extra_attributes` | Blog + pages + landing + structured fields | | **WordPress** | 2–3 | Yes (custom post types) | Via ACF/plugins | Flexible, plugin-driven | | **Strapi** | 3 | Yes (type builder) | Full schema | Complex relational models | | **Payload** | 3 | Yes (code-first collections) | TypeScript config | Developer-defined schemas | | **Directus** | 3 | Yes (any SQL table) | Full | Database-first modeling | ## FAQ ### What is a custom content type in a CMS? It's a distinct kind of content with its own fields and behavior, separate from the default blog posts and pages — for example a "Product," "Event," or "Team Member" type. It lets you model content that a generic post can't hold cleanly. ### Does UnfoldCMS support custom content types? UnfoldCMS ships four built-in content types (post, page, landing, block) and a schemaless `extra_attributes` JSON field for structured data. It does not have a full type builder for defining brand-new types with their own endpoints — for that, use Strapi, Payload, or Directus. UnfoldCMS fits sites that need a blog, pages, and some structured fields, not a many-type relational model. ### Do I really need custom content types? Probably fewer than you think. If your site is a blog plus some pages, the built-in types are enough. Add custom fields when a few items need extra structured data. Only reach for a full type builder when you have several distinct, related kinds of content. Buying a heavy type system for a simple site adds complexity you'll maintain forever. ### What's the difference between a content type and a custom field? A content type is the whole shape of a piece of content; a custom field is a single attribute within that shape. A "Product" is a type; its "price" is a field. Many needs that sound like "I need a new type" are actually "I need a field on an existing type." ### Which CMS has the best custom content type support? For defining many distinct types from scratch, Strapi, Payload, and Directus lead — they're built around a type/collection system. WordPress does it via custom post types and plugins. If you only need a handful of shapes, a simpler CMS with built-in types plus flexible fields saves you the overhead. ## The bottom line "Custom content types" sounds like a must-have, but it's really a spectrum. Most sites live at Level 1 or 2 — a blog, pages, and a few structured fields — and don't need a full type builder. UnfoldCMS covers that range with four built-in types and a JSON field, and it's honest about not being the tool for complex, many-type models. Match the content system to your actual content shape. Overbuying a type builder you'll never fully use is its own kind of technical debt.