What the Speakable Schema Generator does
This tool builds SpeakableSpecification structured data in JSON-LD, the markup that tells a voice assistant exactly which sentences on your page are suitable to be read aloud. Speakable is a property of a WebPage or Article that points at specific sections of your content and effectively says, these passages are written to be spoken, so use them when a user asks a smart speaker or voice assistant for this information. You give the generator the parts of your page that work as a clean audio answer, and it produces a spec-compliant speakable block you can drop into your page's existing schema.
The key idea behind speakable is that text designed to be read with the eyes is often poor when read with a voice. A headline crammed with a brand name, a date, and a category works visually but sounds clumsy aloud. A long paragraph with parenthetical asides and links reads fine on screen but trips up a text-to-speech engine. Speakable lets you hand-pick the sentences that survive being spoken, typically a crisp headline and a one or two sentence summary, so the assistant lifts the right words rather than guessing. This generator focuses you on choosing those spoken-friendly passages and marking them correctly.
How speakable points at your content
Speakable identifies the relevant sections in one of two ways, and the generator supports both. The most common is a CSS selector approach, where the speakable object lists one or more cssSelector values that match elements on your page, such as the class on your headline element and the class on your summary paragraph. The assistant resolves those selectors against your rendered page and reads the text inside the matched elements. The alternative is an xpath approach, which uses XPath expressions to point at the same elements; this is useful when your markup lacks stable classes but has a predictable document structure.
Whichever method you choose, the principle is the same: the markup does not contain the spoken text itself, it contains a pointer to where that text lives on the page. This is a crucial difference from most other schema types, where you embed the content directly in the JSON. Because speakable references live page elements, the selectors must stay accurate as your template evolves. If you rename the class on your summary block, your speakable markup silently stops matching anything. The generator produces the selectors you specify, so keeping them aligned with your real markup is the ongoing responsibility once you ship.
How to choose the right passages
The strongest speakable selection is short, self-contained, and answers the implied question on its own. For a news or article page, that is usually the headline plus a tight summary sentence that captures the core fact. Aim for content that makes complete sense when heard without any surrounding context, because a listener has no screen to glance at. Avoid pointing speakable at sections full of links, because a link read aloud becomes meaningless, and avoid pointing it at sections heavy with numbers, abbreviations, or symbols that a text-to-speech engine may mangle. Two to three sentences of clean prose is the sweet spot.
Think about how the passage sounds, not how it looks. Spell out what would be ambiguous when spoken, keep sentences at a natural spoken length, and lead with the answer rather than burying it after a clause of setup. The discipline of writing for the ear tends to improve the passage for human readers too, since clarity helps everyone. When you select these passages in the generator, you are really curating the few sentences you would be happy to hear a robotic voice recite back to a user, so judge each candidate by that test before you mark it speakable.
Where speakable fits in 2026
Speakable began as an experimental feature aimed at Google Assistant reading news aloud on smart speakers, and its official status has always been limited and tied largely to news content. It is honest to say that speakable is not a guaranteed path to a voice result, and you should not add it expecting an immediate feature. What has changed is the broader context: voice queries, in-car assistants, and AI systems that respond by speaking have all grown, and these systems all face the same underlying problem of deciding which sentence to read. Explicitly marking your most spoken-friendly passage is a low-cost way to make that decision easier for them.
Treat speakable as part of a wider answer-engine and voice readiness strategy rather than a standalone trick. The same passages you mark as speakable are usually the same crisp, lead-with-the-answer sentences that AI Overviews and chatbots prefer to quote, so the work compounds. Marking them does no harm and signals intent clearly, while the real win comes from writing genuinely spoken-friendly content in the first place. This generator helps you formalize that intent in markup, but the value lives in the quality of the passage you point it at.
It is worth being clear-eyed about how narrow speakable's official footprint is compared to other schema types. Where Article or FAQ markup is read broadly across search, speakable has only ever had limited, mostly news-oriented support, and it has never been a guaranteed feature you can switch on. That is not a reason to ignore it, but it is a reason to keep your expectations grounded and to invest most of your energy in the writing rather than the markup. The markup is a small, honest signal of which sentences you intend to be spoken; the listenable quality of those sentences is what actually determines whether any voice or AI system chooses to read them aloud, so let the passage do the heavy lifting and let the speakable block simply point the way.
How to read the generated markup
The output is a JSON-LD block whose top object is typically an Article or WebPage carrying a speakable property. That speakable property is a SpeakableSpecification object with either a cssSelector array or an xpath array. Walk through the selectors and confirm each one matches the element you intend on your real page, the headline selector pointing at your headline, the summary selector at your summary. If a selector matches nothing, or matches a large container full of unrelated text, the markup is technically valid but practically useless, since a voice assistant would either read nothing or read too much.
Confirm the order makes sense, since assistants generally read the matched sections in document order. The headline should come before the summary so the spoken result flows naturally. Keep the number of selectors small; pointing speakable at five different blocks produces a long, rambling read rather than a clean answer. The mark of good speakable markup is that, if you mentally read aloud only the text inside the matched elements, you get a coherent, complete, listenable answer in well under a minute.
Common speakable mistakes
The most common mistake is selectors that drift out of sync with the page, where a template change renames a class and the speakable pointer quietly stops matching. Because nothing visibly breaks, this can go unnoticed for a long time. The second mistake is selecting too much, pointing speakable at an entire article body so the assistant would read minutes of text instead of a tight answer. The third is selecting passages full of links, tables, or symbol-heavy content that sound terrible aloud, which defeats the entire purpose of the feature.
Another error is applying speakable to content types it was never meant for, or expecting it to work broadly outside the narrow news context where it has official support. Speakable is not a generic ranking booster and adding it to a product page will not produce a voice shopping result. Finally, some people embed the spoken text directly in the JSON rather than using a selector to reference the page, which is not how speakable works; the specification is about pointing at existing on-page elements, so the text must live on the page and the markup must reference it.
What to do after you generate it
Paste the speakable block into your page, ideally merging the speakable property into your existing Article or WebPage schema rather than adding a competing duplicate. Then open your page and verify that each selector you used actually resolves to the intended element, using your browser's developer tools to test the CSS selector against the live document. Run the page through Google's Rich Results Test and the Schema Markup Validator to confirm the JSON-LD is syntactically valid, while keeping in mind that these tools check structure rather than whether a voice assistant will choose to use it.
After it is live, read your selected passages aloud yourself, or have a text-to-speech tool read them, to make sure they sound clean and complete. Adjust the passage wording until it works for the ear, then update the markup if you move it. Build a habit of revisiting the selectors whenever you change your page template, since that is where speakable most often breaks. Treat speakable as one small, well-targeted signal inside your broader voice and AI readiness work rather than a feature you flip on and forget, and pair it with genuinely concise, answer-first writing that serves every channel that reads your content aloud.