Headless CMS websites

An agentic website with a familiar editor on top. Your editors publish through the CMS, the marketers working with agents work through the repo, and it’s still one site with one set of rules. You own the code, the content and the site.

[ What is it? ]

One site. Two ways to edit it.

A headless CMS website is the same foundation as every agentic website we build: code in your GitHub repository, your brand encoded into it, guardrails and the machine layer built in. The difference is one extra component: a headless CMS where your editorial content lives, with the kind of editing interface your content team already knows.

The work splits cleanly. Editorial content, blog posts, resources, case studies, translations, flows through the CMS, with drafts, roles and review states. The site itself, new pages, sections, templates, campaigns, is still changed by brief to your agent and lands on a preview. The AI proposes, you approve what ships.

And the CMS is a component, not a landlord. Your content is structured and exportable, the front end is yours, and if you ever change CMS, or drop it, the site isn’t held hostage.

[ Who it’s for ]

Some of your team live in their
agents. Some want an editor.

For B2B SaaS and software companies with a content operation to run, not just pages to ship.

  • Some of your team brief an agent. Others want a familiar editor, and should have one.

    One site with two ways to edit it. Marketers brief the agent, editors publish in the CMS, and both follow the same rules.

  • An editorial team publishes most days and needs drafts, roles and review.

    Daily publishing needs a proper editorial workflow: drafts, scheduling, roles and sign-off before anything goes live.

  • You publish across languages or markets.

    Structured content keeps every language and market in step, without copying pages by hand.

[ What’s included ]

Owned code underneath,
whatever sits on top.

For B2B SaaS and software companies where the website is a growth channel, and the marketing team is carrying a number.

  • The keys

    Code in your GitHub repository, under your name, from the first commit: the front end, the design system, the deployment. Whatever CMS sits behind it, the site is yours. If we disappeared tomorrow, everything still works.

  • The CMS as a component, not a landlord.

    Structured content, cleanly exported and portable. Self-hosted on infrastructure you control, or a hosted backend your team never has to maintain. Change CMS or drop it, and the site isn’t held hostage.

  • Your agent still ships the site.

    The CMS handles editorial content; the agent handles the site. Your team briefs new pages, sections and campaigns in plain language to the agent it already uses, and the change lands on a preview. The AI proposes, you approve what ships.

  • The guardrails.

    A structured brand.md in the codebase and more than a decade of design and development standards, encoded as the guardrails and skills your agent runs on. Every change, from the CMS or the agent, renders inside the same rules. Five years in, it still looks like day one.

  • The machine layer.

    Structured data, schemas, llms.txt and a clean sitemap, with the site fast and server-rendered underneath. CMS content feeds the same layer, so the AI systems answering your buyers can read, retrieve and cite what your site actually says.

  • Editors and marketers, both trained.

    Roles, permissions, and draft and review states set up properly, and training for the editorial team. Playbooks and paired working for the marketers running the agent, with first supervised changes in week one.

  1. Discovery
  2. Transform
  3. Run & grow

[ The instances ]

We build on the ones worth owning.

Either way, the site around it works with the agents your team already uses: Claude, Claude Code, ChatGPT, Gemini, Cursor, Codex. Which CMS, or whether you need one at all, is a Discovery question, and we answer it for your team specifically.

  • Strapi

    Strapi CMS websites

    Open source and self-hosted: the CMS itself runs on infrastructure you control, which makes it the deepest-ownership option. Strong roles and permissions, first-class multi-language. The one we shipped for SalesStar.

  • Sanity

    Sanity CMS websites

    Structured content done properly, real-time collaboration, a hosted backend your team never has to maintain. In our builds it stays a component in your repository, never the platform your site depends on.

  • Astro
  • Strapi
  • Sanity

Astro on the front, your CMS behind it. The site is built on Astro: content-first, extremely fast, server-rendered for the machine audience. Behind it sits Strapi or Sanity, handing structured content to the site through an API. The site reads from the CMS; the CMS never owns the site. Nothing in the stack is exotic or roll-your-own; every part is widely used, documented, and replaceable. The stack serves the ownership, never the other way around.

[ Proof ]

