Voice search queries behave differently from typed ones. They are longer, more conversational, and they expect an answer that sounds natural when read aloud. Speakable schema markup is Google’s mechanism for you to point directly at the portions of your content best suited for spoken delivery — rather than letting an algorithm guess which paragraph to extract.

What Speakable Schema Does

The Speakable property, attached to a WebPage or Article entity, tells Google Assistant which sections of a page are most appropriate to read aloud in response to a voice query. Without it, a voice assistant extracts content based on its own inference — and inference often lands on the wrong section, pulling a table of contents header or a boilerplate disclaimer instead of the actual answer.

Currently, Google has Speakable in limited release, primarily active for news content and AMP pages. However, the markup is valid schema.org vocabulary and worth implementing on informational pages now, because the surfaces that use it — AI Overviews, Google Assistant, and future voice interfaces — are expanding rather than contracting.

The Two Ways to Define Speakable Sections

CSS Selector Approach

If your content uses consistent class names or IDs, target sections by CSS selector. This is the approach I use for most WordPress-based builds because it scales without touching the JSON-LD on every individual page — add the class to the right element in your template and the schema works across the whole content type:

  • Add a class like speakable-intro to the opening paragraph in your article template
  • Add speakable-summary to a closing summary section
  • Reference those selectors in a single SpeakableSpecification entity on the WebPage node

One JSON-LD template update covers every page that uses those classes.

XPath Approach

For sites without reliable class naming, XPath expressions can target elements by position or structural path. XPath is more brittle — any layout change can break the path — but it works when CSS classes are unavailable or inconsistently applied. Target the title and the first paragraph of the article body as a minimum viable Speakable implementation when other options are not available.

What Content to Mark as Speakable

The goal is to flag content that delivers a direct, complete answer in two to four sentences — something that sounds natural and useful when a voice assistant reads it without the surrounding visual context. Good candidates:

  • The opening summary paragraph of an article or service page
  • The answer paragraph immediately following a question-formatted H2 heading
  • A conclusion or TL;DR section that stands alone
  • A clearly phrased definition or explanation of the page’s core topic

Bad candidates for Speakable markup: navigation elements, sidebars, author bios, legal notices, tables, and lists that lose meaning when read without visual context. If a section would be confusing or incomplete when heard alone — without seeing the surrounding layout — do not mark it speakable.

Speakable and AEO (Answer Engine Optimization)

There is a direct line between Speakable markup and broader AEO strategy. Google’s AI Overviews and voice-delivered answers both favor content that is concise, authoritative, and self-contained. Marking your best answer sections with Speakable is a concrete, explicit signal that you have identified and surfaced that content deliberately — rather than relying on Google to find it by inference.

There is also a useful editorial side effect: if you cannot identify two or three sections on a page worth marking as speakable, the page may not have clear, answer-forward writing. The process of implementing Speakable markup forces a useful pass over the content structure. It is one of the few schema types where the implementation discipline improves the content itself.

Relationship to Other Markup

Speakable lives on the same entity as your page-level markup — a WebPage or Article node in a @graph block. You do not need a separate script block. Add the speakable property to the existing node alongside headline, datePublished, and author. If you are not yet using the connected graph pattern, see nested schema and @graph for the right structure to add this to.

For publishers running news-type content, Speakable pairs naturally with NewsArticle schema, which is the primary content type where Google currently acts on Speakable signals in production.

Validation

The Rich Results Test does not have a dedicated Speakable result type, but it will flag structural errors in the markup. Use the Schema.org validator at validator.schema.org to confirm the SpeakableSpecification node is well-formed. Then manually test the CSS selectors or XPaths against the live page — open browser developer tools and confirm they resolve to the intended content elements before considering the implementation done.

Content Quality as the Real Gatekeeper

Speakable is a hint, not a guarantee. Google can choose to ignore it, and will on pages that do not meet its content quality bar for voice delivery. The minimum bar: the flagged sections must contain accurate, expert-level information in plain language without technical jargon that would confuse a voice listener. Schema is the vehicle; quality is the ticket.

Realistic Current Impact vs. Future Value

Right now, Speakable has limited visible SERP impact outside of news content. The case for implementing it is forward-looking: as voice interfaces, smart speakers, and AI assistants grow as search surfaces, the sites that have already signaled their best answer content will have an advantage over those that have not. The implementation cost is a property addition to an existing entity — low overhead, meaningful future exposure.

Rewriting Content to Qualify for Voice

Before adding Speakable markup, audit the content you plan to flag. Voice delivery has specific requirements that standard editorial writing does not always meet. The target sections should: start with the key information, not context-setting; avoid first-person pronouns that reference page layout (‘as you can see in the table above’); avoid jargon that voice listeners will not recognize; and answer the most likely spoken query directly in the first sentence. If the current content does not meet these criteria, the right first step is a content edit, not adding the schema. Speakable markup on content that does not read well aloud produces a poor user experience even when technically valid.

Testing Voice Delivery

After implementing Speakable markup, test the flagged sections by reading them aloud yourself. Does the section make sense without the surrounding visual context? Does it sound natural at the pace a voice assistant would deliver it? Does it answer the question a voice query would have asked? This subjective test catches more problems than technical validation does. Technical validation confirms the markup is correctly structured; reading aloud confirms it will actually serve a voice listener well.

Voice optimization fits naturally into the broader structured data conversation I have with clients. If you want to think through which pages on your site are the strongest Speakable candidates, that is a good starting point for a schema strategy discussion with my schema markup consulting work.