Speakable Schema Generator

Speakable schema is a property within Schema.org that identifies specific sections of a web page as being especially suitable for audio playback using text-to-speech engines. Instead of marking up an entire page as speakable, you pinpoint the exact elements, typically a headline and a concise summary, that a voice assistant should read aloud when your content is selected as an answer.

The property works by referencing parts of your page using CSS selectors or XPath expressions. You might point to your article's H1 heading and the first paragraph of the body content, telling voice assistants that those specific elements contain the most relevant, self-contained information worth reading aloud.

Speakable is not a standalone schema type. It's a property that gets added to an existing schema block, most commonly a NewsArticle or Article type. The speakable property nests inside the article's JSON-LD and contains an array of SpeakableSpecification objects, each pointing to a section of the page.

Google introduced speakable markup as part of its push toward voice search and smart assistants. It's currently supported in Google Assistant's news results for English-language content in the United States, with potential for broader rollout as voice search continues to evolve.

Voice search has grown steadily as smart speakers, phone assistants, and in-car systems have become part of daily routines. The way people search by voice is fundamentally different from how they type. Voice queries tend to be longer, more conversational, and more likely to be phrased as complete questions. The responses need to be different too: concise, direct, and natural-sounding when read aloud.

When a voice assistant answers a query, it typically reads a single short passage from a single source. There's no list of ten blue links. There's one answer. Being that answer gives you a level of visibility and authority that standard search results can't match. The assistant often credits the source by name, saying something like "According to [your publication]," which builds brand recognition with an audience that isn't even looking at a screen.

Speakable schema is one of the few tools available that lets you explicitly tell search engines which parts of your content work best as a spoken answer. Without it, voice assistants have to guess which section of your page to read, and they may pick a passage that's awkward, incomplete, or out of context when spoken aloud.

The investment in voice optimization goes beyond just schema. It requires thinking about how your content sounds, not just how it reads. But speakable markup is the technical mechanism that connects your optimized content to the voice platforms that deliver it.

The generator builds a complete JSON-LD block with a NewsArticle or Article type that includes the speakable property configured with your specified content selectors.

Parent article schema. The generator creates the full article markup including headline, author, publisher, dates, images, and description. Speakable doesn't exist on its own. It has to live inside an article schema block, and that block needs to be complete and valid for the speakable property to be processed.

Speakable specification using CSS selectors. The default output uses cssSelector to point to page elements. You enter the CSS selectors that target your headline and summary content, like .article-headline or #summary-paragraph, and the generator wraps them in the proper SpeakableSpecification format.

Speakable specification using XPath. Alternatively, the generator supports XPath expressions for targeting content. XPath is more flexible for complex page structures but less familiar to most users. CSS selectors work for the vast majority of cases.

Multiple speakable sections. You can define more than one speakable section per article. The typical setup includes one selector for the headline and one or two for summary content. The generator handles multiple entries and formats them as an array within the speakable property.

Not everything on your page is suitable for being read aloud. The content you mark as speakable needs to work as a standalone spoken passage, which requires a different editorial sensibility than writing for reading.

Headlines. Your article headline should almost always be one of your speakable sections. It orients the listener to the topic before the assistant reads the summary. Keep headlines clear and descriptive. Clever wordplay and puns that work visually often fall flat or confuse when spoken.

Concise summaries. The ideal speakable summary is two to three sentences that capture the essential point of the article. Think of it as the answer a newsreader would give if someone asked "What happened?" The summary should be self-contained and make sense without any surrounding context.

Avoid lists and complex formatting. Bullet points, tables, data-heavy passages, and content that relies on visual formatting don't translate well to speech. A sentence like "Revenue increased 14% year-over-year to $3.2 billion" works spoken aloud. A table comparing quarterly revenue across six divisions does not.

Avoid references that require visual context. Phrases like "as shown in the chart below" or "click here for more details" are meaningless in a voice context. Your speakable sections should be free of any language that assumes the listener is looking at a screen.

Keep it short. Google's guidelines recommend that each speakable section be no longer than a few sentences. Voice assistants are designed to deliver quick answers, not read entire articles. If your speakable content runs too long, the assistant may truncate it or skip your content in favor of a more concise alternative.

CSS selectors in speakable schema use the same syntax you'd use in a stylesheet to target HTML elements. They tell the voice assistant exactly which DOM elements to extract text from.

Class selectors. .article-summary targets any element with the class "article-summary." This is the most common approach since most CMS templates assign classes to key content sections.

ID selectors. #main-headline targets the single element with the ID "main-headline." Use these when your page structure guarantees a unique ID on the element you want.

Element and attribute selectors. article h1 targets the H1 inside an article element. [data-speakable="true"] targets elements with a custom data attribute, which is useful if you want to add speakable markers to your templates without relying on existing classes.

