Running AEO and GEO as a practice means adding three things to an SEO team’s existing work: a recurring audit of whether answer engines can reach, read, and attribute your pages; a set of editorial and template standards that keep new pages passing that audit; and a reporting line that keeps readiness and outcomes in separate columns. It does not need a new department, a new title, or a new dashboard. Most of the work is crawling, editing, template changes, and tickets, which the team already does.
What does change is the unit and the evidence. The unit of work moves from the page to the passage: a section that has to answer its heading on its own, with a figure, a source, and a named author behind it. And the evidence gets weaker at the outcome end. Rankings were never perfectly stable, but an assistant’s answer to the same question can differ from one run to the next, and the tools that report on it see only part of the picture. A practice that is honest about that, and puts its weight on the part it can verify, is easier to run and easier to defend.
This guide covers what carries over from SEO, who owns which part, a cadence that fits around existing work, the reporting format, and the habits worth dropping.
What changes for an SEO team, and what doesn’t?
Most of the technical foundation carries over unchanged; what is new is a second set of crawlers, a passage-level editing standard, and a measurement problem without a clean answer. The table maps it:
| SEO work you already do | What carries over | What is new for AEO and GEO |
|---|---|---|
| Crawlability and indexing | robots.txt, status codes, canonicals, Search Console | Search crawlers from each AI vendor as separate tokens; CDN rules that block them; snippet directives that gate Google’s AI features |
| Rendering | Server-side rendering for Googlebot | Most AI crawlers are not documented to render, so content must be in the HTML response |
| On-page optimization | Titles, headings, internal links | A direct answer as the first sentence under each heading; sections that stand alone when lifted |
| Structured data | Markup for rich results | Markup as a statement of identity that must agree with the visible page |
| Content quality | Expertise, freshness, depth | Citable sentences: scoped figures, named sources, attributed quotations, honest dates |
| Link building | Earning inbound links | Linking out to primary sources as evidence |
| Reporting | Rankings, clicks, conversions | Readiness metrics you control, reported beside outcome signals you don’t |
Google’s position supports treating this as an extension rather than a new discipline. Its documentation states there are “no additional requirements to appear in AI Overviews or AI Mode, nor other special optimizations necessary,” and that the SEO best practices still apply (Google Search Central, last updated 2025-12-10). Other assistants run their own crawlers, which is where the new access work comes from.
Who owns which part?
AEO and GEO work spans more owners than most SEO work, because the failures live in templates, edge configuration, editorial habits, and policy as well as in pages. The SEO lead’s job is to find the failures and route them; most of the fixes belong to someone else.
| Area | Owner | What they own |
|---|---|---|
| Audit, prioritization, reporting | SEO lead | Running the audit loop, ranking findings, the monthly report |
| Crawler policy | Leadership, with legal where relevant | Which training and search crawlers to allow, written down and dated |
| robots.txt and snippet directives | SEO, with developers | Making the files and meta tags match the written policy on every host |
| CDN and firewall rules | Infrastructure or security | Allow rules for verified search crawlers; telling SEO before bot settings change |
| Rendering and templates | Developers | Content in the HTML response, real tables, JSON-LD in the initial HTML |
| Answer-readiness and citability | Editors and content owners | Answer-first sections, sourced figures, bylines, honest dates |
| Product and pricing facts | Product marketing | Specs, fit statements, prices that match the markup |
| Entity markup | SEO, with developers | Organization and Person markup, sameAs links, author pages |
Two rows cause most of the friction. Crawler policy is a business decision, not an SEO setting: blocking a training crawler is a defensible position, but it should be made deliberately by someone with the authority to make it, and recorded so the audit can tell a decision from an accident. And edge configuration usually sits with a team that has never heard of OAI-SearchBot. When your CDN or firewall blocks bots robots.txt allows includes ticket text phrased for that team.
What is the cadence?
The cadence is a small set of recurring checks attached to things that already happen: releases, the monthly report, the quarterly review. Nothing on it needs a standing meeting.
| When | What | Who |
|---|---|---|
| Every release that touches templates | Crawl the affected templates and compare against the last baseline | SEO, with developers |
| Every new page | A pre-publish check: answer under each heading, sourced figures, byline, honest date, real tables | Editors |
| Monthly | Outcome signals: Search Console, analytics referral segment, manual citation log | SEO lead |
| Monthly | Freshness pass on two or three important pages: real updates, real dateModified | Editors |
| Quarterly | Full audit of access and extraction across the whole site | SEO lead |
| Quarterly | Re-read each AI vendor’s crawler documentation; update robots.txt and edge rules | SEO, with infrastructure |
| After any CDN or security change | User-agent test on robots.txt and key URLs, every hostname | SEO, with infrastructure |
The quarterly vendor review exists because crawler names and purposes change. Vendors add agents, split one bot into several, and retire tokens; a robots.txt line naming an agent that no longer exists blocks nothing. The release crawl exists because templates break pages silently: a component change that moves a spec table into a script-loaded tab produces no error anywhere except in a crawl.
The audit loop is the backbone
The recurring audit follows one loop, in a fixed order, because each layer gates the next: access (can the crawler fetch the page), extraction (does the response contain the content), answer-readiness (can a passage be lifted), citability and entity (is there something worth attributing and a clear source), and measurement. How to audit a site for AEO and GEO is the full method, with a by-hand check and an at-scale method for each layer.
Two properties make the loop work as a practice rather than a project. It is repeatable: layers 1 to 4 are deterministic, so the same crawl on the same pages gives the same result, and a change in the result means the site changed. And it closes: every fix is verified by a re-crawl in the same mode as the baseline, so “done” means a crawl showed it, not that a ticket was closed.
The answer-readiness layer has its own reference in Answer Engine Optimization: a page-level guide, and the citability and entity layer in citability and entity signals: a GEO guide. Editors who own those layers should have both.
How do you decide what to fix first?
A real audit produces more findings than a quarter can absorb, so the practice needs one ranking method that everyone accepts in advance. The one that holds up is severity multiplied by page value, divided by effort, with access failures treated as gates that outrank everything else on the same page. Page value comes from data the team already has: traffic bands from Search Console, the page’s business role, and evidence that people ask the question the page answers.
Prioritizing AEO fixes: severity × page value is the spreadsheet, with a worked example. Its most useful rule for a practice is to collapse findings that share a fix: forty product pages missing the same markup is one template ticket, and should be one row.
How do you report it?
Report readiness and outcomes in two separate sections, and never combine them into one score. Readiness is what the team controls and can prove. Outcomes are what the team hopes the readiness contributes to, measured with tools that see only part of the picture.
Readiness comes from the audit and is stated as shares of a fixed set of priority URLs:
- Share reachable by each search crawler your policy allows, including through the CDN.
- Share whose main content is in the HTML response.
- Share with an answer-first section under each question heading.
- Share with a byline, an honest date, and markup that matches the page.
- Count of open Critical findings, and the change since last month.
Outcomes come from three sources, each reported with its limits:
- Search Console. Google includes traffic from AI features in the Performance report under the Web search type (Google Search Central). The generative AI performance report covers AI Overviews and AI Mode and reports impressions only; Google says it had rolled out to all websites as of 31 August 2026 (Search Console Help). No clicks, no queries.
- Analytics. A referral segment for sessions from the assistants’ domains. It undercounts, because an answer that is read and not clicked leaves nothing.
- A manual citation log. A fixed list of questions, run monthly on each assistant you care about, each more than once, with the date and the range of results. It is a sample, not a measurement.
A one-page monthly report can be this short:
| Section | Contents |
|---|---|
| Readiness | The five shares above, this month and last, with the crawl date |
| Shipped | Fixes verified by re-crawl this month, one line each |
| Regressions | Anything a release broke, and its status |
| Outcome context | Search Console AI-feature impressions, referral sessions, citation log ranges, each with its limits stated |
| Next | The top five rows of the priority sheet |
The discipline that makes the report credible is the separation. When readiness goes up and outcomes don’t move, the report says so. When outcomes move and nothing shipped, it says that too. Attributing a change in an assistant’s answers to a specific fix is a claim no available data supports, and a reader who catches one overclaim discounts the rest.
What should the team stop doing?
Some habits from SEO, and some from the early AEO and GEO advice, cost time without doing anything the evidence supports. Stop these:
Keyword stuffing for generative answers. In the GEO research paper, adding more query keywords was one of the methods that offered “little to no improvement” (Aggarwal et al., arXiv). Name the subject clearly once per section; do not repeat it for density.
Adding FAQ markup for rich results. Google’s documentation updates record that “the FAQ rich result feature is no longer shown in Google Search results” (Google Search Central). FAQPage markup can still describe a page’s question-and-answer structure, which is entity markup rather than a rich-result tactic; FAQ sections: leverage or filler covers when the section itself earns its place.
Bumping dateModified without changing the content. It is a false statement the page makes about itself, and it is easy to detect by comparing dates against edit history.
Blocking AI crawlers by accident. A wildcard rule, an inherited bot-management setting, or a subdomain nobody checked. Make the policy deliberate, write it down, and audit against it.
Treating llms.txt as a priority. It is cheap to publish and unclear what reads it. llms.txt: what it is, how it works, and whether to bother has the evidence; it belongs after access and extraction, not before.
Reporting prompt results as rankings. A screenshot of one assistant answer, taken once, is an anecdote. If the practice tracks prompts, it records ranges across repeated runs and reports them as context.
Rewriting pages in an “AI-friendly” voice. The changes that help are structural and factual: the answer first, the subject named, the figure sourced, the date honest. They read better to people too. A tonal rewrite that does none of those things is effort with no checkable effect.
Where do tools fit?
Tools fall into three classes, and each answers a different question. Monitoring tools, such as prompt-tracking platforms, sample what assistants say about a topic or brand; they answer “what showed up” and can’t tell you why or what to change. Diagnostic tools, such as crawlers, inspect your own pages; they answer “can this page be reached, read, and attributed, and what is wrong with it,” and can’t tell you whether anything cites it. Reporting tools, such as Search Console and analytics, record what reached you; they answer “what traffic arrived,” and undercount anything that didn’t click.
A practice needs a diagnostic tool, because the audit loop runs on one, and it needs the reporting tools it already has. Whether it needs monitoring depends on whether leadership wants a sampled view of answers and accepts its limits. Buying monitoring first and diagnosis second gets the order backwards: it tells you a problem exists without telling you what to fix. What GEOBee measures, and what it deliberately doesn’t states where one diagnostic tool stops.
If you run this for clients
An agency or consultant runs the same loop with two differences. The owners in the table above sit at the client, so the deliverable is the ranked list and the tickets, written so the client’s developers and infrastructure team can act on them without a translation step. And the baseline matters more, because the client will ask what changed: a crawl taken before the engagement starts, kept, and compared against at every report is the evidence that the work shipped.
Scope by template rather than by URL count, state the crawler policy as the client’s decision rather than yours, and put the readiness and outcome sections in every report from the first month. A client who has seen the two kept apart from the start is less likely to read a flat outcome month as a failed engagement.
The first 90 days
For a team adding this to existing SEO work, a reasonable sequence:
Days 1 to 30: policy and access. Write the crawler policy and get it signed off. Audit robots.txt on every host against it. Run the user-agent test through the CDN on robots.txt and the top URLs. Take a baseline crawl of the whole site and keep it.
Days 31 to 60: extraction and templates. Check every template for content in the HTML response, real tables, a single <main>, and JSON-LD in the initial HTML. File one ticket per template fault. Set up the analytics referral segment and start the citation log, so there is a baseline before anything ships.
Days 61 to 90: editorial standards and the first report. Write the pre-publish checklist for editors: answer under each heading, sourced figures, byline, honest date. Apply it to the ten highest-value pages. Re-crawl, compare against the baseline, and send the first monthly report with readiness and outcomes in separate sections.
By the end of the quarter the practice exists: a policy, a baseline, a cadence, owners, a standard for new pages, and a report that says what moved and what didn’t. After that, it is the same loop every month.
For the diagnostic side of the practice, download GEOBee: it crawls a site, scores every URL for AEO, GEO, and SEO with published weights, and compares crawls to show what moved. The 7-day trial includes every feature.