What SpeakableSpecification Actually Does
SpeakableSpecification is a schema property originally designed for voice assistants. The idea was simple: mark up the sections of a page that are most worth reading aloud. Google Assistant and similar tools could then pull the right snippet rather than reading out a navigation menu or a cookie consent banner.
That origin story is worth knowing, because it shapes how the property works technically. But the reason it matters now has less to do with voice and far more to do with how large language models (LLMs) process your content when deciding what to cite.
When an AI like ChatGPT, Perplexity, or Gemini visits your page, it does not read it the way a human does. It processes a flattened version of your HTML and has to infer which bits are the main point and which bits are boilerplate. SpeakableSpecification gives you a direct signal to say: "This section. This is what I want you to take away."
It is not a magic override. The AI still makes its own judgements. But a clear, well-structured speakable annotation gives your content a meaningful advantage over pages that offer no guidance at all.
The Two Ways to Point at Your Content
SpeakableSpecification lets you identify speakable content in two ways: using CSS selectors or using XPath expressions. Both approaches attach to the speakable property on your primary schema type, usually Article, NewsArticle, or WebPage.
CSS Selector approach
This is the simpler option for most people. You target HTML elements by their class or ID, the same way you would write a CSS rule. Here is a basic JSON-LD example for an article page:
{
"@context": "https://schema.org",
"@type": "Article",
"name": "How to Reduce Cart Abandonment",
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [".article-summary", ".key-takeaways", "h2"]
}
}That tells any consuming system: the content inside elements with those selectors is the most important content on this page. Keep the list focused. If you point at everything, you have effectively pointed at nothing.
XPath approach
XPath is more precise and more verbose. It is worth using when your HTML structure is complex or when CSS class names are not stable across templates. An XPath selector might look like this:
"xpath": [
"/html/body//p[@class='summary']",
"/html/body//section[@id='key-findings']//p"
]In practice, most e-commerce and content sites are better served by the CSS selector method. It is easier to maintain, easier to audit, and easier to explain to a developer or a non-technical colleague.
Which Schema Types Support the Speakable Property
Schema.org currently lists speakable as a property of Article and its subtypes, including NewsArticle, BlogPosting, and TechArticle. It also appears on WebPage and its subtypes.
For e-commerce brands, this has a practical implication. Your product pages probably use Product schema, which does not natively carry the speakable property in the same way. The workaround is to nest a WebPage type alongside your Product type in a JSON-LD array, then attach speakable to the WebPage node. It looks like this:
[
{
"@context": "https://schema.org",
"@type": "Product",
"name": "Merino Wool Base Layer",
...
},
{
"@context": "https://schema.org",
"@type": "WebPage",
"name": "Merino Wool Base Layer",
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [".product-intro", ".why-buy", ".key-specs"]
}
}
]This keeps your Product schema clean while still giving AI systems a speakable signal for the page.
What Content Should You Actually Mark as Speakable
This is where most implementations go wrong. People either mark up the entire page body or mark up nothing meaningful. Neither helps you.
Think about what a good AI answer would quote if someone asked about your product, service, or topic. That is your speakable content. In practical terms, this usually means:
- A concise summary of what the page is about (50 to 100 words, ideally near the top)
- Your key differentiators or product benefits, stated plainly
- Any specific facts, figures, or claims that make your content quoteable
- Your main conclusion or recommendation if the page is editorial content
What you should not mark as speakable: navigation text, call-to-action buttons, legal disclaimers, author bios, related products sections, or anything that only makes sense in a visual context.
A good rule of thumb: if you read the speakable section aloud on a podcast, would it make sense and be genuinely useful? If yes, it belongs. If it sounds like a website element rather than a piece of knowledge, leave it out.
How AI Search Engines Actually Use This Signal
It is worth being honest here. Google has the most documented support for SpeakableSpecification, having referenced it in relation to Google Assistant. OpenAI, Anthropic, and Perplexity have not published explicit documentation confirming they parse the speakable property during indexing.
So why bother?
Two reasons. First, the discipline of implementing speakable schema forces you to do something enormously valuable anyway: identify and mark up the best, most quoteable content on each page. That clarity benefits every AI system, whether it reads the schema directly or simply benefits from the fact that your content is better organised and more structured.
Second, as AI search matures, structured signals like this are increasingly likely to be used. Getting ahead of adoption now costs very little. Retrofitting it across hundreds of pages later costs a lot.
At FlinnSchema, we treat speakable implementation as part of a broader AI-readiness stack, sitting alongside clean Article or Product schema, well-maintained robots.txt rules, and E-E-A-T signals. No single element does everything on its own. You can see how we approach the full picture on our what we do differently page.
Implementing SpeakableSpecification on Shopify
Shopify does not give you a native JSON-LD editor, so you have two practical options: edit your theme's product.json or relevant liquid templates directly, or use a structured data app that allows custom JSON-LD injection.
If you are editing theme files manually, find the <head> section of your product or article template and add a <script type="application/ld+json"> block. You can use Liquid variables to make the CSS selectors dynamic if your theme uses consistent class naming. For example:
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "WebPage",
"name": "{{ page_title }}",
"speakable": {
"@type": "SpeakableSpecification",
"cssSelector": [".product__description-intro", ".product-benefits"]
}
}
</script>The CSS selectors need to match the actual class names in your theme. Check your rendered HTML with browser developer tools before you deploy. A mismatch here means the schema is technically valid but pointing at nothing.
Implementing SpeakableSpecification on WordPress
On WordPress, you have more flexibility. If you are using a plugin like Rank Math or Yoast, check whether it supports custom JSON-LD injection for individual posts or page types. If not, a lightweight custom JSON-LD plugin works well.
One approach is to add a speakable block to your article template using a small PHP snippet in your child theme's functions.php:
add_action('wp_head', function() {
if (is_single()) {
$schema = [
'@context' => 'https://schema.org',
'@type' => 'Article',
'name' => get_the_title(),
'speakable' => [
'@type' => 'SpeakableSpecification',
'cssSelector' => ['.entry-summary', '.key-points', 'h2']
]
];
echo '<script type="application/ld+json">' . json_encode($schema) . '</script>';
}
});Again, confirm your CSS selectors against actual rendered output. WordPress themes vary enormously in their class naming conventions.
If you are already managing custom JSON-LD on WordPress and worrying about conflicts with plugin-generated schema, our post on stopping Yoast from adding duplicate schema covers how to handle that cleanly.
Validating Your Implementation
Use Google's Rich Results Test at search.google.com/test/rich-results and the Schema Markup Validator at validator.schema.org to check your output. Neither tool will tell you exactly how AI systems use the speakable data, but they will confirm the JSON-LD is syntactically valid and that the speakable property is being parsed correctly.
You can also inspect the rendered HTML alongside your schema to manually verify that the CSS selectors you have specified actually match the elements you intend. This takes five minutes with browser developer tools and catches the majority of implementation errors before they go live.
If you want a fuller picture of how AI crawlers are actually interacting with your site, including whether they are accessing your pages at all, our guide to checking which AI crawlers are visiting your site walks through how to read your server logs for that data.
The Bigger Picture: Speakable as Part of AI Content Strategy
SpeakableSpecification is not a standalone tactic. It works best when the content it points to is already well written, factually specific, and structured clearly. Schema tells AI systems where to look. Good content is what they actually quote.
The brands that will do well in AI search over the next few years are the ones treating structured data as a content strategy discipline, not a technical afterthought. Speakable schema is one piece of that. Entity definition, review signals, and clean crawl access are others.
If you are unsure where your site currently stands, a free AI visibility audit is a good starting point. It gives you a clear picture of what structured data you have, what is missing, and which pages are most likely to be cited or ignored by AI search engines.
Frequently Asked Questions
Does Google still use SpeakableSpecification in 2025?
Google introduced SpeakableSpecification primarily for Google Assistant and has documented support for it in that context. Its use in generative AI search features like AI Overviews is less explicitly documented, but implementing it correctly remains a sound practice. The structure it imposes on your content benefits AI readability regardless of whether the property is parsed directly.
Can I use SpeakableSpecification on product pages, not just articles?
Yes, but with a workaround. The speakable property is formally attached to Article and WebPage types. For product pages, include a WebPage node in your JSON-LD array alongside your Product schema, and attach the speakable property there. This keeps your Product schema valid while still providing the speakable signal.
How many CSS selectors should I include in SpeakableSpecification?
Keep it focused. Two to four selectors is a sensible range for most pages. If you target too many elements, you dilute the signal and end up marking up content that is not genuinely your most important material. Think of it as curating, not cataloguing.
Will SpeakableSpecification help my content appear in ChatGPT or Perplexity answers?
There is no confirmed documentation from OpenAI or Perplexity stating they parse the speakable property directly. However, structuring your content clearly and marking your best material with schema is consistently associated with better AI citability across platforms. The effort is low and the upside is real, particularly as these systems evolve and adopt more structured data signals over time.