Built for SaaS teams like yours.

  • [ 01/ Future of Marketing Work ]

    A brand and website for a three-way event.

    A brand, website and print system for a collaboration between academia, industry and the AI community, delivered in an eight-week sprint.

    The FMW mark on a blue and violet blur.

[ Related services ]

Other ways we build.

[ Questions we hear most ]

The honest answers.

Rheed MacPherson, founder of Signal Studio

Can’t find your answer?

Book a Discovery call and ask us directly.

Book a Discovery call
Do we lose the agentic layer if we add a CMS?

No. The CMS and the agent divide the work. Editorial content flows through the CMS, and the site itself, new pages, sections, templates, campaigns, is still changed by brief to your agent, on a preview, with a person approving what ships.

Headless CMS versus content in the repository: how do we choose?

Team shape decides it. A handful of marketers shipping pages and campaigns almost never needs a CMS; the repo plus the agent is simpler. A team where some people live in their agents and others want an editor, or a daily editorial operation with roles and review, usually does. Discovery makes the call for your team, with the reasoning attached.

Which headless CMS do you recommend?

The one your team actually needs, which is a Discovery answer, not a doctrine. Broadly: Strapi when self-hosting and deep control matter, Sanity when structured content and real-time collaboration matter. Both stay components inside code you own.

We already have a headless CMS. Can you build on it?

Usually, yes, and sometimes the right move is keeping your content exactly where it is while we rebuild what's underneath it. If you're looking to leave your current setup instead, see the migrations overview .

Rheed MacPherson, founder of Signal Studio

Can’t find your answer?

Book a Discovery call and ask us directly.

Book a Discovery call
Signal Studio
Book a Discovery call
HEADLESS-CMS.MD HEADLESS-CMS

# Headless CMS websites

 

Headless CMS websites on code you own. Editors publish through Strapi or Sanity, marketers brief their AI agent, and it's one site with one set of rules.

 

## Headless CMS websites

 

An agentic website with a familiar editor on top. Your editors publish through the CMS, the marketers working with agents work through the repo, and it’s still one site with one set of rules. You own the code, the content and the site.

 

- [Sanity](/services/sanity/)

- [Strapi](/services/strapi/)

 

- [Book a discovery call](/contact/)

// What is it?

## One site. Two ways to edit it.

 

A headless CMS website is the same foundation as every agentic website we build: code in your GitHub repository, your brand encoded into it, guardrails and the machine layer built in. The difference is one extra component: a headless CMS where your editorial content lives, with the kind of editing interface your content team already knows.

The work splits cleanly. Editorial content, blog posts, resources, case studies, translations, flows through the CMS, with drafts, roles and review states. The site itself, new pages, sections, templates, campaigns, is still changed by brief to your agent and lands on a preview. The AI proposes, you approve what ships.

And the CMS is a component, not a landlord. Your content is structured and exportable, the front end is yours, and if you ever change CMS, or drop it, the site isn’t held hostage.

 

box-shift

 

// Who it’s for

## Some of your team live in their agents. Some want an editor.

 

For B2B SaaS and software companies with a content operation to run, not just pages to ship.

 

- Some of your team brief an agent. Others want a familiar editor, and should have one.

One site with two ways to edit it. Marketers brief the agent, editors publish in the CMS, and both follow the same rules.

 

- An editorial team publishes most days and needs drafts, roles and review.

Daily publishing needs a proper editorial workflow: drafts, scheduling, roles and sign-off before anything goes live.

 

- You publish across languages or markets.

Structured content keeps every language and market in step, without copying pages by hand.

 

 

// What’s included

## Owned code underneath, whatever sits on top.

 

For B2B SaaS and software companies where the website is a growth channel, and the marketing team is carrying a number.

 

- The keys

Code in your GitHub repository, under your name, from the first commit: the front end, the design system, the deployment. Whatever CMS sits behind it, the site is yours. If we disappeared tomorrow, everything still works.

 

- The CMS as a component, not a landlord.

Structured content, cleanly exported and portable. Self-hosted on infrastructure you control, or a hosted backend your team never has to maintain. Change CMS or drop it, and the site isn’t held hostage.

 

- Your agent still ships the site.

