SpeakableSpecification Schema Markup vertieft: cssSelector, XPath und Sprachassistenten

Die speakable Property von Schema.org ist eine der spezialisiertesten Markup-Eigenschaften überhaupt: Sie teilt Googles Sprachassistenten mit, welche Teile deiner Seite laut vorgelesen werden sollen. Während der Einführungsartikel zur speakable Property die Grundlagen erklärt, geht diese Vertiefung auf die technischen Details ein — insbesondere auf den Unterschied zwischen cssSelector und XPath, auf Googles aktuelle Unterstützung und auf Best Practices für die Praxis.

Was ist SpeakableSpecification genau?

SpeakableSpecification ist ein Schema.org-Typ, der über die speakable Property eines Article-Schemas angegeben wird. Er benennt Abschnitte einer Webseite, die sich besonders gut für die Wiedergabe durch Text-to-Speech eignen — zum Beispiel die Zusammenfassung, den Hauptfakt oder die wichtigste Schlussfolgerung eines Artikels.

Die Spezifikation bietet zwei Selector-Mechanismen:

cssSelector — Selektiert HTML-Elemente per CSS-Selektor (einfacher, weitverbreitet)
xpath — Selektiert Elemente per XPath-Ausdruck (mächtiger, aber komplexer)

Du kannst beide Varianten in einem Markup gleichzeitig verwenden oder dich auf eine konzentrieren.

cssSelector vs. XPath — der technische Vergleich

cssSelector

CSS-Selektoren sind die intuitivere Variante. Webentwickler kennen sie aus CSS-Stylesheets und JavaScript (document.querySelector()). Für SpeakableSpecification gibst du einen oder mehrere CSS-Selektoren an, die die vorlese-würdigen Elemente identifizieren.

Beispiel: Heading-basiert

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Wie funktioniert die Hitzepumpe?",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": ["h1", ".article-summary", "#key-facts"]
  }
}

In diesem Beispiel werden der H1-Heading, ein Element mit der Klasse article-summary und das Element mit der ID key-facts als sprechbar markiert. Der Google Assistant kann dann genau diese Abschnitte vorlesen, wenn jemand nach dem Thema fragt.

Vorteile von cssSelector:

Vertraute Syntax für alle Webentwickler
Einfach mit bestehenden HTML-Klassen und IDs kombinierbar
Gut lesbar und wartbar
Unterstützt alle Standard-CSS-Selektoren (Element, Klasse, ID, Attribut)

Einschränkungen:

Keine Textknoten selektierbar (nur HTML-Elemente)
Keine komplexen Bedingungen (z.B. „das zweite Absatz-Element nach einem H2")
Keine Positionen im Dokumentbaum relativ zu Geschwisterelementen

XPath (xpath Property)

XPath (XML Path Language) ist die mächtigere, aber auch komplexere Alternative. XPath erlaubt die Selektion von Elementen anhand ihrer Position im Dokumentbaum, ihrer Attribute, ihrer Textinhalte oder komplexer Kombinationen davon.

Beispiel: XPath-basiert

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Quartalsbericht Q1 2026",
  "speakable": {
    "@type": "SpeakableSpecification",
    "xpath": [
      "/html/body/article/section[1]/p[1]",
      "//div[@id='zusammenfassung']",
      "//h2[contains(text(),'Fazit')]/following-sibling::p[1]"
    ]
  }
}

Der erste Ausdruck selektiert den ersten Absatz des ersten Abschnitts im Artikel. Der zweite wählt ein Element mit der ID „zusammenfassung". Der dritte ist der mächtigste: Er sucht ein H2-Element, das das Wort „Fazit" enthält, und selektiert dann den unmittelbar folgenden Absatz — etwas, das mit CSS-Selektoren nicht möglich wäre.

Vorteile von XPath:

Kann Textknoten und Textinhalte direkt selektieren
Ermöglicht Selektion basierend auf Geschwister- und Vorfahren-Elementen
Unterstützt Positionen ([1], [last()])
Bedingte Selektion (contains(), starts-with())
Ideal für dynamisch generierte Seiten mit konsistenter Struktur

Einschränkungen:

Steilere Lernkurve für Teams ohne XML-Erfahrung
Fragil bei strukturellen HTML-Änderungen
Schwieriger zu debuggen als CSS-Selektoren

Direkte Gegenüberstellung

Kriterium	cssSelector	xpath
Lernkurve	Niedrig (bekannte Syntax)	Mittel bis hoch
Mächtigkeit	Mittel	Hoch
Textknoten selektieren	Nein	Ja
Relative Selektion	Begrenzt	Vollständig
Robustheit bei HTML-Änderungen	Hoch (bei Klassen/IDs)	Niedrig (bei Pfadselektoren)
Google-Empfehlung	Bevorzugt	Alternativ

Empfehlung: Für die meisten Anwendungsfälle ist cssSelector die richtige Wahl. Nutze XPath nur, wenn du gezielt Inhalte selektieren musst, die sich per CSS nicht eindeutig identifizieren lassen.

Welche Inhaltstypen eignen sich für speakable?

Nicht jeder Seiteninhalt macht als vorlese-würdiger Text Sinn. Sprachassistenten brauchen kurze, klare, für sich allein verständliche Aussagen. Google empfiehlt maximal zwei bis drei kurze Textabschnitte pro Seite.

Gut geeignet:

Kurze Zusammenfassungen oder Abstracts (1–3 Sätze)
Die wichtigste Kernaussage eines Nachrichtenartikels
Antworten auf häufige Fragen (in Kombination mit FAQPage Schema)
Definitionen und Erklärungen
Quantitative Fakten und Datenpunkte
Schlussfolgerungen am Ende eines Analyse-Artikels

Schlecht geeignet:

Navigationselemente und Menüs
Tabellen (werden vorgelesen, klingen aber seltsam)
Bildbeschreibungen oder Alt-Texte
Code-Blöcke und technische Snippets
Werbetexte und Calls-to-Action
Langen Fließtext ohne klaren Kernsatz

Ein häufiger Fehler: Webmaster markieren die gesamte <article>-Sektion als speakable. Das Ergebnis ist, dass Google potentiell 3.000 Wörter als „vorlese-würdig" betrachtet — was für einen Sprachassistenten unbrauchbar ist. Weniger ist hier definitiv mehr.

Googles aktuelle Unterstützung (Stand 2026)

Hier die nüchterne Wahrheit: Google hat die aktive Verwendung von speakable in der Google-Suche und im Google Assistant im Jahr 2023 signifikant eingeschränkt. Die Funktion war ursprünglich für Nachrichtenpublisher gedacht — Seiten, die im Google News-Index sind — und sollte es dem Google Assistant ermöglichen, aktuelle Nachrichten vorzulesen.

Aktueller Status nach Plattform:

Plattform	Speakable-Support	Hinweis
Google Assistant (Smart Speaker)	Eingeschränkt	Nur für Nachrichtenpublisher in Google News
Google Suche (Rich Results)	Kein visueller Rich Result	Kein sichtbarer Effekt in SERPs
Bing / Cortana	Nicht implementiert	Kein bekannter Support
Amazon Alexa	Nicht über Schema.org	Verwendet eigene Alexa Skills API
Apple Siri	Nicht über Schema.org	Verwendet eigene SiriKit-Mechanismen

Das bedeutet: speakable ist aktuell vor allem für Nachrichtenportale relevant, die Google News-akkreditiert sind. Für normale Unternehmenswebsites oder Blogs hat die Property 2026 keinen messbaren Ranking- oder Traffic-Effekt.

Trotzdem gibt es gute Gründe, es zu implementieren:

Zukunftssicherheit: Google hat angekündigt, speakable auf weitere Publisher auszuweiten
Signalwirkung: Es zeigt Google, dass du dir über die Struktur deiner Inhalte Gedanken machst
Qualitätsdisziplin: Wer speakable-würdige Abschnitte definiert, denkt zwangsläufig über Kernaussagen nach

Vollständige JSON-LD-Implementierung mit cssSelector

