How does AEO work with existing HubSpot content?

Google's guide to generative AI search starts from ordinary search eligibility. A page must be indexed and able to appear in Google Search with a snippet. The site must also be included in generative AI features in Search Console. Google's help page for that control says inclusion is the default, and a property with a parent inherits the parent's choice. The guide also lists what you can skip for Google Search: llms.txt and other special files, breaking content into small chunks, rewriting in a style meant for AI, and any special schema markup.

So a HubSpot site doesn't need a parallel set of AI pages for Google. A post that already meets those conditions is eligible as it stands, though Google says plainly that indexing and serving aren't guaranteed.

Other engines have their own access rules, and that's a check we'd make on an older site. OpenAI's crawler documentation says OAI-SearchBot is what surfaces sites in ChatGPT's search features, and GPTBot collects content that may be used for training. The two settings are independent, so a site can allow one and disallow the other. If someone once added a broad rule to your robots.txt file to keep AI crawlers away from training data, read it again and see whether it also blocks the search crawler.

The useful first step doesn't happen on the pages. It's deciding which questions you want to be the cited answer for. Lean Labs, a HubSpot agency, describes its AEO process as starting there. It builds a managed question set from HubSpot sales calls, CRM insights, Search Console demand and competitor prompts, and then writes the answers in HubSpot. If your team logs calls and deal notes in HubSpot, part of that material is already in your account.

With the list in hand, match each question to a page you've already published before you plan a new one. A blog that has run for several years has often touched the same question more than once, in posts written years apart.

Suppose buyers keep asking how long implementation takes for a team of about 50. Suppose your blog has three posts written to answer that same question, from 2021, 2023 and 2024, and none of them states a number. The 2023 post is the most complete of the three and also gets the most search traffic. In that case you'd keep the 2023 URL, put a direct answer near the top, add the figure your customer success team can stand behind, and say what it's based on. You'd bring over anything from the other two posts that's still true, then retire those two and redirect them to the one you kept.

You'd then have one complete page where there were three partial ones, at an address search engines already know.

It's tempting to do the opposite and publish a short new page for every phrasing of every question. Google's guide warns against that. It says creating separate content for each variation of a search, mainly to influence rankings or AI responses, violates its scaled content abuse policy. It adds that its systems can match a page to a query when the wording differs. One strong page can serve several phrasings.

The same guide suggests reducing duplicate content where you have time, and merging posts that answer the same question is one way to do it. When you merge, the retired URLs need somewhere to go. Google's guidance on changing URLs recommends server-side permanent redirects, such as a 301 or 308. It says to point each old address straight at its final destination, because chains of redirects add delay. It also advises against sending many old URLs to one unrelated page such as the homepage, which can be treated as a soft 404. Once the redirects are live, update the internal links that pointed to the retired posts so they go to the surviving page directly.

A redirect tells a search engine where the content went. It doesn't promise that the combined page keeps every ranking the old ones had. So merge posts only when they answer the same question for the same reader, and choose the survivor by how well it answers, with traffic as one input. Posts that share a keyword but do different jobs should stay separate.

A new page makes sense when the question list turns up something no existing page answers. It also makes sense when the only match is a page built for a different job, such as a product page that shouldn't turn into an essay. For the writing itself, see FAQ content that AI answer engines will quote.

HubSpot's blog settings include a structured data switch. HubSpot's documentation says it turns on the BlogPosting schema type to support article rich results in search engines, and that it's on by default for blogs created after August 4, 2022. If your blog is older than that, check whether the switch is on. HubSpot also warns against turning it on where custom schema already exists, because duplicate schema can cause problems in search engines. So look at what your templates already output first.

Google doesn't treat that markup as a condition for AI answers. Its guide says structured data isn't required for generative AI search, though it still helps with eligibility for rich results. Its page on AI features adds that structured data should match the visible text on the page. So the switch is worth a look on an older blog, and the improved answer is still what gives an engine something to cite. We look at this more closely in the role of structured data in AEO.

HubSpot's content guidance for AI has formatting advice that suits an edit of an old post. It recommends clear headings for each section, tables for comparisons, written descriptions as the main source of information with images in support, and specific alt text. Those changes also help a person reading the post, which is a reasonable test for any edit made in the name of AEO.

HubSpot has an AEO tool for measuring the result, which it labels beta. Its documentation says the tool comes with Marketing Hub Professional or Enterprise, or as a standalone AEO subscription. It runs a set of tracked prompts against ChatGPT, Gemini and Perplexity every day.

HubSpot counts mentions and citations separately. Brand visibility is how often your brand is mentioned across the prompts you track, and a source can be cited without your brand being named. When the work is on your own pages, we'd read the citation reports alongside the mention figures. One of them compares how often engines cite your domain against competitors' domains. That figure covers the whole domain, so it can't credit a change to one edited page.

HubSpot recommends tracking before and after a change, and reviewing results across multiple days or weeks, since responses shift over time. So set up the prompts and record the baseline before you edit the implementation post.

The prompts are a sample you chose, so the results describe those prompts and not everything buyers ask. Google's AI Overviews and AI Mode also aren't on the tool's list of supported engines. For those, Search Console's generative AI performance report shows impressions by page, where an impression means a link to your site was shown in one of Google's generative AI features.

Neither visibility report says whether the improved page brought in business. Lean Labs describes its own reporting in three layers: mentions, citations and prompt coverage first, AI referral traffic and engaged visits second, and contacts, deals and pipeline third. If you run your CRM in HubSpot, that third layer sits in the same account as the content.

We'd report the three separately for each page you improve. For the implementation post, that's the page's impressions in Search Console and your domain's citations for the tracked prompts, then the visits the page received, then the contacts and deals that followed. Our answer on tracking traffic from AI answer engines covers the middle figure.

Keeping them apart lets you see what moved after the edit and what didn't. A single blended score would hide whether a rise came from more citations, more visits or more deals.