Speakable is one of the least-deployed Schema.org properties across the treatment center sites our content SEO team audits.
Most SEO agencies do not include it in standard schema deployment. Most operators have never heard of it. Google’s own documentation flags it as a beta feature that has been in beta since 2018.
The reason to care about it in 2026 is not the original use case. Google originally introduced Speakable so Google Assistant could read aloud selected passages of news content for voice-driven news briefings.
That use case never produced meaningful traffic for treatment centers because the voice-assistant news surface is narrow.
The reason Speakable matters now is that the property marks specific passages of your content as designed to be spoken aloud, which functionally means those passages are short, declarative, and self-contained enough to be reused as retrieval chunks.
Google AI Mode, AI Overviews, ChatGPT, Perplexity, and Claude all retrieve passages from indexed content when answering user queries. The retrieval systems prefer passages that are short, declarative, and self-contained because those pass through the summarization step of the answer pipeline with the least distortion.
Speakable is not the only way to signal that a passage meets those criteria, but it is one of the few standardized ways to do it via Schema.org.
The specific 2026 opportunity: Speakable is under-deployed enough across BH sites that facilities that deploy it correctly earn a signal advantage on the retrieval-friendly passage identification without the compressed field getting saturated.
Whether that advantage compounds over the next 12 months is speculative. The deployment cost is low enough that the risk-adjusted answer is to ship it.
This piece walks what Speakable actually is, where it fits in the AI-readability stack, which specific content on treatment center sites benefits most from Speakable markup, and how to deploy it in JSON-LD Schema.org on WordPress.
It also covers the specific gotchas that undermine the signal when deployment is sloppy, and complements our entity SEO explainer that covers the broader Schema.org discipline.
Key Takeaways
- Speakable is a Schema.org property that marks specific passages of a page as designed to be spoken aloud. It was introduced by Google in 2018 for voice-assistant news briefings and has remained in beta ever since. The original voice-assistant use case produces thin traffic for treatment centers. The 2026 relevance is that the marker also identifies passages that are retrieval-friendly for AI answer surfaces.
- Google AI Mode, AI Overviews, ChatGPT, Perplexity, and Claude all prefer passages that are short, declarative, and self-contained when retrieving content for AI answers. Speakable is one of the few standardized Schema.org ways to signal that a passage meets those criteria. Whether AI retrieval systems specifically honor Speakable markers is not publicly confirmed; the deployment is a low-cost hedge that pairs with the other AI-readability surfaces.
- Four content types on treatment center sites benefit most from Speakable markup: FAQ answers (2-3 sentence declarative answers), service page key facts (single-paragraph value propositions), blog post Key Takeaways sections (short bulleted or paragraph summaries), and author bio credential lines (2-3 sentence clinician credentials).
- Speakable deployment uses JSON-LD Schema.org with SpeakableSpecification. The property accepts CSS selectors or XPath expressions that identify the specific passages on the page. Correct deployment marks 2-5 passages per page. Marking too many passages (whole articles, most of the visible content) undermines the signal.
- The specific gotchas that undermine Speakable signal: selector drift when the page template changes, marking passages that contain compound sentences or clinical jargon that does not survive the spoken-aloud test, marking testimonial content or patient-perspective passages that carry HIPAA-adjacent implications, and stacking Speakable with conflicting schema. Audit selectors quarterly and passage quality semi-annually.
DEFINITION
Speakable (SpeakableSpecification). A Schema.org property that identifies specific passages of a page as short, declarative, and self-contained enough to be spoken aloud. Deployed via JSON-LD inside Article, WebPage, or Organization schema using CSS selectors or XPath expressions that point to the marked passages. Originally introduced by Google in 2018 for voice-assistant news briefings; still labeled beta in 2026.
Distinct from FAQ Block schema (which structures FAQ pairs, not passage retrieval preference) and distinct from Article headline metadata (which is page-level, not passage-level). Operates as a within-page passage marker inside the broader AI-readability stack. Functional role in 2026: identifies passages that fit the retrieval-friendly shape AI answer surfaces prefer, regardless of whether the specific Speakable property triggers preferential treatment.
ADOPTION REALITY
Beta since 2018 and never formally graduated. Google’s Search Central documentation still lists Speakable as a beta feature. No major AI system (Google AI Mode, AI Overviews, ChatGPT, Perplexity, Claude) has publicly confirmed consuming Speakable markers as a retrieval signal.
The reason to deploy anyway: the marker identifies passages that meet the retrieval-friendly shape AI answer surfaces demonstrably prefer. Speakable is not a rank driver or a citation guarantee; it is a low-cost hedge that pairs with the other AI-readability surfaces to compound the overall signal. If AI retrieval evolves to honor Speakable specifically, the deployment is already in place. If it does not, the passage-quality discipline the deployment forces has value regardless.
What Speakable actually is
Speakable is a Schema.org property that identifies specific parts of a page as being suitable for text-to-speech playback. The full type is SpeakableSpecification, and it lives inside standard Article, WebPage, or Organization schema as a property value.
The Schema.org documentation describes the intended use case as identifying content that is short, self-contained, and appropriate for reading aloud by a voice assistant.
Google’s implementation guidance from 2018 originally targeted news content, with the specific use case of Google Assistant reading a morning news briefing to a user. Google Assistant would select passages from indexed news content that carried the Speakable marker and read those passages aloud.
That original use case never produced meaningful traffic for treatment centers. The voice-assistant morning briefing surface is narrow, most treatment centers do not compete for news-adjacent queries, and the voice-assistant category has not expanded in the ways Google projected in 2018.
The property remained beta from 2018 through 2026 without formal graduation. Google’s Search Central documentation still lists it as a beta feature. Direct implementation of Speakable-driven voice-assistant briefings continues to be limited.
The reason Speakable matters in 2026 is not the original use case. The property marks specific passages of a page as short, declarative, and self-contained enough to be spoken aloud.
That marker functionally identifies passages that are retrieval-friendly for AI answer surfaces even when the marker is not being consumed for voice playback specifically.
Where Speakable fits in the AI-readability stack
Speakable sits inside the Schema.org layer of the five-surface AI-readability stack: Schema.org (Speakable lives here), llms.txt, entitymap.json, AI Information page, and YouTube channel.
The specific role: Speakable is a within-page passage marker rather than a page-level or site-level signal. Where Organization schema and Person schema identify entities and their relationships, Speakable identifies which specific text passages on a given page are retrieval-friendly.
The interaction with the other four surfaces: AI systems that ingest the Schema.org layer for entity resolution can also parse the Speakable markers on the same pages to identify which passages to prefer when retrieving evidence chunks. The AI Information page and entitymap.json both operate at the entity level; Speakable operates at the passage level within a page. Our full AI search stack piece walks the multi-surface interaction in depth.
Facilities that deploy Speakable without deploying the entity-level surfaces produce a partial signal. The passage markers exist, but the entity context they attach to is thin. Facilities that deploy the entity-level surfaces without deploying Speakable produce entity resolution but leave the passage-preference signal on the table.
Which content types benefit most from Speakable markup
Four content types on treatment center sites carry the passage shape that Speakable is meant to identify.
FAQ answers
The best Speakable candidates on any treatment center site. FAQ answers are already structured to be short, declarative, and self-contained (a 2-3 sentence snippet answer per the v5.5 FAQ pattern). Marking FAQ answers as Speakable formalizes what the format already implies. This is the highest-yield Speakable deployment on a treatment center site.
Service page key facts
Single-paragraph value propositions, program overviews, and clinical positioning statements on service pages. The specific pattern that works: a 40-60 word paragraph near the top of the service page that states what the program is, who it serves, and what makes it distinctive. Marking that paragraph as Speakable identifies it as the retrieval-friendly summary chunk for the service.
Blog post Key Takeaways sections
The KT section on Webserv-format blog posts (short bulleted or paragraph summaries) is already structured for retrieval. Marking KT sections as Speakable reinforces the passage-level signal. Alternatively, individual KT bullets can be marked as Speakable if the bullet is a complete declarative statement rather than a fragment.
Author bio credential lines
The 2-3 sentence clinician credential paragraph in the byline block or in the closing bio. Marking this line as Speakable identifies it as the canonical author-authority retrieval chunk, which pairs with the Person schema surface documented in our author bios that build E-E-A-T piece.
Not every passage on a page benefits from Speakable. The property loses meaning when applied to too much content on a single page. The target: 2-5 marked passages per page, each carrying the short-declarative-self-contained shape.
The Speakable decision surface at a glance
2018
Introduced as beta — still beta in 2026, never formally graduated
4
Content types that benefit: FAQ, service key fact, KT, author credential
2-5
Marked passages per page — more dilutes the signal
90 d
Selector-drift audit cadence — theme updates break CSS pointers
How to deploy Speakable in JSON-LD
The Schema.org syntax uses SpeakableSpecification as a property value inside Article, WebPage, or Organization schema. The property accepts either CSS selectors or XPath expressions that identify the specific passages.
The CSS selector pattern that works on WordPress:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Article Title",
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [
".key-takeaways-section",
".author-bio-credentials",
"#faq-first-answer"
]
}
}The XPath pattern works when CSS selectors are not stable across page templates:
{
"@context": "https://schema.org",
"@type": "Article",
"speakable": {
"@type": "SpeakableSpecification",
"xpath": [
"/html/body/div/article/section[@class='key-takeaways']",
"/html/body/div/article/footer/section[@class='author-bio']"
]
}
}Most treatment center WordPress deployments use the CSS selector pattern because the selectors are more stable across theme updates and are easier to audit visually.
On WordPress with Rank Math, custom Speakable schema goes through Rank Math’s custom schema builder. The exact configuration path: Rank Math, Titles & Meta, Custom Schema, add SpeakableSpecification block with the CSS selectors that identify the marked passages.
Alternatively, JSON-LD can be injected directly through the theme’s wp_head hook for facilities with developer capacity.
The specific gotcha in the deployment: CSS selectors must resolve to actual elements on the page. Selectors pointing to elements that no longer exist because of a theme update or page template change produce invalid Speakable markup that Google’s Rich Results Test flags as an error.
Common deployment gotchas
Five specific gotchas undermine Speakable deployment across the treatment center sites we audit.
Selector drift. CSS selectors marked in Speakable schema become invalid when the underlying page template changes. A selector pointing to .key-takeaways-section becomes invalid when a theme update renames the class to .article-takeaways. Speakable markup then references non-existent elements, and the signal degrades. Audit quarterly.
Marking passages that fail the spoken-aloud test. Speakable is meant to identify passages that would read cleanly if a voice assistant spoke them aloud. Compound sentences with three or more clauses, passages that reference specific visual elements (“as shown in the chart above”), and passages heavy with clinical jargon all fail the test.
Testimonial and patient-perspective passages. Marking a testimonial as Speakable identifies it as a retrieval-friendly chunk that AI systems can lift. Patient testimonials with identifiable details carry HIPAA-adjacent implications when they get consumed by AI training corpora or reused in AI answers. Testimonial content should not carry Speakable markup even when the testimonial otherwise fits the shape.
Marking too much content. The property loses meaning when applied to whole articles, most of the visible content, or every heading on a page. Google’s implementation guidance suggests marking a small number of specific passages per page. The functional target we run: 2-5 marked passages per page maximum. Facilities that mark everything produce markup overhead without additional signal.
Stacking with conflicting schema. Speakable inside Article schema with a conflicting @type declaration or with malformed nested schema produces parsing errors. Google’s Rich Results Test surfaces these errors on any Speakable deployment. Test every Speakable deployment through the Rich Results Test before publishing.
DO
- Mark 2-5 passages per page maximum — FAQ answers, service page key facts, KT sections, and author bio credential lines are the highest-yield candidates.
- Deploy Speakable alongside FAQ Block schema — the two stack. FAQ Block structures the pairs, Speakable adds passage-preference on top.
- Test every Speakable deployment through Google’s Rich Results Test before publish — malformed nested schema or selectors pointing to non-existent elements fail there first.
- Deploy selectively on service pages, cornerstone clinical content, and cluster hub pages — not on every blog post.
- Audit CSS selectors quarterly (catch theme updates) and passage quality semi-annually (catch content edits that break the spoken-aloud shape).
DON’T
- Mark whole articles or most of the visible content — the property loses signal value when applied broadly.
- Mark testimonial or patient-perspective passages as Speakable — identifiable narrative content plus retrieval-friendly signal produces HIPAA-adjacent exposure.
- Mark passages heavy with compound sentences, clinical jargon, or visual references (“as shown in the chart above”) — they fail the spoken-aloud test.
- Expect Speakable to drive voice-search traffic — the original Google Assistant use case never produced meaningful BH traffic. The 2026 case is AI answer retrieval, not voice search.
- Skip the entity-level surfaces (Organization, Person, sameAs) and deploy only Speakable — the passage marker without entity context produces a partial signal.
The Speakable audit cadence
Speakable requires a lighter audit cadence than the entity-level Schema.org surfaces because the passage markers are more stable than the entity metadata. The specific cadence:
Quarterly, run through the sites where Speakable is deployed and confirm the CSS selectors still resolve to real elements. Quarterly is aggressive enough to catch theme updates or page template changes; running less frequently produces stale selectors that persist for months.
Semi-annually, audit whether the marked passages still fit the spoken-aloud test. Content edits sometimes turn what was a clean declarative passage into a compound sentence with visual references. If the marked passage no longer fits the shape, either the passage gets rewritten to fit or the Speakable marker gets removed.
Annually, audit whether the Speakable deployment strategy is still producing the intended signal. AI retrieval systems evolve. If AI answer surfaces stop honoring Speakable markers (which would be visible through citation monitoring), the deployment strategy shifts to prioritize the other AI-readability surfaces.
Frequently Asked Questions
Does Google actually use Speakable markup outside of voice-assistant briefings?
Not publicly confirmed. Google’s Search Central documentation on Speakable references only the voice-assistant use case. Google has not published guidance confirming that Speakable markers influence AI Mode retrieval, AI Overviews content selection, or any other AI answer surface.
The reason to deploy Speakable anyway: the marker signals which passages meet the retrieval-friendly shape criteria that AI answer surfaces demonstrably prefer. Whether the specific Speakable property triggers preferential treatment or whether the underlying passage quality is what triggers it, the deployment cost is low and the risk-adjusted answer is to ship it.
The correct expectation: Speakable is one of several signals that contribute to retrieval-friendly passage identification. It is not a rank driver or a citation guarantee. It is a low-cost hedge that pairs with the other AI-readability surfaces to compound the overall signal.
Do other AI systems (ChatGPT, Claude, Perplexity) honor Speakable markers?
Not publicly confirmed. None of the major non-Google AI systems have published guidance confirming Speakable-specific consumption. The observable pattern is that AI answer surfaces prefer short, declarative, self-contained passages regardless of the specific Schema.org markers present, which means Speakable-marked content tends to get preferential retrieval treatment because the marked passages already carry the preferred shape.
The practical implication: deploy Speakable because it identifies the correct passages, not because a specific AI system has confirmed the marker. If the passages carry the retrieval-friendly shape, the citation lift accrues to those passages regardless of whether Speakable is the trigger or a symptom. Our full AI search stack piece covers where Speakable sits relative to the other AI-readability surfaces.
The correct posture: ship Speakable as a low-cost hedge, expect the passage quality to matter more than the marker itself, and layer the other AI-readability surfaces (Schema.org entity graph, AI Information page, entitymap.json) on top.
Is Speakable a substitute for FAQ Block schema?
No. Both should be deployed. FAQ Block schema (via Rank Math’s FAQ block on Webserv-standard content) produces the structured FAQ format that Google’s AI Overviews and AI Mode surface as FAQ-specific rich results. Speakable adds a passage-preference marker on top of that structure.
The interaction: FAQ Block schema tells the AI system these are FAQ pairs. Speakable tells the AI system these specific passages are especially retrieval-friendly. Deploying both produces the strongest signal on FAQ content.
Speakable can be layered on top of Webserv-standard FAQ deployment with minimal additional configuration work. The CSS selector points at the FAQ answer container, and the SpeakableSpecification wraps around it. No changes to the FAQ block itself are required.
Should we deploy Speakable on all our blog posts or only high-priority pages?
Selective deployment. The value of Speakable degrades when applied to every page on the site because the marker stops being differential. If every page carries Speakable markup, the marker no longer identifies which passages are especially retrieval-friendly relative to other passages.
The specific deployment posture we run: Speakable on service pages (highest-priority commercial content), on cornerstone clinical content (high E-E-A-T authority pieces), on cluster head content (hub pages and sub-cluster head pieces), and on the author bio schema for high-visibility clinicians. Our author bios that build E-E-A-T piece covers the Person schema surface where the author-bio Speakable marker attaches.
Blog posts covering specific narrow queries typically do not need Speakable. Their passage-level shape is already implied by the query intent and the standard content structure. Adding Speakable to every blog post produces markup overhead without additional signal.
How long does the Speakable deployment take across a treatment center site?
For a facility with 20-40 pages of service and cornerstone content, the initial deployment is a 4-8 hour project. The specific work: identifying the target passages per page, mapping the CSS selectors, generating the JSON-LD blocks, deploying through Rank Math or theme injection, and testing every page through Google’s Rich Results Test.
The ongoing maintenance: quarterly selector audits and semi-annual passage-quality audits. Roughly 2 hours per quarter for a mid-size facility.
Portfolio operators deploying across multiple facilities benefit from a shared selector template. If all facilities in the portfolio use the same theme and page structure, the CSS selectors can be deployed once and reused. This reduces the per-facility deployment cost meaningfully.
Does Speakable help with voice-search rankings?
Marginally, if at all. The voice-search surface Google originally designed Speakable for (Google Assistant morning news briefings) never produced meaningful traffic for treatment centers. The general voice-search category (spoken queries to Google, Siri, Alexa) does not directly consume Speakable markers in most observed patterns.
The category that Speakable is functionally relevant to in 2026 is AI answer retrieval, not voice search specifically. Facilities considering Speakable deployment should treat it as an AEO surface rather than a voice-search surface. The traffic case does not depend on voice-search adoption growing; it depends on AI answer surfaces continuing to prefer short, declarative, self-contained passages.
Our full AI search stack piece covers where Speakable fits alongside the other four AI-readability surfaces in the operational deployment order.
Trevor Gage is the Director of Marketing at Webserv, a digital marketing agency for treatment centers.
