The question every planner meets when shaping a CMS is “should this be a page, or does it need its own type?” The short answer: pages are enough most of the time, and the point where they stop working is quite distinct. Recognising that point is what this part is about.
Where pages hold up perfectly well
A page is the simplest container WordPress offers. It has a title and a body, it can nest, and it can go in a menu. For screens that are one of a kind and unlike each other — about, terms, contact — a page is the right answer. There is nothing to model.
Trouble starts when several things of the same shape appear. Twelve job listings, thirty branch locations, a hundred product specs: building them as pages works at first. But the moment someone asks “show me only the London branches” or “sort these by most recently added”, pages give you no way to do it. They were never meant to be handled as a list.
Three signals that justify a type
A custom post type earns its place on three conditions, and the decision is clearest when all three hold at once.
Repetition does not mean “there are many”. It means they fill the same slots. Thirty branches that each carry an address, a phone number and opening hours are a structure; thirty items that each tell a different story are simply thirty pages. Judge this by shape, never by count.
The listing is the most practical signal of all. If the answer to “do these need to appear together on one screen?” is yes, it is almost always a type. Listings bring sorting and filtering with them, and you can only sort or filter on values, never on prose.
Longevity pays off later. When the design changes, anything hand-laid inside a page body has to be rebuilt from scratch, while values sitting in fields are simply picked up by the new template. On a site meant to last three years, this is the difference that matters most.
What a type brings with it
Declaring a custom post type hands you listings, ordering, search, an admin screen and a REST endpoint for free. Those are days of work that WordPress already did, and that is the real gain.
The cost is equally clear. You add a URL space, you have to decide whether those URLs belong in search, and your editors get one more menu item. This site keeps its free tools in a type of their own: the decision produced the free tools listing and its type archives automatically, and it also produced the job of checking that those addresses actually resolve. A type is not one feature — it is a set of addresses.
More on the criteria behind structural decisions lives in the Themes & plugins archive.
Next part
Once you have decided on a type, the next question is what goes inside it. The next part covers field design, and it comes down to one test: can an editor actually fill this in?