What HubSpot tested on AI search, and what to change on your own site

HubSpot ran seven experiments to find out what actually changes how often a business appears in AI answers. Five worked, one did nothing at all, and one was inconclusive.

I sat in that session in Boston in September 2026. Below is each of the seven, then the part that matters more for most businesses: what to change on your own site. Three pages do most of the work and almost nobody has them right.

Search has split into two things, and the second one does not behave like the first.

People still type into Google. They also ask ChatGPT, Gemini and Claude, and those answers are assembled rather than ranked. A page sitting at position three can be completely absent from an AI answer. A page with almost no links behind it can be quoted over and over.

The consequences run through everything below. Links matter less than they did. Structure and clarity matter more. Being the original source of a fact beats being the fifth site to repeat it. And any part of your website a machine cannot read has quietly stopped existing.

One number for scale, because it is the only one here from published research rather than a conference stage. Seer Interactive analysed 5.47 million queries across 53 brands and found organic click-through rates were 61% lower when an AI Overview was present. Their 2026 update finds that decline has slowed, from 1.3% in December 2025 to 2.4% in February 2026, which they call a levelling off rather than a recovery.

One thing about how they worked, before the results. The team was small: two experimenters, one technical and one content, plus a manager. They set themselves a 20% win rate target, deliberately low, so that people would try bold things and be allowed to be wrong.

That is the most transferable idea in the session and it is worth more than any single result below. It is also why this list contains a failure and an inconclusive rather than five wins and a shrug.

1. Glossary pages, and why this is the one to copy

The biggest win, and the one almost any business can do without a developer.

They built glossary pages for the core terms in their category. One concept per page, plain definitions, written in normal English. The reported result was a 36% lift in visibility, those pages outperforming the rest of the site by 15%, and rankings across hundreds of keywords within months.

The reasoning is worth understanding rather than copying blind. Language models hold concepts as positions in a kind of map. A glossary of the terms in your field puts your business close to the concepts you want to be associated with. You are not tricking anything. You are stating plainly what things mean, in your field, in your words.

I have a caveat and it is ours. We built an SEO glossary years ago, long before anyone said "answer engine". It ranks. Our page explaining the local pack sits at position 3.3 for its term and took 2,695 impressions last month. It was clicked zero times. Not a handful. None.

That is the whole argument in one line. Ranking and being visited have come apart. A glossary page now has to earn its place by being the thing that gets quoted, not the thing that gets clicked.

2. Reclaiming traffic from your 404 page

In 2025 AI tools invented URLs constantly, sending people confidently to pages that had never existed. HubSpot built a module on their 404 page that looked at what the visitor had been trying to reach and offered real pages instead. Thousands of recovered visits and more than a thousand additional signups.

Models are much better at URLs now, so this specific tactic has a shorter shelf life than the others. The general point survives and is worth more than the tactic: your own log files contain a record of how AI tools are interacting with your site, and almost nobody has looked at it. That is not a growth hack. It is reading something you already have.

3. Fixing the pricing page

Their pricing pages looked fine to people and were effectively unreadable to AI crawlers, because the important information was loaded by JavaScript. So the models guessed, and the guesses were wrong.

They published a plain, factual, JavaScript-free version. Accuracy scores improved for five of their six product areas.

This one gets a fuller treatment below, because for most businesses it is the single highest-value page on the site and the one most likely to be producing a wrong answer right now.

4. llms.txt, which did not work

llms.txt is a proposed file you add to your site to tell AI systems how to read it. The industry got briefly excited about it. It was on a lot of agency recommendation lists, ours included.

HubSpot tested it properly. Not a single bot crawler attempted to visit the file. Not fewer than expected. None.

So the honest position today is that it does not work. It costs almost nothing to add, which is part of why it spread, but it is not doing anything, and a recommendation to add it is currently a recommendation resting on nothing. If that changes, it changes, and we will say so.

The wider lesson is the more useful one. It had not been tested and everybody recommended it anyway. Worth remembering the next time something in this field arrives with confidence attached.

5. Use case by industry pages

These connect one capability to one industry and one specific situation. Not "CRM software", but closer to "how a car dealership follows up test drive enquiries".

Each page carried the challenge, the solution, a table of real results, integrations, and a deliberately quotable takeaway. Built for a person and a machine at once, which is usually the right answer. More than 15,000 ChatGPT crawls within 30 days, and 92% of the pages cited within months.

It works because the question has changed shape. A Google search is three words. A question typed into an AI assistant is a paragraph, full of context about a specific situation. Generic pages do not match specific situations. Uncomfortably narrow pages do.

If you do one thing from this section: take your two or three most profitable services and write a page for each that is narrow enough to feel slightly embarrassing.

