AEO — How to Optimize Your Website for AI and Answer Engines

Traditional SEO focused on ranking in the ten blue links is no longer enough. More and more users start their research in ChatGPT, Perplexity, Gemini, or Google AI Overviews — and get a single, synthesized answer. For your brand to be inside that answer, your website has to be legible to language models. This is Answer Engine Optimization (AEO) — I cover the broader strategy in OpenClaw and AEO strategies for the AI era.

This article is a practical guide to optimizing a website for AEO — with concrete techniques, numbers, and examples from implementations we run at spoko.space.

How AEO differs from classic SEO

Traditional SEO is not going away. What is changing is the delivery layer — instead of a link list, users see a finished answer generated by AI, with cited sources. Your website needs to be among those sources.

Speed as the foundation

Before an LLM can index your site, it has to fetch it. Slow sites or sites hidden behind heavy JavaScript often never make it into training data or generative context. That is why step one of AEO is radical weight reduction.

A typical WordPress site with a handful of plugins ships 1–2 MB of JS before first paint. A static site built with Astro and islands architecture — usually under 80 KB. A 15–25× difference. In practice this means:

• LCP < 1 s instead of the 4–8 s typical of plugin-heavy CMS setups
• JavaScript activates only where interaction happens (contact form, search widget)
• Googlebot and LLM crawlers see full HTML immediately, without waiting for hydration

The scale of the trend is evident in 2026: Cloudflare acquired the Astro team and released EmDash — an open-source CMS built on Astro 6 + Cloudflare Workers + D1. Infrastructure that serves a significant portion of the global internet is betting on the architecture we have been shipping at spoko.space since 2023.

llms.txt — the standard for AI-ready sites

Analogous to robots.txt for Googlebot, llms.txt is a file placed at the domain root that tells language models: “this is how my site should be understood.” The standard was proposed in September 2024; in 2026 it is becoming a practice adopted by mature projects. For a deeper dive into implementation tradeoffs see llms.txt for SEO.

A typical implementation includes two files:

• /llms.txt — condensed site description with links to key pages (a Markdown sitemap)
• /llms-full.txt — full site content in a single file, ready to be loaded by a model

Why does this work? Language models parse Markdown more reliably than HTML cluttered with ads, trackers, and boilerplate navigation. Serving a clean “summary” raises the chance of accurate citation. The companion piece llms-full.txt: 90% fewer tokens, zero hallucinations walks through the implementation numbers.

Example from our implementation

On catalog.polo.blue — a static Astro + Vue 3 parts catalog we maintain — we shipped both files:

• /llms.txt — ~8 KB, list of all part categories with spec page links
• /llms-full.txt — ~2 MB, full OEM product descriptions, compatibility, PR codes, all three languages

Outcome: generative AI answers (tested in ChatGPT and Perplexity) now cite specific VW part numbers and link back to catalog.polo.blue as the source — instead of the generic “check with your VW dealer” response.

Islands architecture — interactivity without the perf cost

In a classic SPA (React, Vue SPA) the entire page is one JavaScript application. Loading requires fetching the whole framework, hydrating, opening API connections. Time to interactive: 2–5 s.

Islands architecture flips the model: the page skeleton is static HTML, and interactivity is an “island” activated only when the user engages with it. In our 2026 framework comparison I go deeper, but the key insight is: you do not have to choose between speed and functionality.

Concrete numbers from catalog.polo.blue (thousands of pages, 3 languages):

• Weight before interaction: 48 KB HTML + 12 KB CSS + 0 KB JS
• Pagefind (client-side search): loaded only after the user clicks the search box
• Tire calculator (Vue 3): hydrates only when the user scrolls to its section
• Lighthouse mobile: 98–100 Performance

Schema.org and structured data

LLMs parse JSON-LD similarly to classic crawlers, but extract entity relationships more effectively from it. Minimum schema set for a company website:

1. Organization (company data, logo, contact, socials)
2. WebSite + SearchAction (if you have a search feature)
3. BreadcrumbList (navigation hierarchy)
4. Article + FAQPage for blog posts
5. Product / Service for the offering

For catalog-type implementations we additionally use IndividualProduct (instead of Product — to signal a non-transactional catalog), ItemList for category pages, and an @graph binding everything into a single coherent structure. More practical patterns in the Google Search Central docs and on schema.org.

Content under AEO — answer format

Classic SEO copy is the long “10 reasons why…” article. AEO prefers a different format:

• Questions as H2/H3 (LLMs catch them as user intent)
• Short, concrete answers right after the heading (1–3 sentences)
• Lists and tables for comparisons (easier to parse)
• Numbers and data (LLMs cite facts more readily than opinions)
• FAQ section at the end with FAQPage schema

A good test: take a single paragraph from your text and paste it into ChatGPT as a quote — does it read like a complete answer? If yes, it is AEO-friendly.

AEO implementation checklist

Technical layer:

• LCP < 2.5 s on mobile (check in PageSpeed Insights)
• Static HTML generated at build time (SSG) or SSR with cache
• JavaScript under 100 KB for content pages
• llms.txt and llms-full.txt at the domain root
• Complete JSON-LD (Organization, BreadcrumbList, Article/FAQPage)
• sitemap.xml + robots.txt with no errors
• hreflang for language variants
• Images served as AVIF/WebP with fetchpriority on the LCP

Content layer:

• User questions phrased as H2/H3 headings
• Short answers directly under headings
• Comparison tables instead of long paragraphs
• Hard numbers, not generalities
• FAQ section with FAQPage schema
• Internal linking to key pages
• Outbound links to credible sources (builds topical authority)

Authorship layer (E-E-A-T):

• Author name + /about page
• Person or Organization schema
• LinkedIn, GitHub (for devs), Crunchbase (for companies) profiles
• Publication date and update date visible + in schema

Digital sustainability — an AEO bonus

A lighter site = fewer CPU cycles on the server + less data over the wire + less energy on the user’s device. This is not empty marketing — the Website Carbon Calculator shows a typical page produces 0.5–2.5 g CO₂ per view. Cutting weight by 80% (from WP to Astro) is a real saving across hundreds of thousands of monthly visits.

For B2B clients this often becomes an argument in ESG reports. For consumer audiences — a subtle signal that your brand does not drain their phone battery.

Summary

AEO is not a trend — it is a shift in how information access is architected. Users browse link lists less and less; they increasingly get a synthesized answer from AI. For your brand to be inside that answer, your site has to be:

1. Fast (LCP < 2.5 s, under 100 KB JS)
2. Semantic (clean HTML, JSON-LD, llms.txt)
3. Organized around questions, not keyword density
4. Backed by authority (real authorship, credible links, regular updates)

The same techniques that win at AEO also win at classic SEO. The investment has no expiration risk.

Working on a site that should be visible in the AI era? See how we approach these implementations at spoko.space — from a static catalog with thousands of products to a headless WordPress with an Astro frontend. Or just reach out, describe the project, and I will recommend a concrete stack.