The CMS handles editorial content; the agent handles the site. Your team briefs new pages, sections and campaigns in plain language to the agent it already uses, and the change lands on a preview. The AI proposes, you approve what ships.

 

- The guardrails.

A structured brand.md in the codebase and more than a decade of design and development standards, encoded as the guardrails and skills your agent runs on. Every change, from the CMS or the agent, renders inside the same rules. Five years in, it still looks like day one.

 

- The machine layer.

Structured data, schemas, llms.txt and a clean sitemap, with the site fast and server-rendered underneath. CMS content feeds the same layer, so the AI systems answering your buyers can read, retrieve and cite what your site actually says.

 

- Editors and marketers, both trained.

Roles, permissions, and draft and review states set up properly, and training for the editorial team. Playbooks and paired working for the marketers running the agent, with first supervised changes in week one.

 

 

- Discovery

- Transform

- Run & grow

 

// The instances

## We build on the ones worth owning.

 

Either way, the site around it works with the agents your team already uses: Claude, Claude Code, ChatGPT, Gemini, Cursor, Codex. Which CMS, or whether you need one at all, is a Discovery question, and we answer it for your team specifically.

 

- Strapi CMS websites

Open source and self-hosted: the CMS itself runs on infrastructure you control, which makes it the deepest-ownership option. Strong roles and permissions, first-class multi-language. The one we shipped for SalesStar.

 

- [Strapi websites](/services/strapi/)

- Sanity CMS websites

Structured content done properly, real-time collaboration, a hosted backend your team never has to maintain. In our builds it stays a component in your repository, never the platform your site depends on.

 

- [Sanity websites](/services/sanity/)

 

Astro on the front, your CMS behind it. The site is built on Astro: content-first, extremely fast, server-rendered for the machine audience. Behind it sits Strapi or Sanity, handing structured content to the site through an API. The site reads from the CMS; the CMS never owns the site. Nothing in the stack is exotic or roll-your-own; every part is widely used, documented, and replaceable. The stack serves the ownership, never the other way around.

 

- [Astro websites](/services/astro/)

- [Strapi websites](/services/strapi/)

// Proof

## Built for SaaS teams like yours.

 

Read case study

 

- [Future of Marketing Work](/case-studies/future-of-marketing/)

A brand and website for a three-way event.

 

A brand, website and print system for a collaboration between academia, industry and the AI community, delivered in an eight-week sprint.

 

 

// Related services

## Other ways we build.

 

- Agentic websites

Our flagship. A marketing website your team runs with its own agent. Best for: teams ready to brief a change and ship it the same day.

 

- [Agentic websites](/services/agentic-websites/)

- Webflow websites

Built to your design, not the nearest template. Best for: design-led teams who want a visual editor they already know.

 

- [Webflow websites](/services/webflow/)

- Astro websites

The framework under our builds: fast, server-rendered, readable by machines. Best for: teams who want to know exactly what they’d own.

 

- [Astro websites](/services/astro/)

 

// Questions we hear most

## The honest answers.

 

- Do we lose the agentic layer if we add a CMS?

No. The CMS and the agent divide the work. Editorial content flows through the CMS, and the site itself, new pages, sections, templates, campaigns, is still changed by brief to your agent, on a preview, with a person approving what ships.

 

- Headless CMS versus content in the repository: how do we choose?

Team shape decides it. A handful of marketers shipping pages and campaigns almost never needs a CMS; the repo plus the agent is simpler. A team where some people live in their agents and others want an editor, or a daily editorial operation with roles and review, usually does. Discovery makes the call for your team, with the reasoning attached.

 

- Which headless CMS do you recommend?

The one your team actually needs, which is a Discovery answer, not a doctrine. Broadly: [Strapi](/services/strapi/) when self-hosting and deep control matter, [Sanity](/services/sanity/) when structured content and real-time collaboration matter. Both stay components inside code you own.

 

- We already have a headless CMS. Can you build on it?

Usually, yes, and sometimes the right move is keeping your content exactly where it is while we rebuild what's underneath it. If you're looking to leave your current setup instead, see [the migrations overview](/migrate/).

 

 

- Can’t find your answer?

Book a Discovery call and ask us directly.

- [Book a Discovery call](/contact/)

Or email hello@signalstudio.co.nz