6. Pre-rendering, and why crawlers give up

Page speed matters more to AI crawlers than it does to Google, because they are considerably less sophisticated than Googlebot. Many will not wait around. Many will not run your JavaScript at all.

HubSpot used a pre-rendering service rather than rebuilding anything. Load time went from over two seconds to roughly 70 milliseconds, and OpenAI's crawl volume doubled.

There is a test here you can run in under a minute, and it is the first thing I would do. Turn JavaScript off in your browser and reload your most important page. Whatever is still on the screen is roughly what a lot of AI crawlers are seeing. If the page empties out, nothing else in this article matters until that is fixed.

7. FAQs from customer call transcripts, inconclusive

They built FAQs from real customer call recordings, which sounds obviously correct, and it produced no meaningful lift in citations.

Their own reading is that the content was right and the placement was wrong: they built a new repository for the questions instead of putting them on the pages that already had readers.

I would go further. Publishing something in a new place and expecting it to be found is the oldest mistake in content work, and AI has not changed it. Put the answers where the people already are.

Here is the part that surprises people. AI tools do not reliably read your Google or Facebook reviews. Those platforms are awkward to crawl, heavily scripted, and built for human interfaces rather than machines. So the strongest trust signal most businesses own is close to invisible in the place it now matters.

A review hub fixes that. It is a page on your own domain, in plain HTML, gathering what people have actually said about you.

What makes one work:

• /Real words, not star counts. A wall of five-star ratings with no text says nothing quotable. A sentence describing what went right is a sentence an answer engine can use.
• /Named platforms. Say where each review came from. Provenance is what makes a claim checkable.
• /Recent ones at the top. Reviews from four years ago read as history, not evidence.
• /The mix, not the highlights. A page of only perfect scores reads like marketing. A page including a middling review and how you responded to it reads like a business.
• /Plain text. If it is loaded by a widget, assume it is not being read.

Ours, since it would be poor form to recommend this without doing it: we have 136 reviews collected since 2019 at an average of 5.00, and until they sit on a page we control, most of that is invisible to the systems doing the recommending. We are building it now. It should have been done years ago.

Service pages are where the buying decision happens, and most are written as though the only reader is a person who already trusts you.

The checklist we now work through on every one:

• /A visible last-updated date. Not the publish date buried in the markup, a date a reader can see. It tells a person the page is maintained and gives a machine a reason to prefer it over an older page saying something different. If the date is there it has to be honest: update it when you update the page, not on a schedule.
• /What is included, itemised. Vague scope is the most common reason an AI answer about a service is wrong. It cannot summarise what you never stated.
• /What is not included. The most underused line on any service page. It prevents the wrong enquiry and it is exactly the kind of specific, checkable statement that gets quoted.
• /Who it suits, and who it does not. The size of business, the situation, the stage. It costs you nothing but the enquiries you would have lost anyway.
• /A price or a range. More on this below.
• /How long it takes, and what happens first. "Weeks or months" is not an answer. A rough timeline and a named first step is.
• /One question-style heading per section. Headings phrased as the question a buyer would actually ask read better, and in some engines they perform better too.
• /Plain text for all of the above. If the specifics live in a tab, an accordion or a script, treat them as absent.

None of this needs a redesign. It is mostly writing down things you already know and have never had a reason to put in public.

The pricing page is where I would start after the technical check, because it is the page most likely to be producing a wrong answer about your business right now, and wrong answers about price are expensive in a way that never shows up in a report.

Someone asking an AI assistant what you charge is a long way down the buying process. If the answer is invented, you lost them before you knew they existed.

What to put on it:

• /What each option costs, or a genuine range with what moves it up and down. A range beats silence by a distance.
• /What is extra. Setup, onboarding, third-party costs, anything that turns a quoted figure into a different invoice.
• /The trade-offs between options, in words. Not a feature grid with ticks. A sentence saying who each tier is actually for.
• /When you are not the right choice. The same principle as everywhere else here.
• /The date it was last checked, for the same reason as the service pages.

The two-minute version of this section: open an AI assistant and ask what your business charges. Then ask what a named competitor charges. If it answers confidently and wrongly about you and accurately about them, you have found your first job, and it is a writing job rather than a technical one.

In this order. None of it needs a budget conversation.

1. 01Ask an AI assistant about your main service and your prices. Write down what it says. That is your baseline and it takes five minutes.
2. 02Turn JavaScript off and reload your most important page. If the content disappears, that is the first job and it is technical.
3. 03Write the "who this is not for" paragraph and put it on your main service page. Twenty minutes, and it will be among the most quoted things on your site within a year.

After that, in rough order of return: a glossary of the terms in your field, a review hub on your own domain, and one use case page narrow enough to feel uncomfortable.