optimizeaeo
Pages that get cited are usually not "AI optimized" after the draft is done. They are briefed as source-of-truth assets before writing starts.
TL;DR
- Start with the prompt the page should answer, not the keyword the page should rank for.
- Make the first screen identify the entity, answer the question, state the scope, and point to evidence.
- Add structured data only when it matches visible page content. Schema is a clarity layer, not a substitute for useful text.
What is the job of a citable page?
The job of a citable page is to give an answer engine a specific, trustworthy source for a specific user question. That is narrower than "rank for a keyword" and more demanding than "cover the topic."
A citable page usually does one of four jobs:
| Page job | User prompt | Page goal |
|---|---|---|
| Define | "What is X?" | Give a precise answer and scope |
| Compare | "X vs Y for Z?" | Help the user choose |
| Prove | "Is X effective?" | Show evidence and method |
| Instruct | "How do I do X?" | Give steps and prerequisites |
Before writing, choose one primary job. A page can support secondary questions, but it should not try to be a glossary, comparison, case study, product page, and support doc at once.
How should the brief start?
The brief should start with the exact answer-engine prompt the page is meant to satisfy. Write it as a natural question, not a search keyword.
Bad brief:
Target keyword: AI visibility platform Word count: 2,000 Include: definition, benefits, use cases
Better brief:
Primary prompt: How do I know whether my brand is being cited in ChatGPT, Perplexity, Gemini, and AI Overviews? Page job: Instruct and compare. Source-of-truth claim: AI visibility should be measured by prompts, mentions, citations, cited URLs, and answer accuracy, not by traffic alone. Evidence required: Methodology page, product screenshots, sample prompt panel, raw export example.
The better brief gives the writer a retrieval target. The page does not merely mention the topic. It exists to answer a prompt with evidence.
What should appear above the fold?
The first screen should answer four questions: what this page is about, who it is for, what the answer is, and why the reader should trust it.
Use this opening structure:
# How to Track AI Visibility Across Answer Engines Updated: May 7, 2026 Author: [Named person or team] AI visibility should be tracked by prompt, answer engine, brand mention, citation URL, and answer accuracy. Traffic alone misses cases where a brand is recommended without a click or cited through a third-party source. ## TL;DR - Track mentions and citations separately. - Build prompts from customer language, keyword data, and semantic fanout. - Verify results on a fixed schedule because answer engines change.
This is not decorative structure. It gives a retrieval system a clean title, a date, a named entity, a direct answer, and a summary.
How should sections be structured?
Each major section should answer one question and keep the evidence nearby. A section that needs three other sections to make sense is harder to retrieve accurately.
Use this section pattern:
## How often should we re-run an AEO prompt panel? Re-run important AEO prompts every two weeks, or immediately after major page, product, or platform changes. A fixed schedule makes answer drift visible without turning every variance into an emergency. Example: - 20 prompts - 4 answer engines - 1 target page per prompt - fields: answer, mentions, citations, cited URLs, notes Limitation: This does not measure every personalized or logged-in answer state.
The section has the prompt, answer, example, and limitation in one place. That is good for humans and for systems that retrieve passages.
What evidence belongs on the page?
Evidence should match the claim. If the claim is technical, cite documentation. If the claim is performance-related, cite data. If the claim is product-related, link to the source-of-truth page.
Use this evidence map:
| Claim type | Evidence to include |
|---|---|
| Technical behavior | Official docs, reproducible test, source code, standards |
| Product capability | Product page, docs, screenshots, API reference |
| Performance lift | Study, analytics extract, methodology, sample size |
| Comparison | Table with criteria, dates, and source links |
| Process recommendation | Checklist, template, example output |
Google's AI features docs are a good constraint here. Google says there are no additional technical requirements for AI Overviews or AI Mode beyond Search eligibility, and it recommends making important content available in textual form and ensuring structured data matches visible text. That means evidence and visible content still matter more than special AI files.
How should schema be used?
Schema should describe the visible page, not create a second version of the answer. Google structured-data guidelines for FAQ content emphasize that the FAQ content must be visible on the source page, and the question and answer should contain the full text.
For a guide page, Article or a more specific article subtype can describe authorship, date, headline, and related metadata. Schema.org's Article type supports properties that help identify the content and its relationship to other entities.
For FAQ sections, use FAQPage only when the page really contains a list of questions with accepted answers, and when the use case fits Google's current rich-result guidelines. Do not add FAQ schema to every product page just because answer engines exist.
Example:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "How to Track AI Visibility Across Answer Engines",
"dateModified": "2026-05-07",
"author": {
"@type": "Organization",
"name": "OptimizeAEO"
}
}
This markup is not a citation guarantee. It is a clarity signal that should match the page users can read.
How should crawler access be checked before publishing?
Crawler access should be checked before writing is considered done. If the page cannot be fetched by relevant systems, the content work is not finished.
Checklist:
[ ] URL returns 200 without login. [ ] Important text appears in the rendered HTML. [ ] Page is internally linked from a relevant hub. [ ] XML sitemap includes the URL where appropriate. [ ] robots.txt allows the search crawlers you intend to allow. [ ] CDN or bot-protection rules do not block relevant user agents. [ ] noindex, nosnippet, max-snippet, and data-nosnippet rules are intentional.
OpenAI and Anthropic both document separate search or user-retrieval bots. That makes crawler policy part of the page launch checklist, not a separate infrastructure chore.
How should the page be verified after publishing?
Verification should test whether the page is discoverable, retrieved, and represented accurately. Do not stop at "published."
Use this post-launch panel:
Prompt 1: What is [topic]? Prompt 2: How do I [task]? Prompt 3: [brand] vs [competitor] for [use case] Prompt 4: Best [category] tools for [audience] Prompt 5: Does [brand/page] support [specific feature]?
For each prompt, record:
| Field | Why it matters |
|---|---|
| Engine and mode | Answers vary by system |
| Exact prompt | Small wording changes matter |
| Brand mentioned | Mentions can influence without clicks |
| Target cited | Citation shows visible source use |
| Other sources cited | Shows who owns evidence |
| Accuracy notes | Bad visibility can be worse than no visibility |
Run the panel at launch, after indexing, and again two weeks later.
What are the common shipping mistakes?
The first mistake is writing for a topic instead of a prompt. The page becomes broad, but no section is the best answer to a specific question.
The second mistake is separating evidence from claims. The claim appears in the introduction, the data appears in a PDF, and the methodology appears on another page. That forces the answer engine to assemble trust from scattered fragments.
The third mistake is publishing thin comparison pages. If a comparison page does not include criteria, scope, dates, and source links, it is less citable than a third-party review.
The fourth mistake is hiding the answer below a marketing intro. Answer engines do not need a warmup. Readers do not either.
The fifth mistake is treating schema as a patch. If the visible page is vague, markup will not make it authoritative.
What should the final page checklist look like?
Use this before publishing:
Page purpose [ ] Primary prompt is written in natural language. [ ] Page job is defined: define, compare, prove, or instruct. [ ] One source-of-truth claim is named. Content [ ] First paragraph answers the prompt. [ ] TL;DR appears near the top. [ ] H2s are questions or direct claims. [ ] Every H2 starts with a direct answer. [ ] Every major claim has nearby evidence. [ ] Dates and scope limits are visible. Technical [ ] Page is crawlable and indexable where intended. [ ] Important content is text, not image-only. [ ] Structured data matches visible text. [ ] Internal links connect the page to related source pages. Verification [ ] Prompt panel is ready. [ ] Target citation and mention fields are defined. [ ] Owner is assigned for post-launch fixes.
What does a complete AEO page brief look like?
A complete AEO page brief is specific enough that a writer, editor, SEO, and developer can all see their part of the job. It should be shorter than the final page, but more precise than a keyword brief.
Use this template:
# AEO Page Brief Working title: [Question or claim] Primary answer-engine prompt: [Natural-language prompt] Secondary prompts: - [Follow-up prompt] - [Comparison prompt] - [Implementation prompt] Page job: [Define | compare | prove | instruct] Audience: [Specific role, maturity, and use case] Source-of-truth claim: [One sentence we want this page to be cited for] Evidence required: - [Primary documentation] - [Original data or screenshot] - [Methodology note] - [Named example] Required sections: 1. TL;DR 2. Direct answer 3. Evidence 4. How to apply it 5. Caveats 6. Verification steps Technical requirements: - Crawlable HTML - Visible author/date - Internal links to source pages - Schema matching visible content - Prompt panel for post-launch testing
The key field is the source-of-truth claim. Without it, the page can become broadly useful but hard to cite. A citation-worthy page usually owns one sentence better than any competing page.
How do you decide between one page and a cluster?
Use one page when the question is narrow and the evidence fits in one place. Use a cluster when the user question touches product claims, methodology, comparisons, documentation, and proof.
One page is enough for:
- "What is
OAI-SearchBot?" - "How do I add FAQ schema to a government FAQ page?"
- "What fields should an AEO prompt panel include?"
A cluster is better for:
- "Best AI visibility tools for B2B SaaS"
- "How does our product compare with three competitors?"
- "How should enterprises measure answer-engine visibility across regions?"
The cluster should have a clear hub. The hub answers the broad question and links to source pages. Each source page handles one proof job: methodology, pricing, docs, comparison, case study, glossary, or support.
Example cluster:
/ai-visibility/ Main guide and buyer framing /ai-visibility/methodology/ How data is collected and measured /ai-visibility/prompts/ Prompt panel template and examples /ai-visibility/compare/ Comparison criteria and alternatives /customers/octopus-energy-ai-visibility/ Case evidence
This gives answer engines multiple retrievable pages with consistent facts. It also gives human readers a path from answer to proof to action.
How should editors review for AEO before publishing?
Editors should review for extraction, not just style. The question is whether a useful passage can be lifted without losing meaning.
Run this editorial pass:
| Check | What to look for |
|---|---|
| Directness | Does each H2 answer its own question in sentence one? |
| Local context | Does the section name the entity and scope? |
| Evidence proximity | Is the source or example near the claim? |
| Caveat clarity | Are limits stated before the reader overgeneralizes? |
| Table quality | Are comparisons structured where prose would blur them? |
| Internal links | Does the page point to source-of-truth pages? |
| Staleness risk | Does the claim need a date or review cadence? |
If a section cannot pass that review, rewrite the section before touching schema. A clean passage is the raw material. Markup can describe it; it cannot rescue it.
How should developers support citable pages?
Developers support AEO by making the important content available, stable, and inspectable. That means the page should not depend on fragile rendering for the claims most likely to be cited.
Developer checklist:
[ ] Server returns a clean 200 status for the canonical URL. [ ] Canonical tag points to the intended page. [ ] Important copy appears in HTML or reliably rendered output. [ ] Headings are semantic H1/H2/H3, not styled divs. [ ] Tables are real tables or readable HTML, not image-only. [ ] Structured data validates and matches visible text. [ ] Page does not block key crawlers through robots, CDN, WAF, or login. [ ] Internal links are regular links that crawlers can discover.
The point is not to build for bots instead of people. It is to avoid shipping a beautiful page whose evidence is hard to fetch, parse, or verify.
One simple test helps here: copy the rendered page text into a plain text document and ask whether the source-of-truth answer, evidence, date, author, and next step still make sense. If the plain text version is confusing, retrieval systems may struggle too.
What to do Monday morning
1. Rewrite one upcoming content brief around a primary answer-engine prompt instead of a keyword. 2. Add a source-of-truth claim, evidence requirement, and verification prompt panel to the brief. 3. Update the first paragraph so it answers the prompt directly. 4. Move evidence next to the claim it supports. 5. Check crawler access for Googlebot, OAI-SearchBot, Claude-SearchBot, and user-triggered agents where relevant. 6. Add schema only after the visible page content is accurate and complete. 7. Run a five-prompt panel after publishing and log mentions, citations, and accuracy.