SEO AEO GEO

AEO and GEO#

Answer Engine Optimization (AEO) and Generative Engine Optimization (GEO). Make content discoverable, extractable, and citable by AI search experiences.

This skill encodes principles. AI search products evolve fast. The principles age slower than the products.

When to use#

• Optimizing content for AI overviews and generative answer engines
• Building or updating llms.txt
• Structuring content so AI assistants can extract and cite it correctly
• Future-proofing a site as search shifts from blue links to AI answers
• Auditing whether existing content is AI-friendly
• Adding signals that help AI assistants identify the site as a trustworthy source

When NOT to use#

• Traditional on-page or technical SEO (use seo-onpage or seo-technical)
• Keyword research (use seo-keyword)
• Off-page authority and link building (use seo-offpage)

This skill stacks on top of those. Strong AEO/GEO requires strong fundamental SEO underneath.

Required inputs#

• The site or page to optimize
• The topic area or query types AI should cite the site for
• Access to inspect rendered HTML and structured data

The framework: 5 layers#

AI search visibility comes from five stacked layers. Each layer compounds.

1. Extractable content structure#

AI systems extract facts and pull citations from content. Make extraction easy.

• Direct answers. Open major sections with a definitive 1 to 3 sentence answer to the question that section addresses. AI extracts the first answer it sees.
• Question-headers. Use H2s and H3s phrased as questions when natural. Mirrors how people prompt AI.
• Atomic facts. When stating a fact, state it once, clearly, with the supporting context next to it. AI struggles when claims are spread across paragraphs.
• Tables and lists. AI parses these reliably. Use them for comparisons, specs, steps, and data.
• Definitions early. When introducing a concept, define it inline. Do not assume the reader (or AI) saw a definition three pages ago.
• Numbered steps. For procedural content, number every step. Avoid prose disguised as instructions.

2. Citation worthiness#

AI cites sources it considers authoritative. Earn that consideration.

• Original data. Surveys, studies, proprietary research, internal benchmarks. AI prefers primary sources over restatements.
• Specific numbers. "Roughly 40 percent" beats "many." Specific stats with sources beat round-number generalizations.
• Named experts. Author bios with credentials, links to professional profiles, schema-marked-up Person entities.
• Date stamps. Publication date AND last-updated date, both visible AND in schema. AI heavily weights recency for time-sensitive queries.
• Methodology disclosure. When stating a finding, briefly note how it was reached. AI rewards transparency.
• Citations of other sources. Linking to authoritative sources you used builds reciprocal credibility.

3. Structured data depth#

Schema is how you speak machine-readable language. AI assistants parse it heavily.

• Schema.org types appropriate to content (Article, FAQPage, HowTo, Recipe, Product, Organization, Person, LocalBusiness, etc.)
• Required AND recommended properties filled in (most sites only fill required, leaving signal on the table)
• Person schema for authors, with sameAs links to verifiable profiles
• Organization schema on the homepage with logo, contact, social links
• FAQPage schema for content with genuine question-answer pairs
• HowTo schema for procedural content
• BreadcrumbList schema site-wide
• Validates in Schema.org Validator AND Rich Results Test (some properties differ)

4. AI-readable accessibility#

Beyond traditional SEO, AI tools need access patterns of their own.

• llms.txt at the site root. A markdown file at /llms.txt describing the site's content, key URLs, and what topics the site covers. See references/llms-txt-guide.md (opens in a new tab).
• llms-full.txt (optional) - a complete content dump for AI training and context, if the site permits it.
• robots.txt allowing AI crawlers. Decide explicitly which AI crawlers to allow (GPTBot, ClaudeBot, Google-Extended, PerplexityBot, etc.) or disallow. Do not block by default if visibility matters.
• Clean HTML semantics. Semantic tags (article, section, nav, main) help AI parse structure.
• Avoid client-side-only rendering for critical content. Many AI crawlers render less reliably than Googlebot.

5. Real-world entity signals#

AI builds knowledge graphs and prefers entities with multiple consistent signals.

• Wikipedia entry if the brand or person qualifies for notability (do not force this; it requires genuine notability)
• Wikidata entry for the entity, with consistent properties
• Consistent NAP (Name, Address, Phone) across all citations
• Brand mentions across multiple authoritative sources. AI cross-references entity claims across the open web.
• Social profile schema linking owned profiles via sameAs properties
• Reviews and reputation signals. Aggregate ratings on Google Business, Trustpilot, industry-specific review sites where applicable

