The Echorank AEO Course, all lessons

Answer engine optimization (AEO) is the practice of making your brand easy for AI assistants to find, understand, trust and describe correctly, so that when someone asks a question you can answer, the assistant includes you in its reply. The short version: SEO earns you a place in a list; AEO earns you a place in the answer.

That difference sounds small and is not. A results page hands the searcher ten options and lets them choose. An assistant reads those options on the searcher's behalf, compresses them into a few sentences and usually names a handful of brands, or one. If you are not in those sentences, the searcher may never see your site at all.

AEO, SEO and GEO: one discipline, three lenses

You will meet three labels for overlapping work. SEO is optimising for classic search results. GEO, generative engine optimization, is the umbrella term for optimising for any system that generates an answer instead of listing pages. AEO focuses on the moment of the answer itself: the question a buyer asks and whether your brand is part of the reply. This course uses AEO because it keeps attention on the outcome, but the practical work is shared.

Most of what makes a site good for search still matters. Assistants that search the web before answering lean on pages a search engine can crawl, render and understand. What changes is the unit of success and the evidence that counts.

What “being the answer” actually means

Being the answer is not a single yes or no. Echorank scores every answer in four stages, which this course calls MRCA: Mentioned, Recommended, Cited, Accurate. A brand can pass one stage and fail the next, and each failure has a different fix.

• Mentioned: the assistant names you at all.
• Recommended: it suggests you for the need in the question, not just in passing.
• Cited: it links to or names a page you own as a source.
• Accurate: what it says about you is true and current.

What AEO cannot promise

No one controls what an assistant says. Answers vary between runs of the same question, between platforms, between countries and languages, and from one month to the next as models and their sources change. AEO improves the odds that the evidence about you is findable, clear and consistent. It does not guarantee a mention, a ranking or a citation, and anyone who promises one is guessing.

Worked example: Northwind Dental

Northwind Dental is a fictional two-location practice. Its owner asks an assistant, “Which dentists near Riverside offer evening appointments for children?” The answer names two competitors and says Northwind “may offer family dentistry”. Northwind is mentioned but not recommended, no Northwind page is cited, and the answer misses the fact that it opens until eight on weekdays.

That one answer already tells the team where to look. The evening hours are on the site, but only in an image of the opening times, which a crawler cannot read. The practice profile on a major map listing still shows old hours. The fix list writes itself: put the hours in text, correct the profile, and add a short page about children's appointments that answers the question directly.

Where AEO fits in your week

AEO is not a separate channel with its own team. It is a lens over work you already do: content, technical health, reviews and reputation, PR and partnerships. The rest of this course walks through that work in order: how answers are built, how to measure where you stand, how to make your site answerable, how to earn evidence elsewhere, and how to run the whole thing as a program.

An AI answer comes from two places: what the model learned during training, and what it retrieves from the web or another index at the moment you ask. Many answers mix both. Knowing which one an answer leans on tells you where your influence lies: you shape model knowledge slowly and indirectly, and you shape retrieval through pages that can be found and read today.

Model knowledge: what the assistant already believes

A language model is trained on a large body of text collected up to a cut-off date. From that text it learns associations: which brands appear with which problems, which descriptions recur, which claims are repeated by many independent sources. When an assistant answers without searching, it is drawing on those associations.

You cannot edit model knowledge directly, and changes reach it only when a model is retrained. What you can do is make sure the public record about you is consistent, specific and repeated by credible independent sources, so that the associations a future model learns are the right ones.

Live retrieval: what the assistant looks up

When an assistant searches before answering, it sends one or more queries to a search index, reads a selection of the results and writes its answer from them. This is where most short-term AEO work pays off, because the pages it retrieves are pages you can improve, and the answer often shows them as sources.

Retrieval is also where small technical problems hurt most. A page the crawler cannot render, a fact that lives only in an image, or a robots rule that blocks the bot all keep your evidence out of the pile the assistant reads from.

Fan-out: one question becomes several searches

Assistants rarely search for the exact words the user typed. A question with several parts is broken into narrower queries, each answered separately, and the results are combined. A buyer asking for the best CRM for a small sales team with a tight budget may trigger searches about small-team CRM features, pricing models, reviews and alternatives to one well-known product.

