AEO and GEO without myths

This is the module most likely to disagree with something you read last week. AEO and GEO have generated more confident advice per unit of evidence than any topic in search, and most of it consists of a specific tactic presented as necessary, with no product documentation behind it.

The uncomfortable answer is that the foundation has not changed. Answer engines still need to reach the page, read the content, and find something worth using. Accessible, indexable, genuinely useful pages remain the prerequisite, and almost every AI-specific tactic being sold is either a restatement of that or an invention.

What has changed is worth taking seriously, and it is covered properly in the next three lessons: different crawlers with different purposes, agent-driven interaction with your interface, and a category of observation that needs its own evidence discipline. None of it replaces the first seven modules.

There is no AI-only switch. Fix what makes the page usable and retrievable, and be suspicious of any tactic with no documentation behind it.

The tactics with nothing behind them

None of these are harmful in themselves. The harm is the substitution: a team ships an llms.txt file, records the AI optimization task as complete, and never repairs the page that fails to render.

What actually helps, and why it is unglamorous

Horizon's highest-value AI work is repairing the settlement calculator so its explanation exists without scripts, and publishing the reviewed limitations of the estimate. Both are ordinary content and rendering fixes from modules 4 and 5.

They help because they change what is available to retrieve. A page that renders to nothing offers nothing to any system, generative or otherwise. A page carrying a reviewed, specific, attributable statement about Texas settlement limitations offers something quotable that a general article does not.

This is the whole mechanism, as far as anything is documented. Be reachable, be readable, and contain something worth using. Everything else on offer is a claim about internals that no vendor has published.

How to evaluate the next tactic you are told about

The third question is the useful one to keep, because it dissolves most arguments without needing to settle the mechanism. Clear headings, plain answers early, and specific attributable facts are worth doing whether or not any engine rewards them, and a tactic that fails all three questions is asking you to spend effort on a claim nobody will ever be able to check.

Say eligibility, never guarantee

Nothing you do makes a citation certain. Engines choose sources per query, per model version, per mode, and the same page can be cited today and absent tomorrow with no change on your side.

That means the honest promise is about being retrievable and worth using, never about the outcome. A report that says the calculator now renders its explanation without scripts is a fact. A report that says this will get us cited by ChatGPT is a claim nobody can support, and it will be remembered when it does not happen.

Build the foundation

Five steps, none of which are new. That is the lesson rather than a shortcoming of it.

1. Verify crawl and index controls.Module 4, unchanged. A page that cannot be fetched or that carries a stale noindex is not a candidate for anything, generative or otherwise.
2. Make the primary information exist in rendered text.Not behind a click, a tab, or a script that might fail. This is the single highest-value AI-related fix on most sites and it is a rendering fix.
3. Organize it for a person.Clear headings, one idea per section, plain language. Useful for readers, and it happens to be what makes a passage extractable.
4. Support consequential claims with attributable evidence.Named sources, named reviewers, and dates. Specific and attributable content is what a system has a reason to quote rather than paraphrase from elsewhere.
5. Keep important facts current.Stale facts propagate. Module 7's reputation work is the downstream cost of not doing this, and correcting a third party is far more expensive than being right first.

One company can operate several crawlers doing unrelated jobs, and the names do not tell you which is which. Blocking the one you recognize while allowing the one that matters, or the reverse, is the standard outcome of guessing.

The remedy is a matrix you build from official documentation rather than from memory: which product, which robots token, which user agent, what it is for, whether it currently reaches you, and how you verified that.

Build the matrix from vendor documentation, and record how each access result was verified. Allowed in robots.txt proves almost nothing.

What allowed actually means

This is the most consequential misunderstanding in the module. A robots.txt test that comes back allowed tells you one thing: the token you tested was not disallowed by the rules you tested it against.

So the access column in your matrix should record what you verified and how. Request logs showing the user agent arriving is evidence. A robots.txt checker returning green is a configuration statement, not an observation.

Separate the controls, and check the WAF

Search discovery, user-requested retrieval, and training collection are governed by different tokens, and conflating them produces decisions nobody intended. A business that wanted to opt out of training and blocked everything with a similar name can remove itself from answer surfaces it wanted to be in.

