Custom Post Types and ACF Explained for Business Owners

Custom post types are the single concept that separates a properly built WordPress site from a pile of pages, and yet almost nobody explains them to the people paying for the website. If you run a business and you are about to commission a site – or you are staring at one that has become impossible to update – this idea is worth twenty minutes of your time. It decides whether your content survives the next redesign, whether visitors can filter and search what you offer, and whether your team can edit the site without breaking it.

I am a freelance WordPress developer and I have built more than 500 WordPress projects over 12+ years, mostly for small businesses and agencies in Germany, the UK, the US and Australia. A large share of my “rescue” projects exist because the original site was built without structure: sixty hand-made pages, content copy-pasted everywhere, and an owner who is afraid to touch any of it. This guide explains custom post types, custom fields and ACF in plain language – what they are, what they cost, when they are overkill, and exactly what to ask your developer for so you get a site built on structure rather than luck.

Table of contents

• The default problem: when everything is a page
• What custom post types actually are
• What custom fields and ACF add
• Taxonomies: categories for anything
• How structure pays off later
• When a custom post type is overkill
• ACF vs the alternatives
• Rescuing an unstructured site
• What structure means for cost and quotes
• What to ask your developer for
• A mini glossary for your next brief
• Frequently asked questions

The default problem: when everything is a page

Out of the box, WordPress gives you two content types: posts (blog articles) and pages (everything else). That is fine for a five-page brochure site. It falls apart the moment your content starts repeating – team members, properties, courses, projects, testimonials, locations, services. The default answer is to make each one a page, and that is how “page soup” starts.

Here is what page soup looks like in practice, and I see it weekly. An estate agent has forty property pages, each built by hand in a page builder, each slightly different because they were copied from whichever page was open at the time. The office manager updates a price on the listing page but forgets the detail page. There is no way to show “all three-bedroom properties under 300,000” because WordPress has no idea those pages are properties – it only knows they are pages. When a property sells, someone deletes the page and every link to it dies. And when the company wants a redesign two years later, the quote comes back painfully high because every one of those forty pages has the design baked into the content, and every one has to be rebuilt by hand.

• Repetition without consistency. The same kind of content built forty different ways, drifting apart with every edit.
• No listing, filtering or search. WordPress cannot list “all courses” or filter “properties by price” because nothing tells it which pages are which.
• Fragile editing. Content and layout live in the same builder canvas, so changing a word risks nudging a column and breaking the page on mobile.
• Expensive redesigns. The content cannot be poured into a new design because it is welded to the old one.

None of this is the owner’s fault. It is the result of a build that never asked the one question that matters: what kinds of content does this business actually have?

What custom post types actually are

A custom post type (CPT) is a new kind of content you teach WordPress to understand, alongside the built-in posts and pages. If your business deals in properties, your developer registers a “Property” post type. From that moment, WordPress treats properties as first-class citizens: they get their own menu item in the admin sidebar, their own list screen, their own URLs (yoursite.com/properties/park-view-apartment/), and their own templates in the theme.

The mental model I give clients: pages are for the site’s one-off content (About, Contact, the homepage), posts are for news and articles, and a custom post type is for anything you have many of that shares a shape. Concrete examples from my own projects:

• Properties for an estate agency – each with a price, location, bedrooms, floor area, photo gallery and sale status.
• Courses for a training company – each with dates, duration, level, price and a tutor.
• Team members for almost any service business – name, role, photo, bio, languages spoken.
• Testimonials – quote, author, company, star rating, which service it relates to.
• Projects for an agency or builder’s portfolio – client industry, services delivered, results, image gallery.
• Events – date, venue, price, booking link, capacity.

The key point for a business owner: a custom post type is not a design element and not a plugin you buy off a shelf. It is a decision about how your content is modelled, made once at the start of a build, and it costs very little to set up – registering a post type is a few lines of code. The value is not in those lines; it is in everything they unlock, which the next two sections cover.

What custom fields and ACF add

A post type on its own gives each property a title and one big content area – still not enough. What makes structure real is custom fields: named boxes for each piece of data. Price. Bedrooms. Location. Status. Instead of typing “Price: 285,000” somewhere inside a text block, the editor fills in a field labelled Price, and the design decides where and how that number appears.