This matters because your page does not have to match the whole question. It has to be the best answer to one of the sub-questions. A clear pricing page, an honest comparison page or a specific feature page can each earn a place in the final answer by winning one branch.

Why answers change from run to run

Generation involves sampling, so the same model can phrase the same answer differently and pick different examples. Retrieval adds more variation: search results shift, the assistant may choose different sub-queries, and the sources it reads change as the web changes. Location, language, account settings and earlier messages in the conversation all play a part.

Worked example: Lumen CRM

Lumen CRM is a fictional CRM for small sales teams. Its marketer asks an assistant, “What's a good CRM for a five-person sales team that needs email tracking and costs less than our current tool?” The answer recommends three products, not Lumen, and cites a comparison article and two pricing pages.

Working backwards, the team lists the likely sub-questions: CRMs for small sales teams, CRMs with email tracking, affordable CRM pricing, and alternatives to the product they named. Lumen has a strong feature page for email tracking but no public pricing page and no honest comparison page. Two of the four branches have nothing from Lumen to retrieve. That is the gap to close first, and it is far more useful than a general wish to “appear in AI”.

Each answer engine has its own index, its own way of deciding when to search and its own way of showing sources. A brand recommended in one can be absent from another for the same question. Track the engines your buyers actually use, check each one separately, and expect the details below to change: these products are updated often.

The engines, one at a time

ChatGPT

ChatGPT answers from model knowledge and, when it decides a question needs current information or the user asks it to, searches the web. Searched answers usually carry links to their sources. Its crawlers are documented separately for search and for training, which matters in lesson 7.

Gemini, Google AI Overviews and AI Mode

Google's AI features sit on top of Google Search. AI Overviews appear above classic results for some queries and link to the pages they draw on. AI Mode is a conversational search experience with links in the answer. The Gemini assistant can also ground answers in Google Search. If your pages are not eligible for Google Search, they are unlikely to appear in these features.

Perplexity

Perplexity is built around search. Almost every answer is assembled from retrieved pages and shows its sources prominently, which makes it a useful place to see which of your pages, if any, are being read.

Claude

Claude answers from model knowledge and, where web search is enabled, from pages it retrieves, citing them in the answer. Whether search is on depends on the product and the user's settings, so the same question can behave differently for different people.

Copilot

Microsoft Copilot grounds many answers in web search and shows citations alongside them. It draws on a different search index from Google's, which is one reason results do not match across engines.

Why one result set does not transfer

Three things differ between engines: the index each one searches, the rules each one uses to decide when to search at all, and the sources each one tends to trust. A page that is well indexed in one search engine may be thin or missing in another. A brand that is well represented in training data may still lose a searched answer to a fresher page. That is why a single blended score across engines is less useful than a per-engine view.

When engines disagree about you

Disagreement between engines is a clue, not noise. If one engine describes you correctly and another does not, compare the sources each one shows. Often the wrong answer traces back to a single outdated page: an old directory listing, a stale review profile or a press article about a product you have since renamed. Fixing that source can correct more than one engine at once.

Worked example: Northwind Dental

Northwind asks its reception team which tools patients mention. Most say they searched Google; a few younger parents mention ChatGPT. Northwind tracks Google AI Overviews and ChatGPT first. In Google's answer it is mentioned through its map profile; in ChatGPT it is not mentioned at all for the same question, because the searched answer leans on a directory page where Northwind's listing is incomplete. Two engines, two different fixes.

A prompt panel is the fixed list of questions you put to answer engines on a schedule, worded the same way every time. Start with 20 to 30 prompts chosen from the decisions your buyers actually make, label each one by type and journey stage, and log the platform, locale and date of every run. Without a stable panel, you cannot tell whether a change in answers came from your work or from chance.

Start from decisions, not keywords

Keyword lists describe what people type into a search box. Prompts describe what people ask an assistant, which is longer, more specific and full of context: who they are, what they need, what they have already tried. Begin with the decisions a buyer makes on the way to choosing you. Which problem do they have? Which kinds of solution do they consider? What do they compare? What do they need to verify before they commit?

