Blog · Content that gets cited
Definition pages, and why engines love them

The short answer: Engines reach for definition pages because a definition is already shaped like the thing a retrieval system needs: one short, self-contained passage that still makes sense after it has been cut away from the page around it. Little else on a website survives that cut so cleanly. A good glossary entry is a pre-written answer. A bad one is a row in a directory, too tangled in its neighbours to be lifted out whole.
That is the whole mechanism, and it is worth being precise about why it works, because the same precision tells you which of your own definition pages are doing nothing.
The retrieval unit is a passage, not a page
Nobody outside these products can watch one retrieve. What is published about the method is consistent, though, and has been since the paper that named retrieval-augmented generation in 2020: documents are split into passages, the passages are scored against the question, a handful are kept, and the model writes from those. If that is the shape of the systems answering today, then everything you published that did not land inside a kept passage is, for that answer, invisible. We treat it as the working model rather than as a described fact about any named engine.
Most marketing prose fails that cut. A paragraph from the middle of a product page relies on the heading above it, the screenshot beside it and the three paragraphs before it. Lift it out and it reads as a fragment. A definition does not depend on any of that. "X is a Y that does Z, used by W when they need V" carries its own context. It is the rare passage that is equally true alone and in place, which is the best available explanation for why definitions turn up in answers so often. It is an explanation, not a measurement: we cannot see any engine's scoring step. The broader version of this argument is in What makes a page citable by an AI engine.
The demand is measurable, on one engine
On Google, definitional questions are the ones most likely to be answered rather than listed. Pew Research Center logged the browsing of 900 US adults across 68,879 Google searches in March 2025 and found that 60% of queries beginning with a question word such as who, what, when or why returned an AI summary, against 8% for one or two word searches. Queries of ten words or more produced a summary 53% of the time. Pew says plainly that it could not identify AI summaries on other engines, so this is a single engine, a single month and one US panel, and none of it describes ChatGPT, Perplexity, Copilot, Claude or Grok.
The same study found what that costs in clicks. When an AI summary was present, users clicked a traditional result on 8% of visits, against 15% when no summary appeared. Links inside the summary itself were clicked on roughly 1% of visits. Those are shares of visits in that panel's March 2025 browsing, not a rate anyone has shown holds for your traffic.
Read those two findings together and a strategy follows, for Google at least. The "what is" query is there among the most likely to be absorbed into an answer and among the least likely to send you a visit. You are not writing a definition page for its traffic. You are writing it so that the sentence the engine produces is your sentence, with your framing of the problem inside it, because that framing is what the reader carries into the next three questions they ask.
What markup actually buys you here
Schema.org has a type for this. DefinedTerm is described as "a word, name, acronym, phrase, etc. with a formal definition", and it takes inDefinedTermSet to say which vocabulary the term belongs to and termCode to identify it inside that set. A glossary is a DefinedTermSet holding many of them.
Now the part people get wrong. DefinedTerm is not in Google's list of supported rich result features, so marking it up will not win you a decorated Google listing. We checked the search gallery on 12 October 2026 and the type is absent; you can repeat that check in a minute. The precedent is FAQ markup. Google narrowed it on 14 September 2023 to well known, authoritative government and health sites, added a deprecation notice on 8 May 2026, and removed the documentation page on 15 June 2026, which now redirects to that changelog entry. A supported type can stop being one.
So the markup is not a display feature on Google. What it can do is disambiguate. It states that this URL is the canonical place your organisation defines this term, which set it belongs to and what else it is the same as. That is worth having when a term is overloaded, when your industry uses a word differently from the rest of the web, or when something has to decide which of four pages on your domain is the authority on a phrase. Which consumers read it, and with what weight, we cannot see, and the limits below say so. Add sameAs pointing at the relevant Wikidata or Wikipedia entry where one honestly applies, and you have connected your private vocabulary to a public one.
Five ways definition pages fail
One URL, one hundred terms. The most common glossary we meet in audits is a single page listing every term with forty words each. Chunk it and you get slabs containing the tail of one definition and the head of the next. Neither is self-contained, and the page competes with itself for every term it covers. One term, one URL, with an index page that links to them.
The definition uses your product name as the genus. "Our approach to supply visibility is the practice of..." is not a definition, it is a positioning line. An engine cannot lift it to answer a generic question, because the first noun is a brand. Define the category honestly, then say where you sit in it.
The answer is not in the HTML. Glossaries love accordions. If the body of the definition is inside a collapsed component that only populates on click, the fetched document contains the term and not the meaning. Check it with one command: curl -s <url> | grep -c "<a distinctive phrase from the definition>". A zero means the engine sees the heading and nothing underneath.
The glossary route is often the slowest on the site. Term pages are frequently generated by a CMS query nobody has profiled, sitting on a path no performance work ever touched. That is a pattern in the sites we audit, not a law. They are also the lowest-value page for a fetcher to wait on, which is a bad combination. Slow pages get dropped before they get read covers what that costs.
The same term, defined three ways. The glossary says one thing, the product page says another, a two year old blog post says a third. We have watched answers hedge in that situation, or quote whichever copy was retrieved. This is the failure described in Outdated pages are poisoning your answers, and glossaries are where it breeds, because nobody ever reviews them.
How to write one that gets lifted
Lead with a single sentence that could stand alone on a slide: term, category, function, who uses it. Keep it under forty words and put it immediately under the H1, before any preamble.
Then earn the rest of the page, because a forty word page will be treated as thin. Add what the term is often confused with, and say plainly how the two differ. Add a short worked example with a real number. Add the common mistake. That structure gives a retrieval system four distinct passages that each answer a slightly different question, which is four chances to be the chunk that gets kept rather than one.
Write the plural, the acronym and the expanded form into the body at least once each, since people ask with all three. Date the page visibly and update it when the meaning drifts, which in this field it does.
Definition pages also do quiet work for pages that need more room. A comparison page that gets cited is stronger when it can link each criterion to a term you have defined once, properly, instead of re-explaining it in a table cell. The glossary becomes the place your vocabulary lives, and every other page borrows from it.
Honest limits
We cannot tell you how much of a lift this is, and the hedges above are where we know we are short. There is no public dataset isolating glossary pages as a citation source across engines; our own evidence is the audits we run, a prompt set of about forty-five prompts across five engines with retrieval on and off, on a self-selected sample of client sites rather than a census of anything, and in those audits a definition page is almost always one of several things that changed at once, so we cannot attribute a change to it. The engine numbers in this post are Google's behaviour in one month of one panel's browsing, and we have no comparable measurement for any other engine. The passage account in the second section is how retrieval is described in public, not something we have verified inside a live engine. And DefinedTerm is the weakest claim here: we can confirm Google does not use it for a rich result, and we cannot confirm that any assistant reads it at all, so treat it as cheap, correct metadata rather than a lever.
If you want to see where your own terms stand before spending anything, the self-check includes the fetch test above and a way to compare what three engines say your category word means.
FAQ
Should every term get its own page? Every term a buyer would type on its own, yes. Terms that only make sense inside another explanation can stay as sections, with an anchor link from the index.
Is a glossary at risk of being treated as thin content? It is if the pages are generated at scale with nothing in them but a dictionary gloss. The protection is substance per page: the confusion, the example, the mistake. Volume without that reads as filler to a ranking system and gives a retrieval system nothing to keep.
Does DefinedTerm markup produce a rich result? No. It was not among Google's supported rich result types when we checked the gallery on 12 October 2026. Its value is machine-readable disambiguation, and how much any assistant makes of that we cannot see.
What if our definition disagrees with the industry's? Say so explicitly on the page, state the common usage first, then your variant and the reason. A page that acknowledges both is more useful to a model than one that pretends the disagreement does not exist.
How often should definition pages be reviewed? Put them on the same cycle as pricing. Twice a year is enough in a stable category, and quarterly in one where the vocabulary is still settling.
Sources
- Pew Research Center, Google users are less likely to click on links when an AI summary appears in the results, 22 July 2025. Browsing of 900 US adults, 68,879 Google searches collected 1 to 31 March 2025, results scraped 7 to 17 April 2025, Google only by the authors' own statement. Checked 12 October 2026: www.pewresearch.org/short-reads/2025/07/22/google-users-are-less-likely-to-click-on-links-when-an-ai-summary-appears-in-the-results/
- Schema.org, DefinedTerm type definition, for the wording quoted and for termCode and inDefinedTermSet, checked 12 October 2026: schema.org/DefinedTerm
- Schema.org, DefinedTermSet type definition, checked 12 October 2026: schema.org/DefinedTermSet
- Google Search Central, structured data markup that Google Search supports, checked 12 October 2026 and listing no DefinedTerm feature: developers.google.com/search/docs/appearance/structured-data/search-gallery
- Google Search Central, documentation updates log, entries dated 14 September 2023, 8 May 2026 and 15 June 2026. The old FAQPage documentation URL now redirects here: developers.google.com/search/updates#removing-faq-rich-result
- Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, NeurIPS 2020, for the passage-retrieval description, not for any claim about a named engine: arxiv.org/abs/2005.11401