Speakable Schema and Structured Data for Voice and AI Assistants

Someone on your team asked whether speakable schema will get your brand into ChatGPT answers, and you did not have a confident answer. That is a fair place to be. This guide walks you through what the markup does, who it actually works for, and how to add it correctly if you qualify, so you can make the call in an afternoon instead of debating it for a quarter.

Here is the honest headline before we start: speakable is real, easy to add, and much narrower than its name suggests. You will know by the end whether it belongs on your roadmap or your "not now" list. Both answers are wins.

Step 1: Understand what speakable schema actually does

Speakable is a Schema.org property, not a standalone type. Google and Schema.org introduced it together on July 24, 2018.

Its job is small and specific. It marks the sections of a page that are best suited for text-to-speech playback, so a voice assistant knows which passages to read aloud. Schema.org describes it as highlighting content "especially appropriate for text-to-speech conversion." Google frames it more narrowly still: identifying sections within an article or webpage best suited for audio playback.

Three structural facts worth holding onto:

• The property attaches to two types only: Article and WebPage.
• Its expected value is a SpeakableSpecification object, or a URL reference pointing to one.
• It has never produced a visible rich result in Google Search.

That last point trips up most teams. Speakable is not like Recipe or FAQ markup, which earn visual placements on the results page. The entire product surface is audio playback through voice assistants. No SERP feature, no ranking signal, no snippet.

It helps to name the category correctly from the start. Speakable is voice search schema in the literal sense: it exists to serve spoken answers on speakers, not to change what happens on a screen. Most articles filed under voice search schema quietly assume the two are the same thing. They are not, and that assumption is where budgets go to die.

How to tell this step is done: you can explain speakable to a colleague in one sentence without using the word "ranking."

Where people go wrong: assuming a schema property with "speak" in the name influences how AI assistants talk about you. It does not, and we will get to the evidence in Step 7.

Step 2: Check the eligibility rules before you write any code

This is the step that saves you the most time, so do it first.

Google's documentation for speakable structured data carries a beta label, and it has carried that label continuously since 2018. As of mid-2026, no graduation from beta and no expanded product surface have been announced publicly.

The documented restrictions are tight:

When it does fire, a user asks something like "What's the latest news about $topic?" and the Assistant returns up to three articles from different publishers, with attribution, pushing the URL to the user's mobile app.

There is a quieter fact to weigh alongside the table. Through 2024 to 2026, there are no public reports of Google Assistant reading speakable-marked content to users in any widely deployed way. The markup sits as a dormant signal with very little product surface behind it. Schema.org has not deprecated or retired the property, and Google has not pulled the documentation, so this is not a dead feature. It is a parked one.

Read that table again and be honest about your site. Implement speakable structured data only if all of these are true:

1. You publish English-language news content.
2. Your audience is primarily based in the United States.
3. You have development resources to add and maintain the markup.
4. You have already implemented Article or NewsArticle and Organization markup.

If any one of those fails, skip it. Genuinely. It is optional, additive, and required for nothing. Closing this tab and going to fix your Article markup instead is a perfectly good outcome for this guide.

Still qualified? Good. The rest is straightforward.

Step 3: Write the passage you want read aloud

Notice that this step comes before any code. The markup only points at words. The words have to earn the listening.

Write a summary of two to three sentences into the article body, aimed at roughly 20 to 30 seconds of audio, which lands around 50 to 75 words. Write it for the ear:

• One idea per sentence.
• Active voice, clear and declarative.
• Keep sentences under 25 words.
• Spell out acronyms on first mention, like "the Federal Trade Commission, or FTC."
• Skip parenthetical asides and sentence fragments.
• Use present tense where it reads naturally, since tense shifts disrupt prosody.

Break the lede into one-sentence paragraphs. Passages written this way tend to be self-contained, meaning they make sense without the surrounding context. That is also what makes a passage quotable in every other channel, which is a nice bonus for work you were doing anyway.

Now the other half of this step, which matters just as much: what not to mark.

• Datelines. "WASHINGTON" read aloud adds nothing.
• Photo captions. Visual content has no audio utility.
• Source attributions. "Reporting by Jane Smith" is not useful to a listener.
• Entire articles. The system truncates, and you lose the signal about which passages matter.
• Complex data structures. Nested lists, tables, and multi-column layouts confuse text-to-speech engines.

