Speakable schema: marking the parts of an article worth reading aloud

JSON-LD example

Copy this into a <script type="application/ld+json"> tag and replace the values with your own.

{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "County approves $14 million flood wall for the east riverfront",
  "datePublished": "2026-09-28T17:40-04:00",
  "url": "https://example.com/news/east-riverfront-flood-wall/",
  "author": {
    "@type": "Person",
    "name": "Dana Whitfield"
  },
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [
      ".speakable-headline",
      ".speakable-summary"
    ]
  }
}

Properties

What happens when someone asks for the news

When a user asks a Google Home speaker for news on a topic, Google returns up to three articles from around the web and reads the speakable sections aloud with text-to-speech. It names the source and sends the full article URL to the user's phone through the Google Assistant app, so a listener can read the rest later.

Ranking is algorithmic. Speakable decides which part of your article gets read, not whether your article is chosen. If Google picks a competitor's story, adding more selectors won't change that.

Writing sections that survive being read aloud

Google's guidance is about listening, not reading.

• Keep each section short. Around 20 to 30 seconds of audio, roughly two or three sentences.
• Skip what sounds odd spoken. Datelines ("WASHINGTON:"), photo captions and source credits confuse a listener.
• Pick key points, not the whole story. A long selection gets cut off before the important detail.
• Rewrite the top of the story if needed. Break long compound sentences into separate ones so they read clearly aloud.

A two-sentence summary box at the top of a news post works well as a speakable section, and readers skimming the page benefit from it too.

Tagging speakable blocks in the block editor

The block editor lets you add a class to any block: select it, open Advanced in the sidebar and type in Additional CSS class(es). Give the headline block speakable-headline and the summary paragraph speakable-summary, and your cssSelector values are ready. This is sturdier than an xPath like /html/body/div[2]/p[1], which breaks the moment a theme update adds a wrapper element.

Hydrogen SEO prints Article markup for posts, and its hydrogen_seo_schema_markup filter can add the property to that block instead of creating a second one:

add_filter( 'hydrogen_seo_schema_markup', function ( $schema, $post_id, $schema_type ) {
    if ( 'Article' === $schema_type && has_category( 'news', $post_id ) ) {
        $schema['speakable'] = [
            '@type'       => 'SpeakableSpecification',
            'cssSelector' => [ '.speakable-headline', '.speakable-summary' ],
        ];
    }
    return $schema;
}, 10, 3 );

Then view a post's source and confirm that each selector matches an element that exists. A selector pointing at nothing is valid JSON-LD that does nothing.

When it isn't worth the effort

Skip speakable if your site isn't a news publisher, publishes in a language other than English, or serves an audience outside the US. The markup won't hurt, but it won't be used either. Evergreen explainers, product pages and recipes aren't what the feature answers. For those, put the effort into Article markup and clear, answer-first writing that assistants and search engines can quote without special selectors.