How AI May Impact CMS Architecture

Static sites came first: files sitting on a server. But as soon as non-technical people needed to publish, editing raw files stopped scaling. The CMS put content in a database, wrapping the database in an editor, and rendering pages on request. This has been the predominant architecture for the last 20 years.

Server-side rendering, caching, headless APIs — all refinements of one decision: content lives inside a platform, and humans reach it through the platform. [[1](#ref-1)]

A CMS is one runtime server doing five jobs at once: it stores content, governs who can change it, renders it into pages, runs dynamic behavior around the content, and gives authors an interface to create it. For the rest of this article I’ll just refer to these as “CMS”. I’ll also refer to hosting solutions like Netlify, Cloudflare, or Vercel simply as Cloud Hosts.

Now as far as the jobs of a CMS, there is the source of truth — where the canonical content lives — and then the editing interface. They were fused for one reason: a database isn’t human-editable, so every platform had to bolt an interface onto its storage. Which means the whole system rests on a single assumption: the editor is a person. Well, the new editor is looking more likely to be a large language model, and as much as I question the massive investments, the usefulness of AI reading and writing plain files natively can’t be ignored. And the best implementation of AI when it comes to content management systems may not be a module or plugin on a complex and already bloated platform. This article makes an argument for a modern architecture for removing the obstacles from AI in the context of a website content management system. I call it a Content Client (or Content IDE).

The primary responsibilities of a CMS #

Here are the core responsibilities, and approaches of a CMS. I’ve associated them to a few of the most popular systems out there.

None of these responsibilities are going away, and whether AI joins them is no longer the question — every vendor is already bolting an assistant onto their system. But it may be time to reconsider these large, opinionated, mostly proprietary solutions for a more flexible, raw approach.

In these common implementations, AI operates the way a human does — through the vendor’s API, one bespoke integration per row, per content type, per interface. But on plain files under version control, it operates in its native language: the text it was trained on, with diffs, branches, and direct read access to all content. [2] The shortest path to advanced AI isn’t a smarter plugin, combination of tools, or a massive platform. It’s putting the content where the agent is strongest: Markdown and structured data in a Git repository.

Git covers several rows of the table natively — storage, versioning, file history, review-gated approval, write control. Files in Git, with a build step that renders them into pages, is the static site generator (SSG), and the ecosystem around it is over a decade mature. Dozens of generators (Jekyll, Hugo, Eleventy, Astro), git-based editors [3], branch previews, CDN hosting: the whole arrangement was packaged and marketed as the Jamstack. The machinery for running a website out of a repository. The adoption never followed: fifteen years in, WordPress alone still runs 41.5% of the web, while the flagship site generators register a few tenths of a percent between them. [4] [5] Its biggest challenge, and what the movement has always lacked was an author who didn’t need to be a developer. But I believe that given the current circumstances, these systems and slight alterations of them deserve a second look.

Look at who runs the large static sites that already exist. MDN Web Docs is fourteen thousand pages of Markdown in a public Git repository, with some forty-five thousand contributors across its history; the Kubernetes documentation works the same way. [6] These sites are large, multi-team, and governed — and every one of them serves a technical audience and is edited by technical people. Scale was never the limit. The authoring barrier is [7], and the gap of technical knowledge an editor possesses is diminishing. With AI built-in to help editors, and safeguards in place, it makes much more sense now to reduce the complexity of content management systems as opposed to bolting AI onto monolithic server-based solutions.

Where AI belongs #

Authoring shouldn’t be typing into fields, it should be describing changes. “We renamed the Standard plan to Core — update every page that mentions it” is one instruction; the agent finds the mentions — including the ones in comparison tables and old announcements you forgot — and produces a single reviewable change across all of them.

This doesn’t exist currently because none of this works by pouring the site into the model’s context. An agent works the way a developer joins a codebase: nobody reads the whole thing. They search it, follow its structure, and read the three files that matter. So the content needs what a codebase has — a way to be navigated rather than swallowed.

It needs an index: a map of what exists, how it links together, and where to look — one the agent consults before every change and rebuilds after, since it is the one making changes.

Notice what this adds up to. Full-corpus search. Structure it can traverse — links, an index, a map. Assemble those requirements and you have described a wiki. Or more precisely, Karpathy’s LLM wiki design optimized for use as an agentic website management system. [8]

The canonical store is the content graph, markdown and structured data in a Git repository. The public website is not the system; it is one rendered view of the graph, produced by a build step. An internal knowledge base is another view, tracking historical decisions (ADR), RACI matrices, source material, or general wiki content. There are a dozen startups trying to monetize just that offering right now, it might benefit to not keep it outside of the content. Another view would be a machine-readable endpoint (llms.txt) for the agents reading your site. [9] The actual generator (hugo et al.) producing the public view becomes a swappable adapter rather than the primary tool, because everything that matters — the content, the links, the history, the index — lives a layer below it.

I believe this will lead to more advanced setups that are built to support agentic content management specific to websites. Perhaps custom desktop applications with various integrations. There are already so many benefits to SSG [10] [11] that if you can mitigate the shortcomings and/or replace features with modern alternatives simplicity could provide a massive overall benefit to the typical enterprise setup. For the rest of this article, I will call it a content client, and I’ll outline its structure now. You open it and see your site as a graph of pages, internal and public. I imagine the Content Client as a combination of Obsidian, GitHub Desktop, and Dagger (or similar CI pipeline management) plus integrated AI agents/tools.

So let’s start by validating how this system could replace the core features of a CMS, they fall into a few categories.

• Base content & storage
• Authoring, roles, and permissions
• The pipeline
• Additions no CMS has

Base content & storage #

The known SSG limitations apply here unchanged, so briefly: content you’d query at runtime like a large product catalog still requires a database [12]; frontmatter is a document format, not a schema engine [13]. Authoring is Markdown, deliberately — there is no layout builder, and visual page composition stays developer territory in templates as (in my opinion) it should. Any blocks, inline editors, or draggable sections are overcomplicated, and sometimes heavyweight JavaScript overkill. In the Content Client everything renders at build time, so the rows below cover producing pages, not varying them per request.

Authoring, roles, and permissions #

Git has no permission model of its own — write access to a branch is write access to every file on it. But enforcement can happen at the Git host (GitHub, GitLab, etc.), at push and merge time, through four mechanisms:

Push rulesets: (GitHub GA 2024 [15]; GitLab push rules; pre-receive hooks generally) — server rejects any push modifying designated paths. True path-levelwritepermission.: changes touching designated paths require approval from the people who own them. Path-level approval permission.CODEOWNERS+ required reviewsBranch protection— no direct pushes to protected branches, required reviews, force-push blocked.** Required status checks**: the check runner must pass before merge. The softest mechanism, but portable to any host.

All four are server-side. The Content Client UI can be configured for roles, but it is not the security boundary.

A “role” here is just a combination of settings on the Git host: read (yes/no), write (scoped by path patterns), approve (scoped by path via CODEOWNERS), merge (scoped by branch pattern), and administer. Every dimension except read is arbitrarily divisible, so you can create as many role instances as you want:

• Scoped editors — a ruleset limiting a team to content/careers/, or content/fr/ for a translation vendor.
• Scoped approvers — CODEOWNERS entries per path: legal owns content/legal/, brand owns content/press/.
• Branch-scoped roles — rulesets and protections target branch patterns, so “can merge into campaign/* but not main” is expressible.
• Multi-approval tiers — require two approvals on main, or approvals from distinct owning teams, which gets you “senior approver”.

A pre-defined branching structure might look similar to this:

• main as always, remains the published site.
• draft/<slug> one change per branch, created through the client or by the agent [ 16], preview deploy per branch, deleted on merge. - campaign/<name> collects drafts that must ship together; merges to main as one reviewed unit.
• Preview is per-change, every draft/* branch gets its own ephemeral URL, built on push, dead on merge. Cloudflare Pages,Netlify,Vercel, andAmplifyall do this natively today — it’s the default behavior, not a feature you build. - No develop or staging branch required for authoring. Obviously still possible for developers.

The Content Client could prevent editors from seeing git terms. Renaming the vocabulary: branch = draft, pull request = submit for review, merge = publish.

The pipeline #

The previous section used CI as an enforcement hook; this section is the dynamic work a CMS server typically does. Everything a CMS’s application server computes per request, the pipeline computes per merge or on a schedule.

Search #

Search deserves a special callout because everyone thinks search needs a server. But at build time, an indexer can crawl the rendered site and write an inverted index as static files that deploy with everything else. In the browser, a small library fetches only the index chunks relevant to the query and scores results locally. Pagefind — built for exactly this — keeps a search on a ten-thousand-page site to a few tens of kilobytes transferred. [17] Because the index regenerates with every deploy, search is never stale relative to the site — a property database-backed search doesn’t automatically have. Reach for a hosted service (Algolia et al.) when you need what client-side genuinely can’t do: search analytics, typo tolerance and learned ranking, heavy faceting, or corpora in the hundreds of thousands of documents. Even then it’s the same architecture — the build step pushes records to their API instead of writing files.

Analytics are a non-issue because outside of per-page personalization [18], analytics have always run client-side in the user’s browser.

Benefits of the Content Client #

Now let’s discuss the advantages of a Content Client based website generator.

A CMS stores your content. The Content Client’s graph holds the organization’s knowledge about the content — the style guide the lint checks against, the rules the agent must not contradict, the research behind the claims, the decisions and their reasons.

The only thing that doesn’t exist currently is the desktop application that fuses the graph editor, the Git client, the agent, and the pipeline controls into something a non-developer can operate. That’s packaging, not invention, and packaging gaps get filled. I think there is ample opportunity in the enterprise market to recommend a switch like this based on my experience with the monoliths many organizations currently run. I foresee expansion of larger market clients into SSG based approaches solely because of AI, and this would help fuel it.

References #

1. Building with AI: Git-based vs headless vs traditional CMS (CloudCannon). Content “welded to everything around it” in monolithic systems, locked behind a database or vendor API, versus stored as plain files. Interested vendor source.

2. OpenCoder: The Open Cookbook for Top-Tier Code Large Language Models (arXiv). Training corpus composition for a state-of-the-art open code model: 78.4% GitHub code. DeepSeek-Coder reports 87% source code. On Markdown’s saturation of model output, see “The Last Fingerprint: How Markdown Training Shapes LLM Prose” (arXiv, 2026).

3. Sveltia CMS (GitHub). A framework-agnostic, open-source, Git-based CMS — one of a dozen-plus mature options with role-based access and cloud operation. CloudCannon, a commercial peer, has operated in the category for over a decade.

4. Usage Statistics of Content Management Systems (W3Techs, July 2026). WordPress: 41.5% of all websites. Detectable static generators: Hugo 0.1%, Gatsby 0.1%, Jekyll under 0.1%. Static output often carries no fingerprint a crawler can detect, so the true share hides inside the 29.9% “no CMS detected” slice — higher than measured, but still no rival to the platforms.

5. Netlify Acquires Gatsby, Its Struggling Jamstack Competitor (The New Stack, 2023). Gatsby Cloud subsequently discontinued; the framework moved to maintenance. See also The End of My Gatsby Journey (Smashing Magazine, 2024).

6. mdn/content (MDN Web Docs). 14,000+ pages of documentation stored as Markdown (99.9% of the repository) in a public Git repository with ~45,000 historical contributors, statically rendered by Yari. The Kubernetes documentation (Hugo) follows the same pattern. Current-generation SSGs build 10,000 pages in seconds (Hugo, Zola) to minutes.

7. We Migrated Our Blog from Static Site to Decap CMS (Insighture). Team ran Hugo ~4 years, then adopted a Git-based CMS — content stayed in Git; only the editing interface changed. Independent reversal case.

8. LLM Wiki: A pattern for building personal knowledge bases using LLMs (Andrej Karpathy, April 2026). Immutable raw sources; an agent-maintained wiki of interlinked Markdown pages; a schema file that “makes the LLM a disciplined wiki maintainer rather than a generic chatbot.”

9. llms.txt (Jeremy Howard / Answer.AI, 2024). Proposed Markdown index at the domain root for LLM consumption; auto-generated by Mintlify for hosted docs including Anthropic’s. Adoption remains thin (~1,000 domains as of mid-2025) and contested — cited here as a directional signal, not a settled standard.

10. AI Killed The CMS: How I Ditched Mine for Code and Markdown (Sid Bharath). First-hand WordPress-to-Astro-plus-Markdown migration; PageSpeed 67→100; the explicit caveat that “large teams need a CMS.” Independent, not selling a product.

11. Rebuilding DemandSphere with Jekyll and Claude Code (DemandSphere). 288-post migration off a CMS without external contractors; developer-availability cited as the driving motivation. Company engineering blog, not a CMS vendor.

12. Why Static Sites Are Making a Comeback in 2026 (Last Rev). The “when static is the wrong call” boundaries — real-time dashboards, applications, rapidly-changing per-user content — and handling dynamic features via services and edge functions.

13. Stop Using Markdown For Documentation (bandantonio, dev.to). The case against Markdown as a universal: no specification, 41+ incompatible flavors, no semantics without embedded HTML — portability in practice means committing to one toolchain’s dialect.

14. GDPR Compliance in Git: How to Handle Personal Data in Commit History (hoop.dev). Erasure applies to all instances of personal data including history; real deletion requires rewriting history (git filter-repo / BFG) across every clone and mirror. The mitigation is architectural: keep personal data out of the content repository.

15. Push rules are now generally available (GitHub, Sept 2024). Native per-file-path push restrictions on private/internal repositories; combined with branch protection and required reviews, write-side access control reaches path granularity. Folder-level read access remains unsupported.

16. GitHub MCP Server (GitHub). Official Model Context Protocol server letting any compatible assistant read a repository, create content, and open pull requests for human review; graphical configuration aimed at non-technical users.

17. Pagefind — static low-bandwidth search at scale (Pagefind). Client-side search designed for sites with tens of thousands of pages, using a chunked index loaded on demand.

18. AI Personalized Websites: Why Static Sites Die in 2027 (Aleksandr Lishchuk). The personalization-kills-static argument; its own stack runs personalization on edge functions over a static origin.