Schema.org richtig einrichten: Strukturierte Daten für KI-Sichtbarkeit

Was Schema.org eigentlich ist

Schema.org ist kein Google-Produkt, sondern ein offenes Vokabular, das Google, Microsoft, Yahoo und Yandex gemeinsam pflegen. Es definiert Typen wie Product, Organization, Article, Event oder LocalBusiness und dazu passende Eigenschaften wie name, price oder openingHours. Die Idee ist simpel: Statt dass eine Maschine aus deinem Text raten muss, ob 49 Euro ein Preis, eine Hausnummer oder eine Telefonvorwahl ist, sagst du es ihr direkt und eindeutig.

Der wichtige Unterschied: Menschen lesen Bedeutung aus dem Kontext, Maschinen brauchen Struktur. Ein Steuerberater schreibt Erstberatung kostenlos in einen Absatz, und ein Mensch versteht das sofort. Ein Crawler sieht nur Zeichen. Mit strukturierten Daten übersetzt du deine Seiteninhalte in ein Format, das jede Maschine gleich interpretiert, egal ob es eine Suchmaschine, ein Preisvergleich oder ein KI-Assistent ist.

Für KI-Sichtbarkeit ist das entscheidend geworden. Sprachmodelle und Antwortsysteme greifen zunehmend auf strukturierte Signale zurück, um Fakten abzusichern. Wenn dein Firmenname, deine Adresse und dein Angebot maschinenlesbar hinterlegt sind, sinkt das Risiko, dass ein KI-System dich falsch zitiert oder mit einem Wettbewerber verwechselt.

JSON-LD statt Microdata: das richtige Format

Es gibt drei technische Wege, Schema.org auszuzeichnen: Microdata, RDFa und JSON-LD. Microdata und RDFa verweben die Angaben direkt in dein HTML, also in die einzelnen Elemente deiner sichtbaren Seite. Das wird schnell unübersichtlich und bricht, sobald jemand am Layout schraubt. JSON-LD dagegen legst du als separaten Skriptblock ab, getrennt vom sichtbaren Markup. Google empfiehlt ausdrücklich JSON-LD, und es ist heute der Standard.

Der praktische Vorteil von JSON-LD: Du kannst die strukturierten Daten an einer Stelle pflegen, ohne das restliche Template anzufassen. Ein Onlineshop generiert den Product-Block dynamisch aus der Datenbank, ein Verlag den Article-Block aus dem Redaktionssystem. Weil der Skriptblock unabhängig vom Design ist, überlebt er Relaunches und Style-Änderungen deutlich besser als verschachtelte Microdata-Attribute.

Konkret sieht das so aus: ein script-Tag vom Typ application/ld+json im Kopf oder Körper der Seite, darin ein JSON-Objekt mit @context https://schema.org und einem @type. Wichtig ist nur, dass die ausgezeichneten Angaben mit dem übereinstimmen, was der Nutzer tatsächlich auf der Seite sieht. Alles andere gilt als Spam und kann abgestraft werden.

Welche Typen für welche Branche

Fang nicht mit dem seltensten Typ an, sondern mit dem, der zu deinem Kerngeschäft passt. Ein Handwerksbetrieb oder eine Zahnarztpraxis nutzt LocalBusiness mit Adresse, Öffnungszeiten und Telefonnummer. Ein Onlineshop setzt auf Product samt Offer, Preis, Verfügbarkeit und AggregateRating. Ein Magazin oder Blog verwendet Article beziehungsweise BlogPosting mit Autor, Veröffentlichungsdatum und Headline.

Weitere häufige Fälle: Ein Seminaranbieter oder Veranstalter nutzt Event mit Datum, Ort und Ticketpreis. Eine Kanzlei oder Agentur beschreibt ihre Leistungen über Service und die Firma über Organization. Ein Rezepteportal nimmt Recipe mit Zutaten, Zubereitungszeit und Nährwerten. Eine Software-Firma kann SoftwareApplication verwenden. Für jede dieser Vorlagen findest du auf schema.org die vollständige Liste der erlaubten Eigenschaften.

Kombiniere Typen dort, wo es Sinn ergibt. Fast jede Seite profitiert von einem Organization- oder WebSite-Block, der Marke, Logo und Social-Profile bündelt. Häufig gestellte Fragen auf einer Seite kannst du zusätzlich als FAQPage auszeichnen. Übertreib es aber nicht: Nur auszeichnen, was wirklich auf der Seite steht und für den Nutzer relevant ist.

Schritt für Schritt einrichten

