Is Speakable Schema Worth Adding? Our Negative Result

Most schema advice in this niche is someone reselling a hypothetical. This page is the other thing: a report on markup we actually run, everywhere, and what it has earned — which is, as far as we can observe, nothing. We publish that as a finding, not a complaint. Negative results are the one content type this niche cannot fake, and speakable is a clean specimen.

What is speakable schema supposed to do?

speakable flags the parts of a page that are especially appropriate for text-to-speech conversion — the passages a voice assistant could read aloud as an answer. schema.org defines it as a property of Article and WebPage whose value is a SpeakableSpecification: a node that locates the speakable sections either by cssSelector or by xpath. The design intent is straightforward — instead of an assistant guessing which sentences to read, the page declares them.

The property describes; it does not command. Nothing in the vocabulary obligates any platform to fetch, parse, or voice the flagged passages, and no AI platform on our closed source list — OpenAI, Anthropic, Perplexity, Google's crawler and AI-features documentation — documents consuming speakable at all. That gap between what the markup declares and what anyone documents doing with it is the whole story of this page.

How do we deploy speakable in production?

On every page, uniformly, aimed at our most extractable passages. Each page across our 3 production builds ships a speakable node generated at build time, with cssSelector values pointing at the exact CSS classes that render the page's direct-answer box and key-takeaways block — the 2 passages engineered to be lifted whole [our data]. The shape, with placeholder selectors:

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".direct-answer", ".key-takeaways"]
  }
}

The targeting is the deliberate part. If any system ever does read speakable, ours points at the passages built to stand alone — the same answer-first blocks described in how to show up in AI Overviews. We chose cssSelector over xpath for a maintenance reason: the class names are the same ones our page templates render, so the selectors live next to the layout they describe instead of encoding a DOM path that breaks silently on redesign [our data]. The marginal cost of all this is 0: the selectors live in one template, and the markup ships with every page automatically [our data].

What effect have we observed?

None we can attribute — stated plainly, as the finding. Across every page of 3 builds shipping speakable, nothing we track has ever moved in a way that points at the property: no citation observation, no referral pattern, no crawl behavior in our logs distinguishable as speakable-driven [our data].

The honest epistemics cut two ways, and both belong in the record:

That last row is the caveat that keeps this negative result honest: part of what we observe is missing instrumentation, not proven absence. No tool in our stack reports anything about speakable, so a small effect could exist unobserved. But a property with no documented consumer and no measurement surface is unjustifiable as spend either way — "possibly working, invisibly, for free" is an argument for templating it, never for paying for it.

Does any evidence support speakable for AI visibility?

No. The controlled evidence on markup generally is Ahrefs' 1,885-page test (August 2025–March 2026): no meaningful AI-citation lift from adding JSON-LD on any platform tested, with no exception carved out for speakable. Google states there is no special structured data needed for AI Overviews or AI Mode, and its structured-data guidelines position markup as reflecting visible content, not substituting for it. The full accounting of markup versus citations is in what the evidence shows.

Evidence-tiered, speakable lands in the weakest class we publish: not proven in our fleet (we ship it and observe nothing), not supported by a named study, and only partially platform-documented — the vocabulary exists at schema.org, while consumption by any engine is documented nowhere on our list. That is "plausible-but-unproven," and the plausible half is doing all the work in every pitch that includes it.

Is speakable worth adding to your site?

Worth adding at cost 0; worth nothing above that. If your stack already templates JSON-LD, the property is a few lines that double as a declaration of which passages you consider most extractable — a cheap discipline, since deciding what .direct-answer should contain is the useful part. That discipline, not the markup, is where our pages get their answer-first shape, in the same family as our FAQ schema verdict: the visible words carry the value and the markup mirrors them for free.

Above cost 0, decline. A vendor line item for speakable implementation buys markup with no documented consumer, no supporting study, and — from the one fleet we can speak for — no observable effect [our data]. We ship it and we would not pay for it; that is the whole verdict. The levers with actual evidence behind them are content-level, and they are cataloged with their evidence tiers in our generative engine optimization guide.