What CMS features matter for AEO?

The first thing a CMS decides is what comes back when something requests a URL. A CMS that builds the page on the server returns HTML with the words already in it. A site that builds some or all of the page in the browser may leave part of the text out of that HTML, and the missing part appears after a script runs.

Google can handle both. Its JavaScript SEO documentation says Googlebot queues pages for rendering and runs their JavaScript in a headless Chromium browser. The same page still recommends server-side rendering or pre-rendering, partly because, in Google's words, "not all bots can run JavaScript." Text that's already in the server's HTML doesn't depend on a crawler running JavaScript. So delivery belongs on the list when you choose or audit a CMS.

You can check this on your own site. Open a page, view its source, and search for a sentence from the body copy. If the sentence is there, that text is in the first response. If it isn't, treat that as a reason to inspect how the page renders. Google's URL Inspection tool shows the rendered HTML that Google works from.

A missing page should return a real 404 status code, because Googlebot reads status codes to learn that something went wrong. Request a URL that doesn't exist and see what status your CMS sends back. A "not found" message delivered with a 200 success status is the thing to fix.

We'd want a CMS to let you edit robots.txt yourself, write separate rules for separate crawlers, and add a noindex tag to a single page.

Per-crawler rules matter because AI companies run more than one crawler. OpenAI's crawler documentation lists OAI-SearchBot, which surfaces sites in ChatGPT's search features, and GPTBot, which collects content that may be used to train its models. OpenAI says each setting is independent of the other, so a site can allow the search crawler and disallow the training crawler.

That makes two things worth checking. The first is whether your CMS lets you write a rule for a named crawler. The second is whether those rules are set somewhere else, such as a hosting layer or a proxy in front of the site. A rule that blocks every crawler in order to stop training also blocks OAI-SearchBot. OpenAI says sites opted out of that crawler won't be shown in ChatGPT search answers, though they can still appear as navigational links. Blocking a crawler you wanted is one of the biggest AEO mistakes to avoid.

HubSpot shows what these controls look like in a real product. Its documentation on keeping content out of search results describes a robots.txt editor in the SEO & Crawlers settings. You can set rules for all connected domains or override them for one domain. Each rule names a user agent, so per-crawler rules are possible. For a single page, you add a noindex meta tag to the head HTML field in that page's settings.

The two tools do different jobs, and HubSpot warns against combining them. A robots.txt rule tells a crawler not to fetch the page. A noindex tag sits on the page and asks a search engine not to list it. If robots.txt blocks the crawler, the crawler never sees the tag. So decide which one you mean before you use either. Block crawling for the crawlers you don't want, and use noindex for the pages you don't want listed.

Templates supply the structure that pages share: the heading levels, the canonical tag, the slots for a title and description, and any structured data. A mistake in a template repeats on each page that uses it.

Google's guide to generative AI features in Search recommends semantic HTML where possible, and adds that perfect code isn't required. In CMS terms, we'd want the editor to produce real headings and let you set the title and description for each page.

With structured data, look at what the CMS already outputs before you add anything. Google's guide says structured data isn't required for its AI features and that there's no special markup to add. It still recommends markup because it helps a page qualify for rich results. HubSpot covers blog posts natively. Its blog settings include a Structured Data switch that turns on BlogPosting markup for a whole blog, and the switch is on by default for blogs created after August 4, 2022. HubSpot also warns against turning it on when custom schema already exists, since duplicate markup can cause problems in search engines.

Markup that a template generates from the post's own fields changes when the post changes. Markup pasted into a page by hand stays as it was until somebody goes back to it.

Lean Labs' Schema Rocket is an example of the first kind, built on top of HubSpot. Schema Rocket adds markup beyond the native blog setting. Lean Labs describes it as mapping a company's entities and the relationships between them, generating JSON-LD, and giving a person or company the same identifier on every page where they appear. It regenerates the markup when a workflow triggers it after a content change. Whether you buy a tool or build the templates yourself, ask the same thing of the CMS: can markup be generated from the content and updated without a developer editing each page? We go further into markup in what role structured data plays in AEO.

Answers go stale: a price changes, a product gets renamed, a process gains a step. When the person who knows the facts can edit the page in the CMS, a correction doesn't have to wait for a developer's time.

Lean Labs builds its client answer hubs in HubSpot for that reason. Its AEO service page says the content lives in HubSpot so the client's team can update answers without a developer. We describe that upkeep in how AEO works with existing HubSpot content.

Small template settings affect accuracy too. HubSpot's blog settings let you choose the format of the publish date, and the documentation notes a trap. If the format has the year typed in by hand, posts keep showing that year. The displayed date can then be wrong until someone replaces the typed year with the year token.

A feature the platform has isn't always a feature your subscription has. HubSpot's blog settings are available on all plans, but the same page lists exceptions. Changing a blog's root URL requires Marketing Hub Enterprise. Limiting a blog to access groups requires Content Hub Professional or Enterprise. Check any other platform the same way, and compare the plan you'd pay for. We cover HubSpot's product in what HubSpot CMS is and how Content Hub works and its top tier in what HubSpot CMS Enterprise includes.

A CMS can make a page reachable and readable. It can't make the page worth citing. Google's guide says that a page meeting every requirement still isn't guaranteed to be crawled, indexed or served. It also says useful, unique content will likely matter more than any other suggestion in the guide, and that Google Search ignores llms.txt files. So where Google Search is concerned, llms.txt support isn't a reason to choose one CMS over another.

For the same reason, we'd inspect the gaps before changing platforms. Go through the four controls on your current site and name what's missing. Then see whether a setting, a template change or a plan upgrade closes each gap before you price a migration.