Quick answer: Custom post types are extra content types you add to WordPress alongside the built in posts and pages. Examples include portfolio projects, team members, case studies, properties, events, courses or products. Each custom post type gets its own menu in the dashboard, its own URL structure and its own templates, so it can be edited and displayed differently from blog posts. You create one with the register_post_type() function in a plugin, or with a plugin such as Custom Post Type UI, and usually pair it with custom fields and taxonomies to store structured details.
What a post type is
Everything you write in WordPress is stored as a “post” in the database, with a post type that says what kind of content it is. WordPress ships with several:
- post: blog posts, shown in date order and organised with categories and tags
- page: static pages such as About and Contact, organised in a hierarchy
- attachment: files in the media library
- revision: saved older versions of content
- nav_menu_item: items in your menus
A custom post type is simply a new kind added to that list.
When to use a custom post type
Use one when you have content that:
- Is not a blog post or a standalone page
- Has many items of the same kind
- Shares a consistent structure, such as the same fields on every item
- Needs its own archive or listing page
- Should be managed separately in the dashboard
Common examples for business sites:
- Portfolio or projects: client, services delivered, images, results
- Case studies: problem, solution, outcome
- Team members: name, role, photo, bio
- Testimonials: quote, name, company
- Locations: address, opening hours, map
- Properties: price, bedrooms, area, gallery
- Events: date, time, venue, booking link
- Jobs: title, location, salary range, closing date
If you find yourself creating dozens of blog posts in a “Projects” category and fighting the blog layout to make them look right, a custom post type is usually the cleaner solution.
When not to use one
- If there will only ever be three or four items, ordinary pages may be enough
- If the content is really blog content with a different topic, use categories instead
- If a well supported plugin already provides the type you need, such as WooCommerce for products or an events plugin for events, use it rather than building your own
Custom post types, taxonomies and fields
Custom post types rarely work alone. They are usually combined with:
- Custom taxonomies to group items, such as “Project type” or “Property area”. See our guide to WordPress taxonomies.
- Custom fields to store structured details, such as price or event date. Our article on WordPress custom fields explains how they work.
Together they turn WordPress from a blog into a proper content management system for your business data.
How custom post types are created
Option 1: in code
Developers register a post type with register_post_type(), hooked to the init action. A simple example for projects:
add_action( 'init', 'iws_register_projects' );
function iws_register_projects() {
register_post_type( 'project', array(
'labels' => array(
'name' => 'Projects',
'singular_name' => 'Project',
'add_new_item' => 'Add New Project',
'edit_item' => 'Edit Project',
),
'public' => true,
'has_archive' => true,
'rewrite' => array( 'slug' => 'projects' ),
'menu_icon' => 'dashicons-portfolio',
'supports' => array( 'title', 'editor', 'thumbnail', 'excerpt' ),
'show_in_rest' => true,
) );
}
The main settings:
- labels: what the dashboard calls it
- public: whether it appears on the site and in the dashboard
- has_archive: whether there is a listing page, here at
/projects/ - rewrite: the URL base for single items
- supports: which editing features are available, such as title, editor, featured image, excerpt, revisions and custom fields
- show_in_rest: makes the post type available in the WordPress REST API, and it is needed for the block editor to be used when editing this type
After registering a new post type or changing its URL, visit Settings > Permalinks and click Save, so WordPress refreshes its rewrite rules.
Where the code should live
Put custom post type code in a small plugin, not in your theme. If it lives in the theme and you change themes later, your content does not disappear from the database, but it vanishes from the dashboard and the site until the code is restored. Our guide to custom WordPress plugin development covers this approach.
Option 2: with a plugin
Plugins such as Custom Post Type UI let you create post types and taxonomies through a settings screen without writing code. They are popular and reliable for simple cases. Pair them with a fields plugin such as Advanced Custom Fields or Pods to add structured fields.
The trade off is that your site structure depends on the plugin’s settings stored in the database. Some of these plugins can export the registration code, so you can move it into your own plugin later.
Displaying custom post types
WordPress chooses which template file to use for each type, following the template hierarchy:
single-project.phpfor a single projectarchive-project.phpfor the projects listing page- If those do not exist, WordPress falls back to
single.php,archive.phpand finallyindex.php
A theme developer creates these templates to show the custom fields in a tailored layout, such as a project gallery with client details, or a property listing with price and features.
You can also display items elsewhere on the site, such as the latest three case studies on the homepage, using a custom query, a shortcode or a custom block.
URLs and SEO
Each custom post type gets its own URLs, such as /projects/new-office-fit-out/. Plan the base slug carefully before launch, because changing it later changes every URL of that type.
SEO plugins such as Yoast SEO detect custom post types and let you set title templates, choose whether they appear in search results, and include them in the XML sitemap. Decide for each type:
- Should individual items be indexed? Case studies, yes. Simple testimonials displayed elsewhere, often no.
- Should the archive page be indexed and have its own introduction text?
- Does it need structured data, such as event or job posting markup?
Custom post types and the REST API
With show_in_rest enabled, custom post types are available through the WordPress REST API at endpoints such as /wp-json/wp/v2/project. That makes it possible to display them in a mobile app, sync them with another system or use WordPress as a headless CMS.
Common mistakes
- Registering post types in the theme instead of a plugin
- Forgetting
show_in_rest, so the block editor does not load for that type - Choosing a URL base that clashes with an existing page slug
- Creating a new post type when a category would do
- Not planning which fields each item needs before adding content
FAQ
Will custom post types slow down my site?
No. They are stored in the same database tables as posts and pages. Performance depends on how the templates and queries are written, not on the post type itself.
What happens to my content if I remove the custom post type code?
The content stays in the database but is hidden from the dashboard and site. Restoring the registration code brings it back.
Can I convert existing posts into a custom post type?
Yes, with a plugin built for switching post types or a small script. Plan redirects if URLs change.
Do custom post types work with page builders?
Most page builders support custom post types, though you may need to enable them in the builder’s settings.
Make WordPress fit your content
Custom post types let WordPress handle the content your business actually has, with tidy editing screens and layouts built for each kind. Used with fields and taxonomies, they make a site easier to manage and more useful to visitors. If you want a WordPress site structured around your business, see our Turn visitors into customers service.
