Blog · Running the work

An AEO workflow a two-person team can run

Published 8 October 2026 · Updated 12 October 2026 · 8 min read

An AEO workflow a two-person team can run
Photograph: KOBU Agency / unsplash

The short answer: Two people can run answer engine optimisation on roughly four hours a week if they split the work by surface rather than by task. One person owns retrieval, meaning crawler access, markup and the server logs. The other owns the question list and the weekly prompt run. They meet once, for thirty minutes, and move exactly one thing from the fix queue into production. Everything else waits.

That is the whole shape. The rest of this post is why those boundaries hold, and which parts quietly break when a small team tries to do more.

Split by surface, not by chore

The common failure in a two-person setup is that both people touch everything. Both read the prompt outputs, both argue about schema, both open the same crawl report, and neither finishes anything. Work that is genuinely sequential gets run in parallel by two tired people, which costs more than doing it alone.

A surface split avoids that. Retrieval is one surface: can the systems fetch the page, parse it, and find the passage. Questions are the other: what buyers actually ask, what the engines say back, and whether the sentence next to your name is true. The two surfaces fail for different reasons and get fixed with different tools, so handing each to one owner removes almost all the coordination cost. The same logic applies at larger sizes, which is why who owns AEO inside a company usually ends up drawn along retrieval and content lines rather than along job titles.

The retrieval owner's week: forty minutes in the logs

Start with the access layer, because it is the only part of this work where a single line in a config file can erase everything else you did.

We checked three vendor documentation pages on 12 October 2026, and between them they name nine distinct user agents. OpenAI documents four: GPTBot for model training, OAI-SearchBot for the search surface, OAI-AdsBot for ad page checks, and ChatGPT-User for requests a person triggers. Anthropic documents three: ClaudeBot, Claude-SearchBot and Claude-User. Perplexity documents two: PerplexityBot and Perplexity-User. Those three are not the whole field, so treat nine as the floor for your own list rather than the total. All three also publish a JSON file of the IP ranges their agents use, which is what you verify against, because the user-agent string itself is trivial to forge.

Here is the part most small teams miss. At least two of those vendors document that their user-triggered agents behave differently from their crawlers. Perplexity's bot page states that because a user requested the fetch, Perplexity-User generally ignores robots.txt rules. OpenAI's bots page says that for ChatGPT-User, because the action is initiated by a user, robots.txt rules may not apply. On those two documented behaviours, a robots.txt entry aimed at the crawler is not a reliable block on the fetch that happens when somebody pastes your URL into a chat window, and a firewall rule that blocks the fetch will not show up in your robots testing at all. Whether any given engine honoured the file on any given day is not something either you or we can see from outside.

The weekly job is a grep, not a dashboard. Pull the last seven days of access logs, filter for those nine agent strings, and count three numbers per agent: requests, non-200 responses, and median response time. You are looking for two shapes. A crawler that was fetching fifty pages a week and is now fetching two has hit something, usually a WAF rule or a rate limiter that nobody associated with AI traffic. A crawler getting 403s on a path that returns 200 in your browser is being filtered by bot management, and the browser test will never reveal it.

Write down the counts. Forty minutes, once a week, and the trend line is worth more than any single reading.

The question owner's week: the same prompts, every time

The second surface needs a prompt set that does not change. Twenty to thirty questions is plenty at this size, written the way a buyer would type them, including the unflattering ones about price, alternatives and whether the thing actually works.

Run every prompt on at least two engines, three runs each, and record four fields: engine, date, whether you were named, and which sources the answer leaned on. Three runs matters because of what repeat runs show: in our own audit runs we routinely see the same prompt, put to the same engine minutes apart, come back citing different pages. We have not measured how often that happens, and we would not report a rate we cannot reproduce. One run is an anecdote either way. The spreadsheet is the asset here, and after six weeks it is usually the only record in the building that can say whether a change did anything.