Workflow#

1. Audit current state. Run the 5-layer framework against the existing site. Score each.
2. Identify the priority queries. What questions should AI cite this site for? List 10 to 20.
3. Test current AI visibility. Query each of the major AI products (those relevant to the audience) with the priority questions. Note which sources they cite.
4. Identify gaps. Is the site cited? On which queries? Why does it lose to the cited sources?
5. Layer-by-layer plan.
   • Fix extractable structure on top 20 priority pages
   • Add citation-worthy signals (original data, expert authorship, methodology)
   • Deepen schema implementation
   • Build/update llms.txt
   • Strengthen entity signals
6. Implement and re-test. AI products update frequently. Re-test priority queries quarterly.

Failure patterns#

• Treating AEO/GEO as separate from SEO. Strong fundamental SEO is a prerequisite. AI cites pages, not magic.
• Stuffing FAQ schema on pages that have no genuine FAQs. Search engines and AI alike penalize manufactured FAQ blocks.
• Hiding key content behind heavy JavaScript. AI crawlers render less reliably. Server-render or pre-render critical content.
• Optimizing for one AI product only. Different products use different ranking and citation logic. Optimize for the principles, not for one product's quirks.
• Ignoring entity strength. Content alone, with no real-world entity signals, will not get cited reliably for branded or expertise-related queries.
• Treating llms.txt as a magic bullet. It helps, but it is one of many signals.
• Static optimization. AI products evolve faster than search algorithms historically did. Re-audit at least quarterly.

Output format#

Default output is a markdown plan at aeo-geo-strategy.md. Structure:

1. Current AI visibility audit (which queries cite the site, which do not)
2. 5-layer scorecard
3. Priority queries (the 10 to 20 the site should be cited for)
4. Layer-by-layer remediation plan
5. Implementation roadmap
6. Re-test schedule (quarterly)

Reference files#

• references/llms-txt-guide.md (opens in a new tab) - How to write a useful llms.txt, with examples.
• references/extraction-friendly-patterns.md (opens in a new tab) - Content patterns that AI extracts cleanly, with before/after examples.

Supporting file: references/extraction-friendly-patterns.md#

Extraction-Friendly Patterns#

Content patterns that AI search experiences extract cleanly, with before-and-after examples. The goal is not to write for AI exclusively. The goal is to write so a human reader gets the answer fast and an AI extractor gets it fast too. The two overlap more than people think.

The principle#

AI extractors and skim-readers want the same thing: the answer first, the supporting context second. Content that buries the answer behind preamble loses both audiences.

Three structural moves do most of the work:

1. Lead with the answer. First sentence of the section answers the section's question.
2. Use semantic structure. Headings name the question. Lists separate items. Tables compare options. Code blocks contain code.
3. Be self-contained. Each section should make sense without depending on the section above.

Everything below is an application of these three moves.

Pattern 1: question-led headings#

Headings phrased as the question the user actually asks.

Bad#

Onboarding optimization#

Better#

How long should employee onboarding take?#

The question form does three jobs at once: it matches likely search queries, it tells the reader what they will learn, and it tells the AI extractor what answer follows.

Pattern 2: answer-first paragraph#

The first sentence answers the question. Subsequent sentences provide context, caveats, and depth.

Bad#

How long should employee onboarding take?#

Onboarding has many definitions across organizations. Some companies define onboarding as the first day, some as the first week, and others as the entire ramp-up period. There is no industry consensus, and the question depends on many factors. With that said, most modern companies aim for a structured program lasting somewhere between 30 and 90 days.

Better#

How long should employee onboarding take?#

Most structured onboarding programs run 30 to 90 days, with 90 being the most common. The exact length depends on role complexity, company size, and how much time managers can dedicate. The first week typically covers logistics and culture; the first month adds shadowing and small projects; the second and third months ramp the new hire into full ownership.

The "Better" version puts the extractable answer in the first sentence. The follow-up adds context without burying the lead.

Pattern 3: definitions in inverse pyramid#

Define the term in one sentence, then expand.

Bad#

What is a service blueprint?#

A service blueprint is a versatile tool used by many designers and product teams. Originally developed in the 1980s by G. Lynn Shostack at Bankers Trust, it has since been adopted across industries from healthcare to retail. Service blueprints help teams visualize the relationships between people, processes, and physical evidence in a service experience.

Better#

What is a service blueprint?#

