With classic themes, any content that wasn’t a post or a page was a custom post type.

You then combined this custom post type with meta fields to store data that didn’t fit within the available post fields, such as post title or post content.

Testimonials, team members, and FAQs are typical examples of pages that developers built this way.

However, using a post type did not always make sense. Instead, it was a workaround for WordPress’s lack of styling capabilities.

This not only leads to poor data design but also to slow websites.

But with Full-Site Editing, WordPress doesn’t face these styling challenges anymore. We have other ways to style content and keep it in sync across pages: patterns.

But now that we no longer default to post types for everything, should we default to patterns?

No. Instead, you need to choose an implementation that fits the requirements.

But how do you decide which option to choose? That’s what we’ll dive into in this article:

1. We’ll get an overview of pattern and post type capabilities.
2. We’ll discover the key difference between post types and patterns.
3. We’ll examine three common scenarios: testimonials, team, and FAQs. For each, we’ll discuss which implementation to choose.

Understanding patterns and post types in WordPress

While patterns and post types are ways to manage content, they are very different.

Looking at this table, we see that there’s a a key difference between a pattern and a post type:

• A pattern is a single unit of blocks with fixed content and design properties.

• A post type is a set of properties without specific content or design.

So when having to choose between the two, there is one main question you need to ask:

Should the content always look the same? Or do you want different displays depending on the context?

This sounds abstract, so let’s look at examples.

Should testimonials be patterns or post types?

The Smart Passive Income website features testimonials on its pricing page:

Because these testimonials use two different layouts, this is a clear case for using a post type. However, this website does not use a post type.

Why?

Because there are only a few testimonials, manually managing this as content is more efficient than using a post type.

Entering the testimonials as a pattern is as fast as entering them with a post type. But styling the pattern is a lot easier. You’re dealing with basic blocks like paragraphs and an image.

You can use the title and content blocks with a post type. However, the website needs additional work to display the user name, avatar, and other information.

Let’s have a look at another example:

This is but one row of an entire set of 12 testimonials. That’s still a manageable number.

But the Read All Reviews button makes this a clear case for a post type. While you could create a page and add reviews manually, this would be cumbersome.

With a post type, you get an archive page by default. That’s a lot easier to manage. Having a post type also offers the possibility to create other review-related displays:

In addition having a post type offers the possibility to collect testimonials directly from users.

For example, you could have a website form where users can submit reviews. The form would then store the user reviews as a post type.

Team pages: pattern or post type?

Most team pages are only a set of pictures with names and contact information. For this type of page, I’d always recommend a pattern.

But what if you need more information for each team member? You could extend on the pattern with a few sentences for each team member. But the bigger the team, and the more information you want for each member, the less patterns become a good fit.

In this case you’d want to switch to having a detail page per team member. So a page with all team members, and then individual pages with more details. An archive and a single view: classic post type territory.

But there are other options. The Human Made website uses the approach outlined above:

But this data is not stored in a post type. Instead this data is imported from the human ressources software that the agency uses. Each employee is imported as a user.

The team page shows these users throw a custom block. And the detail page is a normal WordPress author page.

This makes sense because Human Made encourages employees to publish content on the company blog. And rather than having duplicate data between a team members post type and WordPress users, uniting them makes sense.

Should FAQ questions be post types?

The third scenario are frequently asked questions. Here it depends on whether you need a single set of questions, or whether you need to assemble questions into an FAQ section depending on context.

Let’s say you sell online courses. And every course is sold and delivered through the same platform. In that case you just need to have the same FAQ section on every sales page. And a synced pattern gives you this.

But let’s take a different e-commerce example. You sell through the same platform, but you sell different types of products.

Some of the frequently asked questions will be the same, for example around payment. But others are dependent on the type of product.

In this case, it’s preferable to use a custom post type to store the question. Coupled with a custom taxonomy with a term for each product type.

This way you can ensure that only relevant content is part of every FAQ section. While having one central way to manage questions.

There is a middle way as well. Rather than having the entire FAQ section as a pattern, one could also have the individual questions as patterns. That way the shared questions can sync between pages, while having the potential to add specific questions on between.

So as with testimonials, it comes down to the number of questions you have to manage.

So what’s the verdict?

Should you use a pattern or a post type? As so often, the answer is: it depends.

What I recommend is that you have a look at these examples, and choose one approach. In my experience, you’ll be right more often than not.

But as we have seen it takes a big of digging into the specifics in order to make the right decision. So don’t attach yourself to a solution before you haven’t yet had a chance to do discovery.

However what you should avoid is using both. Having the same type of content stored in two different ways is confusing, and messy.

So if you chose patterns initially, but need more flexibility, then migrate all the content to a post type.

Now given this, why not default to always using post types? Well because post types take more resources: more queries, more templates, and more interface elements.

And you should always try and strive for simplicity and clarity.