Resist the urge to add prompts. A question list that grows every week cannot be compared against itself, and comparison is the entire point. Freeze it for a quarter, then revise it deliberately. The audits we run use a fixed set of about 45 prompts across five engines, with retrieval on and retrieval off, for exactly this reason: the set has to hold still. The sample audit report shows what the recorded evidence looks like when it is kept properly.

The thirty-minute meeting, and the queue behind it

Once a week the two owners meet with their two artefacts: the log counts and the prompt log. The meeting has one output, which is the single item that goes into production next.

Keep a written fix queue, ordered by how recoverable the loss is. Access problems sit at the top because they are cheap and fast. Identity problems come next, meaning markup, consistent naming, the links between your own profiles. Corroboration sits at the bottom, not because it matters least but because a two-person team cannot schedule it. Anything below the top three lines of that queue is a wish, and labelling it as one keeps the meeting short.

Shipping one thing a week is not modest. It is roughly fifty changes a year, each one attributable to a dated log entry, which is a better record than we usually find when we audit a larger team. The sequencing in the first 90 days of AEO work assumes roughly this throughput.

Where measurement quietly lets you down

Expect your reporting to be worse than your work, and plan for it.

Google's documentation on AI features states that a site showing up in AI Overviews or in AI Mode counts inside the site's ordinary search totals, filed under the Web type of the performance reporting rather than anywhere of its own. That page is not the whole story. Since June 2026 Search Console has also carried a separate Generative AI performance report, rolled out to all sites worldwide on 31 August 2026, which gives impressions for AI Overviews and AI Mode on their own. Use that view rather than inferring the split from the overall graph, and note that it reports impressions, not clicks. This is Google's surface only; other engines publish no comparable reporting, which is a gap rather than a known zero. In the referrer data we have looked at, chat and assistant visits often arrive with nothing useful attached, so analytics is likely to undercount them as well.

This is why the prompt log exists. It is a direct observation of the surface, not an inference from a traffic number, and for a small team it is the only honest measurement available. Pair it with the log counts and you have cause and effect in the same place. The vocabulary argument in AEO vs GEO vs SEO is a distraction next to that.

Honest limits

Four things this post does not establish.

The four hours is a plan, not a measurement. It is the budget this routine is designed around and the one we would propose, not a figure we have timed across a set of teams, so treat it as a starting estimate and record your own.

Corroboration does not fit. Getting trusted third parties to repeat your claim is slow, relationship-driven work, and we have not seen a two-person team move it on this budget. Either accept that the ceiling is lower, or buy the capacity. The trade-offs are set out in in-house or agency for AEO.

Coverage is thin, and thin coverage is not a clean read. Two engines and thirty prompts leaves a lot unobserved, and an absence in your log is an absence of observation, not proof that nothing happened. Server logs have the same limit: they show the fetches that reached your origin, not the ones a cache, a CDN or a model's stored copy served without asking you.

Attribution stays unsolved. You will know your mention rate moved in your own log. You will not be able to prove what that was worth in revenue, and we have not seen a method that does. If you want a shorter on-ramp than all of this, the self-check covers ten things you can test in an afternoon.

FAQ

How many hours a week does this really take? We plan for about four in total across two people once the prompt set is written. That is a budget rather than a timed average, so check it against your own week. The first month costs more, because building the question list and getting log access are both one-off jobs.

Can one person do all of it? Yes, at reduced scope. Run the logs fortnightly and the prompts weekly, and expect to catch access regressions later than a two-person split would.

Do we need a visibility tool to start? No. A spreadsheet and a disciplined repeat schedule will carry a small team for months. Tools earn their place when running the set manually becomes the bottleneck.

Which engines should we pick if we can only do two? The two your buyers actually use, which you find by asking them rather than by reading market share charts. Failing that, pick one chat assistant and one search-integrated surface, since they retrieve differently.

Sources

All five pages were opened and checked on 12 October 2026.

Related reading

The first 90 days of AEO workIn-house or agency for AEOAEO vs GEO vs SEO: what the three terms actually meanWho owns AEO inside a companyBrand safety when a model is doing the talkingHow to buy an AEO audit without being sold a dashboard