Sales calls, support tickets, reviews and your own site search are the best raw material. Write prompts in the buyer's words, with a realistic constraint or two, and avoid stuffing them with your product terms.

Four kinds of prompt, measured separately

Mixing these types into one number makes visibility look better than it is: branded prompts mention you by definition. Keep unbranded prompts as the core of the panel, because they show whether assistants reach for you without being told your name.

Keep the wording stable

Once a prompt is in the panel, do not edit it. Small wording changes can change the answer, and an edited prompt breaks the history you are trying to build. When you want to test a variation, add it as a new, named prompt and keep the original running beside it.

Log every run

For each answer, record the engine, the locale and language, the date, whether you were logged in, and the full text of the answer with any sources it showed. That sounds like a lot; it is what turns a pile of screenshots into evidence. Answers vary between runs, so repeat each prompt more than once per cycle and look at how often an outcome occurs rather than at any single answer.

Worked example: Lumen CRM

Lumen CRM's team pulls twenty recent sales-call notes and highlights the questions prospects asked before booking a demo. They group them into four stages: noticing the problem (“why do deals stall after the first call?”), exploring solutions (“what kind of CRM suits a five-person team?”), comparing (“Lumen or a bigger suite?”) and verifying (“does Lumen integrate with our email?”).

They end up with twenty-four prompts: fourteen unbranded, four comparison, three branded and three fact-check. Each gets an id such as SOL-03, a stage and a type. They run the panel on two engines, twice each, and log the results in a shared sheet. The first run is their baseline; nothing is changed on the site until it is recorded.

How big should the panel be?

Big enough to cover your important decisions, small enough that someone reads every answer. Twenty to thirty prompts is a practical start for one product or location. Add prompts when you launch something new or enter a new market, not because a larger number looks more thorough. A panel nobody reads is worse than a short one somebody acts on.

Score every answer in four stages, in order: was your brand Mentioned, was it Recommended for the need, was one of your own pages Cited, and was what the answer said about you Accurate? This is Echorank's MRCA scorecard. It replaces a single visibility number with four answers, and the stage where you drop out points to the fix.

The four stages

Score stages in order, but record each one independently. An answer can cite your page while recommending someone else, or recommend you while getting your prices wrong. Those combinations are the most useful findings in the whole exercise.

Competitor presence and share of answers

Your score means little on its own. For every answer, also record which other brands were mentioned and recommended. Over a cycle, share of answers is the number of answers that recommend you divided by the number of answers that recommend anyone. It shows whether you are gaining ground against named alternatives, which your own score alone cannot.

Scoring rules that keep the numbers honest

• Score branded prompts separately: they mention you by definition and would inflate the Mentioned stage.
• A mention inside a list of ten is still a mention; a recommendation needs the answer to steer toward you.
• Cited means your own domain. Reviews, directories and press about you count as evidence, not citations of you.
• Accuracy needs a source of truth: compare every claim with a dated internal record, and mark uncertain claims as unverified rather than guessing.

Worked example: Northwind Dental

Northwind runs its panel twice on two engines. For “Which dentists near Riverside see children in the evening?” the scores look like this. Mentioned: yes in most runs. Recommended: rarely; a competitor with many recent reviews is usually suggested first. Cited: never; the answers cite a directory and the competitor's site. Accurate: no; the hours quoted are last year's.

The scorecard turns that into three separate jobs. Accuracy comes first, because wrong hours send patients to a closed door: update the directory listing and put the hours in text on the site. Citation comes next: publish a page about children's appointments that answers the question in its first paragraph. Recommendation is the slow one, and lessons 9 and 10 cover the evidence that moves it.

A simple scoring sheet

One row per answer is enough: prompt id, engine, locale, date, run number, then a yes or no for each MRCA stage, the competitors mentioned, the competitors recommended, the sources shown and a note on anything inaccurate. Keep the full answer text in a linked column. A plain shared sheet works; what matters is that every answer is scored the same way by the same rules.

Reading a scorecard over time

