It’s not the next big thing; it’s already here. But that doesn’t mean it’s the right fit for every project.

If you work with developers or follow tech blogs, chances are you’ve heard the term “headless CMS.” At this point, it’s not a trend, it’s a well-established architecture that’s been widely adopted across industries. We’ve been building headless sites for over four years. Tools like Sanity.io, headless WordPress, and others have become staples in modern dev workflows.

But here’s where it gets tricky: as headless becomes more common, the line between “new standard” and “just one of many options” gets blurrier. It’s easy to feel like you’re missing out by not using it or to assume that all modern websites should be built this way. In reality, it’s a powerful solution with real advantages, but only when paired with the right project and the right team.

A headless CMS decouples your front end (what users see) from your back end (where content is created and managed). This separation gives development teams more flexibility, particularly when designing custom front-end experiences, building multi-channel content strategies, or integrating with modern frameworks and services.

Sounds great, right? It is! When used for the right reasons. But for teams used to traditional WordPress or plug-and-play systems, the jump to headless can introduce unexpected complexity.

Despite the rise of headless, WordPress remains the most widely used CMS in the world. Its plugin ecosystem, editor familiarity, and large support community make it a practical, cost-effective choice for the vast majority of websites. Most agencies we work with default to WordPress unless a project has specific requirements that demand more flexibility or developer control.

That’s not a knock against headless. It’s a reminder that you should choose the tool that fits the project—not the other way around.

We’ve used headless WordPress and Sanity.io to power sites that needed:

Headless is also a good fit when there’s a strong partnership with a development team that will stay involved post-launch. It’s not the best choice if the client needs something self-sufficient, with lots of plugin-ready functionality and minimal ongoing dev support.

Agencies often spend a lot of time thinking about the site’s external audience. But it’s just as important to consider internal users: the marketing team, the content editor, the IT department.

When we’ve recommended Sanity.io, it’s often because the client’s team wasn’t familiar with CMSs and needed something clean, minimal, and intuitive. A few clearly labeled content types, drag-and-drop image fields, and some contextual help go a long way in creating confidence.

On the flip side, a powerful headless setup might frustrate users who expect a WordPress-style editing experience. That’s where communication is key, especially with IT teams, who may need to adjust firewalls, CDNs, or hosting environments to support the architecture. (We’ve run into this with Akamai and other enterprise tools; it’s fixable, but needs planning.)

If your dev team is suggesting headless—or if your agency is curious but unsure—it’s not about whether the technology is “better.” It’s about whether it’s better for this project, this client, and this team.

We’ll never recommend a tool just because it’s trending. But if your project could benefit from headless—if it needs advanced control, tight performance, or a long-term platform that avoids monthly enterprise fees—we’ll help you make the case. And if WordPress (or even something else) is the better fit, we’ll advocate for that too.

Just like in UX, the best solution is the one that meets the needs of the users—and in this case, that includes your developers, your clients, and your content editors.