- Article
- 5 minutes read
- Reviewed August 3, 2026
A custom post type is a content type registered in WordPress for a project-specific object such as an event, property, course, team member or documentation page.
Custom post types use the established WordPress content system while allowing developers and site builders to define their own labels, features, URLs, permissions, archives and API behaviour.
Why Create a Custom Post Type?
A new post type gives a repeated kind of information its own editorial identity. Editors can manage it in a dedicated screen, templates can target it directly and queries can retrieve it without mixing it with unrelated posts or pages.
The strongest reason to create one is semantic: the entries represent a distinct object with a meaningful lifecycle and consistent attributes.
Custom Post Type Examples
- Events with dates, venues and ticket information.
- Properties with prices, locations and availability.
- Team members with roles, biographies and departments.
- Courses with levels, durations and lesson relationships.
- Documentation pages with sections, versions and reading order.
- Portfolio projects with services, industries and outcomes.
When Not to Create a Custom Post Type
Do not create a separate type solely because a group of posts needs a different colour or landing page. A category, template variation or custom field may express the difference more simply.
Too many types fragment the editor, duplicate settings and complicate search, permissions and templates. The model should reflect real differences in the information and workflow.
Registration and Portability
Developers register a post type with register_post_type(), normally on the init action. The registration belongs in a plugin or project-level module rather than the active theme.
A theme may provide templates for the type, but the content definition should survive a redesign. If registration disappears with a theme, the database records remain but become difficult to manage until the type is registered again.
add_action( 'init', function () {
register_post_type( 'event', array(
'label' => __( 'Events', 'example' ),
'public' => true,
'has_archive' => true,
'show_in_rest' => true,
'supports' => array( 'title', 'editor', 'thumbnail', 'revisions' ),
'rewrite' => array( 'slug' => 'events' ),
) );
} );Important Registration Decisions
Identifier
The internal post type key should be stable, lowercase and treated as an implementation contract. Changing it later requires migrating existing records and every integration that refers to the old key.
Labels
Labels should use the language editors understand. Good labels distinguish the singular object, plural collection and common actions such as Add new event or Edit event.
Public Behaviour
The public argument influences several defaults, but more specific arguments control whether the type is queryable, visible in the administration area, included in navigation or exposed through an API.
Supported Features
The supports array enables core features such as title, editor, excerpt, author, thumbnail, comments, custom fields and revisions. Enable only features that make sense for the object.
Hierarchy
A hierarchical type can use parent-child relationships like pages. This can be useful for documentation or nested locations, but large hierarchies can affect administration performance and usability.
Archive and Rewrite
A public archive can list entries at a shared URL. Rewrite settings determine the public slug, but changes require refreshed rewrite rules and may need redirects from existing URLs.
REST API
Setting show_in_rest to true exposes standard endpoints and is important for modern editor integration. Custom metadata must also be registered appropriately if it should appear in REST responses.
Taxonomies and Fields
The post type defines the primary object. Taxonomies classify reusable concepts, while metadata stores values that belong to one entry.
An event might use an event type taxonomy, a venue relationship and metadata for start time. Placing every value in the main editor removes the ability to validate, query and reuse the information reliably.
Capabilities
Custom post types can use the standard post capabilities or a custom capability set. A dedicated set is useful when event managers should edit events without editing blog posts.
Capability mapping must be tested for single and plural actions, published and private items, and ownership rules. Changing capability settings after launch can unexpectedly remove access from existing roles.
Templates and Theme Support
Classic themes can use files such as single-event.php and archive-event.php. Block themes use corresponding block templates and may also include user-created templates stored in the database.
The type should remain functional with a fallback template, even if a purpose-built design improves the experience.
Data Ownership and Uninstallation
A plugin that registers a post type should state what happens when it is deactivated or uninstalled. Deactivation should normally preserve content. Permanent deletion should require an explicit and well-documented decision.
Custom Post Type Checklist
- Define the real object and editorial purpose.
- Choose a stable internal key and public slug.
- Write complete editor-facing labels.
- Enable only relevant features.
- Decide public, archive, search and REST behaviour explicitly.
- Plan taxonomies, fields and relationships.
- Define capabilities and assign them to roles.
- Create template fallbacks and test common themes.
- Document data retention and migration behaviour.
Frequently Asked Questions
Do custom post types require a plugin?
They require code or a tool that registers them. Registration should normally live in a plugin or project-level module rather than a theme.
Will deleting the registration delete the content?
No. The records normally remain in the database, but WordPress will not provide the expected administration and public behaviour until the type is registered again.
Can a custom post type use Gutenberg?
Yes. It should support the editor and generally be exposed through the REST API for full block-editor compatibility.
Can custom post types have categories and tags?
Yes, existing or custom taxonomies can be associated with a post type when that classification is meaningful.