ACF (Advanced Custom Fields) is the tool most WordPress developers, including me, use to build those fields. It lets a developer define field groups – the set of fields a Property or a Course carries – with proper input types: text, number, date pickers, image galleries, dropdowns, true/false toggles, links, relationships to other content (“this testimonial belongs to that project”). The editor sees a clean form; the theme pulls each value into the right place in the design.

This is the philosophy I build every site around, and it is worth stating plainly:

• Editors edit content, not layout. The form asks for a price and a photo; it never asks the editor to drag a column or pick a font size. The design is the developer’s job and it stays consistent on every entry, forever.
• Impossible to break. Because the layout lives in the theme, there is nothing an editor can do in the Price field that wrecks the page. My clients’ least technical staff update their own sites confidently, and my support inbox stays quiet.
• Validation and guidance. Fields can be required, constrained (a number, a date, an image of the right shape) and labelled with instructions. The site enforces its own consistency.
• One source of truth. The price lives in one field. Every page that shows it – the listing grid, the detail page, the “featured properties” block on the homepage – reads the same value.

When I quote a custom build, the ACF field structure is a core part of what I am designing, as much as the visual design. I build themes as structured, editable sections for exactly this reason – it is the difference between handing over a website and handing over a system the client can run. That approach is at the heart of my WordPress theme development work.

Taxonomies: categories for anything

The third piece of the structure puzzle. You already know taxonomies from blogging: posts have categories and tags. WordPress lets a developer create the same kind of grouping for any post type, and that is what makes filtering and browsing work.

Examples make it obvious. Properties get a “Location” taxonomy (city districts) and a “Type” taxonomy (apartment, house, commercial). Courses get “Level” (beginner, intermediate, advanced) and “Format” (online, in-person). Projects get “Industry” and “Service”. Each taxonomy term automatically gets its own archive page – yoursite.com/property-location/riverside/ lists every property in Riverside with no extra work, and it is a real, indexable page that can rank in Google for “apartments in Riverside”.

Taxonomies versus fields is a classic modelling decision, and a good developer will get it right without you needing to care. The rule of thumb: if you want to group, filter or browse by it, it is a taxonomy; if it is a value that belongs to one entry, it is a field. Bedrooms could be either – as a field you display it, as a taxonomy (or a filterable field) visitors can narrow a search by it. This is exactly the kind of question a structure conversation at the start of a project settles in ten minutes, and retrofitting later costs far more.

How structure pays off later

Structure costs a little thought up front and pays for itself several times over the life of the site. This is the part I most want business owners to hear, because the benefits arrive in years two and three, long after the launch invoice.

• Redesigns keep your content. This is the big one. When your content lives in fields, a redesign means building a new theme that reads the same fields – the forty properties, ninety testimonials and twelve team members come along untouched. I have redesigned structured sites in a third of the time (and cost) of comparable page-soup sites, where every page had to be manually rebuilt. You paid to enter that content once; structure means you never pay again.
• Filtering and search that actually work. “Show me online beginner courses in March” is a database query when courses are structured, and impossible when they are pages. Faceted search, sort by price, “related properties” – all of it depends on fields and taxonomies existing.
• Automatic everything. New team member? Fill in the form and they appear on the team page, in the right department, in alphabetical order. Course date passed? It drops off the upcoming list on its own. Nobody edits layouts; the site maintains itself.
• Feeds and integrations. Structured content can be pushed and pulled: properties exported to a portal, courses synced with a booking system, projects fed to a newsletter, everything exposed cleanly through the WordPress REST API to a mobile app or a CRM. Unstructured page content cannot be exported to anything sensibly.
• Better SEO by default. Consistent templates mean consistent headings and metadata, taxonomy archives create landing pages you did not have to write, and structured fields map naturally onto schema.org markup (a Course or Product with real price and date data), which is what search engines and AI assistants increasingly read.

One honest caveat: structure only pays off if the theme is built to use it well. A pile of ACF fields with a poorly built theme is just a different flavour of mess. The field design and the template design have to be done together, by the same person or team, against the same content model.

When a custom post type is overkill

Honesty section. I make my living building structured WordPress sites, and I still talk clients out of custom post types regularly. Structure has a cost – a little in build time, more in editorial overhead – and below a certain scale it is not worth it.