The WAF is where most surprises live. Security tooling makes its own decisions about unfamiliar user agents, usually without telling anybody. A crawler permitted in robots.txt and refused by bot management looks identical to a crawler you blocked on purpose, right up until somebody reads the logs.

Recheck periodically. Vendors add crawlers, rename tokens, and split one product into two, and a matrix built eighteen months ago is describing a landscape that has moved. Put a review date on it like any other evidence.

Deciding what to allow is a business decision

The matrix describes the landscape. It does not tell you what to permit, and that question is commercial rather than technical, which is why it should not be settled quietly by whoever last edited robots.txt.

Blocking training collection has no documented effect on how you rank or whether you are retrieved for a live question. Organizations block it for reasons that have nothing to do with search: licensing positions, contractual obligations, or a view about their content being used to train a competitor's product. Those are legitimate and they belong to the business.

Blocking live retrieval is a different decision with a visible cost. That is the crawler fetching your page because somebody asked a question right now. Refusing it removes you from that surface while your competitors remain, and it is the choice most often made by accident, by somebody blocking a family of similarly named tokens in one edit.

Write the decision and the reason next to each row, and have somebody outside the search team agree to the ones about training and licensing. A rule with no recorded rationale gets reversed by the next person who reads the file and assumes it was a mistake.

Build the matrix

Six columns, filled from documentation rather than from what somebody recalls. Only list products that matter to this organization.

1. List only the products relevant to you.A matrix covering every crawler in existence is unmaintainable and will be abandoned. Cover the surfaces this business actually cares about appearing in.
2. Record the robots token from official documentation.From the vendor's own page, with a link. Tokens copied from a blog post are how a rule ends up matching nothing at all.
3. Write the purpose in your own words.Search discovery, live retrieval, training, or something else. Writing it out is what exposes the cases where two similarly named crawlers do unrelated jobs.
4. Test robots, status, WAF, and rendering separately.Four independent gates. A single pass or fail hides which one is actually deciding the outcome.
5. Record the verification method beside each result.Logs, a published IP verification method, or a reproducible test. An access conclusion with no method behind it is an assumption in a table.
6. Set a review date.The landscape changes without notice. A matrix nobody has revisited in a year is a historical document being read as current.

Software is starting to use interfaces on people's behalf: reading a page, filling a form, choosing from a control, completing or abandoning a task. Whether that works on your site has almost nothing to do with crawler permission and almost everything to do with how the interface is built.

The useful framing is that an agent is a user with no eyes, no intuition, and no patience for ambiguity. Everything that helps it is something that already helps a person using a screen reader or a keyboard, which is why this lesson is mostly accessibility work with a different motivation.

An agent is a user without eyes or intuition. What helps it is accessibility, not an AI-specific text block.

What actually decides whether a task can complete

Every one of these is already a requirement for people using assistive technology, which is the useful thing about this list. The work has an existing justification, an existing standard, and frequently an existing legal obligation, none of which depend on an argument about what any AI system does.

Test a real task, and record what happened

Pick the primary path a person would actually want automated, and give it a boundary. Find a consultation slot and stop before submitting is a good test task: it exercises navigation, controls, and state without taking an action on somebody's behalf.

Preserve the run, not the verdict. Every step result, the observed state, the semantic evidence, the screenshot, the point of failure, and what approval or execution source was involved. A pass or fail with nothing behind it cannot be compared against the rerun after the fix, which is the only thing that proves the fix worked.

Report failures as what they are: user-experience and automation-readiness problems. They are real, they affect real people using assistive technology today, and they do not need an unprovable ranking claim attached to justify the work.

Where an agent should be stopped

Not every task should complete, and a site that lets software do anything is not more ready than one that does not. Irreversible, costly, private, or externally visible actions need an explicit checkpoint, and that checkpoint is a feature rather than an obstacle.

Booking, paying, sending, and deleting are the obvious four. A consultation request submitted by software on somebody's behalf, without that person seeing what was sent, is a problem for the firm and for the client. The correct design lets the task get as far as a filled form and stop, with a human confirming.

