Speakable Schema for Voice AI and Smart Speaker Answers

Speakable schema is a piece of code that tells a voice assistant which sentences on a page to read out loud. That's the whole concept, and it matters more than its plumbing-level name suggests: the assistant that picks your content becomes the only voice a user hears in that moment. Every other result, however well it ranked on a screen, simply doesn't exist to that user. Most sites still treat this as a checkbox for smart-speaker news apps. That's backwards. Speakable is the clearest working example of what every AI retrieval system, from AI Overviews to agentic browsing tools, is now selecting for.

Screen-based search gives people a list. They scan, compare, click, back out, try again. Voice search gives them one answer, spoken once, with no second option displayed alongside it. Edison Research's Infinite Dial 2025 study put smart speaker ownership among Americans aged 12 and up at 35%, roughly 101 million people. Ofcom's Audio Listening in the UK 2025 report, published in May 2025, found that 54% of UK adults had used a voice AI in the prior three months. In the U.S., 45% of adults report using a voice assistant at least once a day, and voice assistants now come built into 75% of new cars sold in the U.S. The living room was never the whole story. The car, the kitchen, the phone in a pocket, all of it counts now.

Without a signal telling an assistant which passage to read, the system guesses, and it guesses badly. It'll grab a caption under a photo, a line from the site's navigation bar, a dateline, a scrap of legal boilerplate sitting in the footer, whatever text happens to sit where its extraction logic looks first. Speakable schema exists to stop that guessing. It's a publisher-controlled instruction that says: read this, not the noise around it. Treat it as a citation and attention problem, not a curiosity for people who read Schema.org documentation for fun.

What speakable schema actually is and where it sits in the structured data landscape

Speakable is a property from Schema.org, specifically the SpeakableSpecification type, used as a value inside the speakable property on Article, WebPage, or NewsArticle markup. Its job is narrow: mark which sections of a page are fit for text-to-speech delivery, so a voice assistant can pull exactly those words and read them without stumbling into surrounding clutter.

It helps to place it against schema types readers may already know. FAQ schema answers one discrete question in a structured pair, question and answer. Speakable doesn't care about question-and-answer format at all; it marks a passage for audio delivery no matter how that passage is structured. Article schema exists to tell a crawler what kind of page it's looking at, background information for indexing. Speakable talks to a different consumer entirely: not a crawler building an index, but a voice system deciding, in real time, what to actually say to a person.

As of Google Search Central documentation last updated on December 10, 2025, speakable remains officially in beta. Google has been the main platform pushing it forward, through Google Assistant, Google Home, and Nest devices. Alexa, Siri, and other voice platforms haven't adopted it with anywhere near the same depth as of 2025. There's a geographic and language ceiling worth knowing about too: it works for users in one specific country, on Google Home devices set to English, on content published in English.

Here's how it plays out in practice. A user asks Google Assistant for news on a topic. The assistant pulls up to three articles and, for any that carry speakable markup, uses text-to-speech to read the marked section aloud, crediting the source and pushing the full article link to the user's phone through the Assistant app.

None of that "beta, news-only" framing is a reason to shrug it off. The discipline speakable enforces, tight, self-contained, unambiguous passages, is exactly what large language models, AI Overviews, and agentic tools reading a page are selecting for too. Speakable is a narrow tool solving a narrow problem today. The underlying skill it demands will matter well past its current beta label.

The three ways speakable schema points to content on a page

Schema.org allows the speakable property to repeat as many times as needed on a page, and each instance points at content using one of three methods. Pick CSS selectors unless a specific structural problem forces you into XPath. That's not a stylistic preference, it's the difference between markup that survives a template redesign and markup that quietly breaks the next time a developer touches the page.

CSS selectors, using the cssSelector property, are the right default for most sites. A block might read "cssSelector": [".headline", ".summary"]. It's readable, it's easy for a content team to maintain months later, and it tends to survive small template changes without breaking. For Webflow builds, this is the recommended approach outright, since class-based selectors sit more naturally in that environment than XPath does; once the JSON-LD pattern is worked out for a template, applying it takes about 20 minutes. Standard WordPress builds follow the same logic: create a class like .summary or .speakable-content, wrap the relevant section of a post in a div carrying that class, and reference it in the JSON-LD block.

XPaths, using the xPath property, look like "xPath": ["/html/head/title", "/html/head/meta[@name='description']/@content"]. These earn their keep on pages with complicated DOM structures where no CSS selector can cleanly grab the target section on its own. Otherwise, avoid them. XPath expressions are brittle: a small structural change to the page can silently break them, and nobody finds out until the markup stops working and nobody knows why.

