Speakable Schema: The Voice Search Reality Check
Speakable schema only works on Google Assistant, only for US English news content, and is still beta. Here is what it actually does and does not do.
Speakable schema does not make your content readable by Alexa, Siri, or voice search in general. It’s a Google-only feature, still officially in beta, that lets Google Assistant read short sections of news content aloud on smart speakers in the US, in English. If a plugin or an agency sold you on “voice SEO” using speakable schema for a non-news site outside those constraints, it’s very likely doing nothing at all.
The confusion is understandable. “Speakable” sounds like it should mean voice search broadly, the way “mobile-friendly” means something across every phone. It doesn’t work that way. Google built this specific property for one narrow use case, documented the constraints plainly, and the wider SEO content mill mostly skipped that part.
What does speakable schema actually claim to do?
The speakable property is a schema.org addition, applied to Article or WebPage types, that flags specific sections of a page as suited for text-to-speech playback. You mark sections with a SpeakableSpecification, using either a CSS selector or an xPath, and in theory a voice assistant can identify and read those sections aloud rather than guessing at what matters on the page.
That’s a genuinely useful idea. The gap is between what the idea sounds like it should cover and what Google actually built and shipped.
Where does the claim fall apart?
Six places, and Google’s own documentation confirms all of them.
Speakable schema: claim vs reality
Speakable Schema: Claim vs Reality
| The claim | The reality | |
|---|---|---|
| Works across voice assistants | Boosts visibility on Alexa, Siri and Google Assistant alike | Only Google Assistant reads schema.org speakable at all |
| Available to any website | Any site can win a spoken voice result | Eligibility is tied to topical news queries, weighted toward news publishers |
| Works in any language or country | Add the markup and it works globally | Limited to US users with Google Home set to English, English-language publishers |
| Improves search rankings | Adding it improves where you rank | It only flags TTS-suitable sections; it isn’t a ranking signal |
| A mature, stable feature | Safe to build a strategy around | Still labelled BETA by Google, subject to change without notice |
| Mark up the whole article | Tag everything as speakable for best results | Google’s own guidance: key points only, 20 to 30 seconds per section |
The first and biggest gap: speakable is a Google Assistant feature, full stop. Alexa doesn’t parse schema.org markup for this purpose, it works through Alexa Skills, an entirely separate development framework. Siri doesn’t read speakable markup either. I’ve had clients ask us to add speakable schema expecting it would help their content surface in an Alexa flash briefing. It won’t, because nothing about Alexa’s architecture even looks at this property.
Second, Google explicitly scopes the feature to news content answering topical queries, the kind of thing you’d trigger by asking a Google Home “what’s the latest news about…” Google’s own getting-started instructions are framed entirely around making “news content” eligible. A recipe blog or a local service business marking up its blog posts as speakable isn’t violating any rule, but it’s very unlikely to trigger the feature it was built for.
Is speakable schema even out of testing yet?
No. Google’s documentation still carries the heading “Speakable (BETA)” and states plainly that the feature is in beta and subject to change in requirements or guidelines. That’s not boilerplate caution, it’s a genuine signal not to build critical infrastructure around it. Features that stay in beta this long sometimes get quietly folded into something else or deprecated outright, and Google gives no commitment either way.
The country and language restriction compounds this. Per Google’s documentation, the property currently works only for US users with Google Home devices set to English, from publishers who publish in English. Google says it hopes to expand once enough publishers adopt it, which has been the stated position for a long time without a firm timeline attached.
Should you implement it anyway?
If you’re a US-based, English-language news publisher, yes, it costs little to add and the eligibility requirements line up with what you already are. Follow Google’s own guidance closely: mark up key points rather than the whole article, avoid tagging datelines, captions, or source attributions since they read awkwardly out loud, and aim for roughly 20 to 30 seconds per marked section, about two or three sentences.
For almost everyone else, speakable schema is a poor use of a developer’s afternoon. A local business, a SaaS blog, an ecommerce site, none of these fit the news-query trigger the feature was designed around, and the audience it could theoretically reach (US English speakers with a Google Home set up a specific way) is a sliver even before you account for whether Google Assistant actually selects your content over a competing publisher’s.
What should you do instead if “voice search” is the actual goal?
Most of what people mean by “voice search optimisation” is really just answering questions clearly and concisely, which is exactly what FAQPage schema and well-structured HowTo schema already help with, on every platform, not just Google Assistant with the right hardware. Featured snippets and AI Overviews pull directly from clearly formatted question-and-answer content far more reliably than speakable ever will, and that content works whether someone’s reading it on a screen or having it read to them by whatever assistant they’re using.
If a client specifically asks for “voice SEO,” the honest answer is usually that clean structure, direct answers in the first sentence, and solid structured data across the page covers the real opportunity. Speakable is a narrow tool for a narrow, mostly-news use case, not a category of SEO work on its own.
Does it help with ChatGPT or other AI assistants?
No, and this is the second confusion worth clearing up while we’re here. ChatGPT’s voice mode, Perplexity, and Amazon’s newer AI-driven Alexa experiences don’t consume schema.org speakable either. They generate spoken answers from whatever text they’ve retrieved or been trained on, not from a page flagging specific sections as TTS-ready. Speakable is a Google Assistant mechanism, full stop, not a general bridge into the wider AI answer-engine ecosystem people sometimes assume it plugs into.
If AI visibility across ChatGPT, Perplexity and Google’s AI Overviews is the actual goal, that’s a separate discipline built on clean entity signals, quotable and self-contained answers, and content structured so an answer engine can lift a paragraph cleanly. Speakable doesn’t touch any of that. It’s worth not conflating the two just because both involve something being “read” to a user eventually.
How do you implement it correctly, if it applies to you?
- Use
cssSelectororxPath, never both. Google’s spec requires one or the other, and mixing them is a common validation error. - Target headline and a short summary, not the full body. Google’s guidance recommends concise sections, not an entire article dumped into one speakable block.
- Rewrite the opening for clarity if you include it. Google explicitly suggests breaking the top of the story into short, individual sentences so TTS reads cleanly.
- Skip datelines, captions and bylines. These read as noise out loud and Google’s technical guidelines call this out directly.
- Validate with the Rich Results Test and confirm there’s no manual action against the page before assuming a lack of results means broken markup.
Frequently asked questions
Does speakable schema work with Alexa or Siri?
No. Speakable is a Google Assistant feature only. Alexa uses a separate Skills framework and Siri doesn’t parse schema.org speakable markup at all, so adding it has zero effect on either platform.
Is speakable schema out of beta yet?
No, Google’s own documentation still labels it “Speakable (BETA)” and states the feature is subject to change in requirements or guidelines, so it isn’t something to build a core strategy around.
Do I need to be a news publisher to use speakable schema?
Not strictly by rule, but Google’s stated use case and getting-started guidance are built entirely around making news content eligible for topical voice queries, so non-news sites are very unlikely to see it trigger.
What’s the difference between speakable and FAQ schema for voice results?
Speakable targets Google Assistant news readouts specifically. FAQPage and HowTo schema help structure clear question-and-answer content that both search engines and AI answer engines can pull from broadly, which is a far bigger and more reliable opportunity for most sites.
Will speakable schema help my rankings?
No. It flags which sections are suitable for audio playback. It isn’t a ranking factor and Google doesn’t describe it as one anywhere in the documentation.
How do I implement speakable schema correctly?
Use either cssSelector or xPath (not both) inside a SpeakableSpecification, mark up short key sections rather than the whole article, and follow Google’s content guidelines on avoiding datelines and keeping each section to roughly two or three sentences.
Sources
- Speakable (BETA) structured data, Google Search Central
- speakable property definition, Schema.org
- Schema Markup: A Practical Guide With Copy-Paste JSON-LD
- FAQPage Schema After Google Reduced Its Display
- HowTo Schema: Where It Still Earns Results
- Rich Snippets vs Rich Results vs SERP Features
Want this done on your site?
Every PalV’s DM engagement starts with a free audit of your actual website — a 12-point
crawl covering what is blocking indexation, on-page gaps against your primary keywords, speed
findings, and the three to five fixes worth making first. Delivered in two working days. No
payment details, and the findings are yours whether you hire us or not.