Hier ein realistisches Beispiel für einen Nachrichtenartikel, das alle relevanten Properties kombiniert. Das Markup gehört in den <head>-Bereich der Seite:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "Deutsche KMU verschenken 40 % ihres Suchpotenzials",
  "description": "Eine Analyse von 500 Unternehmenswebsites zeigt: Fast die Hälfte aller deutschen KMU fehlen grundlegende SEO-Elemente.",
  "image": "https://beispiel.de/images/kmu-seo-analyse.jpg",
  "datePublished": "2026-04-20T09:00:00+02:00",
  "dateModified": "2026-04-20T09:00:00+02:00",
  "author": {
    "@type": "Organization",
    "name": "Shift07",
    "url": "https://shift07.ai"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Shift07",
    "url": "https://shift07.ai",
    "logo": {
      "@type": "ImageObject",
      "url": "https://shift07.ai/assets/logo.png",
      "width": 200,
      "height": 60
    }
  },
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".article-summary", ".key-finding", "h1"]
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://beispiel.de/blog/kmu-seo-analyse.html"
  }
}
</script>

Das dazugehörige HTML muss die selektierten Klassen tatsächlich enthalten:

<h1>Deutsche KMU verschenken 40 % ihres Suchpotenzials</h1>

<p class="article-summary">
  Unsere Analyse von 500 deutschen Unternehmenswebsites zeigt:
  47 % haben keine Meta-Description, 62 % fehlen strukturierte Daten,
  und 38 % sind nicht vollständig mobiloptimiert.
</p>

<!-- Langer Artikeltext ... -->

<div class="key-finding">
  Unternehmen, die diese drei SEO-Grundlagen beheben,
  erzielen im Schnitt 34 % mehr organische Klicks aus Google.
</div>

Vollständige Implementierung mit XPath

Für Seiten mit konsistenter, programmatisch generierter HTML-Struktur kann XPath präziser sein:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "NewsArticle",
  "headline": "Energiepreise 2026: Wie Unternehmen reagieren",
  "speakable": {
    "@type": "SpeakableSpecification",
    "xpath": [
      "/html/body//article//p[@class='lead']",
      "/html/body//section[@id='fazit']/p[1]"
    ]
  },
  "datePublished": "2026-04-20T10:00:00+02:00",
  "author": {
    "@type": "Organization",
    "name": "Beispiel Verlag",
    "url": "https://beispiel-verlag.de"
  }
}
</script>

Der erste XPath-Ausdruck selektiert alle Absätze mit der Klasse lead innerhalb eines article-Elements im Body. Der zweite findet den ersten Absatz innerhalb einer Section mit der ID fazit.

Kombination von cssSelector und xpath

Beide Selektoren können in einem SpeakableSpecification-Objekt kombiniert werden:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Artikelüberschrift",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".zusammenfassung"],
    "xpath": ["/html/body//section[@id='ergebnis']/p[1]"]
  }
}

In diesem Fall versteht der Sprachassistent: „Lese die Elemente mit der Klasse zusammenfassung vor, und zusätzlich den ersten Absatz in der Sektion mit der ID ergebnis."

Debugging: Wie prüfe ich meine SpeakableSpecification?

Da Google aktuell kein visuelles Rich Result für speakable erzeugt, ist das Testing etwas schwieriger als bei anderen Schema-Typen. Diese Methoden helfen:

1. Rich Results Test von Google

Rufe https://search.google.com/test/rich-results auf und gib deine URL ein. Der Test erkennt SpeakableSpecification und zeigt Fehler in der Implementierung an — zum Beispiel wenn der CSS-Selektor auf kein Element der Seite zutrifft.

2. Schema.org-Validator

Unter https://validator.schema.org kannst du deinen JSON-LD-Code direkt einfügen und auf Validierungsfehler prüfen. Der Validator zeigt Warnungen und Fehler nach Schema.org-Spezifikation.

3. Browser-Konsole (cssSelector testen)

Prüfe in der Browser-Konsole, ob dein cssSelector tatsächlich die richtigen Elemente trifft:

// Gibt alle Elemente aus, die dein CSS-Selektor trifft
document.querySelectorAll('.article-summary, .key-finding, h1')

Wenn das Ergebnis leer ist oder falsche Elemente zurückgibt, ist dein Selektor falsch. Passe dann entweder das HTML (füge Klassen hinzu) oder den Selektor an.