• Five items that never change is a page. If you have four testimonials and expect four next year, a well-built page section with editable entries does the job. A CPT with admin menus and archive templates for four quotes is ceremony without benefit.
• One-off content is a page. Your history, your approach, a landing page for one campaign – these have no repeating shape, so there is nothing to structure.
• Do not model what you will not maintain. A “News” post type with three articles from 2023 makes a site look abandoned. If nobody will feed it, do not build it.
• Do not build a CPT where a proven plugin is the real answer. Products belong in WooCommerce, not a homemade “Product” post type – you would be rebuilding carts, stock and tax from scratch. Complex event booking may justify a dedicated events plugin, and behaviour that goes beyond storing and displaying content (calculations, portals, workflows) crosses into WordPress plugin development territory. The judgement call between structure, an off-the-shelf plugin and custom code is its own topic – I wrote about it in when you actually need a custom WordPress plugin.

My working threshold: a custom post type earns its place when you have (or will realistically have) roughly ten or more items of the same shape, or when you need listing, filtering or integration behaviour regardless of count. Below that, structured page sections are cheaper and simpler. A developer who recommends CPTs for everything is selling complexity; one who never recommends them is selling you a future rebuild.

ACF vs the alternatives

ACF is not the only way to add fields, and you may hear other names in quotes and proposals. The honest comparison, from someone who has used all of them:

• ACF (free / Pro, roughly USD 49 per year for one site). The industry standard. Huge ecosystem, every WordPress developer knows it, excellent field types (the Pro repeater and flexible content fields are what most custom builds lean on), stable for a decade. My default, and what I use on nearly every build.
• Meta Box. A serious alternative with a similar feature set, popular with developers who prefer configuring fields in code. Perfectly good; slightly smaller ecosystem. If a proposal names Meta Box instead of ACF, that is not a red flag.
• Native custom fields. WordPress has raw custom fields built in – a bare key-and-value box with no field types, no validation and an editor experience I would not wish on a client. Fine for a developer storing internal flags; wrong for content your team edits.
• Blocks as structure. The modern Gutenberg editor can carry structure too: custom blocks with defined attributes, block patterns, and locked templates that fix which blocks a Property entry contains. Done well, this is a legitimate structured approach and it is where WordPress is heading. Done lazily – a free-for-all block canvas on every entry – it is page soup with newer tools. Many of my builds now combine both: ACF fields for hard data (price, dates, status), blocks for flexible narrative content. I compare the two editing worlds properly in Gutenberg block themes vs classic WordPress themes.

What matters for you as the buyer is not which tool appears in the quote – it is that a deliberate structure exists at all. “We will build Property and Course post types with these fields” is a good sentence in any proposal. “You can build any page you like with the page builder” is, for repeating content, a warning.

Rescuing an unstructured site

If you already own the page soup, structure is retrofittable, and this is one of the most common project types I take on. The pattern is always the same, and knowing it helps you scope the work:

• Audit and model. We list what the site actually contains and find the repeating shapes hiding in the pages. Forty property pages become one Property post type with twelve fields; a long jumbled team page becomes a Team post type. This modelling conversation takes an hour or two and is the most valuable part of the project.
• Build the structure on staging. Post types, field groups, taxonomies and the templates that render them – built alongside the live site, disturbing nothing.
• Migrate the content. The honest part: extracting content from page-builder markup is semi-manual. Scripts get titles, images and detectable patterns across; a human checks and fills the fields the old pages never labelled. For 40-60 entries this is typically one to three days of careful work, and it is the main cost driver in a rescue quote.
• Redirect and retire. Old page URLs get 301 redirects to the new structured URLs so search rankings and bookmarks survive, then the old pages are retired.

A rescue like this usually lands between the cost of a small feature and a fraction of a full redesign – and it is often the smartest first step before a redesign, because once content is structured, the redesign itself gets dramatically cheaper. An agency I work with in Germany now sells exactly this sequence to inherited client sites: structure first, redesign second, and the combined price beats any competitor quoting a hand-rebuild.

What structure means for cost and quotes

Business owners mostly meet custom post types inside a quote, so here is how the numbers behave. Registering a post type and a taxonomy is trivial – minutes of work. The real effort sits in three places: designing the field structure (thinking work, done with you), building the editor experience (field groups, labels, validation, sensible defaults), and building the templates that render the content (the archive page, the detail page, filters, related-content blocks).

