Speakable Schema for Voice Assistants

The Problem Voice Search Has That Speakable Schema Solves

When a voice assistant answers a question, it doesn't read your whole page. It picks a few sentences — usually whatever its model considers the clearest, most direct answer — and reads those aloud. The problem is that without speakable schema, the assistant is guessing. It might pick your navigation text, a stray subheading, or a sentence buried in the middle of a dense paragraph that sounds terrible when read aloud.

Speakable schema fixes this. It's a structured data property — part of the Schema.org vocabulary — that lets you explicitly mark which sections of your page are written to be heard, not just read. Think of it as raising your hand and saying: "This part. Read this part."

If you've already read anything about voice search, you've probably seen speakable schema mentioned in a list of things to do someday. This post is about doing it today — specifically what the markup looks like, where to put it, and how to write the content that goes inside it.

What Speakable Schema Actually Is

Speakable schema is a property of the WebPage and Article Schema.org types. It accepts either CSS selectors or XPath expressions that point to the specific DOM elements on your page you want flagged as voice-ready.

Here's a minimal working example in JSON-LD:

{
  "@context": "https://schema.org/",
  "@type": "WebPage",
  "name": "What Is a Home Warranty?",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".speakable-intro", ".speakable-summary"]
  },
  "url": "https://example.com/home-warranty"
}

In plain English: you're telling the parser "find the elements with the class speakable-intro and speakable-summary — those are the sections optimized for audio delivery."

You can also use XPath:

"speakable": {
  "@type": "SpeakableSpecification",
  "xpath": [
    "/html/head/title",
    "/html/body/article/p[1]"
  ]
}

XPath is more precise but also more brittle — if your page structure changes, your selectors break. CSS selectors tied to stable class names are more maintainable for most small business sites.

Google's Official Stance (And Why It Doesn't Tell the Whole Story)

Google's documentation states that speakable schema is currently limited to news content and is only used in Google Assistant on certain Google Home devices. If you read that and thought "well, it's not for me," you'd be making the same mistake most SMB owners make.

Here's what that framing misses:

1. AI overviews and generative search surfaces are pulling structured data from pages constantly. Google's own AI Mode, Bing Copilot, Perplexity, and others all index your structured data. Speakable schema signals content quality and answer-readiness in ways that matter to all of these systems — not just Google Assistant.

2. The restriction is on which content Google will activate speakable schema for in its own voice product. It doesn't mean other platforms ignore the signal.

3. Voice interfaces are proliferating faster than Google's documentation updates. Car dashboards, smart TVs, third-party assistants, and embedded voice features in apps all consume structured data. The speakable property has far more reach than Google's "news only" framing implies.

The practical reality: implementing speakable schema costs you very little time, and the upside — even partial — is real.

Writing Content That Actually Works When Spoken Aloud

This is where most implementations fail. Developers add the markup, but the text inside the marked elements was written for skimmers, not listeners.

Voice-ready content has specific characteristics:

• Short sentences. Aim for 15–20 words maximum. Anything longer loses the listener.
• No parenthetical asides. "(See section 4 below)" means nothing to someone hearing your page read aloud.
• No relative references. "The table above shows..." — there is no table above when you're listening.
• Active voice, present tense. "We repair HVAC units same-day" lands harder than "Same-day HVAC repair services are offered by our team."
• Answer the question first. Don't build to the answer. Lead with it.

A good test: read your speakable section out loud to someone who hasn't seen the page. If they immediately understand the answer to the question the page is about, it's ready. If they ask a follow-up before they understand, rewrite it.

Where to Put Your Speakable Markup

Not every page warrants speakable schema. Prioritize:

1. Your FAQ page or FAQ sections These are already structured as question-answer pairs. Marking the answer text as speakable is a natural fit.

2. Service pages with a clear value proposition If someone asks "who does same-day plumbing in Austin," you want your service page's intro sentence to be the one the assistant reads. Mark it.

3. Blog posts that directly answer a question Posts structured around a specific question — "how long does X take," "what does X cost," "is X worth it" — are ideal candidates. Mark the first paragraph or the direct-answer summary block.

4. Your homepage hero text (with caution) If your homepage opening line clearly states what you do and who you serve, it can work. But generic taglines ("We deliver excellence") waste the opportunity.

What to skip: contact pages, gallery pages, product category listings, and any page where the content is primarily visual or navigational.

The Technical Implementation, Step by Step

If you're on WordPress, Squarespace, Wix, or most modern CMS platforms, you can add JSON-LD to individual pages without touching code at the template level. Here's how to think through the process:

Step 1: Identify your target pages. Start with three to five pages that answer specific questions your customers actually ask.

Step 2: Write or rewrite your speakable sections. Before touching any markup, make sure the text in question is genuinely voice-ready (see the criteria above). Bad content marked as speakable is worse than no markup at all — it trains AI systems to associate your domain with low-quality answers.

Step 3: Assign stable CSS classes. Add a class like speakable-answer to the exact HTML element (usually a <p> tag or <div>) that contains your voice-ready text. Don't use classes you're already using for styling — create dedicated semantic classes.

Step 4: Write your JSON-LD block. Use the WebPage or Article type and add the speakable property with a SpeakableSpecification pointing to your CSS class.

Step 5: Inject the JSON-LD into your <head>. Most CMS platforms have a "custom code" or "header scripts" field per page. Paste your JSON-LD there.

Step 6: Validate. Run the page through Google's Rich Results Test and Schema Markup Validator. Fix any errors before moving on.

Step 7: Monitor. Check Google Search Console's Enhancement reports over the following four to six weeks. Watch for manual actions or warnings, and track whether your pages begin appearing in voice-related featured snippets.

Combining Speakable with Other Schema Types

Speakable schema doesn't operate in isolation. The pages that consistently get surfaced in voice and AI answers tend to have layered schema implementations:

• FAQPage schema marks individual questions and answers. Combined with speakable, the assistant knows both the structure and the audio-ready text.
• HowTo schema structures step-by-step content. Marking the summary or intro as speakable means voice assistants can introduce the how-to before reading the steps.
• LocalBusiness schema grounds your content geographically. If someone asks a voice assistant "who does X near me," your local business schema provides the context; your speakable markup provides the spoken answer.

If you're already running structured content with strong citation rates, adding speakable is the logical next layer — it's the bridge between being indexed and being spoken.

What "Good" Looks Like in 2026

The bar has moved. In 2022, having any schema markup put you ahead of most small business sites. In 2026, AI search surfaces have changed the entire dynamic — generative answers pull from structured, high-confidence content, and voice interfaces have become the default interaction mode in a growing number of contexts.

A well-implemented speakable page in 2026 looks like this:

• The speakable section is the first full sentence after the H1, written as a direct answer
• It is 40–80 words — long enough to be informative, short enough to be listenable
• It contains your business name, your service, and your location or differentiator naturally
• It is backed by valid JSON-LD with no schema errors
• The rest of the page supports and expands the speakable answer, not contradicts it

That's not a high bar. It's just a bar that most businesses haven't bothered to clear.

The Honest Limits of Speakable Schema

Speakable schema is not a magic switch. A few things it cannot do:

• It cannot force any voice assistant to use your content if your overall domain authority or content quality is low
• It cannot compensate for a page that loads slowly or is not mobile-friendly
• It does not guarantee Featured Snippet placement (though good speakable content often overlaps with featured snippet content)
• It will not help pages that are blocked by robots.txt or noindex directives — the assistant can't read what it can't crawl

Treat speakable schema as one layer of a well-built content strategy, not a standalone fix. It rewards businesses that have already done the work of writing clear, direct, answer-first content — it just makes sure that content gets heard.

Final Thought

Every voice query is someone's hands-free moment — driving, cooking, working. They asked a question and they're waiting for an answer. Speakable schema is how you make sure the answer they hear is yours. The technical lift is minimal. The content discipline required is real. Start with your three most-visited pages, mark your clearest sentence on each one, validate the markup, and move on. That's an afternoon's work with a durable upside.