- Article
- 3 minutes read
- Reviewed August 3, 2026
Use this checklist before registering a custom post type or approving a plugin configuration. It helps verify that the proposed type represents a real content object and that its surrounding architecture has been planned.
1. Purpose and Scope
- The type represents a distinct object, not only a visual style.
- The object cannot be modelled more clearly with an existing post type and taxonomy.
- The intended editors and visitors are identified.
- The expected number of records and growth rate are estimated.
- The source of truth is clear when another system also stores the data.
2. Naming
- The internal key is stable, lowercase and within WordPress constraints.
- The key does not collide with core, theme or plugin registrations.
- Singular and plural labels read naturally.
- The public slug is concise and meaningful to visitors.
- Technical keys are documented separately from editor labels.
3. Core Features
- Title, editor, excerpt, thumbnail, author, revisions and comments are enabled only when relevant.
- Hierarchy is based on a real parent-child relationship.
- Editorial order is not being confused with hierarchy.
- The block editor and REST requirements are understood.
4. Public Behaviour
- The need for single public URLs is decided.
- The need for a post type archive is decided.
- Search inclusion is intentional.
- Navigation and feed behaviour are considered.
- Canonical, sitemap and noindex behaviour will be configured.
5. Classification and Fields
- Every taxonomy represents one reusable classification dimension.
- Every field has a defined meaning, type and format.
- Required and optional values are documented.
- Repeated and relational data have an appropriate model.
- Important metadata keys are registered and protected.
6. Relationships
- Related object types are identified.
- Cardinality and editing direction are defined.
- Order and relationship metadata are considered.
- Deletion and orphan behaviour are documented.
7. Permissions and Workflow
- Creators, reviewers, publishers and administrators are identified.
- Custom capabilities are used when separation from posts is required.
- Private and internal content access has been tested.
- Imports, scheduled updates and external systems follow the same rules.
8. URLs and Rewrites
- Single, archive and taxonomy paths do not conflict.
- Rewrite rules will be refreshed only at appropriate lifecycle events.
- Existing URLs have a redirect plan.
- Multilingual and multisite requirements are considered.
9. Templates and Queries
- Single, archive, search and related-content views are defined.
- The theme has acceptable fallback behaviour.
- Metadata and taxonomy queries have been tested with realistic volume.
- Empty states and missing fields are designed.
10. Integrations and Data Lifecycle
- REST API exposure and authentication are decided.
- Imports, exports and external identifiers use stable formats.
- Deactivation preserves content unless explicitly documented otherwise.
- Uninstallation and data deletion require clear consent.
- Backups and migrations include all related files and data.
11. Editorial Testing
- Real editors have tested representative and edge-case entries.
- Labels and instructions use their vocabulary.
- The form is not longer or more complex than the workflow requires.
- Validation messages explain how to correct errors.
Approval Question
Can the team explain what this post type represents, how it differs from existing content and how its data remains useful if the design or plugin changes?
If the answer is unclear, return to the content model before registering the type.
Frequently Asked Questions
Should every checklist item be required?
Not every project needs every feature, but every item should be considered and marked intentionally rather than ignored.
Can this checklist be used with a no-code post type plugin?
Yes. The architectural decisions are the same whether registration is written in code or configured through an interface.