Our content team met in a small room with cold coffee and sticky notes. Jess wanted a new marketing site that could also feed the mobile app. Tom wanted fewer moving parts and something the editors could drive. Two notes ended up on the whiteboard. One said headless CMS. The other said headful CMS. The room went quiet. We had a site to ship, an app to feed, and no interest in a six month rebuild. Sound familiar?
This choice is not a trend fight. It is about how your content moves, how your team ships, and what you can afford to maintain after launch. Let’s break it down without buzzwords, then make a call you can defend next week and next quarter.
Headless and headful explained
A headless CMS stores content and serves it through an API. Your site, app, kiosk, or voice skill pulls the content and renders the view. Think Contentful, Prismic, Sanity, Strapi, or even WordPress with the REST API or GraphQL. Front ends can be React with Gatsby or Next.js, Vue with Nuxt, native apps, or anything else that speaks HTTP.
A headful CMS is the classic path. The same system stores content and renders pages. WordPress with themes, Drupal with Twig, Sitecore, AEM. Editors write, hit publish, and the platform sends HTML to the browser. Plugins cover SEO, forms, search, and image work out of the box.
Why teams go headless: channel freedom, a shared content model across web and app, and modern tooling. Want a snappy site with pre rendered pages from Gatsby, plus a mobile app reading the same entries, plus a screen in your booth that pulls product details? Headless does not blink. You also get to pick your build tool, your hosting, and your caching story. Netlify and server side rendering are very real options right now.
Why teams stay headful: speed to publish and fewer moving parts. Editors preview with one click, drag blocks, and ship. You can get Yoast for metadata, a forms plugin, a security plugin, and be live. You do not need a separate front end repo, a build pipeline, or a custom preview service. If your main job is the website and you are not feeding many other clients, this path is often faster and cheaper.
Real tradeoffs you will feel
Headless gives control over the front end and reusability of content, but you must build and own routing, previews, sitemaps, redirects, analytics, search, and media handling. You will also need a clear content model early. Editors lose in page editing unless you invest in previews and visual hints.
Headful gives author joy and a huge plugin library, but you can hit limits when you want to push the same content to multiple apps. You may also fight theme constraints, performance issues from too many plugins, and longer upgrades. Going headful does not mean slow or dated, but it does nudge you toward a web first mindset.
Risks to plan for
- Preview gap. In headless setups, editors hate guessing. If you cannot show a shareable preview URL that matches production, expect complaints and slower publishing.
- SEO regressions. JS heavy sites can break crawl, render, or metadata. Solve with pre rendering or server side rendering, accurate canonical tags, XML sitemaps, and clean redirects.
- Content model debt. Fields that fit the site today can block the app tomorrow. Model for reuse, not for a single template.
- Cost drift. Multiple vendors, build minutes, and developer time can add up. Headful can also grow costly with premium plugins and hosting tiers. Budget both paths honestly.
- Team mismatch. A strong editor team without front end devs will move faster in headful. A strong front end team that needs channel reach will move faster in headless.
- Security and uptime. More services means more failure points. Fewer services means a single point of failure. Monitor either way.
Decision checklist
- Channels: Do we need the same content in web, mobile app, and other clients within six to twelve months
- Team: Do we have front end devs who enjoy build pipelines, caching, and routing, or are we editor heavy with little engineering time
- Speed: Do we need to launch in weeks or can we invest more time now to save time later
- Editing: Do editors need in page editing with blocks, or is a form based editor fine
- Personalization: Do we need per user views that are easier in a server rendered world, or is static plus client logic enough
- SEO: Can we guarantee pre rendering or server side rendering if we go headless
- Budget: What are the clear monthly costs for hosting, vendors, plugins, and build time in both paths
- Ownership: Do we want to own a front end repo and its lifecycle, or lean on a theme and focus on content
Action items for next week
- Write your content model. Define entries, fields, relations, and naming. Keep presentational bits out. This helps no matter what you choose.
- Run two tiny spikes. One headless spike: pull three entries from an API and render a page with pre rendering. One headful spike: stand up a theme and publish the same page. Time both.
- Ship a preview plan. If headless, pick a preview flow and build a proof. If headful, confirm the editor experience with your real content types.
- Map SEO basics. Titles, meta, canonicals, XML sitemap, structured data, and redirects. Assign owners.
- Cost the stack. Write a one page budget with vendors, hosting, and maintenance hours. Include people time.
- Decide with a date. Put a decision date on the calendar. Bring the spike results and the budget. Choose and commit.
You do not need a perfect choice. You need a clear choice that fits your channels, your team, and your timeline. If your site is the main output and your editors lead the charge, a headful CMS with a clean theme can win right now. If your content must travel across web and app, a headless CMS with a careful preview story will pay off. Pick, ship, learn, and keep moving.