Traditional visual CMS
Visual editing is often convenient because the CMS also owns the templates and rendering stack. That can be a practical fit, but frontend choices stay tied to the CMS.
Visual Headless CMS
Visual editing for content teams. Headless freedom for developers.
Contoprix combines structured content and visual page composition with a developer-controlled frontend, so editors can build in context while applications receive clean content through modern APIs.
Editors control page composition. Developers keep ownership of components, routing, accessibility, and runtime behavior.
Category Guide
What is a visual headless CMS?
It combines the separation of a headless content platform with an editing experience that shows content teams how approved components fit together on a page.
Basic headless CMS
APIs give developers freedom to build any presentation layer. Editors may still work mainly through forms and depend on developers to understand the final page context.
The Contoprix approach
Structured models and registered frontend components create a safe visual composition layer. Editors assemble pages; developers decide how those components render.
If you are evaluating the architecture before its editing experience, start with the broader headless CMS guide.
Structure + Composition
A visual page still has a content model underneath it
The Visual Builder works with reusable, defined components. It does not replace structured content with an unrestricted HTML canvas.
Structured content remains the source
Fields, components, relations, and validation rules give every visual section a stable content contract instead of storing presentation-only markup.
Editors compose with approved blocks
Content teams arrange registered page components, edit in context, preview draft changes, and publish through the same governed workflow.
Developers own the rendering layer
Your React or Next.js code defines how each component behaves, performs, and responds. The CMS supplies content and composition, not a proprietary frontend runtime.
Visual Builder Workflow
From component contract to published experience
The workflow connects content modeling, frontend implementation, editorial composition, preview, and published API delivery.
- 01
Model
Define content types and reusable component schemas.
- 02
Register
Map component codes to frontend components in your codebase.
- 03
Compose
Let editors arrange approved blocks in the Visual Builder.
- 04
Preview
Review draft content through a protected preview flow.
- 05
Publish
Create a published version for normal delivery.
- 06
Deliver
Render the result through REST, GraphQL, or framework SDKs.
Developer-Controlled Rendering
Composition comes from the CMS. Rendering stays in your application.
Your component registry maps Contoprix block codes to the React components in your repository. That keeps design-system decisions, responsive behavior, and accessibility in the same code review process as the rest of your frontend.
Content model Visual composition REST delivery GraphQL delivery
Content model
-> approved component blocks
-> editor composition + preview
-> published delivery API
-> your React / Next.js rendererEvaluation
Three different approaches to page delivery
The right choice depends on who needs to control presentation, how content is reused, and how much editing context a team needs.
| Decision area | Traditional CMS | Basic headless CMS | Contoprix visual headless model |
|---|---|---|---|
| Frontend ownership | CMS templates or themes | Application code | Application code |
| Editing context | Usually visual and in-page | Often form-based | Visual composition and preview |
| Content structure | Varies by template and plugin | Structured models | Structured models and reusable components |
| Delivery model | Page-oriented rendering | APIs | REST, GraphQL, and typed SDKs |
| Best fit | Coupled sites with simple delivery needs | Developer-led multi-channel delivery | Teams that need editor autonomy and frontend control |
Content Operations
Visual autonomy still needs publishing discipline
Composition becomes more useful when drafts, languages, websites, and access rules are governed in the same platform.
Draft, review, and publish
Editors can separate work in progress from public delivery, review changes, and publish a version only when it is ready.
Localization
Model and deliver language-specific content while keeping locale selection explicit in delivery requests and frontend routes.
Multi-site governance
Manage multiple websites and teams from one tenant-aware platform with scoped access and shared content patterns.
Protected preview
Draft preview uses a separate authorized path from public delivery so unpublished content is not exposed to normal visitors.
Explore the Product