Authentication and paywalls are legitimate stops too, and they should be recorded as such rather than as failures. A readiness report that lists a login wall as a blocking defect is measuring the wrong thing and will push somebody to weaken a control that exists for a reason.

Run a readiness check

Seven steps. The static preflight is cheap and the real task run is the evidence.

1. Inspect what exists without interaction.The rendered information available before anything is clicked. Content that requires a click is content an agent may never reach.
2. Check headings, landmarks, names, roles, and states.The static preflight. It is fast, it catches the majority of blocking problems, and it does not prove a task succeeds.
3. Complete the primary path with a keyboard.If you cannot, software cannot. This single test finds more real blockers than any automated scan.
4. Run the real task with a defined stopping point.Short of any irreversible action. The boundary is part of the test design rather than a limitation of it.
5. Document the authentication and consent boundaries.Where a task legitimately cannot proceed. A paywall or a login is a correct stop, not a failure, and the record should say which it was.
6. Save the ordered evidence.Steps, states, semantics, screenshots, and the failure point. This is what makes a rerun a comparison instead of a fresh opinion.
7. File failures as experience issues.With the affected task named. They compete for priority on their real merits, which is usually enough, and they stay honest.

Answer engines are non-deterministic in a way search results are not. The same prompt returns different answers depending on the engine, the model version, the product mode, the date, the location, the account, and which sources happened to be retrievable in that moment.

That does not make observation worthless. It makes the protocol the thing that carries the meaning, and it makes the language you use about the results the difference between a defensible report and one that falls apart the first time somebody checks.

One run is an observation under conditions. Say what you recorded, not what the system does.

Observation, generalization, and causal claim

An observation is what one recorded test returned under its exact conditions. A generalization is a broader claim from repeated observations, which needs enough varied evidence and still needs its boundaries stated. A causal claim says something you did produced the outcome, and timing alone never supports it.

The defensible sentence names the numbers and the scope. Horizon Legal was cited in 6 of 12 recorded Perplexity snapshots for the fixed Austin-fees prompt cohort, between these dates. Anybody can check that, and it stays true regardless of what the engine does next week.

The indefensible version is shorter and much more appealing: we made Horizon the preferred AI answer. It claims a universal outcome from a sample, attributes it to a cause nobody tested, and will be quoted back to you the first time a client runs the prompt themselves and sees something else.

Four things to classify separately

Record the raw response alongside the classification. Six months on, the classification is somebody's judgment and the raw text is the evidence, and only one of those settles a disagreement.

How many runs before you can say anything

There is no published threshold, so the honest approach is to make the sample visible rather than to claim a standard. Six of twelve snapshots is a statement anybody can weigh. Cited by Perplexity is not, and it is the same underlying observation with the sample deleted.

Hold the prompt cohort fixed across runs. Comparability comes from the prompts staying identical, in the same order, under the same recorded conditions. A cohort somebody edited between runs produces a chart with a discontinuity nobody documented, and it will be read as a trend.

Expect variance and say so in advance. Running the same prompt three times in one afternoon and getting three different answers is the normal behavior of these systems, not a fault in your protocol, and a stakeholder who learns that from you before it happens responds very differently to the one who discovers it themselves.

Record an observation properly

Five fields, then a confidence and a retest date. Anything missing from the first five makes the observation uncomparable.

1. Record the conditions before the result.Prompt text, engine, product mode, date, location, and account state. These are what make two runs comparable, and they are impossible to reconstruct afterward.
2. Save the answer and its cited sources verbatim.The raw text, not a summary. A summary is a second interpretation layered on an unstable observation.
3. Classify mention, recommendation, citation, and accuracy separately.Four independent facts. A single score collapses them and destroys the information you collected them for.
4. List the plausible explanations you did not rule out.Including the possibility that the run was simply variable. This is the field that keeps the report honest and it takes one line.
5. Assign a confidence and a retest date.A single observation is low confidence by construction. The retest is what converts it into something you can generalize from, and without a date it will not happen.