Der Ablauf ist überschaubar, wenn du ihn diszipliniert durchziehst. Erst den Seitentyp bestimmen, dann die Pflichtfelder recherchieren, dann den JSON-LD-Block bauen, dann testen, dann live schalten. Überspringe keinen Schritt. Die meisten Fehler entstehen, weil jemand einen Block aus dem Netz kopiert, ohne die eigenen Werte sauber einzusetzen oder zu prüfen.

Pflege die Werte möglichst dynamisch aus deiner Datenquelle. Ein Preis, der im Shop 39 Euro anzeigt, im JSON-LD aber noch 49 Euro trägt, ist schlimmer als gar keine Auszeichnung, weil er Vertrauen zerstört. Automatisierte Befüllung aus dem CMS oder der Warenwirtschaft ist die einzige Methode, die über Hunderte Seiten hinweg konsistent bleibt.

• Seitentyp wählen: Was ist der Hauptinhalt dieser konkreten URL?
• Pflichtfelder klären: Welche Eigenschaften erwartet Google für Rich Results?
• JSON-LD schreiben oder dynamisch generieren, Werte aus der echten Datenquelle ziehen.
• Mit dem Rich Results Test und dem Schema Markup Validator prüfen.
• Live schalten und in der Google Search Console die Berichte beobachten.

Testen und Fehler finden

Ohne Test kein Live-Gang. Zwei Werkzeuge reichen für den Alltag: Der Rich Results Test von Google zeigt dir, ob deine Auszeichnung für erweiterte Suchergebnisse taugt und welche Felder fehlen. Der Schema Markup Validator von Schema.org prüft dagegen die reine syntaktische und semantische Korrektheit, unabhängig davon, ob Google daraus ein Rich Result baut. Nutze beide, sie beantworten verschiedene Fragen.

Achte auf die Unterscheidung zwischen Fehlern und Warnungen. Fehler bedeuten, dass ein Pflichtfeld fehlt oder ein Wert das falsche Format hat, etwa ein Datum, das nicht dem ISO-Standard entspricht. Warnungen betreffen empfohlene, aber nicht zwingende Felder. Fehler musst du beheben, Warnungen solltest du nach Möglichkeit auflösen, weil vollständigere Daten die Chance auf gute Darstellung erhöhen.

Prüfe nach dem Livegang echte URLs, nicht nur eingefügten Code. In der Google Search Console findest du Berichte zu Produkten, FAQ, Bewertungen und mehr, inklusive der Seiten, auf denen Google Probleme erkennt. Das ist deine laufende Kontrolle: Fehler tauchen dort oft erst auf, wenn eine Vorlage über viele Seiten ausgerollt wurde.

Häufige Fehler, die dich Sichtbarkeit kosten

Der teuerste Fehler ist Inkonsistenz zwischen Markup und sichtbarem Inhalt. Wenn du Bewertungen auszeichnest, die auf der Seite nirgends stehen, oder einen Rabattpreis behauptest, der nicht gilt, wertet Google das als Manipulation. Das kann zum Verlust aller Rich Results für die Domain führen. Zeichne ausschließlich aus, was der Nutzer wirklich sieht und was der Wahrheit entspricht.

Zweiter Klassiker: unvollständige Pflichtfelder. Ein Product ohne gültige Offer, ein Event ohne startDate, ein Article ohne Autor. Solche Blöcke werden ignoriert, deine Arbeit war umsonst. Dritter Fehler: veraltete Angaben. Öffnungszeiten, die sich geändert haben, oder ausverkaufte Artikel, die noch als verfügbar markiert sind, senden falsche Signale an Menschen und Maschinen gleichermaßen.

Vierter Punkt: Copy-Paste ohne Anpassung. Immer wieder finden sich Blöcke im Netz, in denen noch die Beispieldaten der Vorlage stehen, fremde Firmennamen, Platzhalter-URLs oder ein falsches @type. Prüfe jeden übernommenen Block Feld für Feld. Und dedupliziere: Mehrere widersprüchliche Organization-Blöcke auf derselben Seite verwirren Crawler mehr, als sie helfen.

Warum das für KI-Antworten zählt

KI-Systeme beantworten Fragen zunehmend, ohne dass der Nutzer je auf deine Seite klickt. Sie ziehen Fakten aus dem Netz und geben sie verdichtet wieder. Ob du in solchen Antworten korrekt vorkommst, hängt davon ab, wie eindeutig deine Fakten hinterlegt sind. Strukturierte Daten sind dabei das verlässlichste Signal, weil sie keine Interpretation erfordern.

Ein Beispiel: Eine Nutzerin fragt einen Assistenten nach einem Steuerberater in ihrer Stadt mit Abendsprechstunde. Hast du deine Öffnungszeiten sauber als LocalBusiness ausgezeichnet, kann das System dich zuverlässig zuordnen. Steht die Info nur im Fließtext einer Unterseite, ist die Chance geringer, dass sie korrekt erkannt und wiedergegeben wird. Struktur schlägt Prosa, wenn es um harte Fakten geht.

