WordPress Custom Post Types and Custom Fields

WordPress custom post types and custom fields are how you give a site a proper content structure. A custom post type is a new kind of content alongside posts and pages, such as services, team members, case studies, locations, vacancies or properties. Custom fields attach structured data to each item: a price band, a job title, a client sector, a postcode. Used together, they turn a collection of hand-built pages into a content model, where adding the eleventh service is filling in a form rather than designing a page.

The WordPress website development guide argues that the content model is the most consequential decision in a build. This article explains the tools you use to build one.

Posts, pages and custom post types

WordPress stores almost everything as a post with a post type. Out of the box, the two you see are posts (dated, for news and articles) and pages (undated, hierarchical). Neither is a good fit for structured business content.

A custom post type gives you:

• its own menu item in the admin, so editors know where services live
• its own URL base, such as /services/ or /case-studies/
• its own templates, so every item is displayed the same way
• its own archive page listing every item, if you want one
• control over which editor features it supports

Custom fields

Custom fields store specific pieces of data for each item, in named fields rather than in a block of body text. That matters because structured data can be reused: displayed in a card, sorted, filtered, used to build schema markup, or pulled into another page.

For a service post type, the fields might be:

The editor fills in those fields. The template decides how they look. A new service is consistent with the others by construction.

Taxonomies

Taxonomies group content. Categories and tags are the built-in ones. Custom taxonomies let you group custom post types in business-specific ways: case studies by sector, vacancies by department, properties by area.

A rule of thumb: if you will filter or browse by it, it is a taxonomy. If it is a value unique to each item, it is a field.

How to build them: the options

Registering post types in code

Post types and taxonomies are registered with register_post_type() and register_taxonomy(). This is a few dozen lines of PHP and is what I use on most builds, inside a small site plugin rather than the theme. Code lives in version control, can be reviewed, and cannot be accidentally changed in the admin.

Advanced Custom Fields and Secure Custom Fields

For the fields themselves, a field framework saves a great deal of work. The best known is Advanced Custom Fields (ACF), which also registers post types and taxonomies through its interface.

The landscape changed in October 2024. During a dispute between WordPress.org and WP Engine, which owns ACF, WordPress.org forked the free version of ACF into a plugin called Secure Custom Fields and took over the original plugin's listing on the WordPress.org directory. ACF continues to be developed by WP Engine and is distributed from its own site, with a paid PRO version. The two remain compatible with existing field groups for now but are separate projects that will diverge. You can see each on its own page: Advanced Custom Fields and Secure Custom Fields.

What that means in practice: know which one your site runs, keep it updated from the right source, and do not install both.

Other frameworks

Meta Box and Pods are mature alternatives with their own strengths, including custom database tables for large data sets. The choice matters less than consistency: one field framework per site, documented.

Field groups in code

ACF and similar tools can save field definitions as JSON or PHP files in the theme or plugin, rather than only in the database. Do this. It puts the content model in version control, so the structure is the same on staging and live, and changes can be reviewed.

Custom fields and block themes

Block themes changed how fields are displayed. Since WordPress 6.5, the block bindings feature lets core blocks, such as a paragraph or image, display a custom field's value, and ACF added support for it. For simple cases this means no template code. For complex layouts, custom blocks that read your fields are still the cleaner route. WordPress block themes and full site editing covers the theme side.

Using fields for structured data

One of the strongest arguments for custom fields is schema markup. When a service's price, FAQs and description live in fields, the template can generate accurate structured data from the same values visitors see, so the two never drift apart. Hand-written markup per page always drifts. The schema markup guide explains which types are worth adding.

A worked example: a recruitment agency site

Hypothetical, to show how the pieces fit. Say a recruitment agency wants vacancies, sector pages and consultant profiles on its site.

• Vacancy post type, with fields for salary range, contract type, location, closing date and the consultant responsible. A Sector taxonomy groups vacancies, and a Location taxonomy lets candidates filter by area.
• Consultant post type, with fields for job title, phone, email, photo and the sectors they cover.
• Sector pages as ordinary pages, each pulling in the latest vacancies in that sector and the consultants who cover it.

The payoff: posting a vacancy is a two-minute form. It appears automatically on the right sector page, with the right consultant's contact details, and drops off the listings after its closing date. JobPosting structured data is generated from the same fields. Nobody hand-builds a page, and nobody forgets to remove an expired role.

Built as individual pages instead, every vacancy would be copied from the last one, sector pages would need updating by hand, and expired roles would linger until someone noticed.

Common mistakes

1. Registering post types in the theme. Change the theme and the content disappears from the admin. Use a plugin.
2. Fields for everything. Fifteen fields per item, most of them optional, makes editing slower. Keep fields to what the template actually uses.
3. Body content in fields. Long-form content belongs in the editor, where blocks and formatting work. Fields are for discrete values.
4. Changing slugs after launch. Renaming a post type's URL base changes every URL under it and needs redirects.
5. No archive decision. Decide whether each post type has an archive page and whether it should be indexed.
6. Location pages generated from fields with nothing else changed. That is a doorway page pattern, and it does not work.

When the content model needs a plugin of its own

Simple content models fit in a site plugin with a field framework. Once items need relationships, user submissions, workflows or calculations, such as a directory that members submit to, or a course catalogue with sessions and bookings, you are building an application, and a custom plugin is the better home for it.

Custom post types are also the foundation for headless WordPress, where a separate front end reads the same structured content through an API.

Next step

If your site has services, case studies or team members built as individual pages, converting them into a content model is usually a contained job with a long payoff. It is part of the WordPress development service, and anything more complex is scoped through plugin development.