Marketing to machines

Search Engine Optimization (SEO) is all about making information easy for search engines to discover, understand, rank, and present to people. It is primarily concerned with getting into a ranked set of results.

That's a well understood definition. What follows is less understood and not formally agreed upon. It's how I see the landscape.

Answer Engine Optimization (AEO) is more concerned with making information easy for AI systems to retrieve, understand, trust, synthesize, and use when answering questions. AEO becomes more interesting because the machine may synthesize the result, recommend a product, and, increasingly, take action itself.

SEO helps you get considered. AEO affects how a machine understands you and whether it chooses you to accomplish a task.

I thought AEO was renamed SEO

Over the years, I've watched marketing people invent enough acronyms to distrust another one. When I saw AEO become popular among marketing people, my first instinct was that it's just SEO being re-marketed as a new thing to capitalize on AI. After all, I did the same thing by writing a book that uses AI in the caption.

In fact, it's true that AEO does use many of the concepts of SEO. Things like server-rendered content, indexability, internal links, backlinks, canonical URLs, structured data, current facts, and complete answers that form a corpus of knowledge, all these things still matter. And my working rule became that AEO is a superset of SEO. My simple observation was that LLMs use search engines, so SEO is also AEO.

But the truth is a little bit more nuanced. Search remains one of the inputs into what AI systems know and retrieve.

Other inputs matter, too. Models have training data. They retrieve pages directly. They need documentation. They encounter GitHub repositories, directories, reviews, forum posts, partner integrations, and whatever context happens to be available when they are making a decision. Search is part of the system, but it isn't the whole system.

With AEO, the fundamentals are inherited from SEO, but there's a lot more to it that happens after the initial discovery.

Search, answers, and action are different stages

Let's look at three ways that a developer could use various tools to identify which database to use.

First, they may use a search engine. The search engine ranks the pages, and the developer clicks around, reads different articles, and chooses the database for their project. This is the process that we've been using for the last 20 years. It's a process that nearly everyone on the planet is comfortable doing, and it's a process that requires all of us to bring our ability to discern truth from fiction to the quest.

Second, more recently, a developer may use a chat window to get an answer. Let's say ChatGPT or Claude. The developer will ask the chat window what database is best for this type of project, and they'll get an answer. They may get a nuanced answer where the chat engine says, "Well, you have this kind of project, but if you used it for this particular approach, you may have a different answer." But ultimately, the chat engine is going to give them an answer. And that answer will help them make a decision.

The third approach is something that is unique to developers and involves taking action immediately. They may use a coding agent, let's say Cursor or CodeX or Claude Code. The coding agent will ask them not necessarily what database they want to use, but will actually look at the project and look at the plan and determine the best database to use. And increasingly, the coding agent will actually open an account, provision the database, build connections or connection strings, start writing queries, and wire up the database to the project.

Three different lenses and three different starting points on the same problem.

And, ultimately, this is a massive shift in decision-making power from humans to machines.

In the language of marketing, it's useful to think of these as three different funnel stages. Search gives the human a set of candidates. Answer engines interpret and narrow that set. An agent may actually make and execute the task.

These funnel stages don't look and act the same way.

How do models learn about your product?

In order to make a recommendation or take action, the model needs to know about your product. The model's representation comes from several sources, including:

• Its own training data
• Your website
• Your documentation
• GitHub
• Third-party sources
• Comparison pages
• Reviews
• Community conversations and forums
• Retrieved information at the time of inference

Where SEO taught us all to obsess over where we ranked, AEO teaches us that it is most important to know what models think we are. And perhaps even more importantly, what does the model believe we are good at?

This lends itself to marketers asking a different set of questions compared to SEO:

1. What category does the model place us in?
2. What problems does it associate us with?
3. Who does it think we're for?
4. What does it think we're bad at?
5. Which competitors does it consider as substitutes?
6. Under what conditions does it recommend us?
7. Does it understand our limitations correctly?

All of this information is distributed, too. Your homepage is no longer the authoritative description of your product simply because you own it. Your docs say something. Your GitHub says something. A marketplace listing says something. Reddit says something. An entry in a partner's catalog says something. An article from three years ago, containing your old positioning, says something. And so on.

Your product definition and brand are now a distributed asset.

If all of those sources agree, then a machine has a coherent picture of who and what you are. If there are any conflicts, then it will have a hard time resolving them to paint a proper picture.

Measuring what the model thinks we are good at

The most basic mistake here is to ask ChatGPT one question and get a favorable answer, then close your laptop and declare victory! That's anecdotal!

What you want is actual measurement. Think of it as a lightweight evaluation suite. You start with a fixed collection of questions that map to actual customer problems. Make the questions progressively more specific. Broad questions tell you what brands have accumulated general category strength, but narrow questions tell you whether the model understands what you're specifically good at.

For each of these questions, I record a few things:

• Does your product get mentioned at all?
• Is it the first recommendation?
• What does the model say about it being appropriate for the problem?
• What does the model say about your strengths and weaknesses?
• What competitors repeatedly appear beside you?
• Are there any factual claims that the model is making that are stale or wrong?
• Does changing the specificity of the problem change the recommendation?

Things are even trickier for developer products. With developer products, marketers need to be coders. You need to run a second set of tasks for coding agents. The coding agent will actually perform the task. Don't ask which database you recommend. That's a question for the answer engine. For the agent, you want to ask it to actually build the application, and then you record what steps the agent took, which products the agent chose, and how it tried to use those products.

This last part is really important. You aren't just measuring awareness. That's old school. You're measuring the machine's actual behavior.

You want to repeat these tests for different models and different LLMs. They'll all behave differently. You also want to repeat these tests every time a new model comes out, because retrieval will change, models will change, and your own information on your own website will change. The value comes from tracking this over time, rather than believing any individual response is ground truth.