Pro tip: read your summary out loud before you mark it. If you stumble, the Assistant will too. This ten-second test catches more problems than any validator.

How to tell this step is done: you can read the passage aloud in one breath per sentence and it makes sense to someone who has not read the article.

Step 4: Mark the passage in your HTML

You need a stable, semantic hook the markup can point at. Wrap the summary in an element with a class you control:

<section class="voice-summary" aria-label="Article summary">
  <p>The Federal Reserve raised its benchmark interest rate by a quarter percentage point on Wednesday.</p>
  <p>Chair Jerome Powell said the decision reflects ongoing concerns about inflation.</p>
  <p>The move marks the third rate increase of 2025.</p>
</section>

Two things make this work. The class name is semantic, so it survives a redesign. And the selector targets a visible element, so the audio system reads the same content a sighted reader sees.

Where people go wrong: picking a class name generated by a page builder. If your wrapper is .css-1x9k3j, your markup breaks the next time the CMS regenerates it. Give the element a name a human chose.

Step 5: Add the JSON-LD block

Now the part everyone came for. JSON-LD inline in the page is Google's preferred format, delivered in a script tag in the head or the body.

Here is the block that matches the HTML above:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "Fed Raises Rates by Quarter Point",
  "datePublished": "2025-09-17T14:00:00Z",
  "author": {"@type": "Person", "name": "Reporter Name"},
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".voice-summary"]
  }
}
</script>

Note where speakable sits. It is a sibling of headline and author on the article, not something nested inside SpeakableSpecification. The specification is the value, not a wrapper. That inversion is the single most common syntax error.

Choosing your locator

You have three ways to point at content, and they are not equal:

1. ID reference. An absolute or relative URL pointing to an element's id. Simplest and most robust.
2. CSS selector. Standard selector syntax through the cssSelector property. Familiar to everyone on your team, and durable when it targets semantic classes like .summary or .lede.
3. XPath. An expression assuming an XML view of the document, through the xpath property. The most brittle option across template changes, and rarely the best choice.

Google's own reference example uses XPath to target the title tag and the meta description:

"speakable": {
  "@type": "SpeakableSpecification",
  "xPath": [
    "/html/head/title",
    "/html/head/meta[@name='description']/@content"
  ]
}

It validates, and it is a reasonable starting point. For production, CSS selectors on semantic classes hold up better.

You can also supply both kinds when your CMS handles one identifier more reliably than the other:

"speakable": {
  "@type": "SpeakableSpecification",
  "xPath": ["/html/body/article/p[1]"],
  "cssSelector": [".lede"]
}

Only one selector kind is required. Both is defensive, not mandatory.

Marking more than one passage

Want a top summary and a key fact called out separately? Wrap the property in an array:

"speakable": [
  { "@type": "SpeakableSpecification", "cssSelector": [".summary"] },
  { "@type": "SpeakableSpecification", "cssSelector": [".key-fact-1"] }
]

The property repeats an arbitrary number of times. If several Article entities appear on one page, each needs its own speakable value.

Where people go wrong: deep XPath expressions like /html/body/div[3]/section[2]/article/p[1]. That path is a promise that your DOM will never change. It will.

Step 6: Validate what you shipped

Three checks, ten minutes, and you are done.

Schema Markup Validator. Paste your URL or raw JSON-LD into the Schema.org validator. It confirms the speakable property is correctly typed as SpeakableSpecification and that your cssSelector or xpath values are valid. Its limit: it does not verify that your selectors resolve to real elements in the rendered page.

Google Rich Results Test. Run the page through it, and expect "no rich results detected" even when your markup is perfect. That is not a failure. Speakable produces no visible SERP feature, so it will never report as a rich result type. The test still earns its ten seconds by catching syntax errors in your other structured data.

Your browser console. This is the one that finds real bugs. Open the live page, run document.querySelectorAll('.voice-summary'), and confirm it returns the visible, populated element you expect. A selector that matches nothing is the most common failure in the wild, and neither validator above will tell you.

If speakable structured data is going onto more than a handful of templates, make the check automatic. Tooling like schema-dts validates the type graph programmatically, and a custom lint rule can flag any article missing the property once it becomes part of your editorial standard. A rule that runs on every build beats a checklist nobody opens.

Then set expectations for monitoring. Speakable does not appear in Google Search Console as its own report. Observability is genuinely limited: you can monitor Assistant news responses for your content and revisit Google's documentation quarterly, and that is about it.