A service blueprint is a diagram that maps every step of a service experience, both what the customer sees and what happens behind the scenes. It typically uses lanes for the customer journey, frontstage actions, backstage actions, and supporting systems. Originally developed by G. Lynn Shostack in the 1980s, it is now standard in service design, healthcare workflow design, and operations planning.

The first sentence is a complete, extractable definition. AI assistants quoting your page will quote this sentence. Search snippets will lift it.

Pattern 4: numbered lists for sequenced steps#

Sequenced procedures go in numbered lists. Not in prose.

Bad#

To deploy with the CLI, first you'll want to run npm install. Once that completes, run npm run build to generate the production bundle, then npm run deploy to push to your environment. After that, verify the deployment by checking the status endpoint.

Better#

How to deploy with the CLI#

1. Install dependencies: npm install
2. Build the production bundle: npm run build
3. Deploy to your environment: npm run deploy
4. Verify the deployment by checking the status endpoint.

The numbered list extracts cleanly into "how-to" snippets, FAQ-style answers, and HowTo schema. The prose version forces the extractor (human or AI) to do the work of parsing the steps.

Pattern 5: bullet lists for parallel items#

Parallel items go in bullets. Especially "what is included" or "options" lists.

Bad#

Our enterprise tier includes single sign-on, audit logs, advanced role-based access controls, dedicated support, and custom data retention policies.

Better#

What is included in the enterprise tier#

• Single sign-on (SSO)
• Audit logs
• Advanced role-based access controls
• Dedicated support
• Custom data retention policies

The bullet form is extractable. An AI assistant asked "what does the enterprise tier include" can quote this list verbatim.

Pattern 6: tables for comparisons#

When comparing 2+ options across 2+ criteria, use a table. AI extractors handle tables well; prose comparisons get garbled.

Bad#

The free plan supports up to 3 projects and 5 team members, with email support only. The pro plan extends this to 25 projects and 25 team members, adds priority support, and includes the API. The enterprise plan removes all limits, adds SSO, audit logs, and a dedicated success manager.

Better#

Feature	Free	Pro	Enterprise
Projects	3	25	Unlimited
Team members	5	25	Unlimited
Support	Email	Priority	Dedicated CSM
API access	-	✓	✓
SSO	-	-	✓
Audit logs	-	-	✓

Pattern 7: explicit Q&A blocks#

For pages where the user is asking a direct question (FAQs, help docs, glossaries), use explicit Q&A formatting.

Pattern#

Q: [The question phrased as the user would ask it]

A: [Direct answer in 1-3 sentences. Optional supporting paragraph after.]

This is what FAQ schema lifts directly. AI extractors recognize the pattern and treat it as a discrete answerable unit.

Pattern 8: self-contained sections#

Each section under an H2 should make sense if read in isolation. AI extractors often pull a single section as the answer to a query. If the section depends on context from earlier sections, the answer it surfaces will be incomplete or wrong.

Bad#

Setup#

Use the same approach we discussed in the previous section, but with the production endpoint instead of staging.

Better#

Setup for production#

Run the deploy command against the production endpoint:

npm run deploy --target=production

The production endpoint requires the PROD_API_KEY environment variable. See "Environment variables" for setup.

The "Better" version stands alone. A reader (or AI assistant) landing here from search gets a complete answer.

Pattern 9: explicit data and units#

State numbers, ranges, and units explicitly. Vague modifiers ("a lot," "fast," "some users") do not extract.

Bad#

Our customers see a major improvement in conversion after switching.

Better#

On average, our customers see a 23% lift in conversion within the first 30 days after switching, based on data from 412 customers measured between January and March 2025.

The "Better" version has extractable specifics: the metric, the magnitude, the time window, the sample size, and the date range. Trustworthy AI assistants prefer extracting specifics.

Pattern 10: structured author and date metadata#

For any content that depends on currency or expertise, expose the metadata visibly and in schema.

• Author byline with a real name and a credential or one-line bio.
• Publish date and last updated date in human-readable form.
• Reviewer if the content is reviewed by an SME.
• Article schema with author, datePublished, dateModified, and (where applicable) reviewedBy.

AI search uses author and date signals as part of trustworthiness scoring.

Pattern 11: explicit topic boundaries#

Tell the reader (and the extractor) what the page is and is not about.

Pattern#

What this guide covers#

