Speakable schema is a Schema.org markup type that flags specific sections of a webpage as suitable for text-to-speech engines, telling Google Assistant and other voice-first surfaces which sentences to read aloud when users ask voice questions. It uses the SpeakableSpecification property to identify those sections by CSS selectors or XPath.
For treatment centers and service businesses, speakable schema is one of the few structured-data signals built for voice surfaces. When a family asks a smart speaker “what is partial hospitalization,” the device picks a passage to read aloud. Speakable schema tells Google which passage that should be.
What Speakable Schema Does
Speakable schema marks the parts of a page that are good candidates for spoken audio output. It does not change how the page renders for human readers. It only adds machine-readable hints inside the page’s structured data so voice agents know which sentences read cleanly out loud.
The property lives inside an Article or NewsArticle schema block. Inside that block, a SpeakableSpecification points to specific elements by CSS selector or XPath. Google’s documentation describes speakable as a way to expose “concise, easily understood” passages that work without surrounding visual context.
The original use case was Google Assistant on smart speakers. The signal has since expanded into voice queries on mobile, Android Auto, and the audio layer of AI search experiences. As Google’s AI Overviews add voice playback in more surfaces, speakable schema becomes a small but compounding citation signal.
Key Takeaways
- Speakable schema marks page sections for text-to-speech. It tells Google Assistant and other voice agents which sentences to read aloud when a user asks a spoken question.
- Implementation uses CSS selectors or XPath nested inside an Article or NewsArticle schema. Each speakable section should be a self-contained passage, not a fragment that depends on surrounding context.
- Google still labels speakable as “limited release” and ties production eligibility to news publishers. Service-business sites use it as a topical-coverage signal for voice surfaces, not as a guaranteed rich-result trigger.
- The best candidates for speakable markup are FAQ answers, glossary definitions, and intro paragraphs. Short, declarative passages that stand alone are the ones voice agents prefer to read.
- Treatment centers gain real value from speakable schema on family-facing information pages where a parent or partner is searching by voice while driving, in a hospital, or away from a screen.
- Speakable does not replace FAQPage or HowTo schema. The three are stackable signals, each tuned for a different question shape, and the right page often carries more than one.
Why Speakable Schema Matters for Treatment Centers
Behavioral health queries are heavily voice-driven. Families call, drive, and search at moments when typing is impractical. A parent in the ER, a partner in the car after a relapse, a sibling on a hospital floor: each is more likely to ask a smart speaker than open a browser.
That audience asks short, urgent questions. “What is medical detox.” “How long is residential treatment.” “Does insurance pay for IOP.” Each is a question a smart speaker can answer in one or two sentences if the right page has marked up its answer cleanly.
Treatment centers that mark their FAQ blocks and definition sections as speakable give voice agents permission to pull those passages directly. Pages without speakable markup are still eligible to be quoted, but the agent has to guess which sentence reads well. The hint reduces guessing.
The voice channel also feeds branded search. A family that hears your center’s name through a smart-speaker answer is more likely to search the brand the next day. Speakable schema turns voice surfaces into a top-of-funnel signal that compounds with the rest of your answer engine optimization work.
How Speakable Schema Works
A speakable specification sits inside an Article (or NewsArticle, MedicalWebPage, WebPage) schema as a property. It contains either a list of CSS selectors or an XPath expression that points to the readable passages on the page.
CSS selectors are the modern default. They are easier to write, easier to QA, and match how most developers think about page structure. XPath is supported but treated as a fallback for legacy stacks.
A minimal speakable block looks like this:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "What Is Medical Detox?",
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [".article-intro", ".faq-answer"]
}
}The two selectors above tell a voice agent: when reading this article aloud, prioritize the intro section and any FAQ answers. Google does not require selectors to match a single element. Multiple matches are treated as multiple speakable passages, read in DOM order.
For the canonical syntax, see Google’s Speakable structured data documentation and the SpeakableSpecification reference on Schema.org. Both update as Google expands speakable coverage past its original news-publisher scope.
Implementing Speakable Schema on a Treatment Center Site
Implementation breaks into three steps: pick the right pages, pick the right passages, and write selectors that match. None of the three is technically difficult. Most teams trip on selection, not on syntax.
Pick the right pages
Speakable markup makes the most sense on pages a family member is likely to reach via voice search. Definition pages, glossary entries, FAQ-heavy service pages, and admissions intro pages are the strongest candidates. Skip pages that are heavily transactional, image-led, or built around forms.
Pick the right passages
The best speakable passages are short (one to three sentences), self-contained, and free of context-dependent phrases like “as we saw above” or “click here for more.” A passage that reads cleanly when removed from the page is a passage that reads cleanly aloud.
The intro paragraph of a glossary entry is a near-perfect speakable target. The first paragraph of an FAQ answer is another. Bulleted lists work in some cases, though voice agents tend to compress lists into prose during playback.
Write selectors that match
The selectors in the speakable block have to actually match elements on the rendered page. The most common implementation bug is selectors that match in the developer’s local environment but not in the WordPress or Elementor render. QA every selector against the live HTML, not the editor.
Webserv ships speakable selectors on every glossary entry and on the FAQ blocks of every capability page. The selectors target the visible passage and the FAQ answer wrapper, both of which survive the Gutenberg-to-rendered-HTML pipeline cleanly.
Speakable Schema and Answer Engine Optimization
Speakable schema is one signal in a broader stack. It does not produce rankings on its own. It works alongside topical relevance, E-E-A-T, and the rest of the structured-data layer to make a page legible to AI and voice surfaces.
In the AEO stack, speakable sits at the audio output layer. Other schemas describe what the page is about (Article, FAQPage, MedicalWebPage). Speakable describes how the page should sound when read aloud. The two layers stack, they do not substitute.
For treatment centers running a full AEO program through Webserv’s AEO capabilities, speakable markup tends to be added once the page has its core schema in place: Article, FAQPage where applicable, and any medical or organizational entity references. Speakable is a finishing layer, not a foundation.
Citation share in AI Overviews and voice responses is the metric to watch after deployment. The change is usually small per page and meaningful in aggregate across a cluster of 30 or 40 marked-up pages.
Limitations and Common Mistakes
Speakable schema has real limits, and Google has been explicit about them. The feature is still labeled “limited release,” and rich-result eligibility is tied to NewsArticle for now. Adding speakable to a service page will not produce a rich result. It still works as a voice-surface hint.
The most common mistakes:
- Marking too much of the page as speakable. If the selectors capture half the article, the agent has no signal about which passage to prefer. Keep speakable selections short and specific.
- Pointing to passages that depend on context. A sentence that starts with “this is why” or “as a result” reads poorly when lifted out. The passage has to make sense on its own.
- Selectors that match in the editor but not on the live page. Always validate against the rendered HTML using Google’s Rich Results Test or the Schema.org validator.
- Using speakable as a substitute for FAQPage schema. They answer different questions. FAQPage exposes a list of Q-and-A pairs. Speakable says “here is the readable passage.” Most FAQ-rich pages need both.
- Expecting a ranking lift. Speakable is a citation signal for voice surfaces. It is not a ranking factor, and pages that add speakable without underlying content depth will not move.
Speakable Schema vs FAQPage vs HowTo Schema
The three structured-data types get confused often. Each one fires on a different question shape, and the pages that perform best for voice and AI search usually carry more than one.
| Schema type | What it marks | Best for | Voice eligibility |
|---|---|---|---|
| Speakable | Page sections suitable for text-to-speech playback | Glossary intros, FAQ answers, definition passages | Primary signal for Google Assistant audio playback |
| FAQPage | A list of question-answer pairs on the page | Service pages with multiple short Q-and-As | Eligible for AI Overview citations and voice answers |
| HowTo | A sequence of steps to complete a task | Procedural content (currently restricted in Google rich results) | Limited voice surface use post-2023 restriction |
The practical combination on a treatment center service page is FAQPage for the Q-and-A block, Article (or MedicalWebPage) wrapping the page, and speakable selectors pointing to the intro and the first sentence of each FAQ answer. That stack covers AI text citations, voice playback, and rich-result eligibility in one payload.