Designing for AI Answer Engines

The problem

Three things have changed. The question has become a conversation, longer and more specific than a search query. The answer has become a synthesis rather than a list of links. And the click has become optional.

So a business can rank well in search and still be absent from the answer. Or it can be present and described wrongly: an old price, a service it stopped offering, a competitor's claim attributed to it.

Nobody outside the providers knows exactly how each engine chooses its sources, and the systems change often. What a business can control is whether its content is easy to find, easy to understand, consistent wherever it appears, and backed by evidence.

Concept overview

Broadly, an answer engine interprets the question, retrieves candidate sources, reads passages from them, writes an answer, and sometimes cites where it came from. Content can fail at each step:

• Not retrievable — blocked, slow, rendered only by scripts, or buried.
• Not understandable — vague, with the answer in the eighth paragraph, or unclear about who the business is.
• Not trustworthy — no evidence, no author, contradicted elsewhere.
• Not quotable — no passage that answers the question on its own.

Content built for answer engines is therefore retrievable, clear about its entities, evidenced and quotable. None of this is a trick. Google states that appearing in its AI features needs no special optimisation beyond the fundamentals of search; research on generative engines has found that how content is written can change how visible it is in answers, with what works varying by domain. The Guild's operating belief is plain: the goal is not more content, it is becoming the clearest trusted source in your category.

When to use this

Use it when buyers research before they contact you, when your category has questions with real answers — how, how much, which, compared with what — and when you have genuine expertise and evidence to publish.

It helps less when you sell mainly through existing relationships, or when the category is so new that nobody asks about it yet; then building the category's language comes first. And it does not fix a weak offer: answer engines amplify clarity, and its absence just as well.

Architecture

The first four parts decide whether an engine can use your content. The last two decide whether anyone hears about it, and whether you know.

Core components

Entity clarity

Say plainly who you are, what you do, for whom, where, and how you differ — in the same words on your site, your profiles and the directories that list you. A page that says "we deliver solutions" gives an engine nothing to work with. Structured data (organisation, service, person, article with author) says the same thing in machine-readable form, and must describe only what is visible on the page.

The question inventory

Collect the questions buyers actually ask, from sales calls, support tickets, proposals and search data. Group them by intent: understanding the problem, comparing options, deciding, implementing. Every important question deserves a direct answer somewhere on the site.

Answer-first structure

Put the answer in the first two sentences under a heading that states the question or the claim, then add the detail, the conditions and the exceptions. Use lists and tables where the content is a list or a table. A passage that answers a question on its own is a passage that can be quoted.

Evidence and authorship

Original figures, methods, worked examples, named authors with real expertise, dates and sources. Claims without evidence are interchangeable with everyone else's. Say who wrote each piece, and how: when AI drafted it, say so. Google's guidance on helpful content asks the same "who" and "how" questions, and the Guild Library labels every piece by authorship for the same reason.

Consistency elsewhere

Engines compare sources. Profiles, directories, partner pages and press mentions that agree with your site reinforce it. Ones that contradict it — an old address, an old list of services — weaken it.

Implementation

The sequence is the one the Guild uses: audit, map, publish, compound.

1. Audit. Check technical health — can crawlers fetch and read your pages without running scripts, and are you blocking the ones you want? — then entity consistency, then an answer baseline: ask your thirty most important questions in several answer engines and record whether you appear, whether you are cited, and whether the description is right.
2. Map. Choose the questions that influence real buying decisions — usually the comparison and decision questions — and the entities you want to be known for.
3. Publish. One cornerstone asset per topic cluster, written by or with the person who has the expertise: answer first, with evidence. Supporting answers link to it.
4. Fix the facts. Correct contradictions in profiles and directories, and add structured data that matches the page.
5. Distribute. Turn each cornerstone into pieces for the channels your buyers use, each linking back to the canonical page.
6. Compound. Repeat the answer tests every month, update pages when facts change, and link new answers to old ones.

Hermes note — I research, structure, draft, distribute and measure. The point of view comes from a person who has done the work. When no expert has anything to add to a topic, the right move is not to publish.

Evaluation

Measure outcomes, not volume.

• Presence — for your question set, how often you appear in answers, per engine.
• Citation — how often you are cited or linked when you appear.
• Accuracy — whether the answer describes you correctly: services, location, positioning and any public prices. An inaccurate mention is a task, not a win.
• Qualified visits — visits that arrive from answer engines, where they can be identified, and what those visitors do next.
• Search — rankings and organic traffic for the same topic clusters, which still matter.

Answers vary between runs and change over time. Ask each question several times, track trends rather than single results, and keep the raw answers: they explain why a number moved. On the Guild's digital presence missions, discovery and measurement is Oracle's part of the work.

Security and governance

• Accuracy before reach. Every claim on a page can be traced to evidence; every figure has a date and a source.
• Honest structured data. Markup describes what is on the page. No invented reviews, ratings or questions.
• Visible authorship. Named experts for expertise; AI-drafted content labelled and reviewed by a person.
• Crawler access is a business decision. Decide which crawlers may read which parts of the site, write it into your robots rules and review it. Some providers run separate crawlers for search and for model training — OpenAI documents OAI-SearchBot and GPTBot separately — so you can allow one and refuse the other. Blocking everything removes you from answers; allowing everything may expose material you meant for customers only.
• Guardrails for agents. An agent that drafts or distributes content works inside an editorial policy: the topics it covers, the claims it may make, the sources it must cite, and what needs a person's approval before it is published.
• Correct misrepresentation. When an engine repeats something false about you, find and fix the source it probably came from, and keep a record.

Cost considerations

The main cost is expert time: the people whose knowledge makes the content worth citing. Then come writing and editing, technical work (often a one-off), structured data upkeep, distribution, measurement tools and the time to run answer tests.

The levers: start with one topic cluster; reuse knowledge you already produce — proposals, support answers, internal guides — as raw material; let agents draft, structure and repurpose while experts review; and retire pages that answer nobody's question.

Example

Illustrative example, not a client engagement.

A small engineering firm designs ventilation systems for commercial kitchens. Its buyers, facility managers, ask AI assistants questions such as "how often should a kitchen extraction system be cleaned?" and "what does a ventilation survey cost?".

The audit shows the firm rarely appears in answers. When it does, one assistant lists a service the firm stopped offering years ago, apparently taken from an old directory listing. The team corrects the directory listings and adds organisation and service markup. It builds a question inventory from six months of enquiries. With the lead engineer it publishes one cornerstone guide on cleaning schedules — answer first, citing the relevant standards, with a worked example — and a pricing explainer with real ranges. Monthly tests track presence and accuracy for twenty-five questions. The first result to watch is not traffic; it is whether the answers describe the firm correctly.

Failure modes

Checklist

• Pages can be fetched and read without running scripts.
• Crawler access rules are a written decision, reviewed regularly, per crawler.
• One entity description is used on the site and on every profile.
• Structured data matches the visible page.
• A question inventory exists, built from real buyer questions.
• Each priority question has an answer-first passage on the site.
• Cornerstone content carries evidence, a named author and a date.
• AI-drafted content is labelled and reviewed by a person.
• A fixed question set is tested in several answer engines every month.
• Inaccurate answers are traced to a source and corrected.
• Distribution links back to the canonical page.
• Results are reported as presence, citation, accuracy and qualified visits.