4. JSON-LD Structured Data Validator

Unser JSON-LD Structured Data Validator prüft die syntaktische Korrektheit deines Markups und hilft Fehler schnell zu finden.

Integration mit WebPage Schema

Die speakable Property kann nicht nur bei Article, sondern auch bei WebPage und seinen Untertypen verwendet werden. Das ist besonders für Landingpages oder Produktseiten interessant:

{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "SEO-Analyse Tool — shift07.ai",
  "url": "https://shift07.ai",
  "speakable": {
    "@type": "SpeakableSpecification",
    "cssSelector": [".hero-headline", ".value-proposition"]
  }
}

Mehr zur Integration von WebPage-Schema findest du im Artikel zu WebPage und WebSite Schema Markup.

Häufige Fehler bei der Implementierung

Fehler 1: Zu viel Inhalt markiert
Wenn dein cssSelector auf den gesamten Artikel-Container zeigt (article oder .content), markierst du 2.000+ Wörter als vorlese-würdig. Google wird das ignorieren oder schlechte Ergebnisse liefern. Beschränke dich auf 1–3 prägnante Abschnitte mit max. 300 Wörtern gesamt.

Fehler 2: Selektor trifft kein Element
Ein häufiger Bug: Das JSON-LD verweist auf .article-summary, aber das HTML hat die Klasse articleSummary (camelCase). CSS-Selektoren sind case-sensitiv. Immer mit document.querySelectorAll() in der Browserkonsole testen.

Fehler 3: Dynamisch gerenderte Inhalte
Wenn deine Seite JavaScript-Rendering verwendet und der speakable-Inhalt erst nach dem JavaScript-Rendering sichtbar ist, kann Google ihn möglicherweise nicht erfassen. Stelle sicher, dass der markierte Inhalt im Server-seitigen HTML vorhanden ist. Mehr dazu im Artikel über Dynamic Rendering für JavaScript SEO.

Fehler 4: Speakable auf falschen Schema-Typ angewendet
Die speakable Property ist für Article, NewsArticle und WebPage definiert. Sie auf LocalBusiness oder Product anzuwenden ist zwar technisch möglich, widerspricht aber der Schema.org-Spezifikation.

Praktische Empfehlungen für 2026

Angesichts der eingeschränkten aktuellen Unterstützung empfehle ich folgende Strategie:

News-Publisher: Sofort implementieren — das ist euer primärer Use Case, und Google unterstützt es aktiv für Google News-akkreditierte Sites.
Blogs und Informationsseiten: Implementieren als Zukunftsinvestition — es kostet wenig Aufwand und schadet nicht. Verwende cssSelector mit bestehenden semantischen Klassen.
Unternehmenswebsites: Niedrige Priorität — konzentriere dich zunächst auf andere strukturierte Daten mit sofortigem Rich-Result-Effekt, wie FAQPage, HowTo oder LocalBusiness.
E-Commerce: Kein nennenswerter Nutzen aktuell — Product und Review Schema bringen mehr messbaren Traffic.

Fazit

SpeakableSpecification ist eine faszinierende Schema.org-Property mit klarem Zweck: Sie gibt Sprachassistenten Orientierung, welche Textstellen vorgelesen werden sollen. Technisch bietet sie mit cssSelector und xpath zwei Wege, Inhalte zu selektieren — wobei cssSelector für die meisten Anwendungsfälle ausreicht und einfacher zu warten ist.

Die Einschränkung ist real: 2026 profitieren primär Google News-Publisher von dieser Property. Für alle anderen ist die Implementierung ein Zukunftsinvestment — mit dem Nebeneffekt, dass sie dich zwingt, die Kernaussagen deiner Artikel klar zu definieren. Das ist eine Qualitätsdisziplin, die sich immer lohnt.

Validiere deine SpeakableSpecification immer mit dem JSON-LD Validator und teste deine CSS-Selektoren in der Browserkonsole, bevor du das Markup live schaltest.

Strukturierte Daten deiner Website prüfen

shift07.ai analysiert deine Website auf fehlende Schema.org-Properties und zeigt konkrete Verbesserungen — kostenlos.

Kostenlose SEO-Analyse starten →