- Article
- 3 minutes read
- Reviewed August 3, 2026
Names and slugs become long-lived contracts across the WordPress administration area, database, URLs, templates, APIs and integrations.
A clear convention prevents ambiguous editor labels and reduces the risk of destructive renaming after launch.
Separate Human Labels from Technical Identifiers
Editors may see Case Studies while code uses a stable key such as case_study. The public URL might use work or case-studies.
These values serve different audiences and do not need to be identical.
Post Type Keys
Use lowercase machine identifiers, follow WordPress length constraints and avoid reserved names. Prefix or namespace custom keys when collision risk matters.
Treat the key as immutable. Changing it requires updating existing records, capabilities, taxonomies, metadata registration, templates, queries and integrations.
Taxonomy Keys
A taxonomy key should name the classification dimension, not one term. Use industry, not technology-companies.
Avoid generic keys such as type or category_2 that lose meaning outside the current screen.
Metadata Keys
Metadata keys should be stable, descriptive and namespaced. Prefer veyra_event_start over date.
Do not encode changing labels or field-group positions into the key.
Public Slugs
Public slugs should be readable, concise and aligned with visitor language. They become part of indexed URLs and should change rarely.
Do not include implementation details such as cpt or internal plugin names in visitor-facing paths unless they are meaningful to users.
Singular and Plural Labels
Provide complete singular and plural labels so the interface reads naturally: Add New Event, Edit Event, Search Events and No events found.
A generic plural label copied across every action makes the administration interface feel unfinished.
Consistency Across the Model
Choose one vocabulary and use it in post types, fields, templates and documentation. If editors create Venues, do not call the same object Locations in an API and Places in a filter.
Synonyms can appear in explanatory text, but technical and editorial names need a canonical term.
Reserved and Conflicting Slugs
WordPress, themes and plugins register query variables and rewrite bases. Test new slugs against existing pages, taxonomies, endpoints and multilingual routes.
A collision can send requests to the wrong query or produce unexpected 404 errors.
Renaming After Launch
Changing an editor label is normally safe. Changing an internal key or public slug is a migration.
Plan data updates, redirects, cache clearing, sitemap changes, canonical URLs, API compatibility and communication to external consumers.
Suggested Convention
- Human title: Case Studies.
- Internal post type key:
prefix_case_studyor another stable project convention. - Public rewrite slug:
case-studies. - Template name:
single-prefix_case_studyor the applicable block-template equivalent. - Metadata key:
prefix_case_study_outcome. - Taxonomy key:
prefix_industrywith public slugindustry.
Frequently Asked Questions
Can the public slug differ from the post type key?
Yes. The internal identifier and public rewrite slug serve different purposes.
Is changing a label safe?
Usually, if only the visible label changes. Changing keys or public slugs requires a migration plan.
Should every key have a prefix?
Prefixing reduces collisions, especially in distributable plugins. Use a consistent project convention without making public URLs unnecessarily verbose.