Strukturierte Daten sind aber kein Ersatz für gute Inhalte, sondern deren Verstärker. Sie helfen Maschinen, das zu verstehen, was ohnehin auf deiner Seite steht. Wer versucht, mit Markup Substanz vorzutäuschen, fliegt auf. Wer echte, aktuelle Angaben sauber auszeichnet, macht sie für die nächste Generation der Suche und der KI-Assistenten überhaupt erst greifbar.

Schema aktuell halten: Pflege statt Einmal-Setup

Strukturierte Daten sind kein Projekt, das du einmal abschließt. Sie sind ein Versprechen an Suchmaschinen und KI-Systeme: Was im Markup steht, soll auf der Seite stimmen. Sobald sich Öffnungszeiten, Preise, Adressen oder Produktverfügbarkeit ändern, veraltet dein Schema still im Hintergrund – und niemand merkt es, bis eine KI eine falsche Info ausspielt.

Bau dir deshalb feste Kontrollpunkte ein. Wenn deine Daten aus einem CMS oder einem Shop-System stammen, sollte das Schema automatisch mitziehen und nicht von Hand gepflegt werden. Bei statischem Markup lohnt ein Quartalscheck: Stimmen Telefonnummer, URL, Logo-Pfad und Beschreibung noch? Ein einziger toter Link im sameAs-Feld oder ein alter Preis reicht, damit ein System dein Markup als unzuverlässig einstuft.

Praktisch heißt das: Verantwortung festlegen. Wer aktualisiert das Schema, wenn Marketing eine neue Kampagnenseite baut? Ohne klare Zuständigkeit entstehen genau die Widersprüche zwischen sichtbarem Inhalt und Markup, die dich später Sichtbarkeit kosten.

Ein durchgerechnetes Beispiel: von null zur reichen Antwort

Nimm einen kleinen Handwerksbetrieb mit fünf Standorten. Vor dem Setup kennt eine KI nur den Fließtext der Startseite und rät bei jeder Anfrage. Nach dem Einbau von LocalBusiness-Markup pro Standort – mit Name, Adresse, Geo-Koordinaten, Öffnungszeiten und Telefonnummer – hat das System pro Filiale einen sauberen, maschinenlesbaren Datensatz.

Der Effekt ist konkret. Fragt jemand die KI nach dem nächstgelegenen Standort mit Samstagsöffnung, kann sie die openingHours vergleichen und direkt antworten, statt zu passen. Ergänzt du FAQ-Markup mit drei echten Kundenfragen zu Anfahrt, Terminen und Zahlungsarten, tauchen diese Antworten sowohl in Suchergebnissen als auch in KI-Zusammenfassungen auf.

Rechne den Aufwand ehrlich: Der erste Standort kostet dich vielleicht zwei Stunden Einarbeitung, jeder weitere zehn Minuten, weil du die Struktur nur kopierst und die Felder anpasst. Fünf Standorte sind also ein halber Arbeitstag – für eine Datenbasis, die jede KI und jede Suchmaschine dauerhaft nutzt.

Grenzen und Missverständnisse

Schema.org ist kein Ranking-Turbo. Strukturierte Daten sorgen dafür, dass Systeme deine Inhalte korrekt verstehen und darstellen – sie heben eine schwache Seite aber nicht künstlich nach oben. Wer glaubt, mit viel Markup schlechten Content zu kaschieren, verschenkt Zeit. Umgekehrt gilt: Guter Inhalt ohne Markup wird oft trotzdem gefunden, nur eben weniger präzise ausgespielt.

Ein zweites Missverständnis ist die Sache mit den Rich Results. Korrektes Markup ist die Voraussetzung für erweiterte Suchergebnisse, aber keine Garantie. Suchmaschinen entscheiden selbst, ob und wann sie eine reiche Darstellung zeigen. Du lieferst die saubere Datengrundlage – die Ausspielung bleibt außerhalb deiner Kontrolle. Enttäuschung entsteht nur, wenn du das falsch erwartest.

Und markiere niemals Dinge, die auf der Seite nicht sichtbar sind. Bewertungen, die es nicht gibt, Preise, die nicht stimmen, Events, die längst vorbei sind: Solches Markup verstößt gegen die Richtlinien und kann zu manuellen Abstrafungen führen. Die Regel ist einfach – dein Schema beschreibt nur, was Menschen auf der Seite tatsächlich sehen.

• Kein Ranking-Booster, sondern Verständnishilfe für Maschinen
• Rich Results sind möglich, aber nie garantiert
• Nur markieren, was auf der Seite sichtbar ist
• Falsche Bewertungen oder Preise riskieren Abstrafungen