Headless CMS
Headless, without losing the page.
Forrit CMS is a headless CMS that keeps the page. Teams model reusable content with content types and entries, then organise it into pages with their own routes, SEO and metadata. Forrit publishes it all through its JSON channel, and your front end stays in full control of presentation.
The headless compromise
What do content teams lose with a headless CMS?
Headless CMS solves real problems for developers. Content lives apart from presentation and is delivered by API to any front end, so teams can choose their own frameworks and reuse content across web, apps and other channels.
But a pure headless setup often hands work back to everyone else. These are the trade-offs content teams raise most often.
Where the work ends up
Developers model the content and build the front end
Editors fill in forms, often without seeing the page
New layouts go back on the development backlog
SEO and page settings are assembled from other tools
What content teams often lose
Seeing content in context
Content is stored apart from how it is shown, so editors often fill in forms without seeing the page. Live preview becomes extra work for the development team.
Building pages without a developer
A new landing page, section or layout often needs a developer and a deployment, so marketing loses the independence it had with a traditional CMS.
A page-shaped way to work
Editors work with content types, fields and references rather than pages. That is powerful, but many non-technical users find it hard to follow.
SEO and page settings in one place
Page-level features such as SEO controls and navigation are often not built in, so teams assemble them from other tools.
How it works
How does Forrit keep the page in a headless CMS?
In Forrit, headless does not mean pageless. Content stays structured and reusable, and a page adds the context that individual entries should not have to own: where the content lives, how it is described to search engines and how it fits into the site.
Developers get structured content. Editors get pages.
From content type to front end
Define content types for the things you publish
Create each entry once and reuse it anywhere
Organise entries into pages with a route, SEO and metadata
Approve and publish through your workflow
Your front end requests the page as JSON and renders it its own way
What each part does
Structured content
Content types and entries keep content reusable across pages, channels and projects.
Pages with context
A page adds the route, SEO title, description and metadata that individual entries should not have to own.
Delivered as JSON
The JSON channel publishes the page with no markup, so your front end stays in full control of presentation.
For developers
Can a headless page be delivered in a single request?
Yes. A Forrit page can combine entries from many content types. The JSON channel returns the whole page as one response: its route, its SEO metadata and every component, in the order editors arranged them.
Your front end makes one request per page. You don't need to write queries that fetch each content type and then stitch the results together. If an app only needs one entry or content type, it can request just that.
From request to rendered page
Request the page by its route, such as /savings/easy-saver
Receive the route, SEO metadata and every component, in order, in one response
Map each component type to your own UI component and render the page
Why developers like it
Fewer round trips
One request per route keeps server-side rendering and mobile apps fast.
Less glue code
No reference resolution or ordering logic to write and maintain.
Shaped by templates
Each component's JSON template sets which fields are output, so payloads carry only what the front end needs.
Always current
Publish a shared entry once and every page response that uses it updates automatically.
01 · Preview
Can editors preview headless content before it goes live?
In many headless platforms, editors fill in forms without seeing the result, and live preview is extra work for the development team.
In Forrit, changes are made in a task branch, and editors preview the page before it goes for approval, with no extra build for your developers. Teams that want to preview in their own front end can also render draft JSON from the task branch.
From edit to live
Edit content in a task branch, away from live content
Preview the page with the change in place
Review what is changing with a before-and-after view
Approve and publish
Preview capabilities
Preview in Forrit
Editors preview pages out of the box, with no preview build for your developers to maintain.
Preview in your own front end
Teams that want to can render draft JSON from the task branch in their own front end.
Safe from live
Changes stay in a task branch until they are approved and published.
02 · Independence
Do editors need a developer for every new page?
No. Developers build components and page templates once. Content teams then create pages from those approved building blocks, without a development cycle for each new page.
Developers stay in control of the design system and the delivery architecture. Content teams get the freedom to launch pages, campaigns and variants when they need them.
Who does what
Developers build components that format your content types
Developers set up page templates with the right components in place
Editors create pages from approved templates and components
Preview, approve and publish, with no development cycle
Component and template capabilities
Reusable components
Built once and reused across pages and sites, so rebrands, campaigns and launches take less time.
Page templates
New pages start from templates with the right components already in place.
Consistent brand and policy
Approved building blocks and workflows keep layouts and branding consistent, however many sites you run.
03 · Familiar editing
Do editors have to think in content types and references?
Not unless they want to. Power users and developers can work with the content model directly. Everyone else can start from the page: open Home, find the hero, change the content.
The structure underneath stays reusable, and usage information shows where else an entry appears before anyone changes it.
Editing a page
Open the page you want to change
Select the section and its content
Check where else the entry is used
Edit, preview and send for approval
Editing capabilities
Start from the page
Open the page, find the section and change the content, without hunting through the content model.
See where content is used
Usage information shows the pages and entries that reference an item before anyone changes it.
The full model for power users
Developers and power users can still work with content types and entries directly.
04 · Page-level features
Where do SEO and other page features live in a headless CMS?
In Forrit, on the page. Pages carry the route, SEO title, description and metadata across page types, so search and AI visibility are managed in one place and delivered with the content.
For capabilities beyond the page, Forrit is composable. Connect the specialist services you already rely on, rather than replacing them. See how Forrit connects to the services around it.
Managing a page
Set the page route and its place in the navigation
Add the SEO title, description and metadata
Add audience variants where they are needed
Publish, and the metadata is delivered with the page
Page-level capabilities
- Built in
SEO and metadata
Titles, descriptions and metadata are managed per page, across page types, and delivered with the content.
- Built in
Routes and navigation
Page routes and navigation are delivered in the JSON, so your front end builds URLs and menus from the CMS.
- Built in
Audience variants
Create variants of content for different audiences, and control which page components appear for each variant.
- Connects
Forms, personalisation and analytics
Forrit is composable. Connect the forms, personalisation, testing and analytics services you already use.
Hybrid headless
Need Forrit to render the web pages too?
The same content types, entries and pages can also be published as complete web pages through the HTML channel. Use one channel, the other, or both, from one CMS and one approval process.
- Forrit CMS
Hybrid headless
Compare the HTML and JSON channels, see how a page works in each, and find out which suits your website, app or estate.
- Product
Forrit CMS
Create, govern and reuse content across your digital estate, with structured content, visual page building and headless delivery in one CMS.
- Key benefit
Security
Seven layers of protection, from edge security and Airlock Publishing to secure development and ISO 27001 assurance.
Use the Tab key to move through each testimonial
The Forrit team was remarkable in helping our organization move an existing website from its tenant to the Forrit platform in a very short timescale. From migration, to pre and launch day activities, they flawlessly executed all details as outlined making the transition seamless and hassle free. Post launch, the team has continued to make themselves available to troubleshoot and answer questions when they arise, which has been beyond helpful. We are very happy to have made the transition to Forrit!
Headless CMS questions, answered
A headless CMS stores and manages content separately from how it is presented, and delivers it through an API, usually as JSON. Developers choose the front end, and the same content can feed websites, apps and other channels.
Pure headless setups often leave content teams without page preview, need a developer for new pages or layouts, ask editors to work with content types and references instead of pages, and leave page-level features such as SEO to be assembled from other tools. Forrit is designed to remove those trade-offs.
Yes. In Forrit, headless does not mean pageless. Content types and entries stay structured and reusable, and pages organise them with a route, SEO and metadata. The JSON channel delivers each page as data, so your front end still controls presentation.
The JSON channel publishes content as pure JSON with no markup, from a delivery tier that is separate from the CMS. Front ends can request a whole page, including its route, SEO metadata, navigation and components, or request individual entries and content types.
Yes. A Forrit page can combine entries from many content types, and the JSON channel returns the whole page in one response, with components in the order editors arranged them. Each component's JSON template controls which fields are output, and when a shared entry is published, every page that uses it is updated automatically.
Yes. Changes are made in a task branch, and editors can preview the page in Forrit before it goes for approval, with no preview build needed from your developers. Teams can also render draft JSON from the task branch in their own front end.
In many headless platforms, SEO fields are added to each content type or handled in the front end. In Forrit, pages carry the SEO title, description and metadata across page types, and that metadata is delivered in the JSON with the content.
Forrit includes audience variants, so you can create content for different audiences and control which components appear for each. Full personalisation and A/B testing come from specialist services that you connect to Forrit, which is composable by design.