Combining selectors. You can get specific with combinations like .article-body > p:first-of-type to target just the first paragraph inside the article body. This precision helps you avoid including navigation text, sidebar content, or other elements that happen to share a class name.

The selector should return a clean block of text without embedded interactive elements, images, or structural markup that would be meaningless when converted to speech. Test your selectors by running them in your browser's developer console using document.querySelector() or document.querySelectorAll() and checking that the returned elements contain only the text you intend.

Speakable schema was designed primarily for news content, and Google's current implementation is limited to news articles in English for US users through Google Assistant. But the schema itself is not technically restricted to news.

The Schema.org speakable property can be applied to any Article subtype, not just NewsArticle. In principle, educational content, how-to guides, health information, and reference material could all benefit from having speakable sections identified, especially as voice search expands across more content types and regions.

That said, the practical benefit today is concentrated in news publishing. If you're a news publisher producing timely content that targets current event queries, speakable schema has a clear and immediate value. If you publish other types of content, implementing speakable schema positions you for future voice search features but may not produce visible results right now.

The broader takeaway is that structuring your content for voice consumption is valuable regardless of whether you implement speakable schema today. Writing concise summaries, leading with the key information, and keeping language natural and conversational are all practices that help your content perform well in voice search through featured snippets and other mechanisms, even without speakable markup.

Speakable schema and featured snippets serve overlapping goals through different mechanisms. Both aim to surface a concise, direct answer from your content. The difference is in how they're triggered and where they appear.

Featured snippets are selected by Google's algorithms based on content analysis. Google identifies a passage on your page that answers a query and displays it in a prominent box at the top of search results. No special markup is required. Google's systems decide which passage to extract.

Speakable schema is an explicit signal from you telling Google which sections work best for voice. Instead of Google guessing, you're pointing directly to the content you've optimized for spoken delivery. When Google Assistant selects your content for a voice answer, it uses your speakable sections rather than algorithmically extracting a passage.

The two can work together. Content that earns featured snippets is already proven to be concise and answer-focused, which makes it a strong candidate for speakable markup. Adding speakable schema to pages that already perform well in featured snippets extends that visibility into voice search.

However, earning a featured snippet doesn't guarantee your content will be used for voice results, and having speakable schema doesn't guarantee it either. They're separate systems with separate selection criteria. Implementing both gives you the broadest coverage across text and voice search surfaces.

Beyond the schema itself, there are a few technical requirements and best practices for speakable implementation.

Valid parent schema. The speakable property must be nested inside a valid Article or NewsArticle schema block. The parent schema needs to pass validation on its own before the speakable property adds any value. An incomplete article block with speakable is still an invalid schema block.

Accessible content. The elements your CSS selectors point to must be present in the page's HTML when it loads. Content that's loaded dynamically via JavaScript after the initial render may not be available when search engines process your schema. If your content is rendered client-side, verify that Googlebot can see the elements your selectors reference.

Matching content. The text returned by your selectors must be present and visible on the page. You can't point to hidden elements, display:none content, or sections that only appear behind a login wall. Google's guidelines require that speakable content be accessible to all users.

Structured and clean selectors. Your selectors should return predictable, consistent results across articles. If your template changes and the selector no longer matches the intended element, the speakable specification silently breaks. Use stable class names or IDs that are part of your template structure rather than dynamically generated selectors that might change.

One speakable specification per article. While you can include multiple selectors within a single speakable block, you should have one speakable property per article schema block. Don't create multiple speakable objects inside the same article.

Marking too much content as speakable. Pointing your selectors at the entire article body defeats the purpose. Voice assistants need a short, focused passage. If everything is speakable, nothing is optimized for speech. Limit your speakable sections to the headline and a two-to-three-sentence summary.

Using selectors that match unintended elements. A broad selector like p will match every paragraph on the page, including footer text, sidebar content, and navigation labels. Be specific enough that your selectors only capture the content you intend. Test them in the browser before committing them to your schema.

Forgetting to update selectors after redesigns. A site redesign that changes class names, restructures the DOM, or moves content into new containers will break existing speakable selectors silently. There's no visible error on the page. The schema just stops working. Audit your speakable selectors after any template or design changes.

Writing speakable content that sounds unnatural. Text optimized for reading doesn't always sound good when spoken. Abbreviations, parenthetical asides, complex sentence structures, and heavy jargon can make voice playback awkward. Read your speakable content out loud before finalizing it. If it sounds stilted or confusing when spoken, rewrite it.

Implementing speakable without completing the parent schema. Adding speakable to an Article block that's missing required properties like author, publisher, or datePublished means the entire schema block is incomplete. Fix the parent schema first, then add the speakable property.

Assuming immediate results. Speakable is currently limited in scope, and Google doesn't surface speakable results for every query or every article. Implement it as a long-term investment in voice readiness rather than expecting an immediate traffic boost. The publishers who have the markup in place when Google expands voice features will benefit first.