How to Create Speakable Schema

Speakable is the narrowest type in this series and the one worth being honest about upfront. Google documents it as a news publisher feature, so if you are a SaaS company or an ecommerce brand, implementing it will produce no result and the correct decision is to skip it.

For publishers, it does something no other markup does: it decides which words come out of a speaker. Every other structured data type influences how a page is understood. This one dictates what gets read aloud, verbatim, to somebody who is not looking at a screen.

That is a genuinely different editorial problem, and the reason most implementations disappoint is that teams mark up an existing paragraph rather than writing one for speech.

What Speakable Does

Google's speakable documentation describes the property as identifying the sections of a page best suited to audio playback using text-to-speech.

The mechanism is a pointer rather than a container. You do not put the text inside the markup. You point at where the text already lives on the page, using either a CSS selector or an XPath expression, and SpeakableSpecification is the type carrying that pointer.

That design has one important consequence. Because the markup references rendered content rather than duplicating it, the passage read aloud is always exactly what a reader sees. There is no way to write a separate spoken version, and no way for the two to drift apart. It also means a template change that renames a class silently breaks the pointer.

What you are buying is control over selection. An assistant asked to read a news story will find something to read either way. Without the markup it picks, usually the opening paragraph or a snippet Google assembles. With the markup you pick.

Who Is Actually Eligible

Google documents speakable as a news feature, and eligibility has been tied to news publication throughout its life.

Check three things before building.

Your content needs to be genuine news. Timely reporting on events, marked up as NewsArticle, published on a cadence. An evergreen guide is not news regardless of quality, and a company blog is not news regardless of frequency.

Your site needs to be recognised as a news publisher by Google, which is a separate matter from being marked up as one. Sites appearing in Google News and Top Stories have the standing. Sites that do not, do not.

Your locale and the assistant surface need to support it, which has varied over time and by market.

If any of those fail, the honest recommendation is to skip speakable and spend the effort on the markup that will actually run. Our guide to schema markup for AI search covers which types earn returns for non-news sites.

There is one legitimate reason for a non-news site to implement it anyway. The markup is valid schema.org regardless of Google's eligibility rules, and other consumers can read it. If you operate your own voice product, an internal assistant, or an app that reads your content aloud, the markup is a useful contract even with no search benefit. That is an engineering decision rather than an SEO one.

cssSelector Versus xpath

Two targeting forms exist and you should use one, not both, on a given passage.

cssSelector takes a CSS selector. It is the readable, maintainable option and it is what we recommend by default.

"cssSelector": [".article-standfirst", ".key-finding"]

xpath takes an XPath expression. It is more precise and can target things CSS cannot, such as a specific position among siblings.

"xpath": ["/html/body/div/article/p[2]"]

Three reasons to prefer cssSelector.

It survives template changes better, because a class name is a stable contract while a positional path breaks the moment somebody inserts a div.

It is legible to the next person. A selector naming a class communicates intent, whereas an absolute XPath communicates a location and nothing about why.

It matches how your templates are already built. Front-end teams think in classes, so a class-based pointer is one that stays correct through refactors because the class is meaningful to the people doing the refactoring.

Reach for xpath only when the content you need has no distinguishing class and you cannot add one. And if you find yourself writing an absolute path from html, add a class instead. That is a five-minute template change that prevents a recurring breakage.

A Complete Working Example

Speakable attaches to the article rather than standing alone.

{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "@id": "https://example.com/news/harbour-flood-defence-vote#article",
  "headline": "Council approves harbour flood defence after four-year delay",
  "datePublished": "2026-08-24T07:15:00-04:00",
  "dateModified": "2026-08-24T09:40:00-04:00",
  "author": {
    "@type": "Person",
    "name": "Priya Raman",
    "url": "https://example.com/authors/priya-raman"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Example Chronicle",
    "logo": {
      "@type": "ImageObject",
      "url": "https://example.com/logo.png"
    }
  },
  "image": ["https://example.com/img/harbour-defence-16x9.jpg"],
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".article-headline", ".article-summary"]
  }
}

The pattern to copy there is marking two regions: the headline and a purpose-built summary element. The headline gives the assistant the subject, and the summary gives it the substance. Together they run about twenty seconds spoken.