Google's own documentation instructs implementers to use either cssSelector or xPath per markup block, and those two methods cover the practical range of implementation scenarios. Whichever method gets used, keep the selector simple. Whichever method gets used, keep the selector simple. #story-headline or .story-summary will hold up far better over time than a path five levels deep into the DOM.

How to implement speakable schema correctly, including what not to mark up

JSON-LD is the recommended format, and Google confirmed it as the preferred schema markup format again heading into 2026. It sits apart from the HTML itself, so a content or SEO team can update it without a developer touching the page's design or layout. Speakable currently applies to Article, WebPage, and NewsArticle through inheritance.

Length matters more than most implementers expect going in. Google recommends each speakable section run about 20 to 30 seconds when read aloud, which lands at roughly two to three sentences. One industry glossary puts that at somewhere near 50 to 75 words per section. Either way, the target is short, and going long defeats the entire purpose.

What belongs inside a speakable tag: an opening summary that states the article's main point plainly, a direct answer to a question a reader is likely asking, a factual update in a breaking-news story, or a short explanatory passage that makes complete sense with no chart, image, or list sitting next to it for context.

What doesn't belong, and Google is explicit about this: the full article body, navigation menus, footers, cookie banners, paywall teaser text, legal disclaimers, datelines, photo captions, or source attribution lines. Skip any passage that leans on bullet formatting to make sense, uses a vague pronoun without a clear antecedent, drops in an abbreviation without spelling it out first, or points to a chart or image the listener obviously can't see. Write speakable content the way a radio newsreader delivers a script, not the way product copy gets written: complete sentences, clear attribution, natural phrasing, enough context inside the passage itself that it stands alone without the rest of the page propping it up.

Before publishing, check that robots settings and paywall rules actually let the marked section render for crawlers. Markup pointing at content a crawler can't reach does nothing. Run the result through Google's Rich Results Test and, separately, the Schema Markup Validator, since the Rich Results Test alone doesn't always catch every speakable-specific problem. For anyone chasing eligibility on Google News surfaces specifically, the baseline requirements apply on top of the markup itself: a reputable news source, a properly configured Google News Producer account, transparent authorship, no explicit or hateful content, ad load that doesn't overwhelm the content, and no sponsored content dressed up as editorial.

Where speakable fits in the wider shift from keyword search to AI-driven answers

Voice interfaces and AI answer engines are converging on the exact same requirement: a short passage that can be lifted whole, with no surrounding visual context needed to make sense of it. That convergence is why speakable is worth understanding now, rather than filing away as a footnote for smart-speaker news apps.

The scale backs that urgency up. One in ten internet users in that country now goes to a generative AI tool first when searching online. Traffic to AI assistants rose 86% in 2025, with time spent on them up 101%. AI-generated summary panels now show up in 16% of all searches on one major search engine there. Ahrefs found that when an AI-generated summary panel appears above a result, click-through rates for the top-ranking page drop by 58%. Showing up inside the answer itself is starting to matter more than the click that used to follow it.

The terminology around this is still unsettled: GEO (Generative Engine Optimization), AEO (Answer Engine Optimization), LLMO, AIO. These get used almost interchangeably in trade conversation, and there's no fixed academic consensus on where one ends and another begins as of early 2026. Speakable sits at the overlap of all of them. On the SEO side, tighter intros and clearer heading structure improve how well a page gets crawled and understood in the first place. On the AEO side, a well-marked, concise passage is directly liftable into a spoken answer or a featured snippet. On the GEO side, clean and authoritative language is exactly what an AI system wants to quote when generating a summary, and speakable markup is one of the more underused signals available for that purpose.

Pages that actually show up in AI-generated answers tend not to be the longest ones on the topic. They're the ones with the clearest structure, the earliest stated answer, and the least noise between the headline and the point. Speakable schema doesn't just encourage that kind of writing, it enforces it structurally: either the passage stands alone in 20 to 30 seconds, or it doesn't, and no amount of stylistic flourish fudges that requirement.

Agentic AI adds a further layer worth watching. Tools such as OpenAI's Operator can execute transactions autonomously on a user's behalf. At that point, machine-readable structured data, speakable included, stops being an SEO nicety and becomes a prerequisite for the agent to correctly identify what a brand is offering and act on it.

Which content types benefit most from speakable implementation and which translate poorly

