Voice Search AEO: Make Spoken Answers Useful

Separate the voice interface from the underlying task

A person can speak a query into a search box, converse with an assistant, ask for a local fact or request an action. Those interactions share an input method but not necessarily the same information path. An answer may come from public web material, a connected account, a device setting or another supported service. Before changing a website, identify the actual task and the product involved. A public article about reminders is different from the account permission needed to create a reminder.

Google’s Assistant help page groups supported requests into different kinds of tasks. Treat product documentation as a way to check the specific capability being tested, including its stated conditions. Do not infer that improving an article can make a service accept bookings or give an assistant access to a private calendar. The broader distinction between retrieved information and generated wording belongs in how AI answers work. For voice work, the extra question is what the listener can understand and do through the interface available at that moment.

Write a task statement such as “A customer needs to know whether this branch accepts walk-ins today.” That is more useful than “optimise for voice”. It identifies an answerable fact, the relevant location and a time constraint. It also makes clear which operational record must be accurate before any wording exercise begins.

Write an answer that survives being heard once

Listeners cannot scan a long paragraph as easily as readers can. Start with the subject and the decisive information, then give the condition that changes the answer. Avoid relying on “the option on the right”, a colour key or a footnote that the listener cannot see. This is a comprehension exercise, not a universal rule about sentence counts. Some questions need a short answer; others need the assistant to clarify the request or direct the person to a fuller explanation.

Consider a fictional showroom. “Yes, we do, except on those days” depends on context that may disappear. “The Riverside showroom accepts walk-ins Monday to Friday; Saturday visits require an appointment” carries its own subject and exception. That wording still needs verification against the actual business schedule. If holiday arrangements can override it, the source should make the current exception easy to find. The local business AEO guide owns the operational process for maintaining those facts.

Read the answer aloud to someone unfamiliar with the page and ask what they understood. Do not ask only whether it sounded smooth. Ask which branch they would visit, when they would go and whether they would book first. Misunderstandings reveal missing subjects or buried qualifications. The passage clarity guide provides the wider writing method; this listening test adds a constraint that a visually tidy paragraph can otherwise conceal.

Handle numbers, names and ambiguous requests deliberately

Spoken input can leave the intended entity uncertain. Two branches may share a town name, a product code may sound like another code, or a customer may use a nickname for a service. Keep the public name and useful alternative terminology clear in your source material. Do not invent a list of phonetic keyword variations and insert it into an article. A clear identity record and meaningful context are more useful than a page crowded with imagined mishearings.

For a test, include both an unambiguous request and a naturally ambiguous one. “What time does the Riverside branch close?” is different from “What time do you close?” when no branch has been established. Record whether the experience asks for clarification, chooses a location or returns a generic answer. A reasonable clarification is not a failure merely because it delays the response. The outcome should be judged against the information available, rather than against a requirement that every request receive an immediate confident answer.

Numbers need their units and conditions. “Fifteen” might mean minutes, pounds or an age threshold. A useful source states “allow fifteen minutes for collection after confirmation” if that is the verified policy. For technical instructions, preserve the exact identifier in visible text even when a spoken summary uses a more pronounceable explanation. The listener may need to inspect or copy that identifier later, so provide an appropriate written destination.

Keep information and actions as separate promises

An answer explaining how to book is not proof that a booking was made. An assistant stating opening hours is not proof that an appointment slot is available. Make the public instructions distinguish the next step from its completion. A service page might explain which information to prepare and where to request an appointment, while a confirmation comes from the actual booking process. Do not describe an integration the business does not operate merely because a voice assistant can discuss the service.

Test informational and action requests separately. For the fictional showroom, one test asks about appointment requirements; another asks to arrange a Saturday visit. Record what each experience actually does, including whether it opens a link, asks for further information or reports that it cannot perform the action. The website can help by publishing accurate instructions and a clear route to the authorised process. It cannot turn a text statement into an executed transaction.

This distinction matters when interpreting outcomes too. A correct spoken explanation can help a customer even when no website visit is visible. Conversely, an assistant saying a business name does not establish an enquiry. Choose AEO KPIs that match the event you can observe, and keep completion evidence with the service that actually handles the action.

Understand the narrow role of speakable markup

Google’s speakable documentation describes a beta feature for identifying material suited to text-to-speech. Its documented use concerns topical news queries on supported Google Assistant devices, with stated country and language availability. It is not a universal tag that makes any commercial page the answer across voice products. Check that your publication and intended experience fit the current documented scope before treating implementation as useful work.

The markup identifies selected page content using a supported locator. That selected content should make sense when spoken. A selector that matches a decorative caption, a dateline or an entire long article can choose the wrong material even when the JSON parses. If a relevant publisher uses this feature, verify what the locator actually selects in the published page and listen to the selected text. Keep the test tied to the stated consumer rather than assuming all assistants interpret the same property.

Most learning articles still benefit from audible clarity without requiring this particular feature. The practical decision is whether there is a documented, relevant use for the markup, not whether the name sounds connected to speech. General structured identity and an accurate article record serve other purposes. Do not relabel a normal guide as news or invent an editorial role to fit an assumed eligibility shortcut.

Build a small voice evaluation that exposes mistakes

Create a panel of real tasks covering a simple fact, a conditional answer, an ambiguous location and a request that requires action. Record the spoken wording, recognised transcription when available, product, device context, language and date. Save the response or a faithful transcript where permitted. These details help distinguish a misunderstood question from an inaccurate source or an action the product does not support. The multi-platform testing guide explains why observations from different products should retain their conditions.

Assess four things: whether the intended request was understood, whether the answer was supported, whether the spoken wording preserved the important condition, and whether the listener knew the next step. A single overall score hides these different failures. For example, a perfectly transcribed question can receive obsolete hours; a correct answer can still use a confusing pronoun; a useful explanation can correctly stop short of making a booking. The repair should follow the failure you observed.

After revising a source, repeat the relevant task without claiming that one improved response proves a general ranking effect. Keep a record of the page change and any operational facts corrected. Voice-focused publishing is valuable when it makes information understandable beyond the screen and helps people reach an appropriate next step. It should strengthen the existing answer, not create a parallel set of pages for every spoken phrasing.

Sources and further reading

• Google: what you can ask AssistantShows the distinction between different supported assistant tasks.
• Google: speakable structured dataDocuments the beta feature, supported content locators and limited news/device/language scope.