One cycle gives you a baseline, not a verdict. After each cycle, compare stage by stage and engine by engine. Look for answers that moved from one stage to the next, and tie each movement to the change you made. When nothing moves after several cycles, revisit the diagnosis rather than doing more of the same.

What you see in a browser is not always what a crawler receives. A browser downloads the page's HTML, runs its JavaScript and builds the final page. Many AI crawlers stop at the first step: they read the HTML the server sends and do not run scripts. Anything that only appears after JavaScript runs may be missing from what they read, and an assistant cannot quote what it never saw.

Raw HTML versus the rendered page

The raw HTML is the text your server returns for a URL, before any script runs. The rendered page is what exists after the browser has run every script, fetched data and filled in the template. On a server-rendered site the two are nearly identical. On a site that builds its content in the browser, the raw HTML can be an almost empty shell with a script tag.

Where content hides

How to check a page

1. Open the page and view its source (not the inspector, which shows the rendered page).
2. Search the source for a sentence you care about: a price, your opening hours, the first line of your product description.
3. If the sentence is not in the source, a non-rendering crawler does not get it.
4. Repeat for your most important page types: home, product or service pages, pricing, locations, and your best answers to buyer questions.

Fixes, from cheapest to most thorough

The cheapest fix is often to repeat a few key facts in plain text: the hours under the image of the opening times, the price beside the interactive calculator. Next comes rendering the important sections on the server while keeping interactive parts in the browser. Most modern frameworks can do this page by page. The thorough fix is server-side or static rendering for every page that answers a buyer question.

Whatever you change, check the raw HTML again afterwards. It is easy to fix the visible page and leave the source exactly as it was.

Worked example: Lumen CRM

Lumen CRM's pricing page loads its plans from an API after the page opens, so the raw HTML contains a heading and an empty container. The comparison table on the features page is built the same way. In the team's scorecard, assistants describe Lumen's pricing vaguely or not at all, and never cite the pricing page.

The developers move the plan names, what each includes and the billing terms into the server response, and keep only the currency switcher in the browser. They do the same for the comparison table. Viewing the source now shows every plan in text. The team notes the date of the change in the worksheet so the next scorecard cycles can be read against it.

What not to do

Do not show crawlers different content from what people see. Serving a special text-only version to bots, with claims your visitors never read, is cloaking, and it undermines the trust you are trying to build. The goal is one page that people and machines can both read in full.

Your robots.txt file tells crawlers which parts of your site they may fetch. AI companies operate several crawlers with different purposes: some collect pages for model training, others fetch pages so an assistant can answer a question with current sources. Decide for each one whether you want it, write that decision in robots.txt, and then check that your CDN or firewall is not silently overriding it.

Search purposes and training purposes

The distinction matters because the trade-off is different. Blocking a crawler that fetches pages for search answers can remove you from those answers. Blocking a crawler that collects training data affects what future models learn from your pages, not today's searched answers. Several operators now document separate user agents for the two purposes, so you can make the decisions independently.

Writing the rules

Each rule names a user agent and the paths it may not fetch. A blanket “disallow everything” for an agent blocks it entirely; an empty disallow allows it. Keep the rules simple and comment why each one exists, so the next person to edit the file understands the decision. After any change, request the live robots.txt from your domain and confirm the server returns exactly what you wrote.

The blocks you did not choose

Many sites block AI crawlers without anyone deciding to. Bot-protection settings on a CDN or web application firewall can challenge or block unfamiliar agents by default, and the crawler gets an error page instead of your content while robots.txt says it is welcome. Check your CDN's bot settings for rules that mention AI crawlers, and confirm with your logs.

Reading your bot logs

Your server or CDN logs record every request, including the user agent and the response code. Filter them for the AI user agents in the table. Requests that receive a success response are reaching your content; challenge pages, forbidden responses or no requests at all point to a block. Be aware that a user agent string can be faked, so treat logs as a signal and use the operators' published verification methods when it matters.

What about llms.txt?

llms.txt is a proposed plain-text file at the root of a site that summarises the site and links to its most useful pages, written for language models. It is easy to publish and does no harm.

Worked example: Northwind Dental

