How SEO and AEO work together

There is a version of this conversation that treats AEO as the thing that replaces SEO, and another that treats it as SEO with a new label. Neither is much use when you have to decide what to actually build this quarter.

The more practical way to hold it: search engines and answer engines read the same site. What differs is what happens after they read it.

The same crawl, two different jobs

A search engine’s job ends with a list. It has to decide which pages are worth ranking for a query, and then it hands the visitor a set of links and lets them choose. The page is the unit. The visitor does the rest of the work.

An answer engine’s job ends with a sentence. It retrieves passages — not whole pages — and assembles a response out of them. The chunk is the unit. The page is only where the chunk was found.

That single difference explains most of what follows. If you are being ranked, the question is whether your page is the best destination. If you are being quoted, the question is whether a few hundred words lifted out of the middle of your page still make sense on their own.

Where the work overlaps

A lot of it, which is the good news.

Being reachable. Neither system can use what it cannot fetch. Check the obvious things in this order: robots.txt is not blocking the path, the page returns 200 rather than a soft 404, the canonical points at itself, and Search Console’s URL Inspection shows the rendered HTML you expect.

Rendering without JavaScript. Googlebot will execute JS, eventually, in a second pass. Most answer-engine crawlers fetch and parse; several do not run JS at all. If your copy only exists after hydration, you are invisible to a retriever even though the page looks fine in a browser. View source — not the inspector, actual source — and search for a sentence from the middle of your page. If it is not there, that is the whole problem.

Being structured. One subject per URL, headings that describe the section beneath them, <h1> through <h3> used as a hierarchy rather than as sizes. A search engine uses this to understand what a page is for. A retriever uses heading boundaries to decide where one chunk stops and the next begins.

Being consistent about who you are. If your service is called one thing on the homepage, another on the services page and a third on your Google Business Profile, a search engine treats it as noise. An answer engine treats it as uncertainty — and an uncertain fact is one it will take from a source that sounds more sure. Organization schema with a sameAs array pointing at your real profiles is the cheapest fix available.

Structured data. Schema has been an SEO recommendation for years and is easy to treat as a box to tick. For a retriever it does more: it states plainly what would otherwise have to be inferred. The types that earn their place for most businesses are Organization, Service, BreadcrumbList, FAQPage and Article. Validate with the Rich Results Test and the Schema Markup Validator — they disagree often enough to be worth running both.

Speed, still. Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift. Field data from the Chrome UX Report, not a lab score, because the lab number is a simulation and your customers are not.

Where the work is genuinely different

Here is where the effort splits.

Answer-first writing. A page built to rank can spend three paragraphs setting up its topic. A page built to be quoted has to answer in the first sentence and explain after. This is not a style preference. If the answer is on line forty, the retriever may take line forty from somewhere else instead.

Writing in self-contained claims. “It depends on your budget” is fine on a page a person is reading, because the rest of the page is right there. Pulled out of that page it says nothing. Sentences that survive extraction carry their own subject: a paid campaign needs a verified conversion event before budget increases, because otherwise more spend only buys more unattributed traffic. A useful test — read a paragraph aloud with no context. If a listener would ask “about what?”, it will not be quoted.

Chunk-shaped pages. Retrieval works on passages of a few hundred words. A 2,000-word page with no internal structure becomes chunks that start and end mid-argument. The same content under clear <h2>s becomes chunks that each begin with their own subject. Same words, very different behaviour.

Questions as structure. Answer engines are asked questions, which makes question-shaped content map onto them directly. This is why FAQ sections have become useful again after a decade of being filler — not because FAQPage markup is magic, but because the format forces one self-contained answer per question.

Deciding who may crawl you. AI crawlers identify themselves with their own user agents — GPTBot, ClaudeBot, PerplexityBot, Google-Extended among them — and robots.txt governs them the same way it governs anyone else. This is a commercial decision before it is a technical one. Blocking them protects your content and removes you from the surface. Most businesses that want to be cited should confirm they have not blocked the crawlers by accident, which happens more often than you would think, usually via a firewall or bot- protection rule rather than robots.txt itself. Check your edge logs for those user agents; if they never appear, something upstream is refusing them.

A note on llms.txt. You will see it recommended. It is a proposed convention, not a standard, and support for it is not guaranteed by anyone. Adding one costs nothing. Treating it as a strategy costs you the work you should have spent on the six items above.

Measurement. Rankings are measurable in a way answer visibility is not, at least not yet. There is no report of every AI response that mentioned you. What you can do is keep a fixed list of the questions that matter to your business, run them on a schedule against the assistants your buyers actually use, and record verbatim what comes back and which sources were cited. Watch referral traffic from AI hosts in your analytics as a second signal — it is partial, because a cited answer often produces no click at all, but a rising line still tells you something. It is slower and less satisfying than a rank tracker. It is also the only honest way to know.

What this means in practice

Do not run these as two projects. Almost everything AEO asks for is something SEO wanted anyway, done more strictly.

If you are starting from nothing, the order that has held up:

1. Fix the technical floor — crawlable, indexable, server-rendered, fast.
2. One subject per URL, and say what it is in the first sentence.
3. Make your identity consistent everywhere, and declare it in Organization schema with sameAs.
4. Add structured data to the pages that describe what you do, and validate it.
5. Break long pages under real headings so each section stands alone.
6. Write the questions your buyers actually ask, one self-contained answer each.
7. Confirm you are not blocking the crawlers you want to be read by.
8. Pick a set of those questions and check the answers monthly.

One to four is SEO. Five to eight is where AEO asks for something extra. That is the whole of it.

The honest caveat

Answer engines are changing quickly, and anyone who tells you they have a reliable playbook for them is describing something that was true a few months ago. Retrieval behaviour, citation behaviour and crawler policy have all changed inside a year, and will again.

What is unlikely to change is the underlying requirement: be reachable, be clear about what you do, and write things that remain true when they are quoted without you in the room.

That was good advice before any of this, which is a reasonable sign it will still be good advice afterwards.