If there's one takeaway, it's that everything is different now. Things may be similar, but they're not. You need to change your approach to measuring how well you're known online.

The boring SEO work still matters

Importantly, technical SEO still matters. But thankfully, LLMs can take care of this for you very quickly. You can routinely ask your coding agent to clean up your website and make sure it conforms to ideal best practices for SEO.

If decision-making is shifting to machines, then it behooves us to ensure that machines can easily complete their analysis.

This also includes things like:

• Make .md versions of your web pages readily available (e.g., if you have a /docs/getting-started route, the machine should be able to read /docs/getting-started.md and obtain the same information)
• Make sure that your website is easily crawlable and indexed for search engines and models
• Ensure the important subbstance of a page exists in the original HTML rather than after Javascript is run
• Use clear internal links and descriptive anchor text
• Keep canonical URLs and redirects clean
• Remove stale content
• Keep high-value existing content current instead of always writing new content

Don't assume having a Markdown version of your page is some magical talisman. But it does allow you to have a human experience that is dynamic and beautiful, while also maintaining a machine readable version that can be used by AI.

How should your content strategy change for AEO?

The biggest change for me is moving from keywords to questions. And then from questions to tasks.

Traditional SEO content planning might start with a topic like "Postgres row-level security." You'd find the keyword volume. You'd assess the competition, and then you'd build a page intended to rank for it. You would then build a ton of other content to build topical authority. You would build internal links, and then you would look for backlinks so that the topical authority was reaffirmed by external sources.

But that's not how people interact with LLMs. They ask the entire question and expect an entire answer.

They don't ask about Postgres row-level security. They ask about how do I secure my database? They may ask their coding agent to make sure their database is secure, or they may ask their coding agent to make sure that role-based account permissions are set up properly in this app.

So when I'm thinking about an AIO-oriented piece of content, I'm increasingly asking whether it answers the complete set of questions someone would have when they're trying to accomplish a task. That last phrase is actually even more important. In the old days, they may have asked to evaluate your product. Now they're trying to solve a problem. Your product has not even entered the equation.

Even last week, I was researching whether I should switch from Apple Watch to an Oura Ring because the Oura website is horrific and doesn't explain the difference between an Apple Watch and an Oura Ring. The Apple Watch website doesn't explain the difference either. I had to ask ChatGPT. ChatGPT built me a beautiful side-by-side table that told me what data I'd be missing if I chose Oura Ring versus Apple Watch. My question was very different than "Tell me what the features of an Oura Ring are."

Your website, therefore, needs to start understanding what the questions people are asking are and then making sure the content answers those questions. In the old days, a 5,000-word article may be sufficient, but today, if that 5,000-word article omits the answers to three questions that everyone actually asks, then the article itself is wasted.

You no longer have control

SEO also blurs the boundaries between traditional SEO, product marketing, PR, community, and the rest of the marketing team. Your website is only one source of information about you.

The model might encounter you through your GitHub README, or a Cloud Marketplace, or a package registry, a partner's documentation.

We've seen instances where partner marketplaces refer to us using our old positioning, and that is what LLMs currently believe. So part of the job becomes auditing the entire environment around your product, and that includes many things that you don't specifically control.

Identifying factual errors and improving the sources that you do control makes it much easier for everyone else to describe your product correctly. And if you find that there is a third party that is referring to your product differently than you want it to, and you have it in your power to reach out to them to change it, you probably should. And if you yourself are part of a larger company that controls such a marketplace, you should be more amenable and more empathetic towards smaller companies that are asking you to change content.

Documentation that works for people doesn't necessarily work for machines

It's also possible for documentation to be amazing for humans but absolutely awful for machines.

Humans are very good at operating websites. We click tabs, we open drop-downs, and we understand that changing one selector changes the command below it. We even recognize icons, and we can scroll horizontally and vertically. We can infer missing contexts, and we can click around until something on the website works.

A machine consuming that same information may see something completely different.

Imagine a getting started page. You select an operating system, then you check your framework, and then your package manager, and the page generates exactly the command you need. That is fantastic documentation for a person.

But all of that information is hidden behind JavaScript, and machines cannot reason that.

What I would do at a 20-person company

If I were starting from scratch with a smaller company, I would do the following five things:

1. Pick one narrow problem where the product should be the obvious choice.
2. Publish one very strong canonical page that covers the task, setup, limits, errors, alternatives, and what the customer should do next.
3. Put all the essential facts, URLs, and commands in a server-rendered text.
4. Check how the product is described on your website, in docs on GitHub, and in all credible third-party sources. Fix any factual conflicts.
5. Then, repeat these same questions and tasks in all of your LLMs of choice, as well as all of your coding agents. Record what they say, what they choose, and whether or not they finish.

I'd skip generated pages and expensive AEO frameworks. I'd also skip constant protocol chasing. Things are just changing way too fast for you to lock in on one protocol as the end all be all. I'd also be highly focused and avoid AI slop. Do the things you're very good at and do it yourself. Keep information accurate and up to date. Simplify, improve, repeat.

The other thing for marketing teams to understand: you are not only ensuring that your technical SEO and content quality are on point, but you also need to ensure that an LLM can actually complete the task you outlined in step one, above. Machines will be a lot more unforgiving about product deficiencies than people.

Summary

There's a lot here. It's a brave new world. We all need to learn it and be part of it.

Be careful of sneak oil salesmen. There will be a lot of people that will claim to know everything about AEO. This is fundamentally impossible because the category is being written as we speak. This article will probably even be out of date by the time you read it.

Hopefully I've given you a framework to start doing your own research and your own analysis.

Publish what you've learned and, as always, Help First.