Use a WordPress custom post type when a group of records needs its own editing workflow, structure, or presentation. Do not create one simply because a page has a different visual design. First decide what each record represents and how people will create, find, and maintain it.
Start With Real Example Records
For a fictional training business, a course might need a title, summary, duration, audience, and related instructor. A scheduled session may need a date, location, capacity, and booking status. Decide whether courses and sessions are the same record before building the editor.
Write three realistic examples, including one with missing optional information and one with multiple relationships. If the model cannot express those examples cleanly, a polished template will not solve the underlying problem.
Separate Fields, Taxonomies, and Relationships
| Information |
Likely modeling choice |
Question to settle |
| Duration |
Field |
Number and unit, or controlled choice? |
| Topic |
Taxonomy |
Shared vocabulary managed by whom? |
| Instructor |
Related record |
Can one instructor teach many courses? |
| Session date |
Field or separate session entity |
Can the course run more than once? |
These are planning choices, not a universal schema. Avoid duplicating the same instructor biography inside every course if it needs central maintenance. Conversely, do not turn every small label into its own complex record type.
Decide Public and Editorial Behavior
Specify whether records have public detail pages, an archive, search visibility, previews, and drafts. List who may edit their own records, publish others' records, and export information. If staff need a block editor or a headless client, include that requirement in the implementation brief.
The register_post_type reference documents these configuration choices. Public visibility, REST exposure, and editing capabilities need deliberate settings. Hiding an admin field does not by itself protect its value from a public API response.
Test sheet for custom post types in wordpress. Record your own evidence.
Plan URLs and Templates Together
Choose a durable URL pattern and check for collisions with existing pages. Decide what should happen when a record is retired, renamed, or merged. Do not change a published URL structure without an old-to-new map and a reason.
Design empty states before the ideal example. An archive with no published courses should explain the situation, not display a broken layout. A record with no image should still have a readable page. Test long titles, missing optional fields, and pagination with enough sample records to expose layout problems.
Keep Business Content Portable
WordPress recommends registering custom post types in a plugin rather than a theme so the content model is not tied to a visual theme choice. Record the type identifier, field definitions, and taxonomy names in source control.
Test a theme change in an isolated environment. Check that records remain manageable and that the replacement theme can render them. A type no longer appearing in the editor does not necessarily mean its database records were deleted.
Agree on Import and Acceptance Tests
Define how existing content will map into the new structure, how duplicate imports are detected, and what happens to invalid rows. Have an actual editor create and revise sample records. Verify archive links, detail pages, permissions, and search behavior.
Use the feature-request template for acceptance criteria and the integration checklist if another system supplies the data. For a broken existing content model, HandL WP's one-time fix can investigate registration and templates without treating a missing editor menu as proof of lost content.
References checked September 28, 2026. Diagrams and worked examples are explanatory, not customer measurements.