As a rough guide from my own fixed quotes at EUR 15 per hour: a simple CPT (Testimonials – a handful of fields, one display style) adds a few hours to a build. A moderate one (Team, Courses) with its own detail template and archive adds a day or so. A complex one (Properties with faceted filtering, galleries, map integration and portal feeds) is several days and is usually the heart of the project. In a typical business-site build, the full content structure accounts for maybe 15-25% of the budget – and it is the best-spent slice, because it is the part that keeps paying after launch.

Two cost warnings from the other direction. First, a quote that is suspiciously cheap usually has no structure in it – you are buying page soup, and the saving will be repaid with interest at the first redesign. Second, structure decisions are cheap to make early and expensive to make late: adding a field to a live post type is easy, but converting eighty free-form pages into a post type after launch is a migration project. This is why the structure conversation belongs in the brief, not in the change-request pile.

What to ask your developer for

You do not need to design the data model yourself – you need to trigger the conversation and recognise a good answer. Put this in your brief or first call:

• List your repeating content. “We have properties, team members and testimonials, and we add properties weekly.” That single sentence tells a good developer most of what they need.
• Ask for a structure spec. Before build starts, ask for one page listing each post type, its fields, and its taxonomies. Ten lines per type. If the developer cannot produce this, they have not thought about it.
• Ask how listing and filtering will work. “Can visitors filter courses by level and month? Which pages list what, in what order?” The answers reveal whether structure is real or decorative.
• Ask what the editing screen will look like. A good answer describes a form with named fields. A worrying answer is “you can edit everything in the page builder”.
• Ask what happens at the next redesign. The correct answer: your content stays, only the templates change. Make them say it.
• Agree who enters the content and in what format you will supply it – a spreadsheet with one column per field makes population fast and cheap.

If you are writing all this up formally, my guide on how to write a website brief has a full template – the content-structure section is the part most briefs miss, and the part developers most need.

A mini glossary for your next brief

The vocabulary, in plain language, so proposals and developer conversations stop sounding like a foreign language. Feel free to lift this table into your own notes:

With those twelve terms you can read any WordPress proposal and ask precise questions – which, in my experience, immediately raises the quality of the answers you get.

Want a WordPress site built on structure, not luck?

This is how I build every project: a content model designed around your business, ACF-powered editing your team cannot break, and templates that will survive the next redesign. I work with small businesses and agencies across Germany, the UK, the US and Australia at EUR 15 per hour or a fixed price quoted within 24 hours. See my custom WordPress development service and portfolio, or tell me what content your site holds – I reply within 24 hours, usually with the structure spec sketched out.

Frequently asked questions

What are custom post types in WordPress?

Custom post types are new kinds of content a developer adds to WordPress beyond the built-in posts and pages – for example Properties, Courses or Team members. Each gets its own admin section, URLs and templates, so repeating content stays consistent, listable and filterable.

What is ACF and why do developers use it?

ACF (Advanced Custom Fields) is the plugin most WordPress developers use to add structured fields – price, date, gallery, status – to any post type. Editors fill in a clean form and the theme places each value into the design, so content stays consistent and unbreakable.

Do custom post types cost a lot to build?

No – registering one is minutes of work. The real investment is designing the fields and building the templates around them, typically a few hours to a few days per post type. In my quotes, content structure is usually 15-25% of a build and the best-spent part of the budget.

How many items justify a custom post type?

My rule of thumb is around ten or more entries of the same shape, or any need for filtering, listing or integrations regardless of count. Four testimonials that never change are fine as an editable page section.

Can an existing messy site be converted to custom post types?

Yes – this is a common rescue project. The content is modelled, the structure is built on staging, entries are migrated (partly by script, partly by hand) and old URLs are redirected. For 40-60 entries the migration is typically one to three days of work.

Are custom post types better than a page builder?

They solve different problems. Page builders lay out one-off pages; custom post types manage repeating content. The failure mode is using a builder for forty properties – structure is the right tool there, and the two can happily coexist on one site.

Will my content survive a redesign if it uses ACF?

Yes – that is the main payoff. Content stored in fields is independent of the design, so a redesign replaces the templates while every entry carries over untouched, typically cutting redesign cost dramatically.