A headless CMS solves a real problem: separating content from its presentation so that content can travel to any channel — web, app, campus kiosk, voice assistant — without duplicating work. It is sound architecture, and eleven years of market adoption prove it. At Griddo we argue for it: the headless CMS guide for universities explains why, with security and performance data.

But it solves the backend. It does not solve what actually decides whether a university wins or loses an enrolment: how it looks, how it feels and who controls that experience the moment a prospective student, a dean or a journalist lands on a page.

That layer — the one that turns content into experience — is the presentation layer. And for a university with 15, 30 or 60 microsites spread across faculties, campuses, business schools and postgraduate programmes, the presentation layer is not a technical detail. It is the brand. It is the only thing a visitor sees, and the only thing that genuinely distinguishes one institution from the next on a student’s shortlist.

The ecosystem a headless CMS does not cover

A university does not manage a website. It manages an ecosystem: the corporate site, one per faculty, master’s programme sites, campaign-specific admissions microsites, alumni portals, versions in several languages. Dozens of people — not all of them technical — publish into that ecosystem every week.

A modern headless CMS manages the content of each piece elegantly. What it does not solve by design is how that final layout is coordinated, governed and published across dozens of sites, without every change depending on a development cycle. That is where the four problems that genuinely matter to whoever leads a university’s digital transformation appear.

Editing in the dark

When the backend is separated from the frontend without solving the presentation layer, the marketing team writes content without seeing how it will look. It fills in form fields, saves, and waits for a developer to build — or schedule — the final view. If the result is not what was expected, it goes back into the ticket queue.

The industry has a name for this: editing in the dark (CMSWire, 2024). It is not an exaggerated criticism or a label invented to sell an alternative: it is the direct consequence of separating where you write from where you see the result. The more complex the page — an admissions landing page with several modules, a programme page with tabs and CTAs — the more visible the distance between what the editor imagines and what finally gets published.

Bolted-on vs. born-integrated

The need to solve this layer is so evident that headless CMSs are adding it themselves. Strapi offers visual editing through a Vercel integration. Payload reserves its visual editor for the enterprise plan. Contentful launched a new product in 2026, Contentful Studio, with an “Experience Builder” designed to close exactly this gap. Storyblok built its visual editor from the start, inside its own product space.

Each of these platforms has its own architecture, its own approach and its own strengths; there is no need to reduce them to a single sentence. What matters to anyone evaluating an alternative is not that they lack visual editing or governance — most already have it, to varying degrees. What matters is how that layer arrived at the platform: added later, as an external integration or a separate product, on top of an architecture designed first to decouple content from presentation.

Griddo starts from the opposite premise: content modelling and the presentation layer live in the same platform from the original design, not as a piece bolted on later. That order — what was built first and what was added afterwards — is the real difference between a platform with visual editing and a platform designed, from the start, so that editing is publishing.

Real multi-site governance, not isolated spaces

This is where the argument becomes architectural rather than a matter of features. Platforms like Storyblok organise content into “spaces”: independent repositories, each with its own plan, its own seats and its own billing. Sharing an asset library between spaces is now possible; federating the content — the entries, the templates, the approval policies — between them is not.

For a portfolio of 20 or 30 university microsites, that means 20 or 30 separately administered instances, with permissions, approval workflows and billing that do not talk to each other. Every new site does not extend the ecosystem: it multiplies it.

The alternative is a federated ecosystem: different sites, single governance. One Griddo client runs 60 websites in 8 languages from a single instance. Universidad Europea operates five brands and schools — IPAM, IADE Portugal, IADE Spain, UDDI and Centro de Estudios Garrigues — with 16 people working across all five instances, seven of them spread across two or three instances in the same week. At Comillas, 60 people from 31 departments, faculties and institutes publish on a single instance, with centralised governance intact.

That is the difference between “having SSO and roles” — which any serious headless CMS already offers — and having a system where 30 sites behave as one ecosystem rather than as 30 separate contracts. The multi-site management and web governance model works through how that coordination holds up day to day.

Building structure vs. updating content

The reusable block pattern — the editor combines components the developer defined once — no longer distinguishes anyone: Storyblok’s bloks, Payload’s blocks, other platforms’ slices and Contentful’s Experience Builder all work on the same idea.

The difference is where that block lives. In a pure headless architecture, the schema is defined in the CMS and the component that renders it lives in a separate frontend application, maintained by a different team. Every new module requires syncing two systems before marketing can use it: first the backend, then the frontend, then the deployment.

In Griddo, the module you define is, at the same time, what you see and what you publish: modelling and rendering live in the same platform. Griddo offers thousands of atomic modules — Hero, Carousel, Form, Testimonials, Programme Card, FAQ — each with its own schema, styles and logic already solved. Across one month of measured activity on 11 instances, institutional teams performed 4,571 page module configurations: they did not fill in forms, they composed pages.

That distinction — building structure once, versus updating content every week — is what separates a team that depends on IT for every new campaign from a team that publishes it alone.

Honest limitations

The question that genuinely decides the right architecture is not “headless or not”. It is: who needs to publish, how often, across how many sites, and how much development time can the university afford between a campaign idea and its publication?

The decision is not technical, it is about governing the ecosystem

For marketing leadership, the strategic question is whether their university’s digital ecosystem scales as a single platform or as a collection of independent projects that someone has to keep in sync by hand. For the CIO, the question is whether that scale holds up with the security and governance their committee demands, without multiplying the number of systems their team has to watch.

13+ universities have already answered that question by choosing a platform where content management and web publishing are the same thing from the start, not two systems someone had to connect afterwards.

The platform-by-platform comparisons

This article opens the general argument. Each platform has its own nuances — and its own real strengths — so there is a feature-by-feature comparison for each, with pricing, cited sources and the points where the competitor wins:

It also connects with pieces already published: the university web ecosystem and how to build a cohesive vision, on unifying a portfolio of sites without losing governance, and empowering marketing teams and reducing IT dependency, on what changes when a marketing team publishes without waiting for a development cycle.

If your university’s web ecosystem already looks like this problem — several sites, several teams, a brand that depends on coordinating them — request a demo and review with our team whether the architecture you have today is the one you need for the years ahead.