I’ve inherited more websites than I can count. Some were beautiful, fast, feature-packed, and ranked well. Six months later, they all seemed to arrive at roughly the same place: declining traffic, fewer leads, mounting maintenance costs, and a growing hesitation to change anything.

Routine updates became staging exercises. Adding what should have been a simple feature meant testing half a dozen plugins. Every improvement carried the possibility of breaking something seemingly unrelated.

The irony is that most of these sites weren’t built poorly. Many were assembled using what most agencies would have called best practices at the time.

They didn’t fail overnight. They simply stopped evolving.

Eventually, that led me to a different question—not “Which CMS is best?” but:

Why do some platforms become increasingly difficult to maintain while others quietly disappear into the background?

I don’t think the answer has much to do with features. I think it has everything to do with something I rarely see discussed: architectural cohesion.

We’ve become very good at measuring the wrong things

Search for “best CMS” and you’ll find the same comparisons repeated over and over:

• Number of plugins
• Number of themes
• SEO features
• Ecommerce support
• Market share
• Page-speed benchmarks

None of those are bad metrics. They’re simply answering a different question. Almost all of them describe how a platform behaves on launch day.

Very few describe what that same platform looks like after five years of client requests, framework updates, plugin replacements, security patches, staff turnover, and the inevitable: “Can we just add one more thing?”

That’s where architecture begins to matter—or, more accurately, where architecture stops hiding.

Every architectural decision is a maintenance decision

The more systems I’ve inherited, the more convinced I’ve become that architecture determines maintenance. All websites and software require upkeep. The revealing question is when the cost arrives.

• Sometimes it appears during development, when complexity surfaces earlier than expected.
• Sometimes it arrives years later, when a dependency is abandoned or no longer supported.
• Sometimes it appears in the most revealing moment of all: when a feature that should have been simple turns out not to be.

The industry spends a remarkable amount of time celebrating what software makes possible and far less time discussing what those possibilities require in return. We’ve become very good at comparing capabilities while becoming far less comfortable comparing consequences.

Feature lists are easy to market. Maintenance isn’t.

A thought experiment

Imagine hiring a contractor to remodel your kitchen.

One company manages the cabinets, electrical, plumbing, flooring, painting, and countertops. Different specialists, but they’re working from the same plans under the same project manager.

Now imagine hiring twelve independent contractors. Each chooses their own schedule, materials, standards, and warranty.

Individually, they may all be exceptional. Collectively, you’ve multiplied the number of places where communication can fail.

Software isn’t much different. Every dependency introduces another boundary:

• Another update schedule
• Another set of assumptions
• Another opportunity for drift

None of that is inherently bad. Complex systems solve complex problems. The question isn’t whether complexity exists; it’s whether the architecture knows where complexity belongs.

Most architectural problems don’t begin as bad decisions. They begin as reasonable decisions made in isolation. Over time, those decisions accumulate, priorities shift, teams change, and the architecture quietly drifts away from the assumptions it was built upon.

Cohesion isn’t about simplicity

This is where the conversation often drifts off course.

Architectural cohesion isn’t about having fewer features, avoiding plugins, or proving one platform is objectively better than another. It’s simply a different lens for evaluating software.

Instead of asking what a platform can do, ask how many independent systems are required before it feels complete.

If every project immediately reaches for separate solutions to handle forms, redirects, structured data, image optimization, caching, backups, SMTP, analytics, accessibility, and security, we’re no longer evaluating a product. We’re evaluating an ecosystem.

There’s nothing inherently wrong with that. Products accumulate features; ecosystems accumulate relationships.

Those are very different kinds of complexity.

Popularity isn’t architecture

Popularity is often mistaken for architectural quality. The two have very little to do with one another.

A platform can become dominant because it’s approachable, affordable, familiar, or simply arrived at the right moment in history. None of those qualities predicts how gracefully it responds to change.

Architectural cohesion isn’t a measure of popularity. It’s an observation about how responsibilities are distributed, how boundaries are managed, and how systems continue evolving without unnecessary drift.

Why this conversation matters more than it used to

For a long time, content management systems were primarily concerned with rendering pages.

Increasingly, they’re expected to model businesses, people, organizations, services, locations, products, relationships, structured data, APIs, and AI retrieval.

The CMS is quietly becoming the operational source of truth for many organizations. That’s a very different responsibility.

When content, metadata, relationships, and presentation become scattered across multiple systems, maintaining consistency stops being only a technical challenge. It becomes an architectural one.

A better place to start

Architectural cohesion won’t tell us everything we need to know about a CMS. It won’t measure editorial experience, explain governance, or predict the health of an ecosystem.

We’ll get to those.

But I think it’s the right place to begin because so many of those conversations branch from the same observation:

Every architectural boundary introduces another place where assumptions, priorities, and responsibilities can drift apart.

That doesn’t make an architecture wrong. It simply makes maintenance more expensive—not always in dollars, but sometimes in time, confidence, or the quiet reluctance to improve a system because no one is quite sure what else might break.

Features tell us what a platform can do today. Clear structure tells us what it will cost to keep doing it tomorrow.

I can’t help wondering how different our industry conversations would sound if we started with the second question instead of the first.