News articles with a clear factual summary remain the original and still primary use case, straight from Google's own documentation. FAQ pages with direct, self-contained answers work for the same reason. Recipe content translates cleanly too, since ingredient lists and step summaries are exactly the sort of thing someone wants read aloud while their hands are covered in flour. Plain-language market summaries suit voice briefing formats in financial news. Health content that explains a symptom or a treatment without leaning on a diagram does well. Local business content deserves particular attention: voice search users search for local businesses on a near-daily basis in large numbers, and a large majority of voice searches carry "near me" or similarly local intent, which makes location-specific factual summaries some of the highest-value speakable candidates around.

Long-form narrative and opinion writing translate poorly. There's rarely a clean extraction point, and the meaning depends on everything that came before it in the piece. Skip speakable markup on this content entirely rather than forcing it. Heavily technical writing that leans on specialized terms requiring a diagram or table to follow doesn't work either, and neither does content structured around a chart or a side-by-side comparison. Any passage built on bullet points, vague pronouns, or unexplained abbreviations should stay out of speakable markup regardless of how well it reads on screen.

A simple editorial test settles most borderline cases. Read the candidate passage aloud, on its own, with nothing else around it. If a listener hearing it cold grasps the main point within the 20 to 30 seconds Google recommends per speakable section, it's a speakable candidate. If they'd need to see the page to follow along, it isn't, no matter how well the surrounding article performs. The average voice search result runs about 29 words. That's the target length worth writing toward, and it's a tighter constraint than most editorial teams are used to working inside.

How agencies managing multiple client sites should approach speakable at scale

For an agency running speakable across a client roster, the work is a template problem, not a series of one-off builds. Once the JSON-LD pattern and the CSS class convention are settled for a given CMS, whether that's WordPress, Webflow, or something else, the same pattern carries across every client running that CMS. Standardizing selector names across the whole portfolio, something like .speakable-summary or .speakable-headline, turns auditing and future updates into a repeatable process instead of a fresh investigation on every account.

Audit first. Not every client publishes content that benefits from speakable markup, so the sensible move is identifying which accounts actually produce news, FAQ, local, health, or finance content before rolling markup out across the board. Applying speakable tags to content categories that translate poorly to audio wastes implementation time and produces nothing measurable. An agency that skips this step and marks up everything indiscriminately is doing busywork, not strategy.

Monitoring is the harder half of this. Speakable performance, and AI visibility more broadly, doesn't show up in a traditional rank tracker. An agency needs a way to see where a client's brand actually gets surfaced inside AI-generated answers, voice responses, and AI Overviews, not just where a URL sits in a list of ten blue links.

That visibility gap is also the sales problem. AI visibility gets described, often accurately, as a black box: a client can't glance at a dashboard and see a position the way they can with organic rank. Agencies able to report on how often a client gets cited, in what prompt contexts, and how that presence shifts over time turn a channel clients can't see into a deliverable they can. Consumers check an average of 2.4 platforms before making a purchase decision, and AI surfaces now sit inside that shortlist, which means an agency needs to show a client where they land across it, not just where they rank on Google.

There's a sales enablement piece underneath all of this too. Account teams who can explain speakable schema and GEO in plain terms, rather than just handing a client a login to some platform, come across as advisors rather than vendors passing through a tool. That distinction is often what keeps an account on the books in a service category most clients still don't fully understand yet.

Portfolio management platforms built for this exact layer of the work, Thrad among them, tackle the operational side directly: a multi-brand workspace, analytics that roll up across every client account, access controls fine enough to separate what one client sees from another, custom weekly reporting, per-client data exports, and a training process built to get sales reps and account managers speaking credibly about AI visibility instead of reciting a feature list. Done well, that turns an agency into something closer to an authority on the subject, not just another shop that knows how to paste in a JSON-LD block.

What good looks like in practice, and how to know if your speakable implementation is working

Confirmation starts with Google's Rich Results Test, which checks that the markup parses correctly and that the structure is sound. That's a necessary check, but it only confirms the code is valid, not that a voice assistant will actually choose to read it. Passing the validator is the floor, not the finish line.

A well-implemented speakable section reads as a complete thought on its own: a reader unfamiliar with the rest of the page could hear just that passage and walk away understanding the core point of the piece. It avoids jargon that needs a definition, avoids pronouns with no clear referent, and never assumes the listener can see something. It sits at that 20-to-30-second length Google recommends, no more, and it's placed on content, news, FAQ, local, health, that actually suits an audio-first delivery in the first place.

Whether the implementation is working, beyond passing a validator, comes down to whether it shows up where it's meant to: pulled into a Google Assistant response, credited as the source, sending traffic back to the site through the link the Assistant pushes to a user's device. That's the only real proof a passage was written well enough, and marked correctly enough, for a machine to trust it as the one thing worth saying out loud.