Custom Post Types, Taxonomies, or Custom Fields: Which Should You Use?

Custom post types, taxonomies, and custom fields are the three main tools WordPress gives you for structuring content beyond posts and pages. Each solves a different problem, and using them well starts with knowing which problem belongs to which tool.

This guide walks through all three, but here's the quick overview: a custom post type gives a new kind of content its own home, taxonomies group items under shared labels so visitors can browse them, and custom fields store each item's details. A post type is the container, while taxonomies and fields organize and describe what's inside. Once that clicks, most of the custom fields vs custom post types confusion disappears.

The choice still matters, though. Imagine you're building a book library site. Store each book's genre as a custom field, and visitors get no page listing all your fantasy titles. Fixing it later usually means editing every book, one at a time, to move its genre into a taxonomy. The sections below cover what each of the three does best, take real decisions from the example book site, and show both ways to build each. The guide then finishes with a checklist to help you choose the right structure before you build.

The Short Answer

Here's the rule of thumb for each of the three:

• Custom post type: a new kind of content that sits alongside posts and pages, such as books, staff profiles, or properties. It's usually the container that custom fields and taxonomies attach to.
• Taxonomy: a shared vocabulary of labels reused across many items, such as genre or location. Categories and tags are the two built-in WordPress taxonomies.
• Custom field: stores a piece of information about one item, such as a price, a date, or an ISBN.

Treat these as rules of thumb rather than laws. The sections below expand on each one, and the scenarios that follow cover the judgment calls.

What Is a Custom Post Type (and When Should You Use One)?

Posts and pages are the post types WordPress ships with. Custom post types let you add your own kinds of content alongside them. Each one gets its own section in the WordPress admin: its own menu, listing screen, and editing screen. Which features it supports (the editor, author, and featured image, which WordPress labels Thumbnail) is configurable. In the Meta Box plugin, that can be controlled via the Supports tab. Common examples of custom post types include portfolios, staff profiles, events, documentation, and products.

So when does creating a custom post type make sense? If you want to publish a few book reviews, ordinary posts with a "Books" category work fine. However, if you want to keep that content separate from the blog, creating a book post type does exactly that, with its own menu in the admin area, plus the option of its own archive page, templates, and taxonomies for visitors.

One thing a post type won't do is store extra details like a page count on its own. Custom fields handle that, so the two are usually set up together. In the book library, book is the post type everything else attaches to.

What Is a Taxonomy (and When Should You Use One)?

As mentioned above, categories and tags are the taxonomies built into WordPress. A custom taxonomy is the same system applied to labels you define: genre, location, brand, difficulty level. Taxonomies come in two flavors: hierarchical, like categories, and flat, like tags. Either way, when you assign a term to a post, you pick from the existing list instead of retyping the label each time. You can also add new terms whenever you need them.

Taxonomies are the best choice when many items share the same label, and visitors browse by that label. WordPress can generate an archive page for every term of a public taxonomy. Readers can then browse everything assigned to that term in one place. How the page looks, and whether it's linked anywhere, depends on your theme and site configuration.

For the book library example, Genre is the obvious taxonomy, but you're not limited to one. You could add a Format taxonomy alongside it (paperback, hardback, audiobook) so visitors can browse by that as well.

What Are Custom Fields (and When Should You Use Them)?

A custom field attaches an extra piece of information to a single item, like a post, a page, or a custom post type entry. Meta Box can also attach fields to taxonomy terms and user profiles. WordPress stores the value with the item, and it can then be displayed to visitors, depending on how your site is configured. Not every field is shown to visitors on the front end. Some only ever appear in the admin area.

Typical uses: the price on a product page, the start date of an event, the specs on a review, an internal note for your editorial team. For the book library, each book gets a page count, an ISBN, and your rating.

As a rule of thumb, a value that describes one item belongs in a field. When the "value" is really a shared label visitors group content by, like genre, a taxonomy is the better option, as the scenarios below show.

Custom Fields vs Taxonomies vs Custom Post Types: Quick Comparison

The table below puts the three side by side. When you're weighing up custom fields vs taxonomies vs custom post types, the "Ask yourself" row usually settles it.

Same Use Case, Different Approaches

Knowing the definitions is one thing. The real decisions arise when two of the three look equally suitable. Each scenario below takes one requirement from the book library and builds it both ways.

This lets you see the consequences of each choice before committing on your own site. Everything here was built on a site with Meta Box installed.

Letting Visitors Browse Books by Genre

The requirement: every book has a genre, and visitors can view all the books from that genre in one place.

