Voice search

Voice search is search where the query is spoken rather than typed, and where the answer is usually spoken back. The pipeline is speech recognition, then an ordinary text query, then speech synthesis of a single response. The W3C Web Speech API Community Group draft report, dated August 10, 2026, defines the browser-side interface along exactly those two halves — recognition and synthesis — and notes that the API is agnostic of the underlying implementation, supporting server-based as well as client-based or embedded processing.

The consequential part is the last step. A screen shows ten results; a speaker reads one. Everything specific to voice follows from that compression.

The mechanism, and what it discards

Recognition. Speech becomes text. This is where a spoken query gains its characteristic shape: longer than typed input, phrased as a full question, and transcribed with whatever errors the recogniser makes on names and technical terms. Where recognition happens is not fixed — the draft spec lets a page request on-device processing rather than a remote service — which matters for privacy but not for what gets retrieved.

Retrieval. The transcript is a query like any other. There is no separate voice index. The same ranking and, increasingly, the same retrieval-and-generation machinery answers it.

Selection. One passage is chosen to be read. Everything below it is discarded — not demoted, discarded. There is no second result to scan and no snippet to compare against.

Synthesis. The passage is read aloud, stripped of formatting. Tables, footnotes, parenthetical caveats and anything that depended on visual layout do not survive the trip. Neither, usually, does the citation: attribution in speech is a spoken source name at best.

Speakable, and the limits on it

The one piece of dedicated markup is speakable. Schema.org defines a SpeakableSpecification as indicating, typically via xpath or cssSelector, sections of a document highlighted as particularly speakable; it is used as the value of the speakable property on Article and WebPage.

Google's own documentation is narrower than the vocabulary. It describes speakable structured data as identifying the sections best suited to text-to-speech playback, used by the Google Assistant to answer topical news queries on smart speakers, returning up to three articles. It is documented as a beta feature, restricted to English-language news content for users in the United States on English-set devices. The length guidance is specific: around 20 to 30 seconds of content per section, roughly two to three sentences, covering key points and explicitly not datelines, photo captions or source attributions.

Two things follow. Most sites are outside the eligibility window entirely, so implementing speakable is not the lever it is often sold as. And the length guidance is worth reading anyway, because it is a published description of what a spoken answer unit looks like — a self-contained two-to-three-sentence passage — regardless of whether the markup applies to you.

Why this now matters more than it did

Voice search used to mean an assistant reading a featured snippet. Assistants that generate answers from retrieved passages have made that a special case of a larger pattern: an interface that takes a natural-language question and returns one composed answer.

That means voice-optimised writing and agent-optimised writing are the same discipline. Both select a passage rather than a page. Both strip the surrounding article. Both deliver the answer where the user is, so a correct answer often produces no visit at all — the zero-click outcome, in its purest form, since a spoken answer has no link to not-click.

The practical instruction is unchanged and just gets sharper: write sections that are correct when read alone.

Failure modes

• Qualifier stranded from claim. Spoken delivery removes the paragraph above. "Pricing starts at the listed rate" read without the preceding scope becomes a claim you did not make.
• Answer buried under preamble. A section that spends two sentences introducing the topic before answering it is a worse candidate than one that answers first.
• Layout-dependent content. A comparison table read aloud is unusable. If a fact only exists in a table cell, it does not exist for voice.
• Unspeakable identifiers. Names, model numbers and units that a recogniser mangles on the way in and a synthesiser mangles on the way out. Where a term is critical, spell it in text as it is said.
• Treating `speakable` as general-purpose. It is documented as beta, English, US, news. Marking up a product page does not opt it into a surface it is not eligible for.
• Expecting measurement. Voice queries do not arrive labelled, and answered-in-place queries do not arrive at all.

Frequently asked questions

Is there a separate voice index?

No. Speech is transcribed and answered by the same retrieval as text.

Is speakable worth implementing?

Only if you publish English-language news for a US audience, which is the eligibility Google documents for the beta.

How long should a spoken answer passage be?

Google's speakable guidance is around 20 to 30 seconds, roughly two to three sentences.

How is voice search different from an AI assistant answering aloud?

Structurally it is not any more: both select a passage, discard the rest, and deliver a composed answer without a results page.