Determining Whether to Use a Custom Post Type or Post/Page

Understanding WordPress Custom Post Types
Is there a right way and a wrong way to using Custom Post Types? I am not sure. To me, it entirely depends on the amount of work one wants to put into the development of the custom post type. Custom Taxonomies and Post Formats solves many issues, especially for Theme developers, that people were trying to solve via custom post types.

Always ask yourself these questions (some from Taylor D. Dewey)

  1. Do I need discrete categorical or tag-type information applied to this information?
  2. Is this a variation of a blog post or a page?
  3. Do I need to display traditional pages, blog posts, and a 3rd completely unrelated type of information?
  4. Can my data type fit within the existing schema of pages and posts?
  5. What is my goal/objective that I am trying to accomplish?
  6. Can my goal/objective be accomplished through the use of post formats?
  7. Can my goal/objective be accomplished through the use of custom taxonomies?
  8. Do I need to use custom taxonomies?

If you want to make something that shows up in the normal feeds, or shows up mixed into the blog, or shows up using the normal templates, or basically is a “Post” in the sense of the existing WordPress posts in any way whatsoever, then you may not want to use a Custom Post Type.

Custom Post Types, by default, are custom, and as such should be something different entirely. Posts appear in the blog and feeds. Pages are typically static and have their own hierarchical structure. Custom post types are defined by the developer (and in my opinion, by the content) and is NOT a post or a page. If you want a way to separate one “type” of post from another, then custom taxonomies or post formats are the best way to do this.

The confusion stems from the naming of custom post types. If custom post types were called custom content types, I wonder if we would be having this discussion. Regardless, custom post types are content types. They are not different types of posts. Taxonomies allow for the organization and separation of the same types of content into any sort of taxonomy whether hierarchical or not. Post formats allow and encourage different formatting of posts.

Recently, one individual ranted about custom post types not being part of the feeds by default. To me and many others, this is a good thing because custom post types are content types. While some content types are designed for public viewing, they do not belong to the feed per se. For example, if I have a FAQ or event post type, each “post” to those content types do not belong to my feed. Yet on the other hand, if I wanted to make podcast a custom post type, I have to do the work to link it to the feed, have it appear on the blog, create a template to show multiple entries, etc. Could there be some benefit of a podcast custom post type? Yes, but it includes doing work that has already been done. And as such, why would you want to reinvent the wheel? If my goal or objective is user experience, then that might be worth some extra work. I am not sure. That’s for you to decide. However, that was not what WordPress has set out to accomplish via custom post types. Yet, some of us want to reinvent the wheel and have no problem doing so. Jason’s point is that we should not have to reinvent the wheel and that custom post types should come like posts by default. While I disagree with Jason to a degree, I do see his point and have to admit that I agree with him to a degree.

Otto states that “There’s no code in there [WordPress core] to do that [e.g., have custom post types appear in the blog/feed], and there’s very likely not going to be [in the WordPress core].” Though I don’t believe WordPress should write the code to make everything happen as that could be a massive undertaking, I do believe that WordPress should incorporate an argument for feed/loop in the register_post_type that could be boolean types if set to true would add the custom post type into the “blog” and feed. The code to incorporate the custom post type into a blog is fairly simple as Justin Tadlock has demonstrated:
add_filter( ‘pre_get_posts’ , ‘wps_add_my_cpt’ );
function wps_add_my_cpt() {
if ( is_home() && false == $query->query_vars[‘suppress_filters’] )
$query->set( ‘post_type’ , ‘array( ‘post’ , ‘wps_cars’ );
return $query;

And showing the post types in the feed is just as easy!
add_filter( ‘pre_get_posts’ , ‘wps_add_my_cpt’ );
function wps_add_my_cpt() {
if ( ( is_home() && false == $query->query_vars[‘suppress_filters’] ) || is_feed() )
$query->set( ‘post_type’ , ‘array( ‘post’ , ‘wps_cars’ );
return $query;

Therefore, adding a simple if-then statement with these filters should not be a problem.

However, as it currently stands and as Otto simply stated, “Separation of content type in the admin panel is not a good reason to create a whole new “type”. Not if what you really need is to separate existing posts by some other factor. That’s what taxonomies [and post formats] are explicitly designed for.” While I agree with Otto to a degree, I also highly value user experience. So would separation of content type in the admin panel to increase user experience be a good enough reason to create a whole new post type? Again, that’s for the developer/designer to decide. As for WordPress, right now, it’s not.

What can I do for you!?

Custom Development

We develop plugins by determining both business/functional and technical requirements, following WordPress development best practices, and using agile methodology to ensure you get the best solution.


Have questions? Need a reliable developer to consult? Please contact us today!

Customized Theme

We can customize your theme or child theme, or create a child theme for you based on your needs while enhancing the performance of every individual attribute.

Customized Plugin

We can customize your plugins, extend plugins (e.g., Gravity Forms, Jetpack, Soliloquy) based on your needs ensuring security, performance, and positive business impact.


Leave a Reply