What is AEO, and how is it different from SEO?

More and more questions now get an answer instead of a list of links. ChatGPT, Perplexity, Claude, Copilot and Google's AI Overviews read pages, put together a reply, and sometimes name the sources they used. Answer engine optimization (AEO) is the work of making your site one of those sources.

This post explains how AEO differs from classic SEO. It also lists the concrete signals our AEO analyzer checks on a page, so you can see what "AI-ready" means in practice.

SEO ranks links, AEO earns citations

Classic search engine optimization is built around a results page. A query returns a ranked list of links, and the goal is to sit as high as you can on it and win the click. The user lands on your page, and your page does the rest.

An answer engine skips that step. It reads several pages, pulls out the parts that answer the question, and writes its own reply. Your page can still matter a great deal, but it shows up as a cited source or a mention inside someone else's text, not as a blue link the user has to choose.

That changes the questions you ask about a page:

• Can the engine read it at all? If its crawler is blocked, or the page forbids snippets, there is nothing for it to quote.
• Does it understand who is speaking? Structured data and clear identity signals tell the engine which organization and which people stand behind the content.
• Is there a clean, quotable answer? Self-contained statements, direct answers to questions and clear structure are easier to lift into a reply than long, vague paragraphs.
• Is the source trustworthy? Engines have to decide whose claims to repeat, so signals of experience, expertise and trust carry weight.

AEO does not replace SEO. A lot of the groundwork is shared: a page that is crawlable, fast, well titled and well structured is a better starting point for both. AEO adds a layer on top that is about machine readability and being a safe source to cite.

What our analyzer checks

The analyzer at aeo.uplo.services is rule-based: it fetches your page and a few files from your site root and checks them against a fixed set of rules. Here is what those rules look at.

Access: robots.txt and page-level directives

The analyzer reads your robots.txt and splits AI crawlers into two groups.

• Answer crawlers fetch pages to answer live questions: OAI-SearchBot, ChatGPT-User, Claude-SearchBot, Claude-User, PerplexityBot, Perplexity-User and Bingbot. Blocking these is treated as a real AEO problem.
• Training crawlers collect content for model training: GPTBot, ClaudeBot, anthropic-ai, Claude-Web, Google-Extended, CCBot and cohere-ai. Blocking them is a legitimate choice, so the report shows it as information rather than a penalty.

It also flags a site-wide Disallow: /, and Disallow rules that cover directories needed to render the page, such as /_next, /static, /assets or /wp-content. A page can be "allowed" and still be unreadable if its CSS and JavaScript are off limits. If your robots.txt declares Content Signals (for example Content-Signal: ai-train=no, search=yes), the report shows them too.

Then it looks at the page itself. A crawlable page can still be closed to quoting through <meta name="robots"> (or the googlebot and bingbot variants). The analyzer looks for noindex, nosnippet, max-snippet:0, and noarchive or nocache.

Discovery: sitemap, llms.txt and markdown

• Sitemap. The analyzer uses the sitemap declared in robots.txt, or falls back to /sitemap.xml. It flags a declared sitemap that returns 404, follows a sitemap index to its first child sitemap, and counts how many URLs have a lastmod date within the last 90 days. It also uses the sitemap to find your about, FAQ, contact, team, pricing, legal and blog pages.
• llms.txt. It checks for /llms.txt (and /llms-full.txt next to it) and validates its structure against the llmstxt.org format: an H1 title, an optional > summary, ## sections, and lists of markdown links that a crawler can follow. An HTML page served with a 200 status at that address does not count as an llms.txt.
• Markdown negotiation. It requests your homepage with Accept: text/markdown and checks whether the server answers with a text/markdown version instead of HTML. Since no major answer engine documents this as a ranking factor, it is reported as information only.

Meaning: structured data

The analyzer parses every JSON-LD block on the page, including entities nested in @graph. Among other things, it checks for:

• JSON-LD that fails to parse;
• an Organization (or a subtype such as LocalBusiness or Corporation);
• a specific type that says what the page is, such as Article, Product, Service, SoftwareApplication or FAQPage, as opposed to only the generic Thing, WebPage or WebSite;
• sameAs links, and whether any of them point to Wikipedia, Wikidata, LinkedIn or a .gov or .edu domain;
• a person (author, founder, employee or member) linked by @id to the organization;
• name, address and telephone on the organization;
• articleBody on articles and a dateModified date;
• schema types that are eligible for Google rich results.

Answers: FAQ content

Question-and-answer content maps directly onto the questions people ask, so the analyzer looks for it in two places. In the HTML, it looks for FAQ markup: details and summary elements, FAQ-named blocks and FAQPage microdata. In FAQPage structured data, it checks four things:

• whether the answers also appear in the visible text of the page;
• whether answers are a reasonable length on average (between 50 and 500 characters);
• how many named entities the answers mention;
• whether most questions are phrased the way people ask them, ending with a question mark or starting with words like "what", "how" or "why".

Trust: E-E-A-T signals

The analyzer checks experience, expertise, authority and trust with simple, visible signals:

• Experience: first-person phrasing such as "we tested" or "in our experience", and at least two real images that are not logos, icons or stock photos.
• Expertise: credentials in the text (for example "certified", "engineer" or academic degrees) and a consistent, specific vocabulary.
• Authority: sameAs data or links to profiles on LinkedIn, Wikipedia, Crunchbase or Google Scholar, plus links to .gov or .edu sites or to research sources such as PubMed, arXiv or DOI.
• Trust: links to about, privacy and contact pages, a physical address, and HTTPS.

These are weighted differently for informational, e-commerce and business pages, because a product page and a guide earn trust in different ways. On Ukrainian pages, the phrase and keyword checks use Ukrainian vocabulary instead of English.

Content and quotable structure

• Depth. Words are counted in the main content only, leaving out navigation, header, footer and sidebars. Pages under 300 words are flagged as thin, and e-commerce pages under 100 words as too short. It also counts h2 and h3 headings, and flags an average sentence length above 25 words.
• Quotable blocks. It counts blockquotes, definition lists (dl with dt/dd) and callout or TL;DR boxes: self-contained pieces that are easy to lift into an answer.
• Page metadata. A <title> of 10 to 70 characters, a meta description of 50 to 160 characters, and a canonical link with an absolute URL.
• Language and images. A well-formed <html lang> value, and an alt attribute on images. An empty alt="" counts as correct for decorative images.

Where to start

You don't need to fix everything at once. A sensible order follows the sections above. First make sure answer crawlers and snippets are not blocked. Next, tell engines who you are with structured data. Then give them clear, quotable answers and visible trust signals.

To see where your own site stands, run a free check at aeo.uplo.services. You get a score across five categories and the top issues to fix first. If you'd rather have someone handle the fixes, Uplo also does this work as a service.