Most website problems that show up a year after launch are not design problems. They are structure problems. Phone numbers typed into twelve places. A team page built by hand, where adding a person means editing a layout. A portfolio made of ordinary pages, impossible to filter or reuse.
The fix is to decide, early, what kinds of content your site has and where each piece of information should live. WordPress gives you the tools: custom post types for repeating content, fields for the details, and options pages for facts that belong to the whole site. This guide shows how to use them well.
Start by listing your content types
Before you open any plugin, grab a sheet of paper and list everything your site presents that comes in sets. Common examples are services, team members, case studies, locations, testimonials, events, and legal documents.
For each one, ask two questions: will there be more than a few of them, and will they be shown in more than one place? If the answer to both is yes, it probably deserves its own content type.
Posts, pages, or a custom post type?
| Type | Best for | Example |
|---|---|---|
| Pages | One-off, standalone content | About, Contact, Home |
| Posts | Dated, chronological articles | Blog, news |
| Custom post type | Repeating items with their own structure | Services, team, projects, legal pages |
Why not just use pages?
Pages work for a handful of items. At twenty, they become hard to manage: no consistent structure, no archive, and no easy way to display them as a filterable grid. A custom post type gives every item the same fields and lets you build one template that renders them all.
Add fields for the details
A post type has a title and an editor, which is often not enough. A team member needs a role, a photo, and a short biography. A project needs a client name, a year, a result, and a gallery. These details live in custom fields, also called meta fields.
Choosing field types sensibly
Use the narrowest field type that fits: a date field for dates, an image field for images, a select for a fixed list of choices, and a plain text field for short answers. Avoid dumping structured information into the main editor, because you cannot reuse it elsewhere.
Keep the editor for real content
Leave the main editor for content that is actually prose, such as the body of a case study or a legal policy. Put short, structured facts in fields, and display them with a template.
Use an options page for site-wide facts
Some information belongs to the whole site rather than to any single entry: the company name, contact email, address, opening hours, social links, and so on. An options page gives you a single settings screen for them.
If a fact appears on more than one page, store it once and display it everywhere.
The payoff is real. When the phone number changes, you update one field and every page, header, footer, and policy updates with it. It also reduces errors, because there is only one version to keep correct. On a site with a set of legal pages, for example, the company name, address, and contact details can come from a single options page, so a new site needs only one form filled in.
What to put there, and what to leave out
- Good candidates: business name, email, phone, address, opening hours, social profile links, default call-to-action text
- Poor candidates: page-specific copy, anything that varies by entry, large blocks of formatted text
Plan the content model in five steps
- List the content types your site needs.
- Sketch the fields each type requires, and decide which are required.
- Decide what is site-wide and belongs on an options page.
- Plan the templates: a single layout for each type, and an archive or listing where useful.
- Choose names carefully. Use clear, consistent names for types and fields, because they are hard to change later.
An example: a services section
Suppose a studio offers eight services. As a custom post type, each service has a title, an excerpt for cards, an editor for the long description, and a few fields: an icon, a starting price, a typical timeline, and a short list of deliverables. One single template shows the full page for any service. One archive template shows them as a grid. A query on the homepage pulls the top three. Add a ninth service and it appears everywhere automatically, with no layout work at all.
Tools that help
Several plugins can do this work. We often use JetEngine, which handles custom post types, meta boxes, taxonomies, options pages, and query builders in one place, and pairs well with Bricks Builder. Whatever you choose, prefer tools that store data in standard WordPress structures, so your content is not locked into a single plugin. We explain why the builder side matters in why we build with Bricks Builder.
Common pitfalls
Over-engineering
Not every list needs its own post type. If you will only ever have four items, a section on a page may be enough. Add structure where it saves time, not where it only looks tidy.
Renaming too late
Changing a field’s name after content exists can break templates and queries. Settle names early, and document them.
Forgetting the archive and permalinks
A post type with no archive template, or with unclear URLs, leaves visitors and search engines without a clear path to your content. Decide on readable URL slugs, build an archive template, and remember to refresh permalinks if a new section returns a 404.
Ignoring editors
The people who will maintain the site matter as much as the people who visit it. Use clear field labels, short instructions, and sensible defaults so a new team member can add an entry without help.
A quick test
Imagine your client wants to add a new team member next Monday. If the task is ‘fill in a form with five fields and click publish’, your structure is working. If it is ‘duplicate a page, edit the layout, and update the menu’, it is time to rethink.