What answer engines can see, where your CMS actually matters, and why an AEO visibility score needs context.
TL;DR: No CMS makes a website “AEO compliant” on its own. Answer Engine Optimization (AEO) is the ongoing work of making content easy for search and AI systems to discover, understand, trust and use. SEO provides the foundation. Your CMS is an enabler: it should help you structure content, control the output and connect your chosen tools.
It's an easy question to write into an RFP: "Is the CMS AEO compliant?"
I get why people ask. Nobody wants to explain content architecture, retrieval and measurement in a procurement meeting if a green tick will do. “Compliant” makes a complicated subject feel reassuringly binary.
But it hides the decision you actually need to make.
When somebody says a CMS is AEO compliant, ask what they mean. Which standard, test or observable outcome? Are they talking about crawlability, structured data, AI visibility reporting or a checklist?
The distinction I would make is that your organisation practises AEO; your CMS does not pass it.
I use AEO as the umbrella term. GEO and LLMO describe roughly the same area: helping content become useful and visible in AI-generated answers.
Most of the work should feel familiar. Google says its established SEO practices still apply to AI features, with no extra technical requirements or special schema. Pages still need to be crawlable, indexable, useful and technically sound. Structured data should match the visible page. (Google Search Central)
Google’s point matters because, for its AI features, AEO does not sit beside SEO as a separate technical track. It depends on the same foundations: crawlable pages, sensible internal links, clear canonical signals, useful content and structured data that matches what people can see. If those foundations fail, there is nothing reliable for Google to retrieve, however carefully the answer itself is written.
If you already do SEO well, you have built much of the foundation for AEO. I would not attach a percentage to how much of AEO is “just SEO”. Crawlability, citations, referrals and content quality are different outcomes, not pieces of one calculation.
The remaining work is not a secret technical layer. It is mostly editorial discipline:
Answer the real question instead of writing around it.
Put the answer where people can find it, under clear headings with enough context to stand on its own.
Show who wrote or reviewed the content, when it was updated and what evidence supports it.
Keep important facts consistent across product pages, documentation and support content.
Do not treat these as decorative trust signals. If you say an article was reviewed by an Umbraco or Microsoft MVP, link the person’s name to a profile that confirms it. If you make a product, technical or research claim, link directly to the primary source. Give readers, search systems and answer engines a traceable path from the claim to the evidence behind it. A byline or “last updated” date with nothing behind it is presentation, not proof.
It sounds obvious, but this is where content often goes wrong: we publish the background, bury the answer and promise ourselves we will add the evidence later.
That does not mean chopping every page into “AI-friendly” fragments. The goal is clearer content for people, which also helps machines interpret and reuse it. (Google Search Central)
A buyer usually starts with the same practical questions: What is it? What can it do for me? Why should I believe you? When a page answers those questions explicitly, it becomes easier for people to evaluate and easier for search and answer systems to retrieve, interpret and quote. You do not need to write for a robot. You need to remove the unnecessary work both readers and machines would otherwise have to do.
The practical checks in my Umbraco AEO/GEO audit guide apply to any capable CMS.
The licence does not write the answer. The dashboard does not supply the evidence. And the acronym on the feature list does not keep an old page accurate.
When an answer engine retrieves web content, it works from public output such as URLs, rendered text, links, metadata and structured data. It does not inspect your CMS backoffice or editorial workflow. (Google Search Central, OpenAI Help Center)
This is where the conversation often goes wrong. We start looking inside the CMS while the answer engine is looking at the finished page.
Imagine two pages with the same answer. One hides it halfway down a rich-text field under “Our approach”. The other gives it a clear heading, names the reviewer and links to the supporting source. The answer engine does not care which CMS licence sits behind them. It works with what it can retrieve from the published page.
The same logic applies to the newer files some AEO checklists recommend, such as an llms.txt file or Markdown copies of every page. The llms.txt proposal was designed to help AI agents navigate a website and spend fewer tokens doing it (llmstxt.org). That is a reasonable goal for technical documentation.
It is not the same as a visibility signal. For its own AI features, Google says you do not need to create new machine-readable files, AI text files or markup to appear (Google Search Central). That does not make the files useless. They are cheap to add, and we publish one on umbraco.com ourselves.
We checked our own request logs. Between 12 October and 10 November 2026, umbraco.com served /llms.txt successfully about 22 times a day, up from about 13 a day in September. The requests came mostly from small AI, SEO and agent tools. GPTBot, ClaudeBot and PerplexityBot were not among the top fetchers. That is one site over one month, so I would not turn it into a rule. It does fit the picture above: some tools read the file, but I would not count on it as a route into the big AI assistants.
I treat them as a low-cost courtesy to agents, not as the work. If a tool generates them for you, keep any Markdown copies in sync with the real pages, and do not let a generated file stand in for the answer the page itself should give.
A file can point to good content. It cannot make the content good.
None of this makes the CMS irrelevant. It helps your team produce consistent output and move from evidence to an approved change. Those are enabling capabilities, not direct visibility signals.
This is where the CMS earns its keep. Whether you own the platform, manage the content or advise the team, I would look at three things: content modelling, output control and the path from evidence to an approved change.
A large rich-text field gives editors freedom but gives the organisation few guarantees about structure, sourcing, ownership or reuse.
Document types and block editors can give recurring patterns, such as definitions, steps and sourced claims, a consistent structure. Editors get a repeatable starting point, while enterprise teams can apply the same fields across products, markets and languages. That is a governance benefit, not a visibility signal. (Umbraco Block List documentation)
Poor implementation can undermine good content: the wrong heading hierarchy, fragile client-side rendering, conflicting signals about the canonical URL (the preferred version of a page), or structured data that does not match the page.
In Umbraco, the implementation team controls the templates that render the page. Developers can produce semantic HTML and generate JSON-LD, a machine-readable form of structured data, from the fields editors maintain. (Umbraco template documentation)
We do this on umbraco.com. Our page templates add WebPage structured data that takes the published and modified dates straight from Umbraco, so nobody has to remember to update them. Blog posts link to an author record with a name, job title and LinkedIn profile: the same traceable path from claim to person that I described earlier. Our FAQ block generates its structured data from the questions and answers editors write on the page, so the markup always matches what readers see.
Structured data can support search features, but it is not special AEO markup. Control creates the conditions for good work; it does not do the work.
Reporting is only the start. You need to move from “this page has an opportunity” to “here is the change we should review”.
Umbraco’s Management API gives authenticated workflows a documented way to work with content. (Umbraco Management API documentation) The Q3 2026 product update introduced the CMS Editor MCP in public beta, describing how supported AI clients could perform common editorial actions through the editor’s account and permissions. (Umbraco Product Update, Q3 2026)
Neither capability makes content more retrievable by itself. Their value is operational: your team can connect evidence, content and an assistant while keeping a person responsible for publication.
That is a more useful promise than claiming a platform is AEO-ready out of the box.
Think of this as the preflight check. You do not need an “AEO” button; ask the team to show you whether:
robots.txt, CDN and hosting infrastructure allow relevant crawlers to reach important content, which appears in rendered HTML with coherent headings and a clear canonical URL;
templates generate consistent metadata and structured data from managed fields;
editors can maintain evidence, ownership and review dates as structured content;
external workflows use authenticated, documented interfaces;
the organisation can change the implementation without depending on a bundled AEO feature.
That is technical evidence you can inspect. A feature badge is not.
Then we arrive at the dashboards, where tidy percentages can make a messy reality look reassuringly scientific.
"AEO tool" covers several jobs: page audits, prompt tracking, content workflows and analytics. You do not need your CMS to bundle them into one score. Choose the tools that fit your organisation, but inspect their methodology and keep the measurements separate.
Be most careful with prompt trackers. They borrow the language of rank tracking but measure something different: an AI answer is generated for each request, and it can vary with the prompt, the context and the run. (OpenAI Help Center, Google Search Help) A tracker observes what its chosen prompts produced during a measurement window, not what "the market" sees.
The honest wording is: "We appeared in 14 of 24 controlled observations." It is not: "We have 58% AI visibility." The first shows its denominator and scope. The second makes a sample sound like a market-wide measure.
Pair those observations with first-party evidence. Google has announced dedicated Generative AI impression reports in Search Console, initially rolling out to a subset of websites. Where available, these provide another layer of evidence. (Google Search Central) Track identifiable ChatGPT referrals in your analytics, while recognising that referral data is incomplete. I keep search demand, AI impressions, prompt observations, AI-referred visits and what visitors do next as separate layers. Five layers are less satisfying than one clean score. They are also more honest.
Then ask: "What did we learn, what did we change, and did traffic or impressions move with it?"
Whether you are buying, building or advising, ask the platform vendor or implementation team to show their work. Use four questions:
Can teams model answers, evidence and ownership as structured content?
Can they control markup, indexability and structured data?
Can workflow and automation tools access the content through documented, permissioned interfaces?
Who turns the evidence into a reviewed content change?
These work for an enterprise team choosing a platform and a partner explaining an implementation. Umbraco gives you control and extensibility, but the outcome still depends on implementation and ongoing editorial work.
Ask to see the content model, the rendered output and the improvement loop.
In other words: show the work, not the badge.
AEO is a discipline, not a CMS feature. No platform can replace useful, trustworthy and maintained content.
SEO still provides the foundation. Google says the same technical and content fundamentals apply to its AI search features.
The CMS affects execution, not visibility directly. Look for structured content, output control and open ways to connect tools.
Prompt tracking is controlled observation, not market share. It is useful when the method, denominator and raw answers remain visible.
Niels Christian Laursen: How to Audit Umbraco Content for Answer Engine Readiness
Google Search Central: AI features and your website
Google Search Central: Introducing Search Generative AI performance reports in Search Console
Google Search Central: Optimizing your website for generative AI features on Google Search
Google Search Help: Personal Intelligence in AI Mode
OpenAI Help Center: Searching the web with ChatGPT
Umbraco Documentation: Block List
Umbraco Documentation: Templates and Razor
Umbraco Documentation: Management API
Umbraco: Product Update, Q3 2026
llmstxt.org: The /llms.txt file
An AEO content audit checks whether a page answers a real question, adds useful evidence, and can be discovered and understood across search and AI experiences. This guide gives Umbraco editors and developers a practical checklist covering content, published output, technical SEO, internal links, structured data, and measurement, without pretending there is a magic “AEO-ready” switch.