Every CMS vendor now sells an AEO feature. A dashboard that scores your pages, a monitor that tells you when ChatGPT stops citing you, a credit-metered "optimize for AI" button. The market is real — 97% of CMOs reported a positive impact from answer-engine optimization in 2025, and 94% plan to spend more on it in 2026, against a backdrop where Gartner expects traditional search volume to fall 25% by 2026. So the budgets are moving. But almost all of that spend is aimed at the wrong layer. Whether an answer engine can cite you is decided by your architecture, not by a feature you switch on. And the layer that owns your architecture is your CMS. That is the bottleneck.
Three things determine it, and none of them is an "AEO feature":
Rendering, content model, operations. All three are owned by your CMS — which is exactly why a scoring dashboard bolted onto the side can't fix any of them. It can only grade the symptoms.
The single hardest constraint is the one marketers hear about last: AI crawlers do not run JavaScript. Vercel's analysis of crawler traffic across its network found that GPTBot fetches JavaScript files but never executes them, and ClaudeBot downloads JavaScript on nearly a quarter of its requests with no rendering engine to run it. Only Googlebot renders. So a client-rendered site — the default for a lot of modern stacks — returns a near-empty
The point for this argument is narrower: whether your pages render on the server is a CMS decision, not a content decision. No amount of keyword work or schema markup reaches a crawler that received an empty page. You can't optimize text a bot never saw.
Once a page is readable, two things decide whether it gets quoted. First, what's on it: the Princeton GEO study found that adding statistics, quotations, and citations lifts a page's visibility in generative engines by 30–40%. Second, how stable it is: Profound's citation tracking shows 40–60% of the domains an answer engine cites change month to month. Engines churn their sources, and they favour stable, consistent entities over pages that shift under them.
Both of these are content-model properties. A CMS that stores content as structured data — clean fields, not a blob of rendered HTML — is the decoupled, maximally-extractable shape answer engines parse best. And a site whose published pages are frozen — fixed URLs, fixed facts, versioned snapshots — is the stable target citation engines keep coming back to, not the moving one they drop.
AEO is not a one-time pass. The engines change what they reward, your competitors publish, your facts go stale. So the metric that actually compounds is how cheaply you can change the site — and that is where most stacks quietly bleed.
On a headless CMS, a structural change is a developer ticket; on a page builder, it's a human clicking through a dashboard. Both put a person and a delay between "this page should answer the question directly" and the page actually doing it. The teams winning at AEO have collapsed that loop: they describe the change and it ships. That is the whole premise of running content operations through an agent instead of a dashboard — you ask, the agent edits, the site republishes.
Here is the distinction the vendors blur. Webflow is shipping an agentic AEO product; Storyblok and Contentful sell AI suites and GEO explainers. These are monitoring and generation features bolted onto a SaaS backend you still log into and pay per seat for. A monitor that tells you ChatGPT stopped citing you is useful exactly once — after that you need to fix the cause, and the cause lives in the rendering and the content model the feature can't touch.
This is the same pattern we traced in the manifesto and in Claude Code as a CMS: an AI layer on top of an architecture built for human editors is still an architecture built for human editors. AEO-as-a-feature is AEO-as-marketing. The readable, structured, fast-to-change site is the product.
agntcms is the architecture, stated plainly. The public site is a frozen, server-rendered Next.js site with no AI running in production — so every crawler gets the full content in the first response. Content lives as structured JSON, the machine-readable shape engines parse cleanly. Published pages are dated snapshots, so URLs and facts stay stable while you keep editing. And every change goes through the agent, so the iteration loop is a sentence, not a sprint.
None of that is a feature you enable. It's how the thing is built — AEO-correct by construction — and it's open source under MIT, so you can read every line of how the page reaches the crawler.
AEO outcomes are decided by your architecture, and your CMS owns your architecture. Can the crawler read the page, is the content structured and stable, can you change it fast — three properties, all owned by the content system, none fixable by a dashboard bolted on the side. Headless vendors sell you the dashboard because the architecture is the part they can't change. agntcms is the version where the readable, structured, fast-to-change site is the product.
Run the test first: is your site machine-readable for AI? Then read why crawlers can't read most sites, and why llms.txt won't save you. The code is open on GitHub.
github.com/agntcms
What actually decides whether an answer engine cites you
Three things determine it, and none of them is an "AEO feature":
- Can the crawler read the page at all. If the bot that feeds ChatGPT or Claude gets an empty shell instead of your copy, nothing downstream matters. This is a rendering property of your stack.
- Is the content structured and stable. Answer engines reward extractable facts and consistent entities, and they re-pick their sources constantly. This is a content-model property.
- How fast can you change things. AEO is a moving target; the team that ships fixes weekly out-ranks the team that files a ticket and waits. This is an operations property.
Rendering, content model, operations. All three are owned by your CMS — which is exactly why a scoring dashboard bolted onto the side can't fix any of them. It can only grade the symptoms.
The rendering wall
The single hardest constraint is the one marketers hear about last: AI crawlers do not run JavaScript. Vercel's analysis of crawler traffic across its network found that GPTBot fetches JavaScript files but never executes them, and ClaudeBot downloads JavaScript on nearly a quarter of its requests with no rendering engine to run it. Only Googlebot renders. So a client-rendered site — the default for a lot of modern stacks — returns a near-empty
<div id="root"> to the very systems sending you AI traffic. We walk through this in full, with the test you can run yourself, in why ChatGPT and Claude can't read your site and the 60-second machine-readable test.The point for this argument is narrower: whether your pages render on the server is a CMS decision, not a content decision. No amount of keyword work or schema markup reaches a crawler that received an empty page. You can't optimize text a bot never saw.
Structured, stable content gets cited
Once a page is readable, two things decide whether it gets quoted. First, what's on it: the Princeton GEO study found that adding statistics, quotations, and citations lifts a page's visibility in generative engines by 30–40%. Second, how stable it is: Profound's citation tracking shows 40–60% of the domains an answer engine cites change month to month. Engines churn their sources, and they favour stable, consistent entities over pages that shift under them.
Both of these are content-model properties. A CMS that stores content as structured data — clean fields, not a blob of rendered HTML — is the decoupled, maximally-extractable shape answer engines parse best. And a site whose published pages are frozen — fixed URLs, fixed facts, versioned snapshots — is the stable target citation engines keep coming back to, not the moving one they drop.
The iteration tax
AEO is not a one-time pass. The engines change what they reward, your competitors publish, your facts go stale. So the metric that actually compounds is how cheaply you can change the site — and that is where most stacks quietly bleed.
On a headless CMS, a structural change is a developer ticket; on a page builder, it's a human clicking through a dashboard. Both put a person and a delay between "this page should answer the question directly" and the page actually doing it. The teams winning at AEO have collapsed that loop: they describe the change and it ships. That is the whole premise of running content operations through an agent instead of a dashboard — you ask, the agent edits, the site republishes.
"AEO feature" is not AEO architecture
Here is the distinction the vendors blur. Webflow is shipping an agentic AEO product; Storyblok and Contentful sell AI suites and GEO explainers. These are monitoring and generation features bolted onto a SaaS backend you still log into and pay per seat for. A monitor that tells you ChatGPT stopped citing you is useful exactly once — after that you need to fix the cause, and the cause lives in the rendering and the content model the feature can't touch.
This is the same pattern we traced in the manifesto and in Claude Code as a CMS: an AI layer on top of an architecture built for human editors is still an architecture built for human editors. AEO-as-a-feature is AEO-as-marketing. The readable, structured, fast-to-change site is the product.
Where agntcms fits
agntcms is the architecture, stated plainly. The public site is a frozen, server-rendered Next.js site with no AI running in production — so every crawler gets the full content in the first response. Content lives as structured JSON, the machine-readable shape engines parse cleanly. Published pages are dated snapshots, so URLs and facts stay stable while you keep editing. And every change goes through the agent, so the iteration loop is a sentence, not a sprint.
None of that is a feature you enable. It's how the thing is built — AEO-correct by construction — and it's open source under MIT, so you can read every line of how the page reaches the crawler.
The short version
AEO outcomes are decided by your architecture, and your CMS owns your architecture. Can the crawler read the page, is the content structured and stable, can you change it fast — three properties, all owned by the content system, none fixable by a dashboard bolted on the side. Headless vendors sell you the dashboard because the architecture is the part they can't change. agntcms is the version where the readable, structured, fast-to-change site is the product.
Run the test first: is your site machine-readable for AI? Then read why crawlers can't read most sites, and why llms.txt won't save you. The code is open on GitHub.
github.com/agntcms