Speakable is a speakable property within Schema.org's Article and WebPage types that explicitly marks content sections optimized for text-to-speech (TTS) conversion. Unlike generic page scraping, this structured data signals to voice assistants and screen readers exactly which textual segments—identified via CSS selectors or XPath—should be read aloud, filtering out navigation elements, advertisements, and other non-essential content.
Glossary
Speakable

What is Speakable?
A specialized Schema.org property that identifies specific sections of an article or webpage most suitable for text-to-speech conversion by voice assistants and screen readers.
The specification uses a SpeakableSpecification type containing cssSelector or xpath values to pinpoint DOM elements. By implementing this markup, publishers improve audio accessibility and increase the likelihood their content is surfaced in voice search results and Google Assistant responses, ensuring a clean, contextually coherent listening experience for users.
Key Features of the Speakable Property
The Speakable property identifies content sections optimized for text-to-speech (TTS) conversion, enabling voice assistants to deliver concise, high-quality audio summaries.
Core Definition & Mechanism
The Speakable property is a Schema.org type that pinpoints specific parts of an article or webpage suitable for text-to-speech (TTS) conversion. It uses XPath or CSS selectors to target HTML elements. When a voice assistant receives a query, it can parse the structured data to extract only the speakable content, bypassing navigation, ads, and tangential text. This results in a direct, audible answer rather than a robotic reading of the entire page.
Technical Implementation
Implementation requires embedding a SpeakableSpecification within a WebPage or Article schema. The xpath or cssSelector property points to the DOM node containing the speakable text.
- JSON-LD Example:
"speakable": { "@type": "SpeakableSpecification", "xpath": ["/html/head/title", "/html/body/div[2]/p[1]"] } - Content Rules: The targeted text must be straightforward, concise, and grammatically correct when read aloud. Avoid complex tables or nested lists.
- Validation: Use Google's Rich Results Test to confirm the markup is correctly parsed.
Content Guidelines for TTS
Content marked as speakable must adhere to strict editorial guidelines to ensure a natural auditory experience:
- Brevity: Limit to 20-30 seconds of spoken audio (approx. 2-3 sentences).
- Clarity: Use simple sentence structures. Avoid jargon that is hard to pronounce.
- Self-Contained: The snippet must make sense without visual context or surrounding paragraphs.
- No Visual Cues: Avoid phrases like "click here" or "as seen in the chart below."
Accessibility & Screen Readers
While primarily an SEO tool for voice assistants, speakable complements Web Accessibility Initiative (WAI) standards. Screen readers can theoretically leverage this markup to skip repetitive UI elements and jump to the core content. However, speakable is not a replacement for ARIA labels or proper semantic HTML. It serves as a parallel, AI-focused signal that reinforces the primary narrative of the page for auditory consumption.
Limitations & Best Practices
The speakable property has specific technical constraints:
- Eligibility: Currently, Google primarily supports it for news articles and blog posts.
- No Markup in Target: The selected HTML element should contain only text. Inline markup like
<em>or<a>tags can cause TTS engines to stumble. - Single Focus: Do not mark up the entire body. Select only the most newsworthy summary sentence.
- Testing: Always listen to the output via a TTS simulator to catch awkward pronunciations before deployment.
Frequently Asked Questions
Technical answers to the most common implementation and strategic questions regarding the Schema.org Speakable specification for voice assistant and text-to-speech optimization.
Speakable is a Schema.org property that identifies specific sections of an article or webpage most suitable for text-to-speech (TTS) conversion by voice assistants and screen readers. It works by wrapping content within speakable property nodes, typically using JSON-LD or Microdata, to signal to search engines and AI agents which textual segments are optimal for audible recitation. The specification relies on cssSelector or xpath properties to pinpoint HTML elements containing the target text. When a voice assistant like Google Assistant processes a page with Speakable markup, it prioritizes the marked sections, ignoring navigation, ads, or boilerplate, ensuring a clean, concise auditory summary. This is critical for Generative Engine Optimization because AI-driven answer engines use these signals to extract high-confidence, direct-answer content for spoken responses in conversational interfaces.
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
Understanding Speakable requires familiarity with the broader Schema.org vocabulary and structured data concepts that enable voice assistant and screen reader optimization.
WebPage
The parent Schema.org type under which Speakable is declared. A WebPage entity represents a single document on the web and serves as the container for properties like speakable, mainEntity, and breadcrumb.
- Speakable is a property of WebPage (and its subtypes like Article, NewsArticle)
- Declaring a WebPage with
@idenables cross-referencing within a knowledge graph - Voice assistants use the WebPage context to determine which sections to prioritize for TTS output
MainEntity
A Schema.org property that identifies the primary topic of a webpage, helping search engines and voice assistants disambiguate the central subject from peripheral content.
- Works in tandem with Speakable: MainEntity defines what the page is about, Speakable defines which text to read aloud
- Critical for voice search accuracy—assistants use MainEntity to confirm relevance before reading speakable sections
- Example: On a product page, MainEntity points to the Product type while Speakable highlights the description paragraph
DefinedTerm
A Schema.org type for marking up glossary entries and definitions with formal term-description pairs. When combined with Speakable, it enables voice assistants to deliver concise dictionary-style answers.
- Use
DefinedTermwithin aDefinedTermSetto structure entire glossaries - Speakable can point to the
descriptionproperty of a DefinedTerm for TTS-friendly definition snippets - Enhances eligibility for dictionary-rich results and voice answer boxes
FAQPage
A Schema.org type that structures question-and-answer pairs on a single page. Each Question and Answer block becomes a discrete unit that voice assistants can parse and read aloud sequentially.
- Speakable can target individual Answer nodes within an FAQPage for precise TTS selection
- Google often surfaces FAQPage markup as rich results and voice answers
- Best practice: Keep each Answer concise (under 2-3 sentences) for optimal voice delivery
ClaimReview
A Schema.org type used to fact-check a specific statement, indicating the claim, the review verdict, and the fact-checking source. When marked as speakable, voice assistants can deliver verified information with explicit credibility signals.
- Speakable applied to ClaimReview enables voice assistants to read fact-check verdicts directly
- Builds algorithmic trust—AI models weigh speakable, fact-checked content as high-confidence sources
- Critical for news publishers combating misinformation in voice search results

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us