Headless CMS
The content-management half of the spoke’s story — the answer to “if you drop WordPress, where does the content live and how do non-developers edit it?” A headless CMS is a back-end-only content repository that exposes content through an API (REST/GraphQL) instead of rendering pages itself.
Coupled vs headless — the decoupling
- Coupled / monolithic CMS (wordpress): content store, editing UI, themes, and request-time page rendering are one inseparable application — the exact model the synthesis tracks as being displaced.
- Headless CMS: content management is separated from presentation entirely. The CMS owns editing workflows, structure, and roles; the front end is any technology you like, consuming content over an API.
This decoupling is the natural partner of SSGs and jamstack: an SSG pulls structured content from the headless CMS at build time and pre-renders it to static HTML, served via a CDN (e.g. netlify). Content editing without a request-time database is precisely what lets the jamstack model keep an editor experience while shedding the monolith.
Two flavors
- API-based / SaaS — Contentful, Sanity, Prismic, Strapi: content lives in the vendor’s store, fetched via API.
- Git-based — Decap (formerly Netlify CMS), TinaCMS: edits commit Markdown/data straight to the repo, so content stays in the same version-controlled files the SSG already builds from — the tightest fit with the own-your-plain-files ethos.
Trade-offs
More flexibility, scalability, and security (no public request-time DB/admin surface), at the cost of higher setup complexity and front-and-back-end dev knowledge — the same “power-for-simplicity” trade that separates the SSG world from one-click wordpress.
Related
jamstack · static-site-generator · netlify · wordpress · astro