Northwind's robots.txt is a template from its web agency and blocks nothing. Its logs, though, show no requests from OAI-SearchBot or PerplexityBot at all, and a handful of challenge responses for GPTBot. The CDN's bot-protection mode is set to challenge unfamiliar agents. Northwind decides to allow the search crawlers and Googlebot and to block training crawlers, writes that into robots.txt with comments, and adds allow rules for the search agents in the CDN. A week later, the logs show successful requests from both search crawlers.

An answer-ready page states its answer in the first paragraph, explains it in passages that make sense when quoted alone, names products, places and dates explicitly, and backs claims with specifics. Assistants read pages in pieces and quote the pieces that answer a sub-question cleanly. Write so that any paragraph could be lifted out and still be correct.

Answer first

Open with the direct answer to the question the page exists for, in plain words, then give the detail. A page about children's appointments starts with who you see, when and where, not with the history of the practice. This helps readers as much as machines: someone who arrives from an answer wants confirmation fast.

Self-contained passages

Assistants often retrieve a passage rather than a whole page. A passage that depends on the heading above it, or that refers to “it” and “this plan” without saying which, loses its meaning when quoted. Repeat the subject in each section, keep one idea per paragraph and put the important fact in the sentence itself rather than in a link.

Explicit entities and dates

Use full names the first time: your brand, the product, the city, the standard you meet. Write the date next to anything that changes, such as prices, opening hours, availability and feature lists. A dated fact can be trusted or flagged as stale; an undated one forces the reader, human or machine, to guess.

Comparisons, tables and FAQs

Buyers ask comparison questions constantly, and the pages that answer them honestly tend to be the ones retrieved. Publish comparison pages that explain trade-offs fairly, including when a competitor is the better fit. Put specifications and plan differences in real HTML tables, not images. Add an FAQ where people genuinely ask the questions, with answers that begin with the answer.

Structured data that matches the page

schema.org markup describes a page in a machine-readable form: an organisation, a local business with its hours, a product with its offers, a set of questions and answers. It helps machines identify what the page is about. It must describe what the page visibly shows. Markup that claims reviews, prices or answers the visitor cannot see is misleading, and search engines treat it as a violation.

Refresh what goes stale

Keep a list of pages whose facts change: pricing, hours, team, feature lists, policies. Review them on a schedule, update the date when you change them, and remove or redirect pages about products you no longer sell. A stale page that ranks well can keep feeding wrong facts into answers long after you changed your offer.

Worked example: Northwind Dental

Northwind's children's dentistry page opens with three paragraphs about the founder. The rewrite opens with one sentence answering the question parents ask: which locations see children, on which evenings, and how to book. Below it, a short list gives the hours in text, a table compares the two locations, and an FAQ answers what parents actually ask at reception. The page's LocalBusiness markup lists the same hours the page shows, and the page carries the date it was last reviewed.

When someone asks an assistant which business to choose, the answer needs evidence that does not come from the business itself. Reviews and public profiles are often that evidence. How many reviews you have, how recent they are, whether you reply, and whether your name, address, hours and services match everywhere all shape what an assistant can say about you. This is Echorank's home ground, and it is the part of AEO where honest, steady work pays off.

Why reputation shows up in answers

Questions like “best family dentist near me” or “is Lumen CRM any good” are requests for a judgement. An assistant answering them looks for independent signals that support one: what customers say, what directories and review platforms list, how a business responds to criticism. A business that describes itself as excellent is making a claim; many recent customers saying so is evidence.

The signals that matter

Inconsistent facts: the quiet problem

Over the years a business accumulates listings: a map profile, a few directories, an industry association page, an old platform it no longer uses. When those disagree on hours, address, phone number or services, an assistant has to choose, and it may choose wrong. Inconsistency also weakens the link between the listings and you, so the evidence is spread thinner.

1. Write one source-of-truth record: legal and trading name, address, phone, hours, services, website.
2. Search for your business name on the platforms your buyers use and list every profile you find.
3. Compare each profile with the record and correct, claim or close the ones that disagree.
4. Repeat when anything changes, and put the date of the change in the record.

