Voice search optimization: Schema for staying visible in 2026

“Hey Siri, how do I optimize my database?” is a normal way to start a search now: smart speakers in the office, assistants in the car, earbuds paired with a phone. The user asks a question and hears an answer, with no list of links to scan.

For anyone running enterprise WordPress platforms, this is a structural change. Instead of competing only for the first visual page, the goal becomes the short answer an assistant can read aloud. That goal has concrete limits, documented by Google, Apple and Amazon, and this guide separates what those platforms promise in writing from what is only good editorial practice.

See my SEO and GEO services for answer engines and AI assistants.

#How AI agents changed voice search

The first generation of assistants searched for a keyword and read out the top result. Today several products work as conversational agents backed by language models:

• Contextual synthesis: the agent does not read whole paragraphs; it parses documents and extracts the shortest answer it can verify.
• Source attribution: in the one case Google documents (Speakable for news), the assistant attributes the source when it reads the excerpt and sends the full article URL to the user’s phone. Outside that case, no platform promises a spoken mention of your brand.
• Device spread: listening happens in cars, on wearables and in smart homes, where nobody scrolls a list of links.

#Why you can no longer build your own Google Assistant action

For a few years, the way to “be” on Google Assistant was a Conversational Action: a voice app with intents, scenes and webhooks. That route is closed. Google’s developer documentation states that Conversational Actions were deprecated on June 13, 2023. Any article that still tells you to build a voice action for Assistant is out of date.

In practice a WordPress site has three paths left: be a source that search systems can crawl and quote, mark excerpts with Speakable where Google supports it, and publish content in formats an assistant consumes directly, such as the Alexa flash briefing feed described below. A custom REST endpoint “for voice assistants” has no documented consumer today, so I do not recommend it as an investment.

#What Google actually promises with Speakable

The speakable property is the most cited part of voice search guides and also the most misdescribed. The official page, Speakable (Article, WebPage) structured data, is short and clear:

• It is in beta. Google warns that requirements and guidelines may change.
• It works in one market. The documentation says the property works for users in the U.S. that have Google Home devices set to English, and for publishers that publish content in English.
• It is for news. Google Assistant uses Speakable to answer topical news queries on smart speakers and returns up to three articles from different publications.
• It attributes and hands off. When Assistant reads a marked section, it attributes the source and sends the full article URL to the user’s phone through the Google Assistant app.

“For optimal audio user experiences, we recommend around 20-30 seconds of content per section of speakable structured data, or roughly two to three sentences.”

Google Search Central, Speakable documentation

The technical guidelines add details that almost no tutorial mentions. Do not mark datelines (where the story was reported), photo captions or source attributions, because they sound confusing in audio. Use cssSelector or xPath, never both in one specification. And, as with all structured data, Google does not guarantee the feature will show up.

The practical consequence: Speakable produces a voice result only for English-language news content heard by U.S. users on Google Home. A WordPress agency blog, a shop or a site in another language gets no documented voice result from it. Marking a summary does no harm, but do not treat it as a “voice SEO” switch and do not promise a client voice results based on it. What transfers to other markets and assistants is the editorial discipline Google asks for: short summaries, self-contained sentences, nothing that needs an image to make sense.

#How to add speakable schema in WordPress

Google documents speakable as structured data for Article and WebPage. The property points CSS selectors (or XPath) at fragments that are candidates for audio playback. The reference definition is at schema.org/SpeakableSpecification.

#When to use Speakable schema and when to skip it

Use Speakable with care:

• Useful on English news articles or guides with a short, factual, stable summary marked with a unique ID (#tldr-summary).
• Not useful when you mark the whole page, long blocks, sales CTAs or text that changes with every deploy.
• Limited by market and language: outside the U.S. and English, the markup has no documented effect.
• A complement, not a replacement: the quality of the answer under the H2 matters more than the JSON-LD alone.

#Speakable JSON-LD example

<!-- Speakable JSON-LD example for WordPress -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Voice search optimization: Schema for staying visible in 2026",
  "url": "https://wppoland.com/en/voice-search-seo-wordpress-guide-2026-en/",
  "inLanguage": "en",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [
      "#tldr-summary",
      ".faq-answer"
    ]
  },
  "author": {
    "@type": "Organization",
    "name": "WPPoland",
    "url": "https://wppoland.com"
  }
}
</script>

#How to add Speakable through functions.php without a plugin

To avoid a heavy plugin, add speakable to the head with the wp_head hook:

add_action('wp_head', 'wppoland_add_speakable_schema');

function wppoland_add_speakable_schema() {
    if (!is_singular('post')) {
        return;
    }

    $post_id = get_the_ID();

    $schema = [
        '@context'    => 'https://schema.org',
        '@type'       => 'Article',
        'headline'    => esc_html(get_the_title($post_id)),
        'url'         => esc_url(get_permalink($post_id)),
        'inLanguage'  => 'en',
        'speakable'   => [
            '@type'       => 'SpeakableSpecification',
            'cssSelector' => ['#introduction', '.voice-answer'],
        ],
    ];

    echo '<script type="application/ld+json">' . wp_json_encode($schema, JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE) . '</script>' . "\n";
}

Practical WordPress notes: make sure the selectors exist in the rendered HTML (Gutenberg, synced patterns or the theme) and always escape output. Google’s Rich Results Test does not list Speakable among the types it reports, so check the syntax in the Schema Markup Validator. If an SEO plugin already outputs Article, merge speakable into that node rather than adding a second Article on the same page.

#What kinds of intent voice queries carry

The decisive difference is not the microphone, it is intent. Someone who types “wordpress redis cache” is exploring. Someone who says “how do I set up Redis object cache in WordPress without sharing sessions between shops” wants a procedure now.

Three spoken intent patterns deserve different editorial treatment:

1. Procedural (“how do I…”, “what are the steps…”): answer with a short block and visible numbered steps.
2. Definition or comparison (“what is…”, “what is the difference between…”): one factual paragraph of two or three sentences, with no preamble.
3. Local or operational (“near me”, “in Chicago”, “today”): depends on consistent NAP data and local business schema, not on one long article.

In Search Console, filter queries that start with “how”, “what”, “which”, “where” and “when”. These series approximate spoken vocabulary better than a list of two-word keywords. Then rewrite your H2 and H3 headings with the real question and put the useful answer in the first sentence.

#What changed for FAQ and HowTo rich results in 2023

FAQ and HowTo remain natural formats for spoken intent in the page text, but Google’s visual results changed. On August 8, 2023, Google announced changes to HowTo and FAQ rich results on the Search Central blog:

• FAQ: FAQPage rich results are now shown only for well-known, authoritative government and health websites. For all other sites they are no longer shown regularly.
• HowTo: first limited to desktop; on September 13, 2023 Google stopped showing them on desktop too and declared the type deprecated.
• Existing markup: Google says there is no need to remove the structured data, because unused markup causes no problems, but it also has no visible effect in Search.

So the safe criterion is editorial: write questions and steps in the page body because they answer the reader and the assistant that extracts text, not because you expect a visual enhancement. If you keep FAQ or HowTo JSON-LD, it must mirror the visible content, with no questions the page does not answer.

• Frequent questions: an H2 or H3 with the exact question and a short answer in the DOM. Good for “what is”, “when to use”, “what is the difference”.
• Procedures: visible numbered steps with realistic tools and time. Good for “how to enable object cache”.
• Avoid: FAQs written only for markup, empty answers, or procedures with one generic step.

#How to optimize featured snippets for voice answers

Google’s featured snippets reverse the usual result format: the descriptive excerpt comes first and the link second. The editorial logic is the same one that serves an assistant: the question in the heading, the direct answer in the first paragraph, detail after that. There is no markup to request a featured snippet; Google picks the excerpt from the text.

Recommended pattern per section:

1. An H2 phrased as the spoken question.
2. A paragraph of 40 to 60 words with a subject, a verb and a clear conclusion.
3. A list, table or procedure for readers who keep going on screen.

Do not force snippets with formatting tricks. The text must be correct and quotable; a wrong excerpt hurts the brand when it is read aloud.

#How to control what assistants can quote

The other half of optimization is deciding what must not be read out. Google’s documentation on the robots meta tag and the data-nosnippet attribute defines three controls that also reach voice and AI surfaces:

• nosnippet blocks any text snippet for the page. Google says this covers web search, Images, Discover, AI Overviews and AI Mode, and that the content will not be used as a direct input for AI Overviews and AI Mode.
• max-snippet:[number] caps the snippet at a number of characters. The list of covered surfaces includes Assistant, and the cap also limits how much text can be used as direct input for AI Overviews and AI Mode.
• data-nosnippet is an HTML attribute for span, div and section elements that keeps specific parts of a page out of snippets.

On a WordPress site this solves real cases. A table of commercial terms that changes every week, a legal notice or a deliberately wrong example (“do not do this”) can sit inside data-nosnippet while the answer paragraph stays available. Mind the order of precedence: if a page carries both nosnippet and data-nosnippet, nosnippet wins and no snippet is shown. A very low max-snippet also keeps the page out of featured snippets, so use it only where losing that format is acceptable.

#How to structure content for voice search

The synthesis system looks for answers with syntactic precision. Apply the inverted pyramid in every section:

#How to write H2 and H3 headings as questions

Instead of “Caching methodologies”, use the wording a practitioner says to an assistant:

• “How object cache works in WordPress”
• “What is the difference between Redis and Memcached for WooCommerce”

#How to write the answer right under the heading

Right after the heading, one concise paragraph with no warm-up.

• Recommended: “Object cache in WordPress keeps the results of repeated database queries in memory, through Redis or Memcached. It cuts page generation time on sites with heavy dynamic traffic, as long as sessions and object cache are isolated correctly.”
• Avoid: an opening sentence that announces the topic instead of answering the question. Assistants skip preambles without facts.

#What to write after the short answer

After the short answer, add nuance, exceptions and configuration. In the Speakable case Google sends the article URL to the phone; in other cases the user opens the page later. Either way, the full page has to serve the person who wants detail.

#How Siri finds web content

Apple publishes no equivalent of Speakable. What it documents is its crawler. According to the support page About Applebot, data crawled by Applebot powers several Apple features, including Siri, Spotlight and Safari. For a WordPress site that comes down to four checkable rules:

1. Do not block Applebot by accident. Applebot follows robots.txt directives aimed at it. If the file has no rules for Applebot but does have rules for Googlebot, Applebot follows the Googlebot rules. A block meant only for Google can take the site out of Siri.
2. Crawl-delay does not work for Applebot. If you need to limit load, do it on the server or the CDN.
3. Applebot-Extended is not a crawler. It only tells Apple whether content crawled by Applebot may be used to train Apple’s foundation models. Pages that disallow Applebot-Extended can still appear in search results, and Apple says those rules are not considered in ranking.
4. Opting out of training does not remove you from Siri. Even with Applebot-Extended disallowed and nosnippet applied, Apple says the content remains discoverable through Spotlight, Siri and Safari.

Before editing robots.txt through an SEO plugin, check the file actually served in production (not just the settings screen) to confirm Applebot has the access you intend.

#How to publish an Alexa flash briefing from WordPress

Amazon offers a path that does not depend on rankings: the Flash Briefing Skill API. According to Amazon’s documentation, a flash briefing delivers news headlines and other short content to Alexa customers, as text or audio, from an HTTPS feed in RSS or JSON. You can update content as often as every 15 minutes and must update it at least daily.

The feed reference sets rules a WordPress publisher has to follow:

• Text read by text-to-speech: the mainText field (or description in RSS) is what Alexa reads to the customer.
• Under 4,500 characters per item: longer text is truncated to the nearest sentence under the limit.
• Plain text only: no SSML, HTML or XML. WordPress post content has to go through wp_strip_all_tags().
• Punctuation sets the pauses: commas and semicolons give short pauses; periods, question marks and exclamation points give longer ones. Amazon advises against non-standard punctuation.
• Freshness: Alexa ignores items dated more than 7 days back, and items should run from newest to oldest.
• “Read More” link: redirectionUrl points to the article in the Alexa app.

A minimal REST endpoint that builds the JSON feed from recent posts:

add_action('rest_api_init', function () {
    register_rest_route('briefing/v1', '/feed', [
        'methods'             => 'GET',
        'callback'            => 'wppoland_alexa_briefing_feed',
        'permission_callback' => '__return_true',
    ]);
});

function wppoland_alexa_briefing_feed() {
    $items = [];
    foreach (get_posts(['numberposts' => 5, 'date_query' => [['after' => '7 days ago']]]) as $post) {
        $items[] = [
            'uid'            => 'urn:wp:post:' . $post->ID,
            'updateDate'     => get_post_modified_time('Y-m-d\TH:i:s\Z', true, $post),
            'titleText'      => get_the_title($post),
            'mainText'       => mb_substr(wp_strip_all_tags(get_the_excerpt($post)), 0, 4400),
            'redirectionUrl' => get_permalink($post),
        ];
    }
    return rest_ensure_response($items);
}

Each post’s manual excerpt becomes the spoken text, so write it like a Speakable section: two or three self-contained sentences, with no abbreviations that text-to-speech would spell out letter by letter.

#Why does TTFB matter for voice search on WordPress

An assistant in a live dialogue has less patience than a user watching a loading spinner, and a slow page also delays whoever opens the URL on the phone after the answer. No voice platform publishes a TTFB limit for choosing sources, so use the public reference instead: the web.dev article on Time to First Byte says, as a rough guide, that a good TTFB is 0.8 seconds or less and that values above 1.8 seconds are poor. The same article notes that TTFB is not a Core Web Vitals metric.

#Checklist for cutting TTFB in WordPress

The WordPress performance documentation covers caching, object cache and plugin hygiene. Operational checklist:

1. Edge page cache (Cloudflare or similar) for stable public HTML.
2. Object cache (Redis or Memcached) for repeated queries; isolate WooCommerce sessions.
3. Lean semantic HTML: fewer unnecessary nodes, less blocking JS on the critical path. A headless architecture is one option when the theme cannot be slimmed down.
4. Asset CDN and modern images (AVIF or WebP) for whoever opens the page on a phone.
5. Measurement: WebPageTest or CrUX data for TTFB per region (the markets where your audience talks to you).

Measure your stack against those thresholds and compare with the competitors already being used as answers in your niche, instead of chasing numbers without a source.

#Local voice search SEO for WordPress

Many spoken queries on phones are geographic (“where is the nearest WordPress developer”, “WordPress support in Chicago”).

For these intents:

• Align Name, Address and Phone (NAP) with your Google Business Profile, Apple Maps and the directories that matter.
• Use LocalBusiness (or a more specific type) with geo and openingHoursSpecification that match reality.
• Write location pages with street-level references that help navigation assistants, without inventing branches.

#How to measure voice search results

Voice almost never shows up as a clean channel in analytics. Useful proxies:

• Featured snippets and People Also Ask in Search Console for your target questions.
• Question-shaped queries filtered in the performance report.
• Presence in answer engines: regular manual tests with a fixed set of niche questions.
• Requests to the flash briefing feed in server logs, if you publish one.
• Direct brand traffic after campaigns: correlate with dates, without claiming causation you cannot show.

#Summary

Direct answers, honest schema (Speakable only where Google supports it, FAQ and procedures matching the DOM), snippet controls and measured TTFB together prepare a WordPress install to be quoted, on screen and in audio.

Start with a small set of anchor pages (technical guides and product answers) before marking the whole archive. Check selectors, test the target questions by voice on a real phone, and only then roll the pattern out to the rest of the site.