One option is a custom field that stores the genre on each book. A free-typing text field could cause problems, though: enter "Sci-Fi" on one book and "Science Fiction" on another, and you now have two versions of the same genre. A select field fixes that, but neither version gives you a genre page that lets visitors view all the books sharing that value in one place. Developers can build filtered listings from field values, but this isn't available out of the box.

The other option is a genre taxonomy attached to the book post type. Terms are picked from a single list, such as horror or fantasy, and WordPress generates an archive page for each genre. Most themes can handle this without extra work.

The call: taxonomy, unless genre is a display-only detail you'll never group by.

Showing Who Wrote Each Book

The requirement: the author of each book is displayed, along with a short bio.

The custom field route adds author name and bio fields to the book post type, filled in on each book. It works until an author has three books and the same bio is pasted into all three. Sooner or later, one copy gets updated, and the others drift.

The post type route creates an author post type (book authors aren't WordPress user accounts, so the built-in author system doesn't apply). Each bio lives in one place, and Meta Box's Relationships feature links authors to their books. The relationship stores the connection in both directions. Showing the books on an author's page, or the author on a book's page, is a display step for Meta Box's display tools or your theme.

The call: fields when authors rarely repeat; the post type and relationship once they recur. Retyping and updating the same bio in several places soon takes up more time than the one-off setup.

Grouping Books by Publisher

The requirement: group books by publisher, and show some publisher information.

This is the classic custom post type vs taxonomy decision, and the closest call of the three. One question decides it: is publisher mainly a way to group books, or a thing in its own right?

The taxonomy route treats publisher as classification: the taxonomy groups the books, and the term description holds light details, such as a one-paragraph profile. (The premium MB Term Meta extension can add proper fields to terms as well.)

The post type route treats publisher as an entity: its own freely edited page with a logo, a story, and featured books, connected to its books with a relationship as in the author example.

The call: start with the taxonomy, and graduate to a post type if you ever need to write a full page about the publisher itself. The same test applies to authors: classification stays a taxonomy; an entity becomes a post type.

A Three-Question Decision Checklist

This is WordPress data modeling at its simplest. Run any content idea through these three questions, in order:

1. Is it a new kind of content you'll create entries of, each opened and edited like a post? Make it a custom post type.
2. Is it a label many items share, one that visitors browse or group by? Make it a taxonomy.
3. Is it a piece of information about one item? Make it a custom field.

Sites often combine all three, as our book library example does: a post type for books, a taxonomy for genres, fields for the specific book details. You don't need all three for every project, though. Use the pieces that solve the problem in front of you.

Creating All Three Without Code

None of this requires touching any code. The free Meta Box Lite plugin includes the visual builder for all three. Post types live under Meta Box → Post Types, taxonomies under Meta Box → Taxonomies, and field groups under Meta Box → Custom Fields.

Relationships are a free feature as well. The post type and taxonomy screens ask for a plural name, a singular name, and a slug (the URL-friendly name), and sensible defaults cover the rest. A field group needs only a title before you start adding fields. Meta Box's documentation walks through every screen, so this guide won't repeat the steps.
One thing catches people out at first. Creating a post type, taxonomy, or field stores and organizes your content, but how any of it appears to visitors is a separate display step that depends on your theme or Meta Box's display tools. If you've ever created a custom field and wondered why nothing changed on the front end, that's why.

Map Your Content Before You Build

Aim for a site where every piece of content has an obvious home: a post type for each kind of thing, taxonomies for the ways content is organized and people browse, and fields for the details. That's content architecture in practice, even if nobody on the project calls it that. List what your site will hold, run each item through the three questions, then build. Ten minutes of mapping now beats a data migration later.

FAQs

What's the difference between custom fields, custom post types, and taxonomies?

A custom post type is a new kind of content, like books, reviews, or staff profiles. Taxonomies are shared labels, like genre, that group many items. Custom fields store details about one item, such as a price or date. Most structured sites use all three together.

When should I use a custom post type vs a custom field?

Use a custom post type for a new kind of content that needs its own section of the WordPress admin and its own pages on your site. Use a custom field to store a detail about an existing item. If the information describes something, it's a field; if it is the something, it's a post type.

When should I use a taxonomy vs a custom field?

Use a taxonomy when many items share a label visitors browse or group by, like genre. Use a custom field for a value that describes one item, like a page count. Shared label: taxonomy. Individual value: field.

How should I structure custom content in WordPress?

Start with the container. Give each new kind of content its own custom post type, then attach custom fields for the details and a taxonomy or two for the labels visitors browse by. That's exactly how the book library in this guide is put together.

Can I change my mind later and turn a custom field into a taxonomy?

Yes, but it's a migration rather than a toggle: the stored values move into taxonomy terms, and any templates that displayed the field need updating. Manageable on a small site, tedious on a large one. The checklist above exists to spare you the job.