Never fake, buy or gate reviews

Fake reviews, paid reviews and review gating, which means asking only happy customers to post publicly, break the rules of the major platforms, and in many places consumer-protection law too. They also defeat the point: evidence that is manufactured is not evidence. Ask every customer the same way, make it easy, and let the mix of reviews reflect reality. Then use what customers tell you to improve, and reply to criticism in public.

Worked example: Northwind Dental

Northwind's scorecard showed it mentioned but rarely recommended, with a competitor preferred in most answers. Its evidence map tells the story. The map profile has reviews, but the newest is several months old. One directory lists the old Saturday hours. A health directory has the practice under a former name. Nobody has replied to a review in a year.

The plan: a review request card handed to every patient at checkout and a follow-up message the next day, the same for everyone. A weekly half-hour to reply to every new review. The directory hours corrected and the old listing merged into the current one. Two months later the newest review is days old, every profile matches the source-of-truth record, and the team watches the Recommended stage in the scorecard for the effect.

Assistants look for agreement between independent sources. When editors, comparison writers, community members and video creators describe your brand the same way you do, an assistant has more to go on and more reason to recommend you. You cannot buy that agreement. You earn it by being worth mentioning, making the facts easy to find and correcting errors when you see them.

Three rings of evidence

Think of the evidence about you in three rings. Owned: your site, your profiles, your documentation. Earned: editorial coverage, reviews by independent writers, comparison and “best of” pages, interviews and awards. Community: forums, question-and-answer sites, social discussions and user groups where buyers talk to each other. Lessons 6 to 8 covered the owned ring. This lesson is about the other two.

Editorial and comparison coverage

Writers covering your category need accurate, current facts and something worth saying. Give them both: a press page with plain facts, dates and images, and a reason to write, such as original findings from your own data or a genuinely new capability. For comparison pages, contact the author with corrections and trial access rather than complaints, and accept that an honest comparison will sometimes recommend someone else for some buyers.

Communities: earn, do not seed

Community discussions are read by people and increasingly by assistants. The only durable way to appear in them is to be useful there under your own name. Encourage staff who know the product to answer questions openly, state who they work for and help even when the answer is not your product.

Video that machines can read

A video's pictures and sound are hard for a text-based system to use. Its title, description, chapters and captions are not. Give each video a descriptive title, a summary in the description, chapters with plain labels and accurate captions, and publish a written version of what is said on the page that hosts it. That turns a video into text an assistant can read and quote.

Partners and integrations

If your product works with other products, the partner directories and marketplaces that list those integrations are independent pages describing what you do. Keep your listings complete and current, use the same product names as your own site, and ask partners to describe the integration accurately on their side. These pages are easy to overlook and easy to fix.

Correcting third-party errors

When your scorecard finds an inaccurate answer, look at its sources. Often the error comes from a third-party page: an old review of a product version you replaced, a directory with your former address, a comparison with last year's prices. Contact the publisher with the correct fact, a source for it and a polite request. Keep a log of the requests and their outcomes, and re-check the answer after the page changes.

Worked example: Lumen CRM

Lumen is missing from most comparison answers, and the sources those answers cite are three “best CRM for small teams” articles that do not include it. The team writes to each author with a short fact sheet and a trial account. One adds Lumen in an update; one replies that the list is closed; one does not reply. Meanwhile two support engineers start answering small-team CRM questions in a public user forum under their own names. The team logs every contact and watches the comparison prompts in the scorecard.

No single number shows what AI answers do for your business. Analytics captures some visits that come from AI assistants and misses others. Bot logs show which AI crawlers read your pages. Asking customers how they heard about you catches influence that never produced a click. Your MRCA scorecard shows whether answers are moving. Report all four together each month, with their blind spots written next to them.

AI referrals in analytics

When someone clicks a source link in an AI answer, the visit often arrives with the assistant's domain as the referrer, and your analytics can group those visits into their own channel. Set up that grouping once, using the referrer domains of the engines you track, and keep the list up to date as products change their domains.

The four sources of evidence

Ask people how they heard about you

