schema.org/SpeakableSpecificationNo rich result
SpeakableSpecification schema
The CSS selectors holding the page's canonical spoken answer.
Where to use it
Pages with a short, self-contained answer worth reading aloud.
A complete example
Valid as written, with every required property and the recommended ones that carry real information.
speakable-specification.json
{
"@context": "https://schema.org",
"@type": "SpeakableSpecification",
"cssSelector": [
".answer",
".summary"
],
"xpath": "A real xpath value"
}Properties
| Property | Status |
|---|---|
cssSelector | Required |
xpath | Recommended |
The three mistakes this type attracts
- 01Pointing at a heading rather than a complete sentence.
- 02Selectors that match nothing in the rendered HTML.
- 03Pointing at a long paragraph that cannot be read aloud in a few seconds.
Related types
Where this appears in the playbook
- Structured data: what each type is for and which ones earned their place.
- The schema graph: composing types into one graph with stable identifiers.
- One JSON-LD script per page, holding one @graph
- Stable @id anchors that cross-reference rather than duplicate
- Optional fields are omitted, never emitted as empty strings
Questions
What is the SpeakableSpecification schema type for?
The CSS selectors holding the page's canonical spoken answer. Use it on: pages with a short, self-contained answer worth reading aloud.
Which SpeakableSpecification properties are required?
SpeakableSpecification requires one property: cssSelector. It also recommends 1: xpath.
Does SpeakableSpecification produce a rich result?
SpeakableSpecification does not produce a Google rich result. It is still worth shipping, because its value is entity resolution and answer extraction rather than search result presentation.
What is the most common SpeakableSpecification mistake?
The most common SpeakableSpecification mistake is: Pointing at a heading rather than a complete sentence.