Headless CMS Examples: 5 Real Implementations in 2026

Everyone selling a headless CMS shows the same demo blog. None of them show what real implementations actually look like — the messy parts, the architectural decisions, what went wrong, what stuck.

This post walks through five realistic headless CMS implementations across different industries and use cases. Some are public reference architectures, some are illustrative patterns from real production systems. The point isn't to name-drop brands — it's to show the decisions developers make when they actually ship headless.

TL;DR: Headless CMS architectures fall into five repeating patterns: marketing site (Contentful + Next.js), developer docs (markdown + Astro), product catalog (Sanity + Next.js + Shopify), media publication (multi-channel with Strapi), and enterprise content network (Contentful + GraphQL federation). Pick the closest pattern to yours, then adapt — don't start from scratch.

Example 1: SaaS marketing site (Contentful + Next.js)

The pattern: Public marketing site with blog, customer stories, pricing pages, docs. Frequent content updates from a non-technical marketing team. Need fast page loads + good SEO.

The stack:

• CMS: Contentful (hosted SaaS)
• Frontend: Next.js (deployed on Vercel)
• Build strategy: Incremental Static Regeneration (ISR) — pages rebuild every 60 seconds when content changes
• Search: Algolia (synced from Contentful via webhook)
• Analytics: PostHog + Google Analytics

Why this works:

• Marketing edits in Contentful, sees changes live within 60 seconds (ISR revalidates)
• Pages render server-side for SEO, then hydrate to React for interactivity
• Vercel handles CDN + image optimization automatically
• No database, no server maintenance — Next.js builds are stateless

What goes wrong:

• Contentful's content modeling can get rigid — adding new field types means rebuilding components
• ISR cache invalidation is sometimes flaky; marketing complains about "stale" pages
• Vercel costs scale with bandwidth; ~$200-500/month for a moderate-traffic site

Real example: Spotify uses Contentful for their content marketing infrastructure (publicly documented). Many SaaS companies follow this pattern — it's the default for modern marketing sites.

Example 2: Developer documentation (Markdown + Astro)

The pattern: Technical documentation, API references, tutorials. Content owned by engineers, written in Markdown, versioned in Git. Need fast page loads + deep cross-linking.

The stack:

• CMS: Git itself (Markdown files in a docs/ folder)
• Frontend: Astro with content collections
• Build strategy: Full static site generation (no runtime database)
• Search: Pagefind (client-side, no server)
• Deploy: GitHub Pages or Cloudflare Pages (free tier)

Why this works:

• Engineers edit docs in PRs alongside code — review process built in
• Astro outputs static HTML, zero JavaScript by default — Lighthouse 100 is realistic
• Search runs in the browser, no API costs
• Git history IS the version history

What goes wrong:

• Non-technical writers struggle with Git workflows — marketing team needs training
• Image asset management is awkward — typically stored alongside markdown, manually optimized
• No live preview without a build step (workaround: run astro dev locally)

Real example: Stripe, Vercel, and Astro itself ship their docs as static-generated sites from markdown sources. This pattern dominates developer-tool documentation in 2026.

Example 3: Ecommerce product catalog (Sanity + Next.js + Shopify)

The pattern: Product-led ecommerce site where the storefront experience matters as much as the checkout. Inventory and transactions on Shopify, marketing content and product storytelling on Sanity.

The stack:

• Commerce backend: Shopify (handles inventory, checkout, payments, fulfillment)
• Content CMS: Sanity (product descriptions, lookbooks, brand stories)
• Frontend: Next.js (deployed on Vercel)
• Composition layer: Both APIs queried at request time and merged in the frontend
• Image CDN: Sanity's built-in image pipeline

Why this works:

• Shopify does what it's good at (inventory, payments, PCI compliance)
• Sanity does what it's good at (rich content models, real-time collaboration, GROQ queries)
• Next.js composes the two at the page level — product page = Shopify data + Sanity description + Sanity related-content
• Each tool stays in its strength zone

What goes wrong:

