It is half past five on a Friday, and someone in marketing at a furniture retailer in Chennai needs the Pongal sale banner on the homepage and three category pages before the weekend. The developers built the site in Next.js and it is fast. The marketer has a form full of fields, no idea what the banner will look like, and a developer who has already logged off. Most headless setups solved the developers' half of the problem and left the editors' half for later, and that gap is why teams now ask for headless CMSs the editors can actually use.
What editors lost when the CMS went headless
A traditional CMS gave editors a page they could see. Move to headless and the content becomes fields in a form, and the page is built somewhere else. If nothing joins the two, editors are typing into boxes with no idea what comes out the other end.
So they ask for what they had before: a preview of the real page, reusable blocks, clear draft and published states, and a way to find the thing they wrote last month. None of that is cosmetic. Without it every small change goes back to a developer, which is the exact dependency that separating content from code was meant to remove.
- Form with no preview
- Free text for layout
- Publish and hope
- Ask a developer to check
- Preview in the real layout
- Blocks the site supports
- Clear draft and published
- Change shows up on schedule
The same headless CMS can feel like either column, depending on what was built around it.
What Next.js asks of the CMS
Next.js can generate pages at build time, render them on the server for each request, or regenerate static pages in the background after a set time or when the CMS tells it to. You can mix these page by page. Each choice changes what the CMS has to provide, and what the editor sees after pressing Publish.
| Rendering | When a change appears | What the CMS must provide |
|---|---|---|
| Built at deploy | After the next build finishes | A webhook that triggers a rebuild |
| Rendered per request | On the next page load | Fast API responses from where it is hosted |
| Regenerated on demand | Shortly after publish | A webhook that tells Next.js which pages changed |
| Draft preview | Immediately, for the editor only | Access to unpublished entries |
If pages are static, publishing needs a rebuild trigger and a build time editors can live with. A marketer who changes a sale banner and waits twelve minutes to see it will stop trusting the system. If pages render on request, the content has to be quick to fetch from wherever the CMS is hosted. If the site mixes approaches, the team needs a plain list of which pages update instantly and which wait, or the support messages will all say "I published it and it is not there".
- 01Editor savesin the CMS
- 02Previewdraft in the real layout
- 03Publishsends a webhook
- 04Next.jspages regenerated
- 05Live
Preview happens before publishing; the build or regeneration is what makes the change public.
Flexibility editors can use safely
Marketing teams want to launch a landing page or rearrange a section without waiting for a developer. That works when the CMS gives them a set of components developers built and tested, and editors combine those. It fails when editors get free-form layout, because pages drift apart and break on a phone screen.
Content models should be strict about meaning and loose about arrangement. A case study has a client name, a summary and a result. Whether that shows up as a card, a table row or a full page is the frontend's job. For the Chennai retailer, the sale banner is one entry with a headline, an image, a link, a start time and an end time. The homepage and the category pages each decide how to show it, and the banner comes down on its own when the end time passes. Nobody has to remember to remove it on Monday.
An example from this website
Our own site is built on Next.js. It used WordPress as a headless source, read through a GraphQL export step into JSON files that the build consumed. The editors used the WordPress admin, and the frontend was fully ours.
That arrangement kept both parts in their lane. WordPress stored and edited content, Next.js decided how it looked. The cost was the export step and a content system living outside the repository. The site now keeps its content as Markdown and JSON files in the repository, which suits the people who edit it but gives up the admin interface. Which trade is right depends entirely on who edits, and the full write-up of how our site moved from headless WordPress to files covers what that cost.
Where headless projects slip
Choosing the CMS before knowing the rendering plan. A CMS that cannot trigger a rebuild or serve draft content for preview is awkward with Next.js, and you find out after the contract is signed.
Skipping localisation in the model. Adding Hindi and Tamil later often means restructuring every content type. If more than one language or market is likely, decide early whether translations are separate entries or fields on the same entry.
Treating AI drafts as a separate pipeline. Teams that paste generated text into the CMS lose the source and the review record. If drafts come from a tool, bring them in as unpublished entries with a recorded author.
Letting editors configure what developers should own. Caching rules, redirects and site-wide settings belong in code unless there is an interface built specifically for them. An editor should never be one wrong toggle away from taking the site down.
Questions to answer before you choose
- Who will use the CMS every day, and have they tried it with their own content rather than the vendor's demo?
- Can an editor preview a draft in the real layout?
- How long does a published change take to show up on the site?
- Are the components limited to ones the frontend already supports?
- Are languages and regions part of the content model?
- How do you get back a previous version of an entry?
If you are still deciding between headless and a traditional setup, start with our headless and traditional CMS comparison. If you have already chosen headless, pick the two editors who will live in the system most and have each of them make one real change in every candidate, a price, a banner, a new page, before anyone signs anything. Their notes from that hour are the best requirements document a web development team can get.