A short question on a demo form, at checkout or at the first appointment, such as “How did you hear about us?”, catches influence analytics cannot see. Offer an option for AI assistants and a free-text field. Expect the answers to be imperfect: people forget and simplify. Read them as a direction, compare them over time, and never treat them as precise.

Bot activity as an early signal

Requests from AI crawlers that fetch for search show that your pages are being read. A new page that receives no such requests weeks after publishing may be blocked or undiscovered. Bot activity is a leading indicator for the Cited stage, not a result in itself.

Who the report is for

Write the report for the people who decide what happens next: whoever owns the website, content, reviews and the budget. They need to know what moved, why you think it moved and what you are asking them to do. A line such as “the pricing page is now cited in one engine since the rendering fix; next, the same fix for the features page” is worth more than a chart nobody can act on.

What not to claim

Resist turning partial signals into a single return-on-investment figure. AI influence is real and hard to measure, and an invented number undermines the honest parts of the report. Say what you observed, what it suggests and what you do not yet know.

Worked example: Lumen CRM

Lumen's first monthly report fits on a page. At the top, the MRCA stages for the unbranded prompts on two engines, this month against the baseline. Below, share of answers against the four tracked competitors. Then AI referral visits from analytics, labelled “a floor”, and the count of trial sign-ups that chose “an AI assistant” in the new how-did-you-hear question. Then bot requests to the rewritten pricing page since the server-rendering fix. Last, three changes made this month and three planned for next month. The report makes no revenue claim, and says so.

The illustration above shows the shape of such a report. Its bars and lines are placeholders, not data: your own numbers belong there.

An AEO program is a rhythm, not a project. In the first week, set up the measuring stick: engines, prompt panel and baseline scorecard. In the first 30 days, fix what is broken: access, rendering and wrong facts. By day 60, improve the pages that answer your weakest prompts and start the evidence work. By day 90, report the trend, decide what worked and plan the next quarter.

The first week

1. Choose the engines to track, from what your buyers use (lesson 3).
2. Build and freeze the prompt panel (lesson 4).
3. Run the baseline and score it on the four MRCA stages (lesson 5).
4. Check crawler access, CDN settings and your source-of-truth record (lessons 7 and 9).
5. Name an owner for each part of the plan and a date for the first monthly report.

The 30, 60, 90-day rhythm

When an answer about you is wrong

Wrong or outdated answers will happen. Treat them as incidents with a simple routine. First, record the answer with its engine, locale, date and sources. Second, find the source of the error: your own page, a profile, a third-party article, or no visible source at all. Third, correct what you control and ask publishers to correct what you do not. Fourth, make the right fact easy to find in text on your own site, with a date. Fifth, re-check the prompt in later cycles rather than the next day, because answers change on their own schedule.

When to re-baseline

A baseline is useful only while the conditions behind it hold. Re-baseline, meaning run the full panel fresh and start a new comparison, when you add or retire many prompts, when you launch a major product or enter a new market, when you start tracking a new engine, or when an engine changes its product in a way that clearly changes its answers. Keep the old history; just stop comparing new results with it directly.

Worked example: Northwind Dental's quarter

Northwind's first week produces a panel of twenty-two prompts on two engines and a baseline: mentioned in most answers, rarely recommended, never cited, hours wrong. In the first month it fixes the hours everywhere, puts them in text on the site and opens its CDN to the search crawlers. In the second month it rewrites the children's dentistry page answer-first and starts asking every patient for a review. In the third month its report shows the Accurate stage fixed, citations of the new page in one engine, and recommendations not yet moving. The next quarter's plan focuses on reviews and the second location's page.

After day 90

The second quarter looks like the first, with less setup. Keep the panel and the monthly report running, review the pages and profiles on their schedule, and pick the next weakest stage to work on. Add prompts only for new products or markets. Once a year, check that the engines you track are still the ones your buyers use, and adjust the list before you re-baseline.

Your plan

Every practice task in this course added a section to your AEO plan. The worksheet brings them together: engines, baseline, site fixes, off-site evidence and the program itself, with a summary on top. Finish the summary, share it with the people named as owners, and put the first monthly report in the calendar.