Custom Post Types Explained Through the Site You Are Already Building
When to Use Custom Post Types: Questions to Ask Before Modelling Content in WordPress
Most portfolio sites cram works into pages, and most product catalogues are just posts with category tags. Yet WordPress lists portfolio items and products as common examples of content suited to a custom post type. It's not about the complexity of content; it's about the inherent nature of the information and its intended use.
WordPress offers Post, Pages, and tags - so why would developers need a custom post type at all? Well, each content type needs to be used appropriately. That's a question for the WordPress Content Model.
WordPress has multiple built-in post types, such as Posts, Pages, and Attachments, but it also allows developers to register Custom Post Types (CPTs), which behave like posts but store different kinds of information via a different post_type value in the database.
WordPress Core supports dedicated templates for CPTs, including single-{post_type}.php for single entries and archive-{post_type}.php for a type's archive listing on the front end.
But is a CPT necessary if Data Structure, admin management, or information flow will not be very complicated?
At their core, custom post types in WordPress are a way to extend the functionality of the default 'Posts' content type. They are designed to hold content that is different from standard posts and pages, and should be used when the new content has different looks, meaning, and content from existing types.
For example, a blog post about a new product release can be a Post, but the product itself merits a CPT, complete with its own fields, taxonomies, and templates.
So when should a WordPress developer choose a CPT?
The WordPress Developer Resources outlines a few common use cases for CPTs, including Products, Team Members, Portfolio Items, and Events - all examples of structured, repeatable information that needs to be managed and presented differently from blog posts or pages.
Portfolio items or projects are a particularly clear example: a portfolio section is a whole thing. A Portfolio item is not a post about a project, but the project itself - with a client, dates, brief, deliverables, and often individual pieces of work (images, documents, links) to be displayed and managed.
A small portfolio may be manageable as a category of tagged posts, but as the portfolio grows, each project needs its own content type. Each project is a distinct entity, and each may have distinct characteristics in terms of client, deliverables, delivery dates, and type of work. Pages would be the wrong structure (Managing each project as a page in a portfolio’s hierarchy takes work.) - and it detracts from the holistic nature of the portfolio, as an archive and browseable arrangement of individual projects on the front end.
The same is true of a product catalog. In principle, a range of products could be classified under a Products category and displayed/linked on a dedicated Products page. But each product has properties, and each ought to have its own Catalog details. This isn't about future management (although that's a factor) - it's about representing products as products, not blog posts or static pages.
From a site visitor's perspective, seeing an Archive of Products or Portfolio projects is a more meaningful browsing experience than seeing a list of tagged or categorized Posts or linking from a Products or Portfolio page to individual pages. The visitor sees these content types as Clickable Categories rather than Categories or Tags.
From an admin perspective, managing each Portfolio piece or Product as a new Entity type is clearer than managing them as all-lumped-in Posts or Pages. Each new Portfolio item or Product is generated, rather than manually created, as a new addition to an 'archive'. Each exhibits the same structure, because they share the same structure at content creation.
Essentially, a CPT should be used for any Content in WordPress that's browsable as a separate category, rather than browsing all Posts or browsing a folder/sublocation of Pages.
Ultimately, the choice of Posts, Pages, or CPT depends on the content's relationship to other content in terms of what it is rather than just how it will be managed or displayed. Posts are posts and share the timeline; Pages are static snippets of site info. A CPT is an independent content type that stands alone and should not be a thing tagged in posts about, or a part of the arrangement of an 'About' page.
So, the guiding principles for deciding between a Post, Page, or CPT are:
- Is the content inherently independent, neither a blogged slice of time nor a static snippet?
- Will it grow and be browsed/accessed in its own right, rather than being the container of some other information?
If so, it should be a CPT.
CPTs aren't a way of storing site data that wouldn't be stored as Posts or Pages. They are an alternative to thinking of new content as Posts or Pages. Instead, think how that type of information will be managed and accessed in the future, and create a new content type that meets that need.