Structured content for modern websites

A university website, for example, might contain:

• Courses
• Subjects
• Departments
• Campuses
• Staff
• Events
• Facilities
• News and guidance

A course is not simply a page. It is a type of content with information such as its title, qualification, duration, entry requirements, subject area and associated department.

Once that information is structured, the website can use it to populate subject listings, search results, related content and departmental pages without editors recreating the same information each time.

The same principle applies to smaller websites, particularly where information needs to appear in several places or be updated regularly.

Structured content provides a foundation for:

• Consistency, because similar information follows the same model
• Reuse, because information can appear in several places without being recreated
• Maintenance, because updates can be made at their source
• Navigation and discovery, because relationships between content are understood
• Integration, because information can be exchanged with other systems more predictably
• Search and AI, because machines have more context about what information represents

This doesn’t mean every piece of website content needs to be broken into dozens of fields. Good structure should make content easier to manage rather than creating unnecessary complexity.

The challenge is finding the right level of structure for the information and the organisation using it.

Traditional website planning often starts with pages:

But the information itself may have much richer relationships:

Those relationships can be used in many different ways across the website.

For example, a case study might be associated with particular services and sectors. The website could then automatically show that case study wherever those relationships are relevant.

The case study hasn’t been copied. The website understands how the information is connected.

This is one reason we increasingly think about websites as digital platforms rather than collections of individual pages. The page is still important to the visitor, but it can be assembled from structured information underneath.

It considers questions such as:

• What types of content do we have?
• What information belongs to each type?
• How should different types of content relate to one another?
• Which information should be reusable?
• Where should information be managed?
• How will people and systems find it?

These decisions affect much more than the CMS, influencing navigation, search, filtering, integrations, editorial workflows and the features a website can support later.

A useful content architecture should reflect the organisation and its information rather than simply the pages included in the current website design.

For example, an organisation might classify its case studies by:

An article might instead be associated with:

These classifications make it possible to group, filter and retrieve information consistently.

The important part is that taxonomy is planned rather than allowed to develop accidentally. If editors can create slightly different versions of the same category — Artificial Intelligence, AI and AI & Automation, for example — the structure quickly becomes less useful.

A good taxonomy should be understandable to the people maintaining the website as well as the people using it.

The term can sound much more complicated than the underlying idea.

Imagine a website containing people, services, projects and organisations.

Rather than treating them as independent records, the website might understand that:

Those relationships create useful context.

They can support related content, better search experiences and more sophisticated digital features. They can also help external systems understand the organisation and the entities it talks about.

You don’t necessarily need to describe this as an “ontology” inside the CMS. What matters is deliberately modelling meaningful relationships between information.

A case study might contain:

• Client
• Project title
• Summary
• Services
• Sector
• Project challenges
• Outcomes
• Related insights

A person might contain:

• Name
• Role
• Biography
• Expertise
• Associated projects

The model gives editors a consistent way to create information while giving developers predictable data to work with.

It also separates the information from a particular page layout.

That means the same content can potentially be used on a webpage, within search results, through an API or elsewhere in the website without maintaining several versions.

Consider a team member’s job title. If it has been typed manually onto their profile, a project page, an office page and several service pages, changing that person’s role means finding and updating every occurrence.

With structured content, those pages can reference the same information:

This isn’t simply about saving editors time. It reduces the chance of contradictory or outdated information appearing across the website.

Not everything should be reusable, however. Trying to turn every sentence into a reusable component can make editing unnecessarily complicated.

The useful question is:

Does this information have its own meaning, and is there a realistic reason we might need it somewhere else?

If the answer is yes, giving it structure may be worthwhile.

The same structure can support:

• Filtering
• Related content
• Recommendations
• Contextual navigation
• Automated listings
• Personalised experiences

This is closely connected to information architecture. Content structure describes the information and its relationships; information architecture determines how that information is organised and presented so people can find and understand it.

Structured content can make it easier to maintain meaningful relationships between entities and to generate consistent metadata and structured data. For search engines and AI systems to make use of that information, it also needs to be available to them through the website, its markup or another suitable source.

It is important not to confuse structured content with structured data.

Structured content is how information is modelled and managed within your website or content systems. Structured data, such as Schema.org markup, is one way of describing information to external systems in a machine-readable format.

Good internal content structure can make good structured data considerably easier to implement and maintain.

Different content may need different publishing processes.

A news article might only require an author and editor, while regulated or sensitive information could require several stages of review and approval.

A structured workflow could look something like:

The CMS can support these processes by defining responsibilities, permissions, statuses and review dates.

Instead of relying on informal processes outside the website, publishing governance can become part of how the platform works.

Editors shouldn’t need to understand the technical architecture behind the system. They should simply find that common publishing tasks make sense.

This is something we consider when designing custom WordPress platforms. Rather than starting with a collection of generic page-building tools, the CMS can be designed around the organisation’s actual content, relationships and editorial processes.

From there, identify the main content types and what each one needs to contain. A course, service or case study may need its own fields, classifications and relationships, while more individual editorial content might be better managed with greater flexibility.

Test those decisions against real publishing tasks before committing to a complete model. Can an editor add a new service without duplicating information? Can they update a person’s role in one place? Can visitors find relevant content through the categories and relationships you’ve defined?

It is usually better to start with a few important content types, involve the people who maintain them and refine the structure as you learn. The aim is not to model every possible requirement upfront, but to establish a foundation that makes everyday content management easier.

When information is modelled consistently and separated from individual layouts, it can often be reused in ways that weren’t considered when the website was first built.

For example, a new search interface might use existing taxonomy, while another digital service could access the same information through an API.

The value is not in trying to predict every future requirement. It is in avoiding unnecessary dependencies on how the website happens to work today.