AEO stands for answer engine optimization, but the term gets thrown around without much rigor. Most of what is written about it online is recycled SEO advice with the word AI sprinkled in. The actual mechanics are different, the protocols are different, and the work product is different. This page describes what we actually deploy when we ship AEO infrastructure on a real site, and why each piece is on the list.
The premise: a customer is increasingly likely to ask an assistant (ChatGPT, Claude, Perplexity, Gemini, the Google AI overview, a chatbot embedded in their procurement tool) about your business before they ever land on your site. If the assistant cannot read your site, or cannot parse what it reads, you are invisible at the moment of evaluation. Building AEO infrastructure is the work of making your site machine-legible without sacrificing what makes it human-readable.
What AEO actually is
Strip the marketing gloss and AEO is four concrete things, in order of how often we see them missing on real sites.
First, an llms.txt index at your site root. This is a small, human-readable file (the convention follows robots.txt and sitemap.xml) that lists the URLs an AI assistant should consider authoritative for your business. It is not a standard the way HTML is a standard, but it is a working convention adopted by enough people that worth shipping. Anthropic publishes one, major SaaS sites publish them, and assistants increasingly check for one before scraping ad-hoc. The file points at canonical pages, optionally annotates each with a short description, and gives the assistant a clean entry point to your content.
Second, JSON-LD structured data. This is the standard (schema.org, embedded as a script of type application/ld+json) that lets you describe your organization, your services, your people, and your location in a format that machines can parse without guesswork. It is older than the AI-assistant era (Google has used it for rich results since the early 2010s), but it has taken on new weight because assistants read it directly. schema.org/Organization, schema.org/Service, schema.org/Person, schema.org/FAQPage, schema.org/Article. We deploy these by hand, tuned to what the page actually is. We do not deploy a generic template that says the same thing on every page.
Third, agent-discoverable surfaces. The web was built for human browsers. An assistant prefers a clean text endpoint over a JavaScript-rendered page with three layers of navigation. We add /raw endpoints (or equivalent) that serve clean markdown of article and product pages, addressable by URL pattern, so an assistant can pull the canonical text without parsing through a navigation shell. This costs little to ship and dramatically improves what shows up when an assistant is asked about you.
Fourth, a robots.txt that takes a position. Most robots files are accidents of history (auto-generated by a CMS, never reviewed). We rewrite yours as a deliberate allowlist. We grant access to the assistants we want reading us (GPTBot, ClaudeBot, PerplexityBot, Google-Extended, and the rest of the named agents), we deny the scrapers we do not want, and we point at the sitemap. The file becomes a one-page statement of how your site wants to be crawled.
How we ship it on a real site
Two weeks of work, give or take, depending on how much existing content there is to mark up and whether the site is on a framework that makes adding routes cheap (Next.js, Astro, Eleventy, anything modern) or one where it is a slog (older WordPress, custom PHP, hand-rolled stacks). Two weeks is the target on a typical SMB site. Larger or more bespoke sites take longer. We will tell you the real number after the audit.
Week one is taxonomy and content prep. We review every URL on the site, decide which ones are canonical (which ones you want an assistant pointing at when asked about you), and write the JSON-LD blocks for each canonical page by hand. This is not the place for plugins. A plugin will give you a generic Organization block that says nothing your homepage does not already say. We are after specific, rich descriptions that an assistant can actually quote back. We also write the llms.txt index in week one, though we do not ship it until the rest of the infrastructure lands.
Week two is the build. We add the /raw endpoint pattern, deploy the JSON-LD into the page templates, ship the rewritten robots.txt and the llms.txt, and update the sitemap to reflect anything new. Then we do the validation pass. We feed the live site to the schema.org validator, the Google Rich Results test, and a small set of manual probes (we ask each major assistant a handful of test questions and read the answers). If something is wrong, we fix it before we hand off.
We also write a short maintenance note. Two pages, telling your team what to do when you add a new service or a new article so that the AEO infrastructure stays consistent. This is the difference between shipping a one-off project and leaving infrastructure that compounds.
The artifacts we leave behind
Concrete list. After we are done, your site has:
/llms.txtat the site root, with a short business description and a categorized list of canonical URLs (homepage, services, methodology, contact, anything the assistants should quote back)./robots.txtrewritten as an allowlist, with named-agent rules for the major AI crawlers and an explicit sitemap reference./sitemap.xmlreviewed and reformatted, with no orphan pages and no junk.- JSON-LD
application/ld+jsonblocks on every page that should have one. Organization on the homepage, Service on every service page, Article or BlogPosting on every long-form page, FAQPage on any genuine FAQ surface. Hand-written, not templated. - A
/rawendpoint pattern (or.mdsuffix, depending on your setup) that serves the canonical text of articles and key pages in clean markdown. - A two-page maintenance note in your team’s wiki or repo README, describing what to do when content changes.
That is the deliverable. No deck, no abstract framework, no twelve-month engagement. The work is the artifacts.
How we measure if it is working
Three checks, run before we leave and re-run thirty days later.
First, validators. The schema.org validator and the Google Rich Results test should both come back green for every page that ships JSON-LD. This is binary; it either passes or it does not. If it does not, the structured data has a bug we need to fix.
Second, assistant probes. We ask the same set of seven to ten customer-style questions to ChatGPT, Claude, Perplexity, and the Google AI overview, before the work and after. We compare what comes back. We are not looking for vanity wins (your name in a bigger font); we are looking for whether the assistants now have access to the right facts, can quote your services correctly, and can point a curious customer at the right page.
Third, traffic shape. Your analytics will start showing referrers from assistant platforms (chat.openai.com, claude.ai, perplexity.ai, and the rest as they evolve) once the assistants start citing you. Volume is small at first, intent is high. We track the trend, not the absolute number. If thirty days in your referrers from assistant platforms have grown from zero to a few sessions a week, the work is doing what it was supposed to do.
Where this fits
AEO infrastructure is the foundation. Without it, the rest of the AI work you might do (chatbots, agents, automation) is being built on a site that is invisible to the assistants you are trying to compete with. With it, every other surface of your business benefits, because the assistants now have a clean, authoritative source to draw from. Read the visibility service page for the customer-side framing, or get in touch if you want to know what your site looks like to an assistant today before you decide.