Stop Designing Pages. It's Time for an Entity-Based Schema.

Rethinking the Page-Based Workflow

For many web projects, the design and development process revolves around a familiar unit of work: the page. We design a homepage, then a product page, then a contact page. This common approach can lead to building brittle, context-specific components that are difficult to reuse and maintain. An alternative model to consider is an architecture for presentation based on an entity-based design schema.

An entity-based approach treats your content not as blobs of text and images on a static page, but as structured, reusable objects. An 'Author', a 'Product', an 'Event'—these are your core entities. You define their data structure once, then design a system of components to present them in any context. This isn't just a semantic difference; it's a fundamental shift that can build resilience, consistency, and scalability into your theme design from day one.

What Most Guides Skip: An Entity Is Not Just a Component

Many developers hear “reusable” and immediately think of component libraries like those in React or Vue, or methodologies like Atomic Design. While related, an entity schema is a layer above that. A component is a piece of UI—a button, a card, a header. An entity is a structured data model that defines a piece of content.

Here’s the critical distinction:

• Component: A `ProfileCard` component displays a picture, a name, and a title. It knows nothing about the data it holds.
• Entity: An `Author` entity defines the data fields: `firstName` (text), `lastName` (text), `profileImage` (image asset), `biography` (rich text).

The `ProfileCard` component is then designed to render an `Author` entity. But you might also create a `ProfileAvatar` component that only renders the `profileImage` and `firstName`. Both components pull from the same single source of truth—the `Author` entity. This decouples your data structure from its presentation, which is a key principle in many modern, flexible web architectures.

A Common Scenario: Building a 'Blog Post Template'

A classic workflow illustrates the problem. A designer creates a beautiful mockup of a single blog post. A developer then builds a `single-post.php` or equivalent template, hardcoding the layout for the title, author byline, and featured image. The problem arises when the marketing team wants to display the three most recent posts on the homepage. Now the developer has to create a new query and build a separate, slightly different-looking 'post card' component, often duplicating logic and styles.

An entity-based approach would handle this differently by defining a `Post` entity schema first. It has a `title`, `author` (a relationship to the `Author` entity), `publishDate`, `featuredImage`, and `bodyContent`. From there, you design presentation components:

• `PostFull`: The component for the main article view.
• `PostCard`: A smaller component for archive and list views.
• `PostFeatured`: A large, visually rich component for the homepage.

Now, when a new requirement appears—like an 'Author's Other Posts' section at the bottom of an article—the task can be more straightforward. You can query for posts by the current author and render them using the existing `PostCard` component. The goal is to compose a view from your system of entities and components rather than modifying a rigid template.

A Common Objection: "Is This Overkill for a Simple Site?"

A common objection to this approach is that it introduces unnecessary complexity for simple websites. If you're just building a five-page site for a local business, defining formal data schemas can feel like over-engineering. While a simple static site might not see the immediate benefit, it's worth considering how content needs can evolve. The client who wanted a simple 'Services' page may later want to feature a specific service on the homepage, then list them in the footer, then create case studies related to each service. In a page-based model, each of these requests often requires custom development and can introduce inconsistency. In an entity-based model, you could create new presentation views for the `Service` entity you defined at the start. This approach is about building for the website's potential future, not just its launch day requirements.

How to Implement an Entity-First Approach

To make this concrete, you can use tools that prioritize schema. Your choice can fundamentally impact your workflow, and a schema-first headless CMS is one option for new projects.

For example, a platform like Contentful requires you to build your 'Content Model' (your entity schema) before you create content. This workflow encourages a data-first mindset across the team, because you cannot create content until you have defined its structure. Without a disciplined, schema-first step in a headless architecture, the resulting API can become inconsistent and difficult to manage, which undermines some of the benefits of decoupling your content.

For teams working within a monolithic CMS, WordPress with a plugin like Advanced Custom Fields (ACF) Pro can be used to create entity-like structures. ACF's features allow you to build out custom fields and define relationships between post types, emulating an entity model. The main distinction is that Contentful is schema-native and API-first, making it a natural fit for projects that need to serve content to multiple platforms (web, mobile apps). In contrast, WordPress with ACF bolts this functionality onto a page-native system, which may be more familiar for many developers but requires discipline to maintain a rigorous schema design.

For a genuinely simple, single-purpose landing page or a personal blog with a single content type and no plans for expansion, a straightforward static site generator could be a more efficient choice.

The Potential Payoff: Your Website as an Application

Adopting an entity-based design schema can do more than clean up your code; it can change what your website is capable of. When your content is structured as discrete entities, you can more easily filter, relate, and syndicate it. You can build a directory of 'Team Members' and then, on a 'Service' page, dynamically display only the team members who specialize in that service. You can expose your 'Events' entity to an API for a mobile app. This approach shifts the focus from managing pages to managing a content ecosystem, opening up possibilities for building more dynamic and scalable web experiences.