When do we need custom post types instead of pages and posts?

When a type of content has its own attributes, its own template, or its own audience. Reports, events, courses and use cases behave nothing like a page, and forcing them into pages means you cannot filter them, cross-reference them, or give editors a consistent screen to fill in. The opposite failure is just as common: a post type created for something that was only ever a category. If the only real difference is the label, you want a taxonomy.

Why define content types in code instead of using a plugin like CPT UI?

Because structure that lives only in the database is structure nobody can review and nobody can roll back. CPT UI and similar visual tools are fine for prototyping, but they are not versioned, so they are hard to maintain and impossible to deploy predictably. Registering post types by hand gives maximum control at the cost of a lot of repetitive code. Extended CPTs, our default, gives clear syntax plus admin ordering, labels and visibility control, in versioned files. Fields follow the same logic. We compose ACF field groups in code, so a structural change arrives as a pull request, not an undocumented click in production.

Do we need ACF Pro, and when is a custom field the wrong answer?

ACF Pro is our standard for structured, client-editable data, composed in code with ACF Composer on a Sage stack or ACF Builder elsewhere. Meta Box is a credible alternative with a smaller ecosystem. A field is the wrong answer when what you are storing is really a classification. If you would ever want to list everything sharing that value, filter by it, or give it an archive, it is a taxonomy. Fields used as pseudo-taxonomies make a model hard to query later.

How do you handle filtering and search across thousands of items?

FacetWP is the default. It works natively with ACF fields and taxonomies, runs on AJAX without extra work, and covers filters, search, sorting and pagination as one system. For high-volume or unusual cases we drop to WP_Query, the REST API or endpoints tuned to the specific query. What teams underestimate: on a large library, asynchronous filtering and pagination have to be designed in at the start, because adding them once the templates exist means rewriting them. Our advanced search capability goes deeper.

How many content types is too many?

There is no number, but there is a test: each type has to earn its own editing screen and its own template. Commvault's model carries Use Cases and a Resource Center. Everest Group's carries Reports and Analysts, with more than 5,000 reports and role-based access on a single WordPress instance. What goes wrong is predictable: content types created without a clear purpose, relationships skipped between content that needs them, navigation hardcoded against pages instead of built from structure, and implementation started before the content was modeled.

How do we know the model is right before you build it?

Because the definition stage produces something you can review: every content type, a map of their attributes and relationships, and the taxonomy assignments, documented visually rather than buried in a ticket. Then QA checks the model against reality. Required and conditional fields behave correctly, editing and preview work from the admin, and filters load fast enough at your real data volumes. The inventory that feeds all of this comes out of the discovery phase.

Content Architecture

Enterprise WordPress content architecture, modeled before it is built

Custom post types, taxonomies and editable fields defined in versioned code, so your editors know where content belongs and your developers are not patching structure two years from now.

Home
Capabilities
Content Architecture

What we model

Structure decided in discovery, then written into the repository

When everything is a page or a post, content gets hard to organize, impossible to cross-reference, and prone to inconsistency. Seven decisions prevent that.

An inventory before an implementation

Every content type gets listed, its attributes mapped, its relationships drawn, and its taxonomies assigned to the types that use them. Fields your team edits are separated from fields the system calculates.

Content types defined in versioned code

We register post types and taxonomies with Extended CPTs in versioned files, never a plugin UI. Structure moves through environments with your releases and is reviewable like any other code.

Taxonomies that carry real structure

Taxonomies drive navigation, filtering and cross-referencing between types. When a classification helps your team but means nothing to visitors, we register it as non-public, so internal structure never reaches your URLs or sitemap.

Fields grouped for the people who fill them

ACF Pro is the standard, composed in code with ACF Composer on a Sage stack and ACF Builder elsewhere. Groups are organized by logical unit with tabs, repeaters and conditional logic, and documented.

Who can edit what, settled with the model

Access belongs to the structure, not to a later ticket. Each content type declares which roles can create and edit it, and we validate those capabilities, along with export and import, before the model reaches your editors.

Relationships modeled, not improvised

News to events, resources to use cases, tags shared across a course catalog: connections are designed alongside the types. We use relational fields sparingly, and never a field where a taxonomy is the right answer.

Filtering that survives volume

To list and filter thousands of items we implement FacetWP, native to ACF and taxonomies and AJAX by default. Where performance demands it, WP_Query, the REST API or purpose-built endpoints, with async pagination designed in from the start.

The editing layer

Structure is half of it. Editors meet the model through blocks.

A content model your team cannot operate is just a schema. The 40Q Atomic Block System is how the structure becomes something marketing can publish with.

A block library, not a page builder

Twenty to forty blocks, approved up front and built around your content types, with Tailwind as the CSS framework. Page builders hand editors everything and return inconsistency and slow pages.

Design tokens shared by Figma and code

Colors, type scales and spacing exist as tokens, and theme.json tracks the Figma design system instead of drifting from it. Spacing and style controls are exposed with explicit limits, so editors get real choices inside a boundary they cannot break.

Patterns, documentation and training

Page patterns and templates give marketing a starting point instead of a blank canvas. Every block is tested in isolation, checked for keyboard navigation and screen reader behavior, and handed over with written guides and recorded walkthroughs.