Two architectures for the same outcome[/HEADING>
Both headless CMS and static site generators (SSGs) produce websites where the content layer is decoupled from the rendering layer. They get used interchangeably and shouldn't be — they fit different team and content shapes. Below is the practical separation.
Static site generators[/HEADING>
Astro, Next.js (with static export), Hugo, Eleventy, Gatsby, Jekyll. Build the site at build time from content stored in files (Markdown, MDX, JSON).
Wins on: performance (pre-rendered HTML), security (no runtime backend), git-based content workflow (developers edit content the same way they edit code), cheap hosting (any static host works).
Where it hurts: non-developer content editors. Markdown in a git repo is not a content workflow for a marketing team. Build times become painful at large content scales. Dynamic content (search, comments, user-specific) requires bolting on services.
Use when: technical team owns content, content volume is moderate, deployment cadence is normal (not "publish 50 articles a day"), the site is mostly informational.
Headless CMS[/HEADING>
Sanity, Contentful, Strapi, Storyblok, Directus, Hygraph (formerly GraphCMS), Payload. Content lives in a managed database with an editor UI; the website fetches the content at runtime or build time via API.
Wins on: non-technical editors, structured content modelling, multi-channel content (web + mobile + email), content workflows (review, approval, scheduling), large content volumes.
Where it hurts: additional cost (managed CMS) or operational complexity (self-hosted CMS). Build pipeline dependent on the CMS being available at build time. Rendering pipeline is more complex.
Use when: non-developer editors need to publish frequently, content has structure that benefits from typed models, content drives multiple channels.
The hybrid that works for many teams[/HEADING>
- Headless CMS as the content store
- SSG as the build / render layer
- Webhook from CMS triggers a rebuild on content change
- Editor experience preserved, performance preserved, technical-team workflow preserved
This is the "JAMstack" pattern that emerged a few years ago. Still works in 2026, especially with build performance improvements (incremental builds, partial rebuilds).
The "WordPress" alternative[/HEADING>
WordPress with a "headless" plugin (WPGraphQL, REST) can be the headless CMS. Trade-offs:
- Familiar editor for clients
- Plugin ecosystem
- But: WordPress security posture is its own ongoing concern; the headless setup is awkward; PHP hosting still required
For projects where the customer demands WordPress, headless WordPress is workable. For projects starting fresh with a "what's best" question, modern headless CMS options are cleaner.
Specific picks[/HEADING>
- Sanity — strong for structured content modelling, real-time collaboration, generous free tier
- Storyblok — visual editor that maps to component tree, good for marketing-heavy sites
- Strapi / Directus / Payload — self-hostable, control over hosting and data, more operational overhead
- Contentful — enterprise-mature, expensive at scale, predictable behaviour
- Hygraph — GraphQL-first, schema flexibility, good for complex content shapes
Image handling[/HEADING>
- Static / SSG sites — image optimisation pipelines (Next/Image, Astro Image, gulp / sharp scripts)
- Headless CMS — most include CDN-backed image transformations (resize, format, quality)
- Either way: don't ship un-optimised images in 2026. AVIF / WebP, responsive sizes, lazy loading.
The stack we ship for AIOR-style marketing sites
- Astro for the frontend (static, partial hydration where needed)
- Sanity or Storyblok as headless CMS
- Webhook from CMS → build pipeline → CDN deploy
- Cloudflare or Bunny for edge caching
- Forms via lightweight backend (a small API server or a serverless endpoint)
One pattern we'd warn about[/HEADING>
Picking a CMS based on the editor demo. The "first-week experience" sells; the "year-three experience" determines whether the project succeeds. Read about migration / export / backup before committing.
One pattern that always pays off[/HEADING>
Content modelling time before tool selection. Write down the content types, fields, relationships, validation rules. The tool then either fits or doesn't.
What's your stack? And — for the large-content folks — what's the SSG / CMS combination that's held up at 10 000+ pages?
Astro, Next.js (with static export), Hugo, Eleventy, Gatsby, Jekyll. Build the site at build time from content stored in files (Markdown, MDX, JSON).
Wins on: performance (pre-rendered HTML), security (no runtime backend), git-based content workflow (developers edit content the same way they edit code), cheap hosting (any static host works).
Where it hurts: non-developer content editors. Markdown in a git repo is not a content workflow for a marketing team. Build times become painful at large content scales. Dynamic content (search, comments, user-specific) requires bolting on services.
Use when: technical team owns content, content volume is moderate, deployment cadence is normal (not "publish 50 articles a day"), the site is mostly informational.
Headless CMS[/HEADING>
Sanity, Contentful, Strapi, Storyblok, Directus, Hygraph (formerly GraphCMS), Payload. Content lives in a managed database with an editor UI; the website fetches the content at runtime or build time via API.
Wins on: non-technical editors, structured content modelling, multi-channel content (web + mobile + email), content workflows (review, approval, scheduling), large content volumes.
Where it hurts: additional cost (managed CMS) or operational complexity (self-hosted CMS). Build pipeline dependent on the CMS being available at build time. Rendering pipeline is more complex.
Use when: non-developer editors need to publish frequently, content has structure that benefits from typed models, content drives multiple channels.
The hybrid that works for many teams[/HEADING>
- Headless CMS as the content store
- SSG as the build / render layer
- Webhook from CMS triggers a rebuild on content change
- Editor experience preserved, performance preserved, technical-team workflow preserved
This is the "JAMstack" pattern that emerged a few years ago. Still works in 2026, especially with build performance improvements (incremental builds, partial rebuilds).
The "WordPress" alternative[/HEADING>
WordPress with a "headless" plugin (WPGraphQL, REST) can be the headless CMS. Trade-offs:
- Familiar editor for clients
- Plugin ecosystem
- But: WordPress security posture is its own ongoing concern; the headless setup is awkward; PHP hosting still required
For projects where the customer demands WordPress, headless WordPress is workable. For projects starting fresh with a "what's best" question, modern headless CMS options are cleaner.
Specific picks[/HEADING>
- Sanity — strong for structured content modelling, real-time collaboration, generous free tier
- Storyblok — visual editor that maps to component tree, good for marketing-heavy sites
- Strapi / Directus / Payload — self-hostable, control over hosting and data, more operational overhead
- Contentful — enterprise-mature, expensive at scale, predictable behaviour
- Hygraph — GraphQL-first, schema flexibility, good for complex content shapes
Image handling[/HEADING>
- Static / SSG sites — image optimisation pipelines (Next/Image, Astro Image, gulp / sharp scripts)
- Headless CMS — most include CDN-backed image transformations (resize, format, quality)
- Either way: don't ship un-optimised images in 2026. AVIF / WebP, responsive sizes, lazy loading.
The stack we ship for AIOR-style marketing sites
- Astro for the frontend (static, partial hydration where needed)
- Sanity or Storyblok as headless CMS
- Webhook from CMS → build pipeline → CDN deploy
- Cloudflare or Bunny for edge caching
- Forms via lightweight backend (a small API server or a serverless endpoint)
One pattern we'd warn about[/HEADING>
Picking a CMS based on the editor demo. The "first-week experience" sells; the "year-three experience" determines whether the project succeeds. Read about migration / export / backup before committing.
One pattern that always pays off[/HEADING>
Content modelling time before tool selection. Write down the content types, fields, relationships, validation rules. The tool then either fits or doesn't.
What's your stack? And — for the large-content folks — what's the SSG / CMS combination that's held up at 10 000+ pages?
- Headless CMS as the content store
- SSG as the build / render layer
- Webhook from CMS triggers a rebuild on content change
- Editor experience preserved, performance preserved, technical-team workflow preserved
This is the "JAMstack" pattern that emerged a few years ago. Still works in 2026, especially with build performance improvements (incremental builds, partial rebuilds).
The "WordPress" alternative[/HEADING>
WordPress with a "headless" plugin (WPGraphQL, REST) can be the headless CMS. Trade-offs:
- Familiar editor for clients
- Plugin ecosystem
- But: WordPress security posture is its own ongoing concern; the headless setup is awkward; PHP hosting still required
For projects where the customer demands WordPress, headless WordPress is workable. For projects starting fresh with a "what's best" question, modern headless CMS options are cleaner.
Specific picks[/HEADING>
- Sanity — strong for structured content modelling, real-time collaboration, generous free tier
- Storyblok — visual editor that maps to component tree, good for marketing-heavy sites
- Strapi / Directus / Payload — self-hostable, control over hosting and data, more operational overhead
- Contentful — enterprise-mature, expensive at scale, predictable behaviour
- Hygraph — GraphQL-first, schema flexibility, good for complex content shapes
Image handling[/HEADING>
- Static / SSG sites — image optimisation pipelines (Next/Image, Astro Image, gulp / sharp scripts)
- Headless CMS — most include CDN-backed image transformations (resize, format, quality)
- Either way: don't ship un-optimised images in 2026. AVIF / WebP, responsive sizes, lazy loading.
The stack we ship for AIOR-style marketing sites
- Astro for the frontend (static, partial hydration where needed)
- Sanity or Storyblok as headless CMS
- Webhook from CMS → build pipeline → CDN deploy
- Cloudflare or Bunny for edge caching
- Forms via lightweight backend (a small API server or a serverless endpoint)
One pattern we'd warn about[/HEADING>
Picking a CMS based on the editor demo. The "first-week experience" sells; the "year-three experience" determines whether the project succeeds. Read about migration / export / backup before committing.
One pattern that always pays off[/HEADING>
Content modelling time before tool selection. Write down the content types, fields, relationships, validation rules. The tool then either fits or doesn't.
What's your stack? And — for the large-content folks — what's the SSG / CMS combination that's held up at 10 000+ pages?
- Sanity — strong for structured content modelling, real-time collaboration, generous free tier
- Storyblok — visual editor that maps to component tree, good for marketing-heavy sites
- Strapi / Directus / Payload — self-hostable, control over hosting and data, more operational overhead
- Contentful — enterprise-mature, expensive at scale, predictable behaviour
- Hygraph — GraphQL-first, schema flexibility, good for complex content shapes
Image handling[/HEADING>
- Static / SSG sites — image optimisation pipelines (Next/Image, Astro Image, gulp / sharp scripts)
- Headless CMS — most include CDN-backed image transformations (resize, format, quality)
- Either way: don't ship un-optimised images in 2026. AVIF / WebP, responsive sizes, lazy loading.
The stack we ship for AIOR-style marketing sites
- Astro for the frontend (static, partial hydration where needed)
- Sanity or Storyblok as headless CMS
- Webhook from CMS → build pipeline → CDN deploy
- Cloudflare or Bunny for edge caching
- Forms via lightweight backend (a small API server or a serverless endpoint)
One pattern we'd warn about[/HEADING>
Picking a CMS based on the editor demo. The "first-week experience" sells; the "year-three experience" determines whether the project succeeds. Read about migration / export / backup before committing.
One pattern that always pays off[/HEADING>
Content modelling time before tool selection. Write down the content types, fields, relationships, validation rules. The tool then either fits or doesn't.
What's your stack? And — for the large-content folks — what's the SSG / CMS combination that's held up at 10 000+ pages?
Picking a CMS based on the editor demo. The "first-week experience" sells; the "year-three experience" determines whether the project succeeds. Read about migration / export / backup before committing.
