An AEO Metadata Layer That Answer Engines Can Actually Cite

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.

Real result

Ship this layer and an answer engine stops treating your page as one of ten blue links to skim — it can match your target-question tag straight to what someone asked, quote your answer paragraph verbatim with no surrounding context required, use the authority-level flag to pick your canonical page over a competing one of your own on the same topic, and match your entity list against its knowledge graph instead of guessing from keywords. 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. That’s the difference between showing up in search and being the sentence an AI assistant actually says back to the person who asked it.

Variations

• Multi-author or larger sites should tighten authorityLevel into a real content-governance rule: exactly 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, exactly like 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.