Growth & Marketing AI

An AEO Metadata Layer That Answer Engines Can Cite

Jul 20, 2026

Result:

Your pages carry the fields an answer engine checks before it quotes something: a target-question tag it can match to what someone asked, a self-contained paragraph it can quote with no missing context, an authority flag that breaks ties between your own pages on the same topic, and an entity list its knowledge graph can match against — the gap between ranking for a query and being the sentence an AI assistant reads back.

▲ AEO METADATA DIAGRAM

One frontmatter entry, three surfaces an answer engine actually reads

Standard metadata gets a page ranked for a click. Five fields on one page, written once, get rendered onto meta tags, a JSON-LD graph, and a build-time crawler index, so nothing drifts between what a person sees and what a bot reads. Hover a field below to trace where it lands.

01 / FIELDS: written once in frontmatter

targetQuestion

The literal query

The exact question a person would type, not a scanning-friendly headline.

answerSummary

A quotable paragraph

60–120 self-contained words, no pronouns borrowed from the page.

authorityLevel

primary / secondary

A tie-breaker between a site’s own overlapping pages.

audience

Who it’s for

A comma-joined list, including a bot entry, named on purpose.

topics

Named entities

A list a knowledge graph can match, not just a keyword hint.

02 / SURFACES: rendered from the same fields at build time

<head> meta tags

Five new meta tags

target-question, answer-summary, authority-level, audience, and a repeated article:tag per topic.

JSON-LD @graph

Article + BreadcrumbList

name, abstract, an about[] array of schema.org Things, and keywords, in one graph.

llms.txt

A build-time crawler index

One line per page, grouped by section, built from the same query as the sitemap.

EFFECTFIELDS → SURFACES

The gap between ranking for a query and being the sentence an assistant reads back, closed with five fields and no second copy of the truth to keep in sync.

Shortcut

Paste this into Claude Code, pointed at your own content collection.

Requires manual input

Deciding which single page per topic gets authority level: ‘primary’, an editorial call about your own content. No account or credential involved.

Add an AEO metadata layer to my content collection, using my own schema's
field names:

1. Add five fields: a target question (the literal query the page
   answers), a self-contained answer-summary paragraph (60-120 words, no
   pronouns or context that depend on the rest of the page), an
   authorityLevel enum (primary/secondary), an audience array (including a
   "bot" entry), and a topics array of named entities.
2. Render all five as meta tags in my base layout's <head>: target
   question, answer summary, authority level, audience (comma-joined), and
   a repeated tag per topic.
3. Add them to each page's JSON-LD as an @graph containing an Article
   (name, abstract, an about[] array of schema.org Thing entities,
   keywords, isAccessibleForFree) plus a separate BreadcrumbList.
4. Generate a build-time llms.txt from the same collection query that
   renders my sitemap, grouped by section with a one-line summary per
   entry, and point robots.txt at it alongside the sitemap.

Show me the schema diff and the layout diff before writing the llms.txt
route.

Problem#

Standard SEO metadata — a title tag, a meta description, OpenGraph, a generic Article JSON-LD block — was built to help a search engine rank a page in a list of blue links a human then reads and clicks. An answer engine does something different: it reads several pages, picks one, and writes or speaks the answer itself, often without sending the reader to the page at all. A page optimized only for ranking can still lose that citation to a competitor whose metadata makes the answer engine’s job easier: a shorter path from “what is the user asking” to “here is the self-contained paragraph that answers it, and here is who wrote it.”

Pattern#

