- Article
- 3 minutes read
- Reviewed August 3, 2026
A hierarchical content type allows entries to have parent and child relationships. A non-hierarchical type treats entries as a flat collection.
The choice affects editing, URLs, queries, navigation and the mental model of the content. It should reflect a real containment or inheritance relationship, not merely a desire to indent items in the administration screen.
How Hierarchical Content Works
Pages are the familiar hierarchical post type. A page can name another page as its parent, creating a tree.
Custom post types can enable the same model. Documentation sections, geographic areas or nested organizational units may benefit from it when each child clearly belongs beneath one parent.
How Non-Hierarchical Content Works
Posts are non-hierarchical. Every post is an independent entry, although categories, tags, authors and relationships can group or connect them.
Events, products and portfolio projects are commonly flat because one item does not naturally contain another. They may still have complex classification without a parent-child post relationship.
Hierarchy Is Not the Same as Ordering
A hierarchy expresses parentage. An order field expresses sequence. A course can contain lessons in a sequence, but the correct model may be a relationship and explicit order rather than a page-like tree.
Do not enable hierarchy solely to gain drag-and-drop ordering. Use an ordering mechanism that communicates the actual rule.
Hierarchy and URLs
For pages, WordPress can include ancestor slugs in the permalink. Custom post types may require additional planning if nested URLs are expected.
A URL that mirrors the hierarchy can be readable, but moving an item to a new parent changes its address and requires redirects. The public URL does not have to expose every internal relationship.
Hierarchy and Scale
Large hierarchical post types can be expensive to load and difficult to navigate in the administration area. Thousands of entries in one parent selector produce a poor editorial experience.
At scale, consider taxonomy trees, search-based relationship controls or purpose-built interfaces instead of relying on the standard page parent dropdown.
When a Taxonomy Is Better
Use a hierarchical taxonomy when the hierarchy describes reusable classification rather than content containment. A location taxonomy can classify many events under Country, Region and City without making each event a child post.
Taxonomy terms can be assigned to multiple items. A post hierarchy normally gives an item one direct parent.
When a Relationship Is Better
Use an explicit relationship when two independent objects are connected. An event occurs at a venue, but the event is not necessarily a child of the venue in every editorial and URL sense.
Relationships can also be many-to-many, while the native post parent field describes a simpler parent-child model.
Decision Questions
- Does every child belong to exactly one parent?
- Does the parent represent containment rather than classification?
- Should moving an item affect navigation or URLs?
- Will editors understand and maintain the tree?
- Could the collection grow beyond the standard hierarchy interface?
- Would a taxonomy or relationship describe the meaning more accurately?
Frequently Asked Questions
Can custom post types be hierarchical?
Yes. A custom post type can enable hierarchy and parent support through its registration arguments.
Does a hierarchical post type automatically create nested URLs?
Not in every custom implementation. URL behaviour depends on registration, rewrite rules and permalink generation.
Can one post have multiple parents?
The native post parent model stores one parent. More complex relationships require another modelling approach.