Voice search optimization

Voice search optimization is the practice of shaping content for a channel that returns a single spoken answer rather than a page of links: longer, question-shaped queries in, one passage read aloud out. The constraint that defines it is serial delivery — there is no second result a listener can glance at.

The one piece of dedicated markup, and its actual scope

Most of what circulates as voice SEO technique is ordinary on-page practice restated. There is exactly one markup feature built for the channel, and it is worth reading its documentation rather than its summaries.

Speakable structured data is a schema.org property that, in Google's words, "identifies sections within an article or webpage that are best suited for audio playback using text-to-speech (TTS)." It applies to Article and WebPage objects, and sections are designated using either CSS selectors or xPaths — Google requires one approach or the other, not both.

Its stated scope is much narrower than its reputation. Google's documentation says the property "works for users in the U.S. that have Google Home devices set to English, and publishers that publish content in English", and the feature carries a beta designation: "This feature is in beta and subject to change." Schema.org's own type page describes SpeakableSpecification as indicating, typically via xpath or cssSelector, sections of a document highlighted as particularly speakable.

For length, Google recommends around 20-30 seconds of content per section, or roughly two to three sentences. That number is the most useful thing on the page, because it is a design constraint disguised as a formatting note: a spoken answer is two or three sentences long, so the passage has to carry its own subject, its own claim and its own qualifier inside that budget.

Why the single-answer constraint changes the writing

A list of ten results is forgiving. A reader who lands on a near-miss scrolls back. A spoken result has no back, which means three ordinary practices stop being optional.

Answer in the first sentence. A section whose answer arrives in paragraph three is not selectable, because there is no way to read paragraph three aloud without the two before it.

Keep the qualifier in the same sentence as the claim. This is the failure that produces confidently wrong spoken answers. "Support is available around the clock" and "for enterprise plans" in separate sentences will be separated again on the way out.

Give the section a subject it states. A heading that names the question — not a label like "Overview" — is what makes a passage addressable at all.

None of that is specific to voice. It is the same discipline that governs featured snippets, and the same one that governs which passage a retrieval system lifts. See conversational search for the query-side half, and voice search for the channel itself.

Where it overlaps with being cited by an agent, and where it does not

The overlap is real: both channels return one answer, both select a passage rather than a page, and both punish content that depends on surrounding context. Writing that survives being read aloud usually survives being retrieved.

The divergence matters too. A voice assistant reading a search result is selecting from an index built for search. A model answering from retrieved documents is selecting from whatever its retriever returned for that query, and it may paraphrase, merge two sources, or attribute badly. Speakable markup has no documented role in the second case: it is a Google Search feature, and no retrieval-augmented assistant publishes it as a ranking or selection input. Optimising for AI search is a different job with a shared writing style.

The honest summary is that speakable is a small, beta, geographically-scoped feature, and the durable part of voice optimization is passage hygiene that pays off in several channels at once.

Failure modes

1. Implementing speakable and expecting broad effect. Its documented scope is US English on Google Home devices, and it is beta.
2. Marking up both CSS selectors and xPaths. Google asks for one method.
3. Marking up a section longer than a spoken answer. Past two or three sentences, there is nothing to read aloud that is not an excerpt of an excerpt.
4. Stranding the qualifier. A caveat in the next sentence does not travel with the claim, and the spoken version becomes false.
5. Q&A padding. Generating dozens of near-duplicate question headings to catch phrasings produces a thin page that fails on its own merits.
6. Assuming a spoken result implies a visit. The channel is answer-delivery, not traffic; treating it as a traffic source misprices the work. See zero-click search.

Frequently asked questions

Is there markup for it?

Speakable structured data — beta, and scoped to US English Google Home users and English-language publishers.

How long should a speakable section be?

Around 20-30 seconds, roughly two to three sentences, per Google's documentation.

Does it help with AI assistants?

Not as markup: speakable is documented as a Google Search feature, not as an input any retrieval-augmented assistant publishes. The writing discipline transfers, the tag does not.

What is the single highest-value habit?

Answer in the first sentence of the section, with the qualifier in that same sentence.