This guide covers backup strategies for Postgres databases on managed services (AWS RDS, GCP Cloud SQL, Supabase). It does not cover self-hosted Postgres tuning, backup of file storage, or disaster recovery testing.

If you are self-hosting Postgres, see [other guide]. If you are designing DR drills, see [other guide].

This pattern protects against AI summaries that conflate your scope with adjacent topics.

Pattern 12: predictable summary blocks#

Sections like "Summary," "Key takeaways," "TL;DR" at the top or bottom of an article extract well. Keep them tight: 3-7 bullets, one short sentence each.

Pattern#

Key takeaways#

• Aim for 30-90 day onboarding, with 90 being the most common.
• First week: logistics and culture. First month: shadowing and small projects. Months 2-3: full ramp.
• The single highest-impact factor is manager time, not program design.
• Track time-to-productivity, not arbitrary onboarding completion.

A summary block doubles as the AI snippet, the social card excerpt, and the email digest line.

What to avoid#

These patterns hurt extraction:

• Walls of text without headings. The reader and the extractor both lose place.
• Inline references that depend on prior sections. "As mentioned above" is invisible to a snippet.
• Vague modifiers in place of numbers. "Many users," "several studies," "a long time."
• Jargon without definition. AI assistants will define it incorrectly if you do not.
• Marketing fluff in lead sentences. "Discover the powerful possibilities of..." extracts as gibberish.
• PDFs and images for content that should be text. Tables and key data trapped in images cannot be extracted.
• Iframe-embedded content. AI assistants do not consistently follow iframes.

How to test#

After writing a page, simulate extraction:

1. Read only the H1 and the first sentence under each H2. Does the page still make sense?
2. Read only the bullet lists, tables, and Q&A blocks. Do they answer the obvious questions?
3. Ask an LLM (in a fresh context) the questions your page answers. Does it pull useful, accurate snippets from your page?
4. Check Google's "People also ask" for your topic. Does your page answer those exact questions?

If a test fails, the structure needs more semantic markup, not more words.

Supporting file: references/llms-txt-guide.md#

llms.txt Guide#

llms.txt is a markdown file at the root of a domain (e.g., example.com/llms.txt) that helps AI systems understand what the site is, what it covers, and which URLs are most valuable.

It is the AI-era equivalent of robots.txt plus a sitemap, written in plain language for language models.

This guide walks through how to write a useful one.

What llms.txt is for#

• Tell AI assistants what the site is and what it covers
• Point AI to the most valuable URLs for citation
• Provide structured context that helps AI summarize and cite the site accurately
• Reduce the chance of AI hallucinating about your brand or content

What it is NOT:

• A ranking signal (yet, possibly ever)
• A guarantee of citation
• A replacement for sitemap.xml or robots.txt
• A way to block AI crawlers (use robots.txt for that)

The format#

llms.txt is a markdown file with a specific structure:

# [Site or Brand Name]

> [One-sentence description of what the site is and who it serves]

[1 to 3 paragraphs of context. Who runs the site, what topics it covers, what makes it credible, what audience it serves. Plain language.]

## [Section 1 - typically content categories or product lines]

- [Title](URL): [One-line description]
- [Title](URL): [One-line description]

## [Section 2]

- [Title](URL): [One-line description]

## Optional

[Less critical resources.]

Section headers are flexible. Use whatever organization fits the site's content.

Example: a simple content site#

# Example Knowledge Base

> A free guide library on [topic area] for [audience].

We publish in-depth guides, comparisons, and how-tos on [topic area]. Content is written by [credentials of authors] and updated [frequency]. Our methodology is documented at /methodology.

## Core guides