What that example deliberately avoids is pointing at .article-body. The body is long, contains pull quotes and captions, and includes sentences that reference images. An assistant reading it aloud produces a mess.

Writing Passages That Work as Speech

This is where the value actually is, and it is a writing problem rather than a markup problem.

Text that reads well on screen frequently fails when spoken, because the reader loses every visual cue. Six patterns break audibly.

• Parenthetical asides. A listener cannot hear a bracket. The aside merges into the sentence and the meaning shifts.
• Formatting that carries meaning. Bold, italics, and quotation marks are silent, so emphasis and attribution vanish.
• References to what is visible. As shown above, see the chart, and the table below are all meaningless to somebody listening.
• Long subordinate clauses. A sentence a reader can re-scan is a sentence a listener has already lost.
• Numbers and units that need reading conventions. 1.2m could be spoken several ways, and abbreviations like approx read badly.
• Acronyms on first use. Fine on screen with a gloss, unclear when spoken.

The fix is to write a dedicated summary element into the template rather than reusing an existing paragraph. A short standfirst, written to be heard, that states what happened and why it matters in two or three sentences.

Two constructive habits. Front-load the subject, because a listener who tunes out after five seconds should still have the point. And read the passage aloud before shipping it, which sounds obvious and is the step teams skip.

Our post on AI voice agents covers the broader shift toward spoken answers across assistants beyond Google.

How Much to Mark

Aim for roughly 20 to 30 seconds of speech, which is 2 or 3 sentences or about 40 to 70 words.

The reasoning is behavioural rather than technical. A spoken answer is consumed linearly with no skimming, and attention on a voice surface is short. A passage over about thirty seconds gets abandoned before the useful part.

Three practical rules.

Mark the headline plus one summary region. That combination gives context and substance without overrunning.

Do not mark the full article body. It contains material that fails as speech and it is far too long.

Do not mark several scattered regions hoping the assistant picks the best one. It concatenates what you point at, and three disconnected paragraphs read in sequence sound broken.

If the story genuinely needs more than thirty seconds to convey, that is a signal to write a tighter summary rather than to mark more text.

Validation and Common Errors

Validate with the Rich Results Test and the Schema.org validator, then do the test the validators cannot: read the marked text aloud.

Six errors account for most problems.

• Selectors that match nothing. A renamed class silently breaks the pointer and no validator flags it, because the markup is valid and the page simply has no matching element.
• Selectors that match too much. A generic selector like p catches the whole article including captions.
• Both cssSelector and xpath on the same passage. Pick one. Using both is ambiguous.
• Marking content that fails as speech. Parentheses, formatting-dependent emphasis, and references to visible elements.
• Speakable on non-news content. Valid markup with no eligibility, which is wasted effort unless you have your own voice consumer.
• Passages far over thirty seconds. Technically fine, practically abandoned.

Add one monitoring check that catches the first failure mode: crawl your templates and assert that every selector named in speakable markup matches at least one element on the page. It is cheap and it catches the breakage that otherwise persists for months.

Our guide to article schema covers the NewsArticle wrapper this attaches to.

Frequently Asked Questions

Can non-news sites use speakable schema?

The markup is valid schema.org for any content, but Google documents the feature as a news publisher one, so a non-news site should expect no search benefit. It remains useful if you operate your own voice product that reads the markup.

Should I use cssSelector or xpath?

Prefer cssSelector. It is readable, it communicates intent, and it survives template refactors because class names are stable contracts. Use xpath only when the target has no distinguishing class and you cannot add one.

How long should a speakable passage be?

Around twenty to thirty seconds spoken, which is two or three sentences or roughly forty to seventy words. Longer passages are abandoned on voice surfaces, where there is no skimming and attention is short.

What happens if I do not add speakable markup?

An assistant asked to read your article picks its own excerpt, usually the opening paragraph or an assembled snippet. You still get read aloud, you just do not choose which words. The markup buys editorial control rather than eligibility.

Can I write a separate version of the text just for speech?

No. Speakable points at content that exists on the page, so the spoken passage is always what a reader sees. The workable approach is a purpose-built summary element in the template, written to be heard and visible to readers too.