Custom post types: what they are and why they matter

A "post" in WordPress (and many CMSes) is a generic container for content. Posts are usually blog articles. But your website probably has more than just blog articles. It might have projects, products, testimonials, events, team members, or resources. Custom post types let you manage these different content types with their own fields, templates, and workflows.

Understanding custom post types is understanding how to scale a CMS beyond a basic blog.

What is a custom post type?

A post type is a category of content. WordPress comes with two built-in post types:

• Posts. Blog articles. Have publishing date, author, categories, tags.
• Pages. Static content. Typically hierarchical (parent/child).

A custom post type is anything else. Examples:

• Products. In e-commerce sites. Have SKU, price, inventory, variants.
• Portfolio pieces. In designer portfolios. Have images, technologies used, client info.
• Team members. Have headshot, bio, role, social links.
• Events. Have date, time, location, capacity, registration.
• Services. Have name, description, pricing, availability.
• Testimonials. Have quote, author, company, role.

Each post type can have its own fields, template, and appearance. A product page looks nothing like a blog post, and a custom post type lets you manage both in the same CMS.

Why custom post types matter

Without custom post types: You force everything into the "post" structure. A product becomes a post with a custom field for price. A team member becomes a post with a custom field for bio. This works for small sites but becomes unwieldy fast.

Problems:

• The post list shows everything mixed together (products, blog posts, team members)
• Categories and tags don't make sense for products
• Templates are one-size-fits-all (doesn't work for very different content types)
• Querying products becomes complicated (you're filtering posts by type)

With custom post types: Products are posts. Team members are a different post type. Blog posts are their own type. Each has:

• Its own list in the CMS
• Its own fields (price for products, bio for team)
• Its own template
• Its own URL structure (if desired)

Custom post type anatomy

A typical custom post type has:

Type name. Usually something like "product" or "team_member" (internal identifier).

Display name. "Products" - what shows in the admin menu.

Singular name. "Product" - for UI ("Add new product").

Description. "Physical products for sale" - so editors understand what goes here.

Icon. A dashboard icon (looks nice, helps navigation).

URL slug. /products/ - where URLs like /products/red-shoes/ live.

Supports. Which standard post features does it have?

• Title? Yes.
• Excerpt? Probably yes.
• Featured image? Maybe.
• Revisions? Usually yes.
• Custom fields? Often.

Capabilities. Who can create, edit, delete? Usually editors and admins.

Taxonomies. Does it use categories, tags, or custom taxonomies?

• Blog posts: categories and tags (makes sense)
• Products: product categories (makes sense), but tags are weird
• Team members: department taxonomy (makes sense), tags don't

Custom fields vs custom post types

These are often confused.

Custom fields: Additional data attached to a post. A blog post with a custom field "author_bio" stores extra data about the author in that one post.

Custom post types: A completely separate type of content with its own structure.

When to use which:

• Use custom fields if you're adding attributes to an existing post type. A blog post with an "featured_date" field.
• Use a custom post type if you're managing a fundamentally different type of content.

A product isn't a post with extra fields. It's a different content type that happens to live in the same CMS. Custom post type.

Real-world examples

E-commerce site:

• Posts: Blog articles
• Products: Physical products
• Reviews: Customer reviews

Agency website:

• Pages: Static content
• Projects: Portfolio pieces
• Testimonials: Client reviews

News site:

• Articles: News stories
• Videos: Video content
• Podcasts: Podcast episodes

Course platform:

• Pages: Static pages
• Courses: Course information
• Lessons: Individual lessons

Each content type has different needs, different fields, different templates.

How custom post types help you scale

Small site (just a blog).

• 100 posts
• One post type (posts)
• Categories and tags for organization
• One template

Custom post types are overkill here.

Growing site (blog + products).

• 200 blog posts
• 500 products
• Need to manage them separately
• Different fields
• Different templates
• Different workflows (products need approval before publishing)

Custom post types are essential here.

Large site (multiple content types).

• Blog posts, products, events, testimonials, team members, resources
• Each with separate workflows
• Different permissions (editors can create posts, but only admins can create products)
• Separate archives and templates
• Different SEO strategies

Custom post types are how you keep this organized.

Building a custom post type

Manually (code). If you're comfortable with code, you define the post type in code.

register_post_type('product', array(
  'labels' => array('name' => 'Products'),
  'public' => true,
  'has_archive' => true,
  'supports' => array('title', 'editor', 'thumbnail'),
));

Via UI. Many modern CMSes let you create post types via the admin interface - no code needed.

Via plugin. Custom post type plugins (Custom Post Type UI, etc.) provide a UI for building them without code.

Custom taxonomies

A related concept: custom taxonomies. While post types are "what" (product, event, blog post), taxonomies are "how to organize" (category, tag, format).

Blog posts have tags and categories. Products might have brand, color, size. Events might have location, type, audience.

Don't force taxonomy names to make sense if they don't. A product "tag" is weird - use a custom taxonomy instead.

When NOT to use custom post types

• Different permission levels for similar content. Use custom post types when the content is structurally different, not just because permissions differ.
• Just adding a few extra fields. If a post just needs one extra field, use a custom field, not a custom post type.
• Content that's truly hierarchical. Pages have parent/child relationships. If your content is hierarchical, pages might be better than a custom post type.

The architecture question

As a CMS grows, think about content structure first. Before you start creating posts, ask:

• What types of content do I have?
• How are they different?
• Will they need different fields, templates, workflows?
• Will editors need to find them separately?

If the answers suggest different content, use different post types.

How Contensio approaches custom post types

Contensio makes custom post types first-class. They're not an afterthought or a plugin feature - they're built into the core.

Creating a post type is straightforward. Each type gets its own admin section, its own querying system, its own permissions. The Blade templating system makes it easy to create different templates for different types.

Because custom fields are also built-in (not a plugin), combining them with custom post types is seamless. You can structure sophisticated content hierarchies without plugin conflicts or complexity.

For sites that need to scale beyond a simple blog, Contensio's approach to custom post types makes growing easier. Explore https://contensio.com.