- [The Complete Guide to X](https://example.com/complete-guide-x): A 5,000-word reference covering fundamentals through advanced topics.
- [How to Choose Y](https://example.com/how-to-choose-y): Decision framework with comparison tables and worked examples.
- [The Beginner's Guide to Z](https://example.com/beginner-z): A 30-minute primer for someone new to the topic.

## Comparisons

- [A vs B](https://example.com/a-vs-b): Head-to-head feature, pricing, and use case comparison.
- [Top 10 [Category]](https://example.com/top-10): Ranked list with selection criteria.

## Tools

- [Calculator](https://example.com/calculator): Free interactive tool for [purpose].
- [Templates](https://example.com/templates): Downloadable templates with examples.

## About

- [About us](https://example.com/about)
- [Methodology](https://example.com/methodology)
- [Editorial standards](https://example.com/editorial-standards)

Example: a SaaS product site#

# ProductName

> [Product category] for [target audience]. [Core value proposition in one phrase].

ProductName is built and operated by a team of [size and background]. We serve [audience description]. The product is used by [scale, e.g., "over 10,000 teams" or "from solo founders to Fortune 500 companies"].

## Product

- [How it works](https://example.com/product): Overview of core functionality and architecture.
- [Pricing](https://example.com/pricing): Transparent pricing tiers and what each includes.
- [Integrations](https://example.com/integrations): Third-party tools we connect with.

## Documentation

- [Getting started](https://docs.example.com/getting-started): 15-minute setup guide.
- [API reference](https://docs.example.com/api): Complete API documentation.
- [Best practices](https://docs.example.com/best-practices): How successful customers use the product.

## Resources

- [Customer stories](https://example.com/customers): How specific customers achieved specific outcomes.
- [Blog](https://example.com/blog): Engineering posts, product updates, and industry analysis.
- [Changelog](https://example.com/changelog): Recent product changes.

## Trust

- [Security](https://example.com/security): SOC 2, encryption, compliance.
- [Privacy policy](https://example.com/privacy)
- [Terms of service](https://example.com/terms)

What to include#

A good llms.txt is curated, not exhaustive. Include:

• Cornerstone content. Your 10 to 30 best, most authoritative pieces.
• Decision-support pages. Comparisons, calculators, frameworks.
• Authority signals. Methodology, editorial standards, about pages.
• Trust signals. Security, privacy, compliance, certification pages.
• Recency cues. A changelog or "latest" link if you publish frequently.

What to leave out:

• Every URL on the site (use sitemap.xml for that)
• Marketing fluff with no informational substance
• Pages that exist primarily for SEO (low-quality programmatic content, doorway pages)
• Internal admin URLs

What to write in the description#

The opening description (under the title, prefixed by >) is what AI extracts when asked "what is [site]?" Make it count.

Bad description:

A leading provider of innovative solutions in the digital space.

Good description:

A free guide library on home renovation for first-time buyers, with calculators and template contracts.

The good description names: what it is (guide library), what topic (home renovation), who it serves (first-time buyers), and what's unique (calculators and templates).

Length and depth#

• Title and one-sentence description: required
• Context paragraphs: 1 to 3 paragraphs, 100 to 400 words total
• Sections: 3 to 8 sections is typical
• URLs per section: 3 to 10 is the sweet spot
• Total file length: 500 to 2000 words for most sites

A 50-word llms.txt is too thin to be useful. A 5000-word llms.txt buries the signal.

Updating#

• Update llms.txt when you launch a major new content category, product, or section
• Re-review at least quarterly
• Remove dead links (broken URLs in llms.txt actively damage credibility with AI)
• Keep the description fresh as the site evolves

llms-full.txt (the optional sibling)#

Some sites also publish llms-full.txt, which contains the full text content of the linked pages concatenated into one file. This is more aggressive: it offers AI systems the entire content for context.

Reasons to publish it:

• You want maximum AI context, including verbatim content
• Your content is freely licensed or you accept it being used for AI training
• Your content is short enough that the file is manageable (under 10MB, ideally under 5MB)

Reasons NOT to publish it:

• You sell or gate content (e.g., paid courses, premium reports)
• Your terms of service disallow AI training on your content
• File size would exceed reasonable limits

If you do publish it, link to it from llms.txt:

## Full content

- [Full content dump](https://example.com/llms-full.txt): The complete content of all linked pages.

Common mistakes#

• Auto-generating llms.txt from sitemap.xml. Defeats the purpose. The point is editorial curation.
• Treating it as a sitemap. Sitemap is for crawlers. llms.txt is for AI context.
• Stuffing it with thin content. Every URL listed should be content you would proudly cite if a human asked.
• Forgetting to update it. A 2-year-old llms.txt makes you look abandoned.
• Hosting it at a non-root path. It belongs at /llms.txt (root of the domain), not /docs/llms.txt.
• Returning HTML instead of plain text. Serve as text/markdown or text/plain, not as a rendered HTML page.

Verification#

After publishing:

• File is at https://yourdomain.com/llms.txt (root)
• File serves with content type text/markdown or text/plain
• All linked URLs return 200
• All linked URLs use the canonical URL form (no redirects)
• File is referenced (or at least not blocked) in robots.txt
• File renders cleanly in a plain text viewer
• Description and section headings accurately describe the site