Where people go wrong: treating a green validator as proof the feature works. Validating correctly and producing results are two different things. The first is achievable. The second is limited to that narrow Assistant surface.

Step 7: Set honest expectations for AI assistants

Here is the question underneath every search for voice search schema, so let's answer it plainly.

Does speakable markup make ChatGPT, Perplexity, Gemini, or Claude more likely to cite you? No.

None of the major AI search or assistant systems document speakable as a signal for retrieval or citation. Not one. There is no published evidence connecting the property to AI answer visibility.

The broader question got tested directly. In March 2026, Ahrefs tracked 1,885 pages that added JSON-LD schema markup between August 2025 and March 2026, matched against 4,000 control URLs with similar citation levels beforehand. The schema types included Article, FAQ, Product, HowTo, and Organization. After 30 days, AI Overviews citations moved slightly down, while AI Mode and ChatGPT moved slightly up by amounts statistically indistinguishable from zero.

The researchers' read: schema markup does not boost AI citations for pages already being cited. Schema and citations correlate because high-authority, technically polished sites tend to have both, not because one causes the other.

If that stings a little, take a breath. This is good news disguised as bad news. It means the effort you were about to spend on structured data for AI assistants can go toward things that actually move citations:

• Clear question-and-answer structure near the top of the page.
• Explicit definitions of the terms you want to own.
• Quotable statistics with named sources.
• Crawlable HTML, not content that only appears after JavaScript renders.
• Topical authority built through consistent coverage.

Speakable is not harmful to add. It just should not be rationalized as an AEO investment. Say that out loud in your next planning meeting and you will save your team a sprint.

Worth separating two ideas that get blurred here. Structured data for AI assistants is not one lever with one switch. Marking up your entity, your products, and your articles helps machines understand what you are and what you publish, and that understanding work is worth doing on its own terms. What the evidence does not support is the further step, the belief that adding markup causes engines to cite you more. Understanding and citation are different problems, and only one of them has a schema-shaped answer.

You also do not have to guess at any of this. The way to know whether a change moved your visibility is to measure mention and citation rates per prompt, before and after. DeepSmith tracks how AI engines answer the questions that matter in your space across ChatGPT, Gemini, Perplexity, Claude, and Google AI Mode, then reports which of your pages actually get cited. That turns "does schema help?" from a debate into a chart.

Step 8: Put your schema effort where it pays

Speakable is additive, not substitutive. It replaces nothing. So if your schema time is limited, and it always is, spend it here first:

• Article and NewsArticle. Active and recommended for publishers, driving Google News and Top Stories placement, entirely independent of speakable.
• Organization, Product, and BreadcrumbList. Entity and navigation signals feeding knowledge panels, sitelinks, and product cards.
• HowTo. Still supported, with step lists in results, though eligibility has narrowed for some categories.
• FAQPage. Worth knowing the history: Google retired FAQ rich results in organic search in August 2023, though the markup remains valid for third-party use.

Notice the pattern. These types have proven product surfaces. Speakable, for now, does not. Adding schema for voice assistants at the expense of the types above is a misallocation, and it is the quietest mistake on this list because nothing visibly breaks.

It is worth being precise about how speakable and FAQPage differ, since they get lumped together as voice-adjacent markup. FAQPage was a visual enhancement, surfacing question and answer pairs as an expandable dropdown in results until Google retired that treatment. Speakable is audio, with no visual component at all. Choosing schema for voice assistants over FAQ markup is not a trade between two similar options. They were never doing the same job.

The durable version of this work is not a one-time schema sprint. It is having heading structure, schema markup, internal linking, and metadata handled as part of how content gets made, so no one is retrofitting markup onto published pages six months later. DeepSmith builds those into the writing pipeline rather than bolting them on afterward, which is what keeps the standard from drifting as volume goes up.

What to do next

Pick one of two paths this week.

If you are an English-language news publisher serving a US audience, and your Article and Organization markup is already solid, add speakable to one template. Mark one summary. Validate it. Total cost: an afternoon.

Everyone else: close the loop and move on. Write the answer-first summary anyway, because that helps you everywhere, and put the sprint into extractability and evidence instead.

Either way, you now have a defensible answer for the person who asked. That was the real deliverable.

Want to see which of your pages AI engines cite today, before you change anything? Start a free DeepSmith trial and get real data on where you show up.