• Two CMS dashboards for the marketing team (Shopify Admin + Sanity Studio) → training overhead
• Data sync edge cases — a product deleted in Shopify but still referenced in Sanity content
• Costs add up: Sanity Growth ($99/mo) + Shopify Basic ($39/mo) + Vercel ($20+/mo) + image CDN

Real example: This is the dominant pattern for premium DTC ecommerce brands launching headless storefronts in 2025-2026. The "Shopify backend + headless storefront" approach is what Shopify itself promotes via Hydrogen.

Example 4: Media publication (Strapi + Next.js + multi-channel distribution)

The pattern: News or magazine publisher pushing the same content to web, mobile app, email newsletter, and partner syndication feeds. Multiple editors, scheduled posts, complex categorization.

The stack:

• CMS: Strapi (self-hosted, customized content types for articles, authors, categories, sections)
• Frontend (web): Next.js with ISR for article pages
• Frontend (mobile): React Native, pulls from the same Strapi API
• Newsletter: Webhook → Mailchimp/Resend when an article publishes
• Syndication: RSS feed + custom JSON feed for partners
• Hosting: Strapi on a VPS ($20-50/mo) + Next.js on Vercel + CDN for images

Why this works:

• One Strapi instance is the source of truth for every channel
• Editor workflow stays in one place even though distribution is multi-channel
• Custom content types match the publication's editorial model exactly
• Self-hosting means no per-API-call billing — fine at high volume

What goes wrong:

• Strapi requires ongoing maintenance (security patches, version upgrades)
• Self-hosting at scale means real DevOps cost — at least one developer rotation per quarter
• Editorial UX in Strapi is improving but lags behind hosted alternatives (Contentful, Sanity)
• Real-time collaboration is limited compared to Sanity Studio

Real example: Many independent media publications and B2B newsletters use this pattern. Strapi's open-source model fits publishers who want to avoid per-content-item pricing.

Example 5: Enterprise content network (Contentful + GraphQL federation)

The pattern: Large enterprise with multiple brands or product lines, each needing its own marketing site, but sharing common content (legal pages, brand assets, employee bios). Hundreds of editors across regions and languages.

The stack:

• CMS: Contentful Enterprise with multiple spaces (one per brand/region) + a shared "common" space
• Federation layer: GraphQL gateway (Apollo Federation or Hasura) that stitches multiple Contentful spaces into one API
• Frontends: Multiple Next.js sites, each pulling from the federated API
• Localization: Contentful's built-in locale system + AI translation pipeline
• Governance: Custom Contentful workflows + role-based permissions per space

Why this works:

• Brand A doesn't accidentally edit Brand B's content (separate spaces)
• Shared content (legal disclaimers, employee bios) lives in one place
• GraphQL federation means each frontend queries one endpoint, not many
• Contentful's localization handles 30+ languages without custom code

What goes wrong:

• Contentful Enterprise is expensive — typical annual spend is $150K-$500K
• GraphQL federation adds operational complexity — when the gateway breaks, every brand site breaks
• Content modeling decisions made early become very expensive to undo at scale
• Onboarding new editors takes 1-2 weeks of training

Real example: This is the architecture pattern at large multinationals running 10+ brand sites on a shared content infrastructure. The trade-off: real flexibility for real operational cost.

Pattern comparison — when to pick which

| Pattern | Best for | Monthly cost | Operational burden | |---|---|---|---| | 1. SaaS marketing | Single product, marketing-led | $200-500 | Low | | 2. Docs (Markdown + Astro) | Developer tools, tech companies | <$50 | Very low | | 3. Ecommerce composition | Premium DTC, content-heavy commerce | $300-800 | Medium | | 4. Media publication | Publishers, B2B newsletters | $100-400 | Medium-high | | 5. Enterprise federation | Multinational, multi-brand | $10K-50K+ | High |

The pattern that doesn't fit your business is the wrong one — even if it's technically impressive.

What every successful headless implementation has in common

After looking at dozens of real implementations, five things show up repeatedly in the ones that work:

