Most AEO advice starts with content. When I review a site, I start lower in the stack.
What does the crawler receive? Is the useful information in the HTML? Can a machine tell which company and product the page is about? Only after those checks do I look at how the answer is written.
I work on FixAEO, so I spend a lot of time thinking about why one brand appears in an AI answer while another does not. There is no single switch that controls this. In practice, the problems are usually spread across access, page structure, entity data, content, and measurement.
The short version: Make the right pages easy to fetch, put the important information in reliable HTML, describe your entities accurately, answer specific questions, and track mentions separately from citations. Add llms.txt if it helps agents navigate your site, but do not treat it as a shortcut.
Answer Engine Optimization (AEO) is the work of making a brand or website easier for answer systems to find, understand, and cite.
It overlaps heavily with technical SEO. The difference is the final output. A search engine usually returns a ranked list of pages. An answer engine may read several pages, write its own response, and show only a few sources.
My review order is: crawler access rendered HTML entity and product data answer-friendly content repeatable measurement Check the response before changing robots.txt
People often open robots.txt, see an Allow, and assume the crawler can reach the page. That is only one layer.
A CDN, Web Application Firewall, rate limiter, or bot-management rule can still return a challenge page or a 403. I check the actual response and the server logs before changing the file.
I also keep search crawlers and training crawlers separate. OpenAI documents OAI-SearchBot for ChatGPT search and lists GPTBot separately for potential model training. Perplexity documents PerplexityBot for its search index and Perplexity-User for user-requested fetches. Anthropic also publishes separate crawler guidance.
That lets a site owner make a more precise choice than blocking every AI-related user agent.
This is a policy example, not a recommended default. The right rules depend on how you want your content used. User-agent names and provider policies can also change, so check the current documentation before deploying anything: OpenAI publisher and developer guidance Anthropic crawler guidance Perplexity crawler guidance
One practical test is to request the page with the intended user agent and inspect the status, headers, and body. This does not prove that the provider will index the page, but it will expose obvious blocking and challenge-page problems. Look at the HTML a crawler actually gets
The next question is simple: if JavaScript does not run, is the useful information still there?
Server-side rendering is not mandatory for every site. It does remove a common source of failure, especially when product details, pricing, documentation, or comparison data load through several client-side requests.
I look for these problems: the product description appears only after hydration pricing is inserted after a click documentation requires a logged-in session the visible headings are styled elements the canonical URL points to another page a noindex directive is present by mistake the server returns different content to a non-browser client
Fetch the page without running JavaScript and read the response. At minimum, I want to see the title, main explanation, headings, canonical URL, update date, and the links that establish context.
If those pieces are missing, I would fix that before rewriting paragraphs for AI search. Add JSON-LD that matches the visible page