Most web projects start by thinking in pages. But the sites that are easiest to manage — and best understood by search engines — are built around components. Here's why that distinction matters.
I’m a record collector. I collect records, which I think is very cool but others might look at in the same way as if I said “I collect phone books” or “I collect Sears catalogs” or “I have a PhD in Microfiche Archival Studies.” But I am not here to defend my record collection; I am here to talk about web content.
One of the longstanding arguments for the vinyl experience (and, beyond that, the argument for listening to any album front-to-back as its own medium) is that the album best represents the artist’s intention — that these albums were recorded and tracked in a specific order in order to best present an artistic vision. That the whole was more important than the parts.
This idea held up through the decades — the 70s especially were ripe with album-oriented artists, who specialized in large sweeping statements over individual elements. But while there are still some brave artists who stay true to the idea of an album, the reality of the music landscape is that it’s the individual songs that people are here for. The core statement is not nine songs of varying quality, but the one distilled perfect moment.
And while this is not necessarily a challenge to today’s streaming landscape (the 60s were just as single-oriented as now) it is heightened by the ease in which streaming services allows us not only to listen to whatever we want, but also — through the power of playlists — to essentially create our own albums from these different elements. To create our own new thing based on the modular elements at hand.
Structured content and modular content models.
For most firms, the days of highly-specialized, single-use page templates is a thing of the past. While there’s still a need in some cases to develop highly-structured, predictable content types (product pages, event listings), most user-facing promotional and information content is build using a mix of structured content and modular content models. But with structured content playing an increasingly important role in generative search and AI-driven discovery, it’s a good time to talk about what “thinking in components” actually means — and, more importantly, why it matters for the people guiding a web project, not just the developers building it.
At Blend, component-based content modeling is an idea we bring up early in discovery. We talk about content types, reusable blocks, and modular design, and the teams we’re working with nod along — because it makes sense in the abstract. But in our experience, the idea doesn’t fully land until wireframes start taking shape and people can see how the pieces fit together.
That gap between hearing about it and truly getting it is worth closing sooner, because the decisions made early in a project — how your content is structured, how flexible it is, how well it travels — shape everything that comes after.
The difference between page-based and component-based content modeling.
Most people come into a web project thinking in pages. “We need a homepage, an about page, a services page, and a contact page.” That’s completely natural — it’s how we experience websites as visitors. We navigate from page to page, so it makes sense to plan a site that way.
But a page is not just a page. A page, when you pull it apart, is really just an assembly of smaller pieces. A hero section at the top. A set of content cards in the middle. A call to action near the bottom. A sidebar with related links. Those pieces are the components — and a component-based content model means designing, building, and managing those pieces independently, then combining them to create pages.
We often compare web projects to building a house, and the analogy works here too. You typically don’t choose a completely different style of door for every room. You find a door that works well — that fits the aesthetic, functions properly, and meets code — and then you install it where it’s needed. Some rooms might get a different handle or a coat of paint, but the core design is consistent. Components work the same way. You build a content card that’s flexible enough to handle different contexts, and you use it wherever a content card is needed — rather than building a brand-new content card for every page that needs one.
Why component-based modeling matters more now.
Content modeling has always mattered, but two forces are making it more important to get right.
- Generative search and GEO are raising the stakes for structured content. As we’ve written about in our exploration of schemaand the shift from SEO to GEO, generative search tools rely on context. They need to understand what your content is, not just where it lives. And while it’s not the only factor in being found via AI search, when your content is broken into well-defined, structured components — each with clear fields, metadata, and schema — it’s far easier to give AI tools the context they need to surface your content accurately. Monolithic page templates, where content is poured into a single unstructured field, make that job significantly harder. The short version: the better your content is structured at the component level, the better machines can understand and reference it.
- Multi-channel delivery depends on content that can stand on its own. Not every organization needs to publish content to multiple platforms — and if your website is your primary channel, you don’t need to architect your content as if it’s destined for a mobile app and a digital kiosk. But if multi-channel delivery is on your roadmap, the time to plan for it is during the initial build, not after launch.
This idea has a history. The concept of COPE — Create Once, Publish Everywhere — has been floating around content strategy circles since 2009, popularized by NPR’s approach to managing content across web, radio, and mobile. The core principle is straightforward: if your content is well-structured and independent of any single layout, it can travel to wherever it’s needed without being re-created for each destination. Component-based modeling is what makes COPE possible. Content locked inside a page template can only live on that page. Content modeled as a standalone component — with its own fields, its own structure, its own meaning — can go anywhere.
Not every site needs this. But building with components means you’re not closing the door on it, either.
Common problems with page-based content models.
When teams think in pages rather than components, a few problems tend to show up — sometimes immediately, sometimes months or years down the road.
- One-off templates pile up and spiral out of control. Every new request becomes a new page type. “We need a landing page for this campaign” becomes a new template. “We need a slightly different layout for this department” becomes another. Over time, the site accumulates a collection of templates that are 90% the same but just different enough to require separate maintenance, which means what started as a quick fix has become a long-term burden.
- Content cannot be reused. When a piece of content is locked into a specific page layout, it can’t be reused anywhere else. A testimonial that only exists on the about page can’t show up on a service page or in an email campaign without someone copying and pasting it — or worse, rewriting it from scratch in a new location, effectively jailing it on a page with no hope of parole.
- Duplicate entry leads to inconsistency. The natural consequence of immobile content is akin to genetic drift and DNA mutations. Editors enter the same content in multiple places, and over time those entries fall out of sync. A team member’s bio gets updated on one page but not the other three. A service description changes in one location but stays outdated everywhere else. The more places the same information lives, the harder it is to keep it all accurate, and hopefully you have not mutated the content with an errant typo or misinformation!
- Site maintenance becomes more expensive. Every unique page type adds weight — in design, in development, and in editorial workload. The more one-off templates your site carries, the more expensive it is to update, redesign, or extend. Meanwhile, a component-based model keeps that weight manageable because changes to a component ripple across every page that uses it.
How the shift from pages to components happens during a project.
Let’s use Blend’s process as an example. In a typical project, the shift from page-based thinking to component thinking happens gradually — and there’s a specific moment where it tends to click.
Discovery focuses on goals and content needs. We start identifying patterns early: what kinds of content show up in multiple places? What information is shared across sections of the site? What elements feel like they belong together? This is conceptual work — we’re mapping out the shape of the site, not the specifics.
Wireframing and content architecture are where the concept becomes concrete. This is usually where clients start to see it: a “services page” isn’t really a unique template — it’s a hero block at the top, followed by a row of content cards, a testimonial component, and a call-to-action strip at the bottom. We can begin to set rules and expectations for the elements: the hero block might need multiple variations, the content cards are pulling meta content from source pages, and the call-to-action strip becomes a part of the footer, showing up on every page but maintained in one single spot in the CMS.
The conversation shifts from “what does this page look like?” to “what pieces do we need, and how do they combine?” That’s the moment when the teams we work with understand, usually — when a page stops looking like a rigid album trackless and starts looking like a personal curated playlist. It moves from abstract to practical — from something they heard about in a meeting to something they can see working.
How component-based modeling changes the editorial experience.
Component thinking doesn’t just affect how a site is built — it changes how editors work with the site every day, and this is worth understanding before the project begins.
Editors gain a defined set of building blocks rather than dozens of unique page types to manage. Content entered once — a staff bio, a service description, a testimonial — can appear in multiple contexts without re-entry. When something changes, it changes everywhere, because there’s a single source of truth. Adding a new page doesn’t always require a new template or a call to the development team — it’s often a new arrangement of existing components, which gives editorial teams more independence in their day-to-day work.
The tradeoff is that component-based editing requires a different mindset. Instead of filling out a single form that maps directly to a single page, editors are building with a system. They’re selecting components, arranging them, and thinking about how individual pieces contribute to a larger whole. There’s a learning curve — we won’t pretend otherwise. But in our experience, editors who make that adjustment find their work is faster, more consistent, and far less repetitive than it was before. The system works for them instead of creating busywork.
Building a content model that works now and adapts later.
Thinking in components isn’t a technical preference or a developer convenience — it’s a strategic decision that affects your content quality, your editorial efficiency, and how well your site communicates with both people and machines. It takes a bit of adjustment, especially early in a project when the instinct is to think in pages. But it leads to a site that’s easier to maintain, easier to extend, and better positioned for how the web is changing — from generative search to multi-channel delivery and beyond.
There will always be a place for the album — for the tightly curated, intentionally sequenced experience. Some pages on your site will be exactly that. But the best content models give you both: the ability to build something cohesive and the flexibility to rearrange, reuse, and remix when the situation calls for it. That’s the playlist, and it’s a much more practical way to build what you need.
If you’re heading into a web project and wondering how content modeling shapes everything downstream — from how your editors work to how search engines understand your site — that’s a conversation worth having early. We’re always happy to have it.