Create Speakable schema markup for voice search and smart speakers. Define which content sections are suitable for text-to-speech.
A smart speaker reads a page out loud only when the page tells it which parts deserve a voice. Speakable schema is that instruction: a JSON-LD block that names the headline and body sections a text-to-speech agent should read, identified by CSS selectors or xpath. This tool builds that block from a headline and the selectors you enter. The step people most often skip is in the HTML, not the JSON: every element the selectors name must also carry aria-label="Speakable", and the markup itself must sit in the page body, where visible content lives, rather than in the head.
A concrete input and expected output from the current implementation.
Input
Article headline: Aurora borealis visible over northern states tonight | Article URL: https://www.example.com/news/aurora-tonight | Speakable sections (CSS selectors): .headline, .article-body, .byline
Expected output
{
"@context": "https://schema.org",
"@type": "NewsArticle",
"headline": "Aurora borealis visible over northern states tonight",
"url": "https://www.example.com/news/aurora-tonight",
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [".headline", ".article-body", ".byline"]
}
} Each entry maps straight into the JSON: headline and URL land in their own properties, and the three selectors pass through verbatim into the cssSelector array. Google's documentation also recommends providing xpath values alongside cssSelector so validation succeeds for at least one, and the named elements must carry aria-label="Speakable" in the page HTML for the markup to take effect.
The builder maps your form entries straight into JSON-LD: the headline becomes the headline value, the article URL becomes the url value, and each CSS selector you enter passes through verbatim into the SpeakableSpecification cssSelector array. The block is nested inside an Article or NewsArticle node with the @context declaration, so the result is paste-ready JSON-LD.
Two conditions outside the markup decide whether Google acts on it. The JSON-LD must sit in the visible page body, not the head. And every element the selectors name must carry the aria-label="Speakable" attribute in the page HTML; Google's documentation lists both as requirements, and also recommends supplying cssSelector and xpath together so validation succeeds for at least one of them.
No. Speakable content surfaces through Google Assistant's news experience, and Google's systems decide when and how it is read; markup is a signal, not a trigger. The Rich Results Test can confirm that Google parses the block, but there is no schedule or guarantee for voice surfacing, and per Google's documentation the feature is scoped to news publications.
No, that is the point of selectors: one block copied into your article template serves every page, as long as the named classes exist there and each carries aria-label="Speakable". Regenerate the block only when the template changes. If a page lacks one of the selected elements, that selector simply matches nothing, so keep to classes every article shares.
The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.
Shorten URLs with local redirect tracking via localStorage. See click counts and generate a QR code for each link.
Build UTM-tagged URLs for campaign tracking with source, medium, campaign, term, and content parameters.
Enter 2+ headlines and see simulated previews in Google results, email subject lines, and social posts side-by-side.
Count characters for Twitter/X, LinkedIn, Facebook, and Instagram with platform-specific limits and warnings.
Calculate click-through rates from impressions and clicks with industry benchmarks and trend analysis.
Check email subject line length against best practices for desktop and mobile with preview text optimization.