1. A clear content model designed before any code is written. Teams that figure out content types as they go regret it within 6 months.
2. One source of truth per content type. Not "products live in Shopify but ALSO in Sanity" — pick the canonical store, the other is a cache.
3. A build/deploy strategy that matches editorial velocity. Daily edits → ISR. Weekly edits → full static rebuilds. Real-time → SSR with stale-while-revalidate.
4. Image pipeline is solved early. Either via the CMS's built-in CDN (Sanity, Contentful) or a dedicated service (Cloudinary, imgix). Doing image optimization yourself is a tar pit.
5. A documented decision on preview environments. How does an editor see draft content before publishing? This is the single most-asked question after launch.

If your implementation is missing one of these, expect to retrofit it within the first year.

When NOT to go headless

Five real signals that headless is the wrong choice:

• No frontend developer on the team. Headless without a developer is paying for a tool you can't use.
• Content team is non-technical and resists training. A complex Studio UI will be abandoned within months.
• Total monthly traffic under 10K visits. The architectural overhead isn't worth it at small scale.
• Single-channel publishing. If you only publish to a website, a traditional CMS is simpler.
• Tight budget and no developer time for setup. Headless means a 2-8 week setup project before first content ships.

For these cases, a self-hosted CMS or a hosted traditional CMS (Ghost, Squarespace) gets you to value faster. The when not to use a headless CMS post covers the trade-offs in more depth.

A note on UnfoldCMS

UnfoldCMS is a self-hosted Laravel CMS. It's not strictly headless — it ships with a public frontend templating layer (Blade templates) alongside a public read-only JSON API.

The pattern it fits well:

• Content sites where you want a real admin UI without writing one (Pattern 1 or 2 territory)
• Hybrid sites: rendered HTML for SEO-critical pages, API for app/mobile consumption
• Teams that want the optionality of headless without committing to a separate frontend stack on day one

What UnfoldCMS doesn't fit: Pattern 5 (enterprise federation), Pattern 4 (multi-channel publishers with complex syndication), or Pattern 3 at scale (real ecommerce). For those, the specialized headless platforms (Contentful, Sanity, Strapi) are better.

For broader context, the complete guide to headless CMS in 2026 covers the architecture from first principles.

FAQ

What are real examples of websites built with a headless CMS?

Spotify uses Contentful for marketing. Stripe and Vercel use markdown-based static sites for their docs. Many DTC ecommerce brands run Shopify backend + Sanity for content + Next.js frontend. Most major SaaS companies have moved their marketing infrastructure to a headless CMS in the past 3-4 years.

Which headless CMS is best for Next.js?

Sanity is the most common pick for Next.js projects in 2026, with Contentful winning at the enterprise tier. Payload CMS is gaining ground because it's TypeScript-native and offers Next.js-native integration. For developer docs, markdown + Astro often beats any CMS.

Can I run headless CMS on a small budget?

Yes — markdown + Astro + GitHub Pages can run a content site for under $20/month. Strapi on a $10/month VPS works for moderate-traffic sites. The $500+/month tier is for enterprise-grade hosted SaaS (Contentful, Sanity Growth+), not a hard minimum.

How long does a headless CMS implementation take?

2-8 weeks for a typical marketing site or docs site. 2-4 months for ecommerce composition. 6+ months for enterprise federation. The variance comes from content modeling decisions and migration complexity, not from technical setup.

What's the biggest mistake teams make with headless?

Underestimating the content modeling work. The technical setup is the easy part. Deciding what content types exist, how they relate, and how editors interact with them is what makes or breaks the project. Plan to spend 30-50% of the project on content modeling before writing any code.

Sources & methodology

Architecture patterns are described based on publicly documented references (Contentful's customer page lists Spotify; Astro and Vercel ship public docs sources; Shopify Hydrogen is documented as the official "Shopify backend + headless storefront" pattern). Specific cost figures are from each platform's public pricing as of May 2026.

This post is published on the UnfoldCMS blog. We make a self-hosted CMS that isn't strictly headless — we've described each pattern honestly, including cases where specialized headless platforms are the better choice.

Related: What Is a Headless CMS? · The Complete Guide to Headless CMS in 2026 · Headless CMS Architecture: How the Frontend-Backend Split Works