Speakable Schema for Voice Search

What speakable schema is

Speakable is a property defined on schema.org that carries a value of type SpeakableSpecification. It marks the sections of a page that make sense when a voice assistant reads them back with text to speech. A device that supports the feature can pull those specific sentences instead of guessing which part of the article to speak, or worse, reading the whole thing. It lives inside the structured data you already publish for an Article or WebPage.

Set expectations first. Google documents Speakable but describes it as a limited feature that has been focused on news content and specific locales rather than a broad, guaranteed enhancement across all queries. Treat the markup as future facing plumbing and a way to structure your answer, not as a switch that turns on rankings. The discipline it forces, writing a tight self contained answer near the top of the page, helps with answer engines and featured snippets regardless of whether a given assistant consumes the property today.

How to point at the content

The specification identifies content in one of two ways, and you pick exactly one per SpeakableSpecification block. The cssSelector approach references elements by CSS selector, which is readable and stable if your templates use consistent class names. The xpath approach references elements by their position in the document tree, which is more brittle when markup shifts. Most teams choose cssSelector.

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "How to prune an olive tree",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": ["h1.headline", ".tts-summary"]
  }
}

The selectors above must match real elements that contain the exact text you want spoken. The .tts-summary class wraps a short lead paragraph written specifically to stand on its own. Here is the xpath variant for the same two elements, shown only to illustrate that you would use this instead of, not alongside, the cssSelector:

"speakable": {
  "@type": "SpeakableSpecification",
  "xpath": [
    "/html/head/title",
    "/html/body//p[@class='tts-summary']"
  ]
}

Write passages that survive being read aloud

A sentence that works on screen can fail out loud. Audio has no headings, no links to click, and no image to glance at, so every marked passage has to carry its own context. Aim for two or three sentences, roughly 20 to 30 seconds. Front load the answer. Avoid phrases like see the chart below or as shown above, because they reference something the listener cannot see. Spell out anything that depends on visual formatting, and keep numbers and units unambiguous.

Do and do not

cssSelector versus xpath

Testing the markup

Validate the JSON-LD like any other structured data. Paste the page or the snippet into the Schema Markup Validator at validator.schema.org and confirm the SpeakableSpecification parses with no errors and that the selectors are present. Note that Google's Rich Results Test does not report a dedicated speakable result, so a clean parse in the schema validator plus a manual check that each selector resolves to the intended text is the practical bar. Load the live page, run the selector in your browser console with document.querySelector('.tts-summary'), and read the returned text out loud to sanity check it.

Frequently asked questions

Related reading

Speakable is one tactic inside answer engine optimization. Pair it with broader voice search optimization work and with your wider schema and structured data setup.