Reverse-engineer the pattern from pages that already show up as citations in AI answers, then adapt the field names to your own content schema instead of copying anyone’s literals:

  1. Add a target-question field, not just a title. A title is written for a human scanning a list; a target question is the literal query the page answers (“How do you build an ICP model that catches its own drift?” instead of “A Dynamic ICP Model That Catches Its Own Drift”). Render it as its own meta tag and as the name on the page’s Article JSON-LD, so an answer engine can match a user’s question to the page without inferring intent from a headline.
  2. Write a self-contained answer paragraph, separate from the human-facing description. A meta description is written to earn a click; an answer paragraph is written to be quoted directly, with no pronoun or context that depends on the rest of the page. Keep it dense (60–120 words), lead with the direct answer, and end with the specific mechanism or number that makes it defensible rather than generic.
  3. Flag authority level per page. One canonical, definitional page per topic should say so explicitly (a simple primary/secondary meta tag and matching frontmatter field) so an answer engine has a tie-breaker when several pages on a site cover overlapping ground.
  4. Tag audience, including the bot itself. A comma-separated audience list (who a page is written for) costs one field and tells a crawler this page was built with it in mind, not discovered as an SEO afterthought.
  5. Turn topics into entities, not just tags. Feed the same topic list two places: a keywords string for the standard OpenGraph/meta layer, and an about[] array of schema.org/Thing entities on the JSON-LD block. Keywords are a hint; an entity list is a structured claim about what the page covers, which is what an answer engine’s own knowledge graph can match against.
  6. Add a breadcrumb graph next to the article, not instead of it. JSON-LD supports multiple typed blocks in one @graph — an Article carrying the fields above, plus a separate BreadcrumbList establishing where the page sits in the site, cost nothing extra once the canonical URL is already computed for the Article block.
  7. Publish a build-time llms.txt. A sitemap lists URLs; an llms.txt summarizes them in plain language, one line per page, grouped by section. Generate it from the same content collection that renders the pages, so it can’t describe a page that no longer exists or omit one that just shipped, and point to it from robots.txt with an Llms-txt: line next to the Sitemap: one.

The fields, concretely#

This site’s recipes content collection (src/content.config.ts) carries five fields beyond the usual title/description/pillar/result: targetQuestion, answerSummary, authorityLevel, audience, and topics. Every recipe’s layout renders them three ways at once: as individual meta tags in <head>, as fields inside the JSON-LD Article block, and — for topics — as repeated article:tag OpenGraph meta and a keywords/about[] pair in the same JSON-LD block. One frontmatter entry, three surfaces, no drift between what a human sees in the page and what a crawler reads in its metadata.

Output#

The same fields also generate a build-time llms.txt, so any crawler that reads a plain-language summary before it reads HTML gets an accurate one instead of inferring from a sitemap.

See how these fields grade on a real page — this site built its own checker to verify them.

Check a page’s SEO/AEO metadata

Variations#

  • Multi-author or larger sites should tighten authorityLevel into a real content-governance rule: one primary recipe per topic cluster, enforced in a content-review checklist, not left to whoever writes the newest entry.
  • If a site’s answer engine traffic becomes measurable (referrer strings from ChatGPT, Perplexity, or Claude, where available), track citation rate per authorityLevel and topics combination — it turns this from a one-time schema change into a loop the same way the dynamic ICP model turns a static tag into one.
  • llms.txt scales past a hand-written file the moment a site has more than a few dozen pages: generate it from the same collection query that builds the sitemap, the way this site does, so the two never disagree about what’s published.
  • The entity list in step 5 compounds: once several recipes share a topic (“Postgres materialized views,” say), an answer engine can infer the site itself is authoritative on that entity across multiple pages, not just one — reason enough to keep the topic vocabulary consistent across recipes instead of inventing a new phrase for the same idea each time.

Nathaniel Stich writes Exit Velocities — recipes drawn from AI/growth systems shipped in production, not opinion pieces.

About the author

Tools used

Page metadata

Target question
What metadata does a site need to get cited directly in AI answers, not just ranked in search?
Answer summary
Getting cited in AI answers takes more than clean SEO metadata: a page needs a target-question meta tag stating the exact query it answers, a dense answer-summary paragraph an LLM can quote verbatim with no surrounding context required, an authority-level flag distinguishing the canonical page on a topic from supporting ones, an audience tag naming who the page is for (including bots), and a topic/entity list that feeds a JSON-LD about[] array instead of just keywords. Layered on top of standard OpenGraph, Twitter cards, and Article/BreadcrumbList JSON-LD, plus a build-time llms.txt index of every page with a one-line summary, this turns a site's existing content-management schema into the source of truth for both the human-facing page and the machine-facing citation.
Authority level
secondary
Audience
practitioner, hiring-manager, bot
Topics
Answer Engine Optimization, structured data, JSON-LD, llms.txt, content schema design

The same fields sitting in this page's target-question, answer-summary,authority-level, and audience meta tags and its JSON-LD — bot-facing metadata, made human-visible.