GEO is the New SEO: Optimizing for AI Answer Engines in 2026

Open ChatGPT or Perplexity and ask a question in your domain. Something a potential customer would type. Watch what gets cited at the bottom of the answer. Is your site there? If not, is it any of your direct competitors? If not, why not?

For a growing slice of your audience, that cited list is the whole search experience. They don't scroll a results page. They read the generated answer, click one or two sources, and move on. If your content isn't in the answer, you weren't in the room.

Traditional SEO was never designed for that. It optimizes for a different game: ranking higher than ten blue links on a page that fewer people are even loading. Generative Engine Optimization (GEO) is what picks up where SEO stops. It's still early, best practices are still shifting, but the shape of the work is clear enough that you can start applying it today.

What GEO actually is#

GEO is the practice of structuring web content so AI answer engines are more likely to cite it, quote it, and include it in their generated responses. The targets are ChatGPT, Perplexity, Claude, Gemini, Google's AI Overviews, and Bing Copilot. The metric that matters is citation probability, not SERP position.

SEO and GEO overlap, but not as much as you'd think. Here's the rough shape of the difference:

Roughly 40% of the work is shared: HTTPS, semantic HTML, structured data basics, signs you're trustworthy. The other 60% is genuinely different work, and most of it is not covered in your current SEO playbook.

Why it matters now#

A few shifts are stacking up at once. AI-native interfaces are capturing more intent. Google's AI Overviews are eating into zero-click traffic that used to land on sites below the fold. Perplexity is positioning itself explicitly as an "answer engine" rather than a search engine. ChatGPT's browsing and search features are pulling live citations. The old funnel (impression, click, session) is getting shorter, and some of it has collapsed entirely into an answer the user reads and accepts without ever leaving the chat.

We don't have great industry stats for this yet. Most of the data that exists is either Google's own telemetry (which they aren't sharing) or early surveys with selection bias. But every operator I talk to has seen the same pattern: the mix of referral traffic is changing, bounce rates on old long-tail pages are moving, and a new category of traffic (from chatgpt.com, perplexity.ai, gemini.google.com and their referrers) is showing up in analytics.

The right stance is to treat this like mobile optimization in 2010. It's a new surface, one that's going to matter more as AI answer engines mature. Worth building habits around before they become table stakes.

The core GEO disciplines#

There's no single trick here. GEO is a grab bag of practices that collectively make your content easier to extract and attribute. Four areas are worth understanding in detail.

llms.txt: the emerging standard#

llms.txt is a markdown-formatted index file placed at the web root. It was proposed by Jeremy Howard in 2024 and the spec is maintained at llmstxt.org. Think of it as sitemap.xml for LLMs, except it's curated, markdown-native, and written for direct consumption.

The minimal structure is simple:

# Site Name

> One-sentence description of what this site is about.

## Primary content

- [Page title](https://example.com/page.md): one-line summary of the page.
- [Another page](https://example.com/another.md): one-line summary.

## Optional

- [Secondary resource](https://example.com/secondary.md): summary.

Rules worth knowing:

• H1 title is required.
• A blockquote description must come immediately after the H1.
• H2 section headers organize the index. ## Optional is treated as lower priority.
• Link to .md companion URLs where the content exists in markdown form. AI engines quote markdown more accurately than HTML that has been extracted and reformatted.

There's also llms-full.txt, which is the comprehensive companion file containing full markdown content rather than just links. Use it when your licensing and bandwidth allow exposing full text to AI engines for direct retrieval.

Adoption is still early. Not every AI engine acknowledges llms.txt yet. But the cost of providing it is low, and the upside (being trivially indexable by engines that do support it) is real.

AI crawler management: training vs citation#

This is the section most developers haven't run into yet, and it's the highest-value one to understand.

Not all AI crawlers are the same. Broadly, there are two kinds:

Training crawlers scrape the web to build training corpora for future model releases. They don't directly contribute to citations you get tomorrow.

Citation or answer crawlers fetch content live (or from a search index built for answering) and determine whether you get cited in real answers right now.

Treating them as a single category is the most common mistake. A site owner may legitimately want to block training (so their content isn't baked into model weights) while allowing citation bots (so they can still be quoted in AI answers). A blanket Disallow: / for every AI-flavored user agent locks you out of both.

Here's a reference table pulled from the docs each operator publishes:

A common intentional pattern, if you want citations without contributing to training, looks like this in robots.txt:

# Training crawlers: blocked
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: CCBot
Disallow: /

# Citation crawlers: allowed
User-agent: ChatGPT-User
Allow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

User-agent: Claude-User
Allow: /

User-agent: Claude-SearchBot
Allow: /

The official sources worth bookmarking: OpenAI bot documentation, Anthropic's ClaudeBot page, Google-Extended, and Perplexity's crawler docs. These pages change. Check them periodically.

Citation-worthiness signals#

LLMs don't just pull text. They decide which sources to cite, and how. The signals that push those decisions look a lot like E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness), with a few GEO-specific tweaks.

The ones that actually move the needle:

• Visible author byline with name, credentials, and a link to a profile page. An unsigned post on a specialized topic is a harder sell than one tied to someone who clearly knows the field.
• Dates that are both visible and in your schema. dateModified in JSON-LD, article:modified_time in Open Graph, and a "Last updated" line in the UI. AI engines push stale content down on many topics, and they can't tell how fresh your page is if you haven't told them when you updated it.
• Identity links via sameAs. Linking your Person schema to your LinkedIn, GitHub, ORCID, Wikipedia, or Wikidata profile tells the engine who you actually are. It also keeps you apart from anyone else who shares your name.
• Original data and primary research. Rehashing other people's content gets cited less than the source that produced the number or the benchmark. If you have internal data you can share, share it.

These nudge the odds in your favor. They're not guarantees. Nobody has published a reliable model of why one source gets cited over another, so treat them as solid rules of thumb, not rules.

AI-friendly structured data#

JSON-LD is the format. Microdata and RDFa are legacy. Every current AI engine I'm aware of reads JSON-LD first, and the types that line up most with AI citations are a specific subset:

• FAQPage for Q&A content. The visible question-and-answer structure matters more than the markup itself: Google dropped FAQ rich results in May 2026 but still parses the schema, and AI engines extract from clean Q&A content either way.
• HowTo for procedural content. Same story.
• Person and Organization with sameAs links for entity linking.
• Article with dateModified for freshness signaling.
• DefinedTerm and ClaimReview for specialized content. Still emerging in usage.

A minimal FAQPage snippet looks like this:

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
      {
        "@type": "Question",
        "name": "What is Generative Engine Optimization?",
        "acceptedAnswer": {
          "@type": "Answer",
          "text": "GEO is the practice of structuring web content so AI answer engines are more likely to cite it in their generated responses."
        }
      }
    ]
  }
</script>

And a Person schema with proper sameAs disambiguation:

<script type="application/ld+json">
  {
    "@context": "https://schema.org",
    "@type": "Person",
    "name": "Charles Jones",
    "url": "https://charlesjones.dev",
    "sameAs": [
      "https://github.com/charlesjones-dev",
      "https://www.linkedin.com/in/charlesjonesdev"
    ]
  }
</script>

If you already do structured data for SEO, most of this is a small add-on. If you don't, visible Q&A sections on your top landing pages (with FAQPage markup layered on) are the easiest place to start.

What's still unknown#

A reminder that this field is young, and anyone who tells you they have a definitive playbook is selling you something.

• Citation ranking inside AI engines is a black box. We don't have anything like Google's guidelines for how answer engines pick and order the sources they cite. Everyone serious about GEO is guessing from what they can see, not reading from a spec.
• Best practices today may not apply in six months. AI engines are updating their retrieval and ranking stacks monthly. llms.txt could become standard, or something else could replace it. Training vs citation lines could shift as policies change.
• Measurement is genuinely hard. Referral tracking from AI interfaces is inconsistent, some engines don't pass referrers at all, and citations aren't captured by any analytics product I've seen.
• Real-world data on what moves citations is thin. Most of the rules of thumb in this post line up with citations in the data we have, but that doesn't prove they're causing them.

Build habits around the basics that are cheap and defensible: clean semantic HTML, structured data, self-contained chunks, a crawler policy that reflects what you actually want. Experiment on the edges with llms.txt, question-shaped headings, identity links. Measure what you can, and expect the ground under you to move.

GEO joins SEO, it doesn't replace it#

The framing that plays best on social media is "SEO is dead, GEO is the future." That framing is wrong. SEO is still doing real work, and Google is still sending real traffic. What's changing is that search is no longer a single surface. It's two surfaces and growing, and each one rewards slightly different work.

Treat GEO as an equal part of your stack, not a replacement. Keep shipping sitemaps, keep writing meta descriptions, keep the lint checks that already run in your build pipeline. Then layer in the GEO-specific work: llms.txt, a deliberate AI-crawler policy, structured data that an answer engine can actually use, content patterns that survive chunking. The sites that invest early will have a meaningful head start when the practices solidify, and the tooling to help you audit it yourself is starting to exist. I built a Claude Code plugin called ai-geo that runs the audit, generates your llms.txt, and proposes the fixes. It's open source if you want to try it, and there's a sister ai-seo plugin for the traditional-SEO side.

If an AI answer engine asks the question your next customer would ask, you want to be in the answer. That's the whole game.