A customer asks an AI assistant to recommend a business and listens to the answer. Your website might appear among the links on their phone while the assistant names a competitor aloud. A report that records only citations would miss that difference.
Voice AI search fits into an answer engine optimization (AEO) program. You still need to know whether the assistant recommends your business and gets the facts right. Voice adds another question: what does the customer actually hear?
What voice and text search share
When a voice assistant searches the web, it needs to find useful sources and work out which business they describe. Those are familiar AEO problems. Changing how someone asks the question does not create a separate body of information about your business.
In its Search Live launch announcement, Google described a custom Gemini model working with its Search systems and using query fan-out, which runs multiple searches to explore a question. The customer gets an audio answer alongside links on the screen.
Two products can share a model family and still use different versions, instructions, search tools, and context. Even the same model can answer differently when those inputs change.
OpenAI's voice-agent documentation describes several ways to build these systems. A chained system converts speech to text, runs an agent workflow, and turns the result into speech. A realtime system can process audio and respond in the same session. A voice interface can also hand reasoning and tool use to a separate backend. The documentation covers options for developers; it does not tell us how every consumer assistant works.
Your test should identify which experience you are measuring:
| Experience | What you are testing | What it establishes |
|---|---|---|
| Dictation into a text search or chat | Speech becomes a submitted text query | How that text product answers the recognized query |
| A spoken AI conversation | An assistant processes speech and replies aloud | What that voice product does in that session |
| Read-aloud playback | An existing written answer is spoken | How the existing answer is delivered as audio |
A read-aloud button plays an existing result. Dictation lets you test whether speech was recognized correctly, but it does not reproduce a live conversation. Label the collection method so the report keeps those results separate.
Start with your existing AEO questions and try them in the voice products your customers use. Check whether the same question produces the same recommendation.
Check how the question became a recommendation
Say a customer asks, "Find a hotel in Portland with parking that can fit a tall van." The assistant needs to identify the right city and find a hotel whose parking can fit the vehicle. Dropping "tall" could leave the customer with a recommendation they cannot use.
You can investigate the answer at four points. These are checks for a reviewer; a native audio system may not expose a text transcript at each one.
Did the assistant preserve the place, business name, and constraints?
Which web pages or connected services supported the answer?
Which businesses qualified, and what claims did the assistant make?
What did the listener hear, and which links appeared on screen?
An incorrect transcript gives you a reason to check whether the assistant heard the request correctly. Read the answer too, because a transcript may not show everything a native audio model understood. If the city or vehicle size is unclear, asking the customer to clarify can be the right response.
Look for evidence of a search: a tool event, a source link, or a Maps result. When the product shows none of these, record retrieval as unknown. You cannot tell from a missing citation whether the assistant relied only on model memory.
Sources retrieved during a search are also different from sources cited in the answer. OpenAI's web-search API can return a source list with more URLs than its inline citations contain. A consumer app may show less evidence. Use the fields or links available in the product you tested, and label where they came from.
The recording tells you what reached the listener. A hotel could appear in the links but be left out of the spoken shortlist. The assistant might name it with an incorrect parking claim, or explain why it is unsuitable. A mention counter alone cannot distinguish those outcomes.
Follow-up questions need the same attention. "Which of those has parking for my van?" depends on the previous answer. "Actually, I meant Portland, Maine" changes the location. To see whether a business remains among the recommendations, you need the whole exchange.
Compare voice and text under the same conditions
I would run a small study before adding voice to a visibility score. We have not collected results for the proposed method below.
Choose questions that can change a buying decision
Use your AEO questions, then add requirements that come up in sales calls, support questions, and site search. Questions that already name your business need their own group. Otherwise, you give the assistant your name and then count its appearance as discovery.
For a hotel, you might ask for recommendations, compare two properties, and check parking restrictions or cancellation terms. Include a short conversation in which the customer narrows their requirements. Writing a longer, more conversational prompt does not show that customers ask it. Keep track of which questions came from customers and which you wrote for the test.
Pair each spoken question with a typed version
Use the same wording and product where both modes are available. Match the account, language, location, and time window as closely as possible. If you compare a text API with a mobile voice app, label the results as a comparison between those products. More than the input mode has changed.
Each independent question should start in a fresh conversation. Alternate which mode goes first and repeat the pairs across several sessions. Begin with clear audio. You can test background noise, alternate pronunciations, and interruptions separately once you have that baseline.
Save the recording you replay, or what the person actually said if they speak each time. That lets you check whether the input changed between runs. Give natural conversations their own test group, since wording and timing can vary there.
Record what the assistant knows about the session
The test record should include the product and mode, timestamp, device, account settings, language, supplied location, and previous turns. Add the app version when visible. Leave the model version unknown unless the product shows it; you cannot infer it from the app's name.
Google's Gemini Live help describes switching between voice and text within a conversation, connected apps, and personalization. Starting a new chat may leave account personalization active. Record the settings you can inspect and mark the rest unknown.
For a local question, note whether the location came from the prompt, the device, or a provider setting. "Near me" tells a reviewer little without that information. Leave camera and screen sharing off unless the test calls for them. A hotel visible on the screen gives the assistant another input.
Keep the recording behind each score
Save the input audio where available, the product's transcript, the output audio, and a screen capture of the sources. A run ID and question ID should connect those files. Note any interruptions, connection failures, or missing captures.
Someone reviewing a spoken mention should be able to replay the sentence. For a follow-up test, they need the full exchange. If a later question supplies the brand name, mark the result as prompted. It no longer measures whether the assistant kept recommending the business on its own.
Score mentions, recommendations, and citations separately
Agree on the scoring rules before comparing results. A spoken recommendation, a neutral mention, and a link to your site tell you different things:
| Measure | Count | Keep separate |
|---|---|---|
| Spoken mention rate | Completed, scorable voice answers that name the business, divided by all completed, scorable voice answers | A name shown only on screen |
| Spoken recommendation rate | Completed, scorable voice answers that recommend the business for the request, divided by all completed, scorable voice answers | Neutral mentions, warnings, and exclusions |
| Visible citation rate | Answers with a citation to an owned domain, divided by answers whose citation display was fully captured | Missing captures and third-party pages about the business |
| Factual accuracy | Checkable claims that match verified business facts, divided by all checkable claims reviewed | Claims with no available ground truth |
| Constraint satisfaction | Recommendations verified to meet every stated requirement, divided by recommendations with enough evidence to assess every requirement | Recommendations with unresolved requirements |
| Follow-up retention | Eligible conversations that still recommend the business at a defined later turn, divided by eligible conversations that recommended it initially | Exclude follow-ups that name the brand or add disqualifying requirements from both counts |
Show the counts behind every percentage. A complete screen capture with no citation can count as zero; an unavailable or unsupported citation view should be marked unavailable. Exclude audio failures from the answers you can score, and report how many runs failed.
Check factual claims against dated business records or other verified information. You can compare a parking-height claim with the hotel's current information, while "best atmosphere" needs a different review standard. Show how many claims and recommendations you could verify.
Also check whether the recommendation meets the customer's requirements. An answer can contain accurate statements and still recommend a garage that cannot fit the van. The constraint satisfaction measure catches that failure even when the answer leaves out the height limit.
For example, 20 questions repeated three times in two modes would produce 120 answers, with 60 per mode. Suppose your business appears in 36 typed answers and 24 spoken answers. The observed rates would be 60% and 40%, a difference of 20 percentage points.
Those numbers describe your selected questions and test conditions. They cannot tell you what share of all voice searches your business wins. Compare the pairs by question: which mentioned you in both modes, only one, or neither?
A formal statistical comparison also needs to account for repeated questions and runs. Those 120 answers are related observations, not 120 independent buyers, and the products may differ in more than input mode. If you give commercially important questions more weight, show the weights and how you chose them.
Check whether both answers cite the same sources
When both modes show comparable citation lists, count the domains they share and divide by the number of distinct cited domains across the pair. If text cites A, B, and C while voice cites B and C, the overlap is two out of three.
You need usable citation evidence from both answers to make that calculation. If both lists are empty, overlap is undefined. Check the URLs too, since two answers can cite different pages on the same domain.
If the sources largely match but the recommendations differ, read how each answer used those sources. If the sources barely overlap, start with retrieval and context. This helps you choose where to investigate. The visible links may show only part of the evidence, so overlap alone cannot explain what caused the difference.
Improve the information behind the answer
Use the results to decide what needs fixing. The hotel's parking page should state the height limit, whether spaces are guaranteed, and where an oversized vehicle can park. Customers should be able to find those details and see the same information when they book.
Google's guide to generative AI search says its AI features rely on core Search ranking and quality systems. It requires no special schema.org markup for generative AI search. The underlying SEO work still applies to Google's search experiences, though other assistants can work differently.
The source of the error helps you choose the work. An outdated restriction from a directory calls for checking that listing. A wrong answer citing your current page calls for a closer read: are the wording or exceptions ambiguous? Clarify them where needed. When the page is already clear, collect more samples before editing it. And when the assistant heard the wrong place, a rewrite of the parking page will not fix the input error.
Put restrictions beside the claims they qualify so they are easier to read together. "Parking available" and "Garage clearance is 6 feet 4 inches" answer different questions. Clearer wording can help a reader understand the offer, though sentence length does not guarantee more citations.
Google's speakable documentation covers topical news playback on Google Assistant devices. It gives us no basis to promise better voice rankings for a hotel or software company. Choose structured data that accurately describes the page and has a documented use.
After a correction, repeat the affected questions under the same conditions and keep the earlier sources and answers for comparison. An improved recommendation is worth recording. If several things changed, you cannot attribute it to one edit from that observation alone.
Add the recordings to your AEO research
For a team using Canonry, I would keep the configured AEO questions as the baseline and test voice separately where spoken recommendations matter. Our article on provider APIs explains what repeatable API requests and saved responses can show, and where they differ from a customer's experience in an app.
A text sweep gives you the baseline. To measure what the assistant says aloud, add audio and screen captures from the voice session. If your tools cannot store those files, use a separate review sheet with the same question IDs. Keep the product, mode, and capture method attached when you bring the results together.
Recurring errors deserve attention first. A wrong location or an omitted restriction gives you something to investigate, as does a warning that keeps appearing. A small change in mention rate with no consistent pattern in the sources or answers may call for more samples before a site edit.
Calls and bookings need their own evidence. Someone can hear a recommendation without visiting your website, and an AI referral may not tell you whether they spoke or typed the question. Leave the mode unknown unless the record identifies it. Asking customers how they found you can add context, but a visibility sample alone cannot tell you how much revenue came from voice.
Use your AEO research to choose the questions and investigate the sources. When you report that an assistant recommended your business aloud, link to the recording so someone else can hear the recommendation and judge it for themselves.