What Is an AI CMS? The Three Kinds Explained

The Short Answer

An AI CMS is a content management system where a large language model does part of the editing work: drafting copy, translating, tagging, or making the change itself when you describe it in plain language. The term covers three quite different products. Some are traditional CMSs with an AI writing assistant added to the editor. Some are AI website builders that generate a whole site from a prompt. And some, like the approach CMS Chat takes, put a chat interface on top of an existing site's code, so the AI edits the real files instead of a separate content database.

Which kind you need depends on one question: where does your content live today?

What "AI CMS" Usually Means

A content management system has always done two jobs. It stores content, and it gives non-developers a way to change that content without touching the code that renders it. "AI" can be added to either job.

Adding AI to the storage side means things like automatic tagging, summaries, alt text suggestions and translation of structured fields. Adding AI to the editing side means you stop filling in forms and start giving instructions: "change the opening hours on the contact page to 9 to 6" or "translate the pricing FAQ into German".

The second kind is the bigger change. It shifts the skill the editor needs from "know where everything is in the dashboard" to "know what you want". It also shifts the risk: when an AI can change content on request, the important question becomes what it is allowed to change, and who checks it.

Kind 1: A Traditional CMS With an AI Assistant

Most established CMS vendors now ship AI features inside the existing editor. The content model, the dashboard and the publishing workflow stay the same. The AI helps you fill in fields faster.

Sanity is a clear example. Its AI Assist documentation describes a plugin for Sanity Studio that brings a "document-aware AI assistant" into the editing environment, where editors write reusable instructions in plain language to take over routine work. The same page notes it is a paid feature on the Growth plan and up.

This kind fits well when:

Your content already lives in that CMS, with a content model your developers built
Editors are comfortable in the dashboard and mainly want help writing, translating or enriching content
You publish a lot of structured content, such as articles, products or documentation

It fits less well when the site was never built on a CMS in the first place. Adding a headless CMS to a finished code-based site means modelling content types, wiring components to fetch from the API, and migrating copy out of the files. We cover that trade-off in detail in CMS Chat vs headless CMS.

Kind 2: An AI Website Builder

The second kind generates a site, or large parts of one, from a prompt. You describe the business, the builder produces pages, layout and copy, and you refine it through more prompts or a visual editor.

This fits a new project with no existing site, where speed to a first version matters more than control over the code. The trade-off is that the builder owns the stack. Content, layout and hosting usually live inside the builder's platform, and moving to a developer-maintained codebase later can mean starting over.

If you already have a site that an agency or developer built, an AI builder does not help you edit it. It replaces it.

Kind 3: Chat Editing on Top of Your Existing Code

The third kind assumes the site already exists as code in a Git repository: a Next.js, Astro, Hugo or Nuxt project, plain HTML, or a site exported from an AI builder into a repo. The content lives in the files themselves: text inside components, Markdown and MDX pages, JSON data files.

Instead of moving that content into a CMS, a chat-based editor reads the repository, finds where a piece of text lives, edits the file and commits the change through Git. Nothing is migrated. The developer keeps working in the same repo, and every edit shows up in the normal Git history.

This fits when:

The site is code-based and the content lives in the repo
The people who need to edit are not developers: clients, founders, marketing staff
You want small edits handled without a developer, but layout and code changes still reviewed by one

It fits less well for very large, highly structured content libraries where a real content model, scheduled publishing and editorial roles are the main need. A headless CMS is built for that.

The Real Question: What Is the AI Allowed to Touch?

Every AI CMS has to answer the same safety question, and it is worth asking any vendor directly. A language model that can edit content on request can also edit the wrong thing on request. "Make the hero bigger" is a layout change. "Remove the cookie banner" touches scripts. "Rewrite the homepage title" can affect how the page ranks.

Good answers look like this:

Scoped access. The AI can only reach the content it is meant to edit, not the whole system.
Change classes. Routine text edits go through directly. Risky ones need confirmation. Structural ones go to a human.
Review in the developer's own workflow. Anything risky lands somewhere a developer already looks, such as a pull request, not a separate inbox.
A visible history. Every change is recorded and attributable, so you can see who asked for what.

If a product cannot tell you where those lines are drawn, the AI is making the decision for you.

AI CMS and SEO

Editors changing their own content creates one specific SEO risk: a title tag, H1 or meta description that ranks well gets rewritten because someone wanted it to sound nicer. An AI makes that faster, not safer, unless it knows which pages and phrases matter.

The useful pattern is to connect real search data to the editor. When an edit touches a ranking element, the editor sees which queries that page ranks for before the change goes out, and can decide with that information in front of them.

Where CMS Chat Fits

CMS Chat is the third kind. You install its GitHub App on the repository you choose, it detects the framework, and it scans the repo to map editable zones: text, images, links and prices in TSX, MDX, Markdown, HTML and JSON files. There is no plugin and no content migration.

Each zone gets a guardrail: editable, warn, escalate or locked. Editors describe a change in plain language, and the AI finds the file, makes the edit and commits it when it is routine. Layout and code changes are not guessed at: they become a GitHub pull request for the developer. If you connect Google Search Console, CMS Chat warns before an edit touches a title, H1 or meta description that ranks. Agencies get client portals organised by organisation, client and site, with invites and activity history. You can also edit the site from Claude, ChatGPT, Claude Code or Cursor through the MCP endpoint.

CMS Chat is not a plugin for another CMS and does not connect to one. If your content already lives in a CMS, the AI features of that CMS are the more natural choice. CMS Chat is in beta. See how it works for the full flow, or read what CMS Chat is for the product overview.

How to Choose

Start from where your content lives:

In a CMS already: use that CMS's AI features. Moving content out to gain a chat interface rarely pays off.
Nowhere yet, no site: an AI website builder gets you a first version fastest. Check how you would export the site later.
In a Git repository, as code: a chat editor that works on the repo avoids a migration and keeps the developer in control of anything structural.

Then ask the safety question. Whichever kind you pick, the AI should know what it may change, what needs a confirmation and what belongs to a developer. If you want to see the repo-based approach on your own site, request beta access.