Voice Search Optimierung: Schema für den Vorsprung in 2026

Die Sprachsuche hat sich von einem experimentellen Smartphone-Feature zu einem weiteren Kanal der Informationssuche entwickelt: smarte Lautsprecher im Büro, Infotainmentsysteme beim Pendeln, Ohrhörer mit Sprachassistent unterwegs. Der Nutzer stellt eine Frage und hört eine Antwort, ohne Trefferliste.

Für Betreiber professioneller WordPress-Plattformen verändert das die Spielregeln: Im Voice-Ökosystem gibt es keine zehn blauen Links, sondern eine kurze Antwort, die ein Assistent vorlesen kann. Dieses Ziel hat konkrete Grenzen, die Google, Apple und Amazon dokumentieren. Dieser Leitfaden trennt, was die Plattformen schriftlich zusagen, von dem, was nur gute redaktionelle Praxis ist.

Lesen Sie auch unseren Leitfaden für WordPress-Entwickler zur technischen Optimierung hochperformanter Unternehmenswebsites.

#Wie KI-Agenten die Sprachsuche verändert haben

Frühe Sprachassistenten beschränkten sich darauf, das erste Suchergebnis vorzulesen. Heute greifen Systeme wie Gemini, Siri und vernetzte Fahrzeugassistenten auf Sprachmodelle zurück:

• Synthese statt Textabruf: Der Assistent liest keine vollständigen Textwände vor. Er extrahiert die kürzeste überprüfbare Antwort.
• Quellenangabe: Im einzigen von Google dokumentierten Fall (Speakable für Nachrichten) nennt der Assistent beim Vorlesen die Quelle und schickt die vollständige Artikel-URL an das Smartphone des Nutzers. Außerhalb dieses Falls verspricht keine Plattform eine gesprochene Nennung Ihrer Marke.
• Ambient Computing: Nutzer recherchieren während des Autofahrens, Kochens oder bei handwerklichen Tätigkeiten. Die Informationen müssen ohne Bildschirm eindeutig und handlungsorientiert sein.

#Warum man keine eigene Google-Assistant-Action mehr bauen kann

Einige Jahre lang war eine Conversational Action der Weg in den Google Assistant: eine Sprach-App mit Intents, Szenen und Webhooks. Dieser Weg ist geschlossen. Die Entwicklerdokumentation von Google hält fest, dass Conversational Actions am 13. Juni 2023 eingestellt wurden. Wer heute noch empfiehlt, eine Voice-Action für den Assistant zu bauen, arbeitet mit veraltetem Stand.

Für eine WordPress-Website bleiben drei Wege: eine Quelle sein, die Suchsysteme crawlen und zitieren können, Auszüge mit Speakable markieren, wo Google es unterstützt, und Inhalte in Formaten veröffentlichen, die ein Assistent direkt abruft, etwa der weiter unten beschriebene Flash-Briefing-Feed für Alexa. Ein eigener REST-Endpunkt “für Sprachassistenten” hat heute keinen dokumentierten Abnehmer. Deshalb haben wir das frühere Codebeispiel dafür aus diesem Beitrag entfernt.

#Was Google mit Speakable tatsächlich zusagt

Die Eigenschaft speakable ist der meistzitierte Baustein in Voice-Search-Leitfäden und zugleich der am häufigsten falsch beschriebene. Die offizielle Seite Speakable (Article, WebPage) structured data ist kurz und eindeutig:

• Beta-Status. Google weist darauf hin, dass sich Anforderungen und Richtlinien ändern können.
• Ein einziger Markt. Laut Dokumentation funktioniert die Eigenschaft für Nutzer in den USA mit Google-Home-Geräten auf Englisch und für Publisher, die auf Englisch veröffentlichen.
• Nachrichten. Der Google Assistant nutzt Speakable, um Anfragen zu aktuellen Nachrichten auf smarten Lautsprechern zu beantworten, und liefert bis zu drei Artikel verschiedener Publikationen.
• Quelle und Weiterleitung. Liest der Assistant einen markierten Abschnitt vor, nennt er die Quelle und schickt die vollständige Artikel-URL über die Google-Assistant-App an das Smartphone.

“Für ein optimales Audioerlebnis empfehlen wir etwa 20 bis 30 Sekunden Inhalt pro Abschnitt mit speakable-Daten, also ungefähr zwei bis drei Sätze.”

Google Search Central, Speakable-Dokumentation (eigene Übersetzung)

Die technischen Richtlinien enthalten Details, die kaum ein Tutorial erwähnt. Markieren Sie keine Ortsmarken (den Ort, an dem eine Meldung entstand), Bildunterschriften oder Quellenvermerke, weil sie im Audio verwirrend klingen. Verwenden Sie cssSelector oder xPath, nie beides in derselben Spezifikation. Und wie bei allen strukturierten Daten garantiert Google nicht, dass die Funktion erscheint.

Die praktische Folge für eine deutschsprachige Website: Speakable erzeugt heute kein dokumentiertes Sprachergebnis für Seiten auf Deutsch oder für Nutzer in Deutschland, Österreich und der Schweiz. Eine Markierung schadet nicht, sie ist aber kein Schalter für “Voice SEO”, und niemand sollte einem Kunden darauf gestützt Sprachergebnisse zusagen. Übertragbar auf andere Märkte und Assistenten ist die redaktionelle Disziplin, die Google verlangt: kurze Zusammenfassungen, eigenständige Sätze, nichts, das ein Bild braucht, um verständlich zu sein.

#Speakable-Schema in WordPress einbinden

Google dokumentiert speakable als strukturierte Daten für Article und WebPage. Die Eigenschaft verweist über CSS-Selektoren (oder XPath) auf Abschnitte, die für die Sprachausgabe in Frage kommen. Die Referenzdefinition steht unter schema.org/SpeakableSpecification.

#Wann sich Speakable lohnt und wann nicht

• Sinnvoll bei englischsprachigen Nachrichtenartikeln oder Leitfäden mit einer kurzen, sachlichen, stabilen Zusammenfassung unter einer eindeutigen ID.
• Wenig sinnvoll, wenn die ganze Seite, lange Blöcke, Vertriebs-CTAs oder Text markiert werden, der sich mit jedem Deployment ändert.
• Auf Markt und Sprache begrenzt: Außerhalb der USA und des Englischen hat das Markup keine dokumentierte Wirkung.
• Ergänzung, kein Ersatz: Die Qualität der Antwort unter der H2 zählt mehr als das JSON-LD allein.

#JSON-LD-Beispiel für SpeakableSpecification

Das Markup wird in das bestehende Article- oder TechArticle-Schema eingebettet und verweist über CSS-Selektoren auf eindeutige Container im DOM:

<!-- Beispiel: Schema.org Speakable JSON-LD für WordPress -->
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "TechArticle",
  "headline": "Voice Search Optimierung: Schema für den Vorsprung in 2026",
  "url": "https://wppoland.com/de/voice-search-seo-wordpress-guide-2026-de/",
  "inLanguage": "de-DE",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [
      "#introduction",
      ".voice-direct-answer"
    ]
  },
  "author": {
    "@type": "Organization",
    "name": "WPPoland",
    "url": "https://wppoland.com"
  }
}
</script>

#Speakable-Markup per functions.php ohne Plugin einbinden

Um die Ladezeiten nicht durch zusätzliche Plugins zu belasten, lässt sich die Speakable-Auszeichnung schlank über die functions.php oder ein projektspezifisches Must-Use-Plugin einbinden:

add_action('wp_head', 'wppoland_add_speakable_schema_de');

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

    $post_id = get_the_ID();
    $permalink = get_permalink($post_id);
    $title = get_the_title($post_id);

    $schema = [
        '@context'    => 'https://schema.org',
        '@type'       => 'Article',
        'headline'    => esc_html($title),
        'url'         => esc_url($permalink),
        'inLanguage'  => 'de-DE',
        'speakable'   => [
            '@type'       => 'SpeakableSpecification',
            'cssSelector' => ['#introduction', '.voice-summary-block'],
        ],
    ];

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

Praktische Hinweise: Prüfen Sie, dass die Selektoren im gerenderten HTML existieren (Gutenberg, synchronisierte Vorlagen oder Theme), und escapen Sie jede Ausgabe. Der Google-Test für Rich-Suchergebnisse führt Speakable nicht unter den gemeldeten Typen, daher prüfen Sie die Syntax im Schema Markup Validator. Gibt ein SEO-Plugin bereits Article aus, ergänzen Sie speakable in diesem Knoten, statt ein zweites Article auf derselben Seite auszugeben.

#Welche Suchintentionen hinter Sprachanfragen stehen

Der entscheidende Unterschied ist nicht das Mikrofon, sondern die Absicht. Wer “wordpress redis cache” tippt, sondiert. Wer sagt “wie richte ich Redis Object Cache in WordPress ein, ohne Sessions zwischen Shops zu teilen”, will jetzt eine Anleitung.

Drei gesprochene Muster verlangen unterschiedliche redaktionelle Behandlung:

1. Prozedural (“wie…”, “welche Schritte…”): ein kurzer Antwortblock und sichtbare nummerierte Schritte.
2. Definition oder Vergleich (“was ist…”, “was ist der Unterschied zwischen…”): ein sachlicher Absatz mit zwei oder drei Sätzen, ohne Vorrede.
3. Lokal oder operativ (“in meiner Nähe”, “in Hamburg”, “heute”): hängt an konsistenten NAP-Daten und LocalBusiness-Schema, nicht an einem langen Artikel.

Filtern Sie in der Google Search Console Anfragen, die mit “wie”, “was”, “welche”, “wo” und “wann” beginnen. Diese Reihen kommen dem gesprochenen Wortschatz näher als eine Liste von Zwei-Wort-Keywords. Danach formulieren Sie H2 und H3 als echte Frage und setzen die nützliche Antwort in den ersten Satz.

#Was sich 2023 bei FAQ- und HowTo-Rich-Results geändert hat

FAQ und Anleitungen bleiben im Seitentext natürliche Formate für gesprochene Fragen, aber die visuellen Ergebnisse von Google haben sich geändert. Am 8. August 2023 kündigte Google im Search-Central-Blog Änderungen an HowTo- und FAQ-Rich-Results an:

• FAQ: Rich Results aus FAQPage erscheinen nur noch für bekannte, maßgebliche Websites von Behörden und aus dem Gesundheitsbereich. Für alle anderen Websites werden sie nicht mehr regelmäßig angezeigt.
• HowTo: zunächst auf Desktop beschränkt; seit dem 13. September 2023 zeigt Google sie auch dort nicht mehr an und hat den Typ als eingestellt erklärt.
• Bestehendes Markup: Laut Google muss es nicht entfernt werden, weil ungenutzte strukturierte Daten keine Probleme verursachen, aber auch keine sichtbare Wirkung haben.

Das sichere Kriterium ist damit redaktionell: Fragen und Schritte gehören in den Seitentext, weil sie dem Leser und dem textextrahierenden Assistenten antworten, nicht weil eine visuelle Erweiterung zu erwarten wäre. Wer FAQ- oder HowTo-JSON-LD behält, muss den sichtbaren Inhalt exakt abbilden.

• Häufige Fragen: eine H2 oder H3 mit der genauen Frage und einer kurzen Antwort im DOM.
• Anleitungen: sichtbare nummerierte Schritte mit realistischen Werkzeugen und Zeitangaben.
• Vermeiden: FAQs nur für das Markup, leere Antworten oder Anleitungen mit einem einzigen generischen Schritt.

#Wie strukturiert man Inhalte für die Sprachsuche

Sprachmodelle bevorzugen klare Satzstrukturen. Wenn die Kernantwort in ausschweifenden Einleitungen untergeht, übergeht das System den Inhalt zugunsten prägnanterer Quellen. Dasselbe Muster bedient die Featured Snippets von Google, die zuerst den Auszug und dann den Link zeigen. Ein Markup, mit dem man ein Featured Snippet anfordert, gibt es nicht; Google wählt den Auszug aus dem Text.

#1. Überschriften als konkrete W-Fragen formulieren

Gestalten Sie H2- und H3-Überschriften so, wie deutschsprachige Nutzer ihre Fragen mündlich formulieren:

• “Wie bereinigt man verwaiste Transients in der WordPress-Datenbank”
• “Was ist der Unterschied zwischen Redis und Memcached bei WooCommerce”

#2. Antwortblock mit 40 bis 60 Wörtern unter der Frage

Platzieren Sie unmittelbar unter der Frage einen kompakten Antwortabsatz. Dieser Block muss syntaktisch eigenständig und frei von Relativierungen sein:

• Empfohlenes Format: “Abgelaufene Transients in WordPress lassen sich über den WP-CLI-Befehl ‘wp transient delete —expired’ entfernen. Der Befehl löscht nur abgelaufene Cache-Einträge in der Datenbank und lässt dauerhafte Optionen und Beitragsdaten unberührt.”
• Zu vermeidendes Format: “In diesem Kapitel beschäftigen wir uns ausführlich mit der spannenden Frage, warum viele Administratoren Probleme mit wachsenden Datenbanken haben.”

#3. Technische Details mit Tabellen und Code ergänzen

Unterhalb der Kurzantwort folgen Erläuterungen, Tabellen und Code. Im Speakable-Fall schickt Google die Artikel-URL ans Smartphone; in anderen Fällen öffnet der Nutzer die Seite später. In beiden Fällen muss die Seite die fachliche Tiefe liefern.

#Wie formuliert man deutsche Texte für die Sprachausgabe

Die deutsche Grammatik stellt Sprachsynthese-Systeme vor spezifische Herausforderungen:

• Komposita klar strukturieren: Vermeiden Sie unübersichtliche Bandwurmwörter in den vorlesbaren Absätzen.
• Abkürzungen ausschreiben: Schreiben Sie im Antwortabsatz “zum Beispiel” statt “z. B.” und “unter anderem” statt “u. a.”, damit die Sprachausgabe nicht buchstabiert.
• Trennbare Verben eindeutig platzieren: Halten Sie Satzklammern kurz, damit die Kernaussage nicht erst am Satzende ankommt.

#Wie man steuert, was Assistenten zitieren dürfen

Zur Optimierung gehört auch die Entscheidung, was nicht vorgelesen werden soll. Die Google-Dokumentation zu Robots-Meta-Tag und data-nosnippet beschreibt drei Steuerungen, die auch Sprach- und KI-Oberflächen erreichen:

• nosnippet verhindert jedes Text-Snippet der Seite. Laut Google gilt das für Websuche, Bilder, Discover, AI Overviews und AI Mode, und der Inhalt dient nicht mehr als direkte Eingabe für AI Overviews und AI Mode.
• max-snippet:[Zahl] begrenzt das Snippet auf eine Zeichenzahl. Die Liste der betroffenen Oberflächen nennt auch den Assistant, und die Grenze beschränkt zugleich die direkte Eingabe für AI Overviews und AI Mode.
• data-nosnippet ist ein HTML-Attribut für span-, div- und section-Elemente, das einzelne Seitenteile von Snippets ausschließt.

Auf einer WordPress-Website löst das reale Fälle. Eine wöchentlich wechselnde Konditionstabelle, ein Rechtshinweis oder ein absichtlich falsches Beispiel (“so nicht”) kann in data-nosnippet stehen, während der Antwortabsatz verfügbar bleibt. Achten Sie auf die Rangfolge: Stehen nosnippet und data-nosnippet auf derselben Seite, gewinnt nosnippet, und es gibt gar kein Snippet. Ein sehr niedriges max-snippet hält die Seite außerdem aus Featured Snippets heraus.

#Wie Siri Webinhalte findet

Apple veröffentlicht kein Gegenstück zu Speakable. Dokumentiert ist der Crawler. Laut der Support-Seite About Applebot speisen die vom Applebot gesammelten Daten mehrere Apple-Funktionen, darunter Siri, Spotlight und Safari. Für WordPress ergeben sich vier überprüfbare Regeln:

1. Applebot nicht versehentlich sperren. Applebot befolgt robots.txt-Anweisungen, die an ihn gerichtet sind. Enthält die Datei keine Regeln für Applebot, aber Regeln für Googlebot, folgt Applebot den Googlebot-Regeln. Eine nur für Google gedachte Sperre kann die Website aus Siri nehmen.
2. Crawl-delay wirkt beim Applebot nicht. Lastbegrenzung gehört auf den Server oder ins CDN.
3. Applebot-Extended ist kein Crawler. Er legt nur fest, ob vom Applebot gesammelte Inhalte für das Training von Apples Foundation Models genutzt werden dürfen. Seiten, die Applebot-Extended ausschließen, können weiterhin in Suchergebnissen erscheinen, und Apple berücksichtigt diese Regeln nach eigener Aussage nicht im Ranking.
4. Ein Trainings-Opt-out entfernt Sie nicht aus Siri. Selbst mit gesperrtem Applebot-Extended und nosnippet bleibt der Inhalt laut Apple über Spotlight, Siri und Safari auffindbar.

Prüfen Sie nach jeder Änderung über ein SEO-Plugin die tatsächlich ausgelieferte robots.txt, nicht nur die Einstellungsseite.

#Wie man ein Alexa Flash Briefing aus WordPress veröffentlicht

Amazon bietet einen Weg, der nicht von Rankings abhängt: die Flash Briefing Skill API. Laut Amazon-Dokumentation liefert ein Flash Briefing Alexa-Kunden Schlagzeilen und andere kurze Inhalte als Text oder Audio, aus einem HTTPS-Feed im RSS- oder JSON-Format. Aktualisierungen sind bis zu alle 15 Minuten möglich und mindestens einmal täglich Pflicht.

Die Feed-Referenz legt Regeln fest, die ein WordPress-Publisher einhalten muss:

• Text per Sprachsynthese: Das Feld mainText (in RSS description) ist der Text, den Alexa vorliest.
• Unter 4.500 Zeichen pro Eintrag: Längerer Text wird am nächsten Satzende unterhalb der Grenze abgeschnitten.
• Nur reiner Text: kein SSML, HTML oder XML. Beitragsinhalt muss durch wp_strip_all_tags().
• Satzzeichen steuern Pausen: Kommas und Semikolons erzeugen kurze Pausen, Punkte, Frage- und Ausrufezeichen längere. Amazon rät von nicht standardisierter Zeichensetzung ab.
• Aktualität: Alexa ignoriert Einträge, die älter als 7 Tage sind; die Reihenfolge läuft vom neuesten zum ältesten.
• “Read More”-Link: redirectionUrl führt in der Alexa-App zum Artikel.

Ein minimaler REST-Endpunkt, der den JSON-Feed aus aktuellen Beiträgen erzeugt:

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);
}

Der manuelle Textauszug jedes Beitrags wird zum gesprochenen Text. Schreiben Sie ihn deshalb wie einen Speakable-Abschnitt: zwei bis drei eigenständige Sätze, ausgeschriebene Abkürzungen.

#Welche TTFB braucht eine Website für Sprachsuche

Eine Audio-Interaktion verträgt weniger Wartezeit als ein Browser mit Ladeanzeige, und eine langsame Seite bremst auch den Nutzer, der die URL nach der Antwort auf dem Smartphone öffnet. Keine Sprachplattform veröffentlicht eine TTFB-Grenze für die Quellenauswahl. Nutzen Sie stattdessen den öffentlichen Richtwert: Laut dem web.dev-Artikel zu Time to First Byte gilt als grobe Orientierung eine TTFB von 0,8 Sekunden oder weniger als gut, Werte über 1,8 Sekunden als schlecht. Derselbe Artikel betont, dass TTFB keine Core-Web-Vitals-Metrik ist.

1. Edge Caching mit Knoten im DACH-Raum: Liefern Sie stabile öffentliche HTML-Seiten über ein CDN aus; die WordPress-Performance-Dokumentation beschreibt Caching und Object Cache.
2. Object Cache (Redis oder Memcached) für wiederholte Abfragen; WooCommerce-Sessions isolieren.
3. Schlanker DOM: Ein geringer HTML-Footprint erleichtert KI-Crawlern das Parsen und Extrahieren relevanter Knoten.
4. Messung: WebPageTest oder CrUX-Daten für die TTFB je Region, verglichen mit Wettbewerbern, die in Ihrer Nische bereits als Antwort auftauchen.

#Wie optimiert man die lokale Sprachsuche für B2B-Unternehmen

Ein großer Teil der gesprochenen Anfragen betrifft Standorte und Erreichbarkeit (“Wo finde ich erfahrene WordPress-Entwickler in Hamburg”, “Öffnungszeiten für technischen Notfall-Support in München”):

• Halten Sie Name, Adresse und Telefonnummer (NAP) auf der Website, im Google Unternehmensprofil, in Apple Maps und in Branchenverzeichnissen konsistent.
• Verknüpfen Sie Standortseiten mit LocalBusiness-Schema einschließlich präziser Geokoordinaten und Öffnungszeiten für Werktage und Feiertage.
• Beschreiben Sie Parkmöglichkeiten und ÖPNV-Anbindungen im Fließtext, damit Navigationsassistenten konkrete Zielhinweise geben können, ohne Filialen zu erfinden.

#Wie misst man den Erfolg bei Voice Search und AEO

Die Sprachsuche erscheint in der Analyse fast nie als sauberer Kanal. Brauchbare Hilfsgrößen:

• Answer Engine Monitoring: Testen Sie die Kernfragen Ihres Fachgebiets regelmäßig in Systemen wie Perplexity, Gemini und ChatGPT Search und dokumentieren Sie Markennennungen.
• Google Search Console: Featured Snippets und People Also Ask für Ihre Zielfragen sowie als Frage formulierte Suchanfragen im Leistungsbericht.
• Abrufe des Flash-Briefing-Feeds in den Server-Logs, falls Sie einen veröffentlichen.
• Markensuchvolumen: Korrelieren Sie Anstiege mit Kampagnendaten, ohne eine Ursache zu behaupten, die Sie nicht belegen können.

#Zusammenfassung

Direkte Antworten, ehrliches Schema (Speakable nur dort, wo Google es unterstützt, FAQ und Anleitungen deckungsgleich mit dem DOM), Snippet-Steuerung und gemessene TTFB bereiten eine WordPress-Installation darauf vor, zitiert zu werden, auf dem Bildschirm und im Audio. Beginnen Sie mit wenigen Ankerseiten, prüfen Sie die Selektoren, testen Sie die Zielfragen per Sprache auf einem echten Smartphone und übertragen Sie das Muster erst danach auf den Rest der Website.