Speakable schema: markup almost nobody is eligible for
This is the one piece of structured data where the first thing to establish is whether you are allowed to benefit from it. The markup takes ten minutes. The eligibility rule behind it excludes most of the web, and knowing which side of it you are on is the whole of the decision.
The short answer
speakable marks the sections of a page suited to being read aloud, and Google restricts the news feature to approved publishers, so most sites will never see it used that way. It is still the only standard way to say which part of a document is the answer rather than the chrome, and cssSelector is the form to use.
The wall, stated before you write a line of it
speakableexists so a voice assistant reading news aloud knows which passage to read. Google's implementation of it has been scoped to news publishers from the beginning, and the documentation has never described a path by which a general site earns the feature. It has also been limited by language and region rather than available everywhere at once.
So the honest sequence is: if you are not publishing news, and not eligible for the news surfaces, the markup will validate and change nothing. That is not a reason to be quiet about the property, because a property that validates and does nothing is exactly the kind of thing that gets added to a template by somebody who read a checklist. It is a reason to be clear about who this section is for.
Two questions decide it, and neither is about your markup.
Do you publish time-sensitive reporting, with datelines, on a site a news aggregator would recognise as a publication? And is your primary audience in a language and region where the voice feature has actually shipped? A no to either means writing this markup is optional work with no expected return, and there is no shame in reading this page and deciding not to.
The rest of the structured data catalogue is not like this. Article, Organization and FAQPage markup does something for any site that publishes the corresponding thing. speakable is the only common property whose eligibility is decided by what kind of publisher you are rather than by what is on the page.
Worth separating from all of the above: speakable is a schema.org property, and schema.org is not any one company. Other consumers can read it, and the vocabulary outlives any particular product decision. What is narrow is the feature, not the property.
cssSelector or xpath, and why one of them is a standing bill
The property does not contain your text. It contains a pointer to your text, wrapped in a SpeakableSpecification, and the pointer takes one of two forms: cssSelector or xpath. You choose one. Both in the same specification is not the pattern.
The consequence is the thing to understand before you pick. Every other piece of structured data on your site duplicates the content: the markup says the headline is X, and if the visible headline changes to Y, the markup is merely wrong. This one is a reference into your DOM, so if the element it points at is renamed, wrapped, or moved by a redesign, the markup is not wrong, it resolves to nothing. Nobody is notified. The passage silently stops being nominated.
{
"@context": "https://schema.org",
"@type": "NewsArticle",
"headline": "Harbour dredging delayed until March",
"datePublished": "2026-08-14T07:30:00+02:00",
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [".article-headline", ".article-standfirst"]
}
}
/* the xpath form, for a template with no stable class names */
{
"@type": "SpeakableSpecification",
"xpath": [
"/html/head/title",
"/html/body//div[@id='summary']/p[1]"
]
}Prefer cssSelector, and prefer a class that exists for this purpose. A selector like .speakable-summary is a contract: it tells the next developer that something depends on it, which .mt-4 > p:first-child does not. An xpath expression walking a position-dependent path through your markup is the most fragile option available, because inserting one wrapper anywhere above the target breaks it.
The selector must also match content that is in the served HTML. A passage rendered by client-side JavaScript is not there when the document is parsed, which puts this in the same category as everything else that appears after load.
What to nominate, if you are one of the sites that can
The guidance is unusually specific and worth following exactly, because the failure modes are not syntax errors. Mark the headline and a short summary. Two or three sentences, in the region of twenty to thirty seconds of speech. Not the article body, and not the first paragraph if the first paragraph is a scene rather than a summary.
Marking the whole body is the mistake that looks like generosity. An assistant handed four minutes of prose to read has been handed something unusable, and the practical result is that your nomination is skipped in favour of a publisher who marked three sentences. More is not better here in a way that is genuinely unlike the rest of this audit.
Two things must not be inside the selected region: anything that is not prose, and anything that only makes sense visually. A byline, a timestamp, a photo caption, a share row, a "read more" link, a table. If your standfirst sits in a container that also holds the byline, the selector picks up the byline, and the assistant reads it out. That is the most common real-world defect in speakable implementations and no validator reports it, because the markup is correct and the container is simply larger than the author thought.
It also has to be text a person would recognise as an answer when it arrives with no screen attached to it, which is a writing problem rather than a markup one and has its own check.
Finding a property that lives inside another block
Listing the types a page declares is cheap. speakable is not a type, it is a property nested inside an Article or a WebPage, so finding it means parsing each JSON-LD block and walking into it, and confirming it is useful means resolving the selector against the served DOM as well.
This one needs the full crawl
Speakable is a property nested inside another type rather than a type of its own, so finding it means reading the contents of each block rather than listing the types a page declares.
The instant search on this site audits a single page, so rather than show you a verdict it cannot support, this guide sends you to the place the check actually runs.
The manual version, if you want it now: fetch the page, find the JSON-LD, and check that the selector inside speakablematches exactly the elements you meant, in the HTML as served rather than in your browser's inspector.
Does this affect AI search?
Not in the way the name suggests, and the distinction is worth drawing because voice and AI search get conflated constantly. speakableis a nomination for a text-to-speech pipeline: it says "read this bit out". It is not a retrieval signal, and no assistant treats a marked passage as more authoritative than the same sentences unmarked.
What a model reading your page needs is a passage that answers the question early and stands on its own, and that is a property of the writing. If you have one, you are already better placed for retrieval, whether or not a selector points at it. The markup does not add anything a language model was missing.
There is one genuine second-order benefit, and it is worth being honest that it is a side effect. Adding this property forces a decision you have probably never made explicitly: which two sentences on this page are the answer. Teams that go through that exercise usually improve the page, because the act of nominating a passage exposes pages that do not have one. The value is in the audit of your own content, not in the tag.
Why a property most sites cannot use is still in the catalogue
It sits at the bottom of the scale for the plainest reason available: for the large majority of sites, the correct action is to do nothing, and a check whose most common right answer is "not applicable" cannot be rated any higher.
It stays in the catalogue for two reasons. The first is that when it is present and broken, it is broken in a way nothing else reports. A stale selector is invisible to every schema validator, because the JSON is valid; it is only detectable by resolving the pointer against the page. That makes it a real finding rather than a stylistic one, and it is the only structured data on your site that can rot without anybody editing it.
The second is that its presence is often a symptom. Speakable markup on a site that publishes no news is a strong sign the structured data was assembled from a list rather than from the content, which usually means other blocks on the same page were built the same way. Nobody adds this property by accident. Finding it tells you something about how the rest of the markup got there.
Questions this check raises
- Can any site use speakable markup?
- Anyone can publish it, and Google restricts the news-reading feature it powers to approved publishers in supported regions. For everyone else it is not a rich result, it is a statement about your document that other consumers can read. That is a smaller benefit but not zero.
- Should I use cssSelector or xpath?
- cssSelector. An xpath expression is bound to the exact document structure, so any markup change silently repoints it at the wrong element or at nothing. A class or attribute selector survives a redesign, and it can be applied deliberately to the element you mean.
- What should be marked speakable?
- The passage that answers the page, usually the headline plus a short summary. Not the whole article, which is unlistenable read aloud, and not the introduction if the introduction is throat-clearing. Marking too much is the same as marking nothing.