Strukturierte Daten per Plugin oder im Code: warum der Unterschied erst bei KI-Antworten sichtbar wird

Die Frage «Plugin oder im Code?» wird meistens als Glaubensfrage geführt, und in dieser Form ist sie nicht zu beantworten. Ein aktuelles SEO-Plugin gibt heute ein sauber verschachteltes JSON-LD aus, das jeden Validator besteht. Ein handgeschriebener Block kann dieselbe Prüfung bestehen und trotzdem falsch sein. Die Ausgabe allein trennt die beiden Wege nicht.

Der Unterschied liegt eine Ebene tiefer, und er ist organisatorisch, nicht technisch: Wie viele voneinander unabhängige Stellen dürfen dieselbe Aussage über dein Unternehmen schreiben, und wer entscheidet im Konfliktfall? Diese Frage entscheidet, ob dein Markup nach zwei Jahren Betrieb noch stimmt. Und sie wird ausgerechnet dort sichtbar, wo man sie am wenigsten erwartet: in einer KI-Antwort, die deine Adresse falsch nennt oder dich gar nicht erwähnt.

Was ein Plugin und was Code beim Markup tatsächlich tun

Beide Wege erzeugen am Ende denselben Artefakttyp: einen JSON-LD-Block im Kopfbereich der ausgelieferten HTML-Seite. Ein Plugin liest dafür Werte aus Eingabefeldern und Datenbanktabellen, eine Code-Lösung liest sie aus einem Modul oder aus dem Datensatz, aus dem auch der sichtbare Text gerendert wird. Für die Suchmaschine ist das Ergebnis ununterscheidbar.

Ein gutes Beispiel für saubere Plugin-Architektur liefert Yoast. Die Dokumentation beschreibt den Ansatz, keinen verschachtelten Baum zu bauen, sondern für jede Entität einen eigenen, gleichrangigen Knoten in einem einzigen @graph auszugeben. Standardmässig sind das drei Knoten pro Seite — Organization (oder Person), WebSite und WebPage — ergänzt um kontextabhängige Knoten wie Article, Product, BreadcrumbList oder den Autor. Die Knoten verweisen über @id aufeinander, statt sich ineinander zu verschachteln. Das ist genau das Modell, das man auch von Hand bauen würde.

Auch die Gegenrichtung stimmt: Handgeschriebenes Markup ist nicht automatisch besser. Wer einen JSON-LD-Block als statischen Textbaustein ins Template kopiert, hat dieselbe Doppelpflege wie ein Plugin-Feld, nur ohne Oberfläche. Entscheidend ist nicht, wo der Code liegt, sondern woher die Werte kommen.

Warum mehrere Schreiber auf denselben Kopfbereich das Kernproblem sind

Das Kernproblem entsteht nicht durch ein Plugin, sondern durch das zweite, dritte und vierte. In einem gewachsenen Setup schreiben typischerweise das SEO-Plugin, das Theme, ein Bewertungs- oder Buchungs-Plugin und manchmal noch ein Page Builder jeweils eigenes JSON-LD in dieselbe Seite — ohne voneinander zu wissen und ohne eine Instanz, die entscheidet, welche Aussage gilt.

Das ist keine Unterstellung von aussen, sondern in der Herstellerdokumentation beschrieben. Yoast benennt ausdrücklich Szenarien, in denen Plugins, Themes oder Systeme von Dritten zu einem «aufgetrennten» Graphen, zu doppelten beziehungsweise vermischten Eigenschaften oder zu geteilten ID-Räumen führen, und empfiehlt als Lösung, das eigene Framework zu übernehmen und dessen Programmierschnittstelle zu nutzen, statt parallel auszugeben. Übersetzt heisst das: Die Plugin-Welt hat für dieses Problem eine Antwort, aber sie funktioniert nur, wenn jemand sie aktiv anwendet und die konkurrierenden Ausgaben abschaltet.

Genau dieses «jemand wendet sie aktiv an» ist der Unterschied zur Code-Variante. Dort gibt es keine zweite Ausgabe, die man vergessen könnte, weil es nur eine Funktion gibt, die den Block erzeugt. Der Vorteil ist keine bessere Technik, sondern eine Struktur, in der der Fehler gar nicht erst entstehen kann.

Was bei einer Kollision im ID-Raum passiert

Eine @id-Kollision entsteht, wenn zwei Blöcke denselben Bezeichner für unterschiedliche Inhalte vergeben, und sie ist deshalb tückisch, weil kein Validator sie meldet. Beide Blöcke sind für sich gültig. Erst das verarbeitende System muss entscheiden, welcher Knoten mit der Kennung https://example.ch/#organization nun gemeint ist — der mit der Adresse aus dem SEO-Plugin oder der mit der Adresse aus dem Theme.

Es gibt keine verbindliche Regel, die diesen Konflikt auflöst. Je nach Verarbeitung kann ein Teil der Eigenschaften verloren gehen, oder es entsteht eine Entität, die Angaben aus beiden Quellen mischt. Yoast baut seine Kennungen bewusst nach einem eigenen Muster auf, um dem auszuweichen, aber das schützt nur, solange alle Beteiligten dasselbe Muster respektieren.

Praktisch heisst das: Wer prüfen will, ob er ein Konfliktproblem hat, schaut nicht in den Validator, sondern in den Quelltext. Wie viele application/ld+json-Blöcke stehen auf der Seite? Wie viele davon behaupten, dieselbe Organisation zu beschreiben? Kommen dieselben Kennungen mehrfach vor? Drei Fragen, fünf Minuten, und das Ergebnis ist eindeutig. Wer diese Prüfung nicht selbst machen will, findet sie als festen Bestandteil in unserem Website-Audit.

Warum Markup vom sichtbaren Inhalt abdriftet

Drift entsteht immer dann, wenn dieselbe Tatsache an zwei Orten gepflegt wird, und sie ist bei strukturierten Daten besonders folgenreich, weil Google ausdrücklich verlangt, nur auszuzeichnen, was auf der Seite auch sichtbar ist. Die Richtlinien sind an dieser Stelle unmissverständlich: Inhalte, die Leserinnen und Leser nicht sehen, dürfen nicht markiert werden, und irreführendes Markup kann zu einer manuellen Massnahme führen — die zwar das Ranking in der Websuche nicht direkt beeinflusst, aber die Berechtigung für Rich Results kostet.

Wie schnell so etwas passiert, zeigen wir am eigenen Beispiel. In einer früheren Fassung dieser Website behauptete das Organization-Markup auf der Startseite den Standort «8000 Zürich», während Impressum und Footer die tatsächliche Adresse an der Gustav-Maurer-Strasse 23 in 8702 Zollikon nannten. Telefonnummer und E-Mail-Adresse standen in keinem einzigen Schema-Knoten. Niemand hatte etwas falsch gemacht: Der Wert war einmal eingetragen worden, danach hatte sich der sichtbare Teil weiterentwickelt und der Markup-Teil nicht. Behoben haben wir das nicht durch besseres Markup, sondern durch das Entfernen der zweiten Quelle — seither ziehen alle Knoten Name, Adresse und Kontaktdaten aus einem einzigen Modul, und eine Abweichung ist strukturell nicht mehr möglich.

Das ist der eigentliche Vorteil der Code-Variante, und er hat mit Programmierkunst wenig zu tun. Wenn der sichtbare Text und der JSON-LD-Wert aus derselben Variablen kommen, können sie nicht auseinanderlaufen. Wenn sie aus zwei Feldern kommen, laufen sie irgendwann auseinander. Für eine neu gebaute Seite ist das eine Architekturentscheidung, die einmal getroffen wird — wir behandeln sie beim Website erstellen lassen als Teil der Grundeinrichtung, nicht als Zusatzleistung.

Wo der Unterschied in KI-Antworten sichtbar wird

Der Unterschied wird bei KI-Antworten deshalb sichtbar, weil ein Sprachmodell Widersprüche nicht anzeigt, sondern auflöst — und zwar unsichtbar für dich. Eine Suchmaschine zeigt im schlimmsten Fall kein Rich Result. Ein Modell, das aus mehreren Quellen eine Antwort formuliert, muss sich für eine Variante entscheiden: Es nennt eine der beiden Adressen, oder es lässt die Aussage weg, oder es nennt dein Unternehmen gar nicht erst, weil eine widerspruchsfreiere Quelle danebensteht.

Wichtig ist dabei die richtige Erwartung. Strukturierte Daten sind kein Zitations-Hebel, den man ziehen und dann messen kann — die Datenlage dazu haben wir in Schema.org für Dienstleister ausführlich aufgearbeitet, inklusive der kontrollierten Messung, die keinen belastbaren Effekt auf KI-Zitate fand. Der Nutzen liegt eine Stufe früher, bei der Frage, ob dein Unternehmen im Index als eine eindeutige Entität geführt wird oder als zwei halbe. Wie diese Entitätenzuordnung funktioniert, beschreibt unser Beitrag zu Entity SEO und dem Knowledge Graph.

Dazu kommt ein banaler, aber messbarer Faktor: Was das Modell überhaupt zu sehen bekommt, hängt am ausgelieferten HTML. Wie stark dieser Umfang schwanken kann, haben wir an der eigenen Seite gemessen. Nach dem Entfernen einer einzigen Build-Option fiel das ausgelieferte HTML unserer Seite /seo-agentur-zuerich von 517 KB auf 159 KB, die Text-Ratio stieg von 2,45 auf 9,45 Prozent, und die Datenmenge bei internen Klicks sank um 79 Prozent (eigene Messung, August 2026). Das ist eine eigene Messung an der eigenen Seite und kein allgemeiner Benchmark — die Einordnung dazu steht in Text-Ratio und Payload in der KI-Suche.

Die Rechnung: was eine Adressänderung kostet

Der greifbarste Unterschied zwischen den beiden Wegen ist die Zahl der Orte, an denen eine einzige Tatsachenänderung nachgezogen werden muss. Die folgende Aufstellung beschreibt ein Setup, wie wir es in Übernahmeprojekten mehrfach angetroffen haben — sie ist keine Statistik, sondern eine Inventarliste.

Sechs Stellen sind nicht dramatisch, solange man alle sechs kennt. Das Problem ist die fünfte, an die niemand denkt, weil sie in einer Theme-Option steckt, die vor drei Jahren jemand anders gesetzt hat. Genau diese eine vergessene Stelle erzeugt anschliessend den Widerspruch, der bei einer KI-Antwort sichtbar wird.

Wie man beide Wege sauber macht

Beide Wege werden mit denselben vier Regeln sauber, und keine davon setzt eine bestimmte Technik voraus. Erstens: genau ein Verantwortlicher für die Ausgabe. In WordPress heisst das, das SEO-Plugin als alleinige Quelle zu bestimmen und die Schema-Ausgabe von Theme und weiteren Plugins abzuschalten oder über deren Schnittstelle einzuspeisen. Im Code heisst es, eine einzige Funktion zu haben, die den Block erzeugt.

Zweitens: eine einzige Quelle für die Werte. Name, Adresse, Telefonnummer und Öffnungszeiten stehen an einer Stelle, sichtbarer Text und Markup lesen von dort. Drittens: kein Markup ohne sichtbares Gegenstück, weil das die Richtlinie ist und weil ein Widerspruch teurer ist als eine fehlende Auszeichnung. Viertens: eine Prüfung, die jemand tatsächlich macht — Quelltext öffnen, Blöcke zählen, Werte gegen Impressum und Kontaktseite lesen.

Wer diese vier Punkte einhält, braucht keinen Systemwechsel. Wer sie nicht einhalten kann, weil zu viele Erweiterungen mitreden, hat ein Architekturthema, kein SEO-Thema — und sollte es auch so behandeln. Wir gehen solche Fälle in der Regel als technische Bestandsaufnahme an und entscheiden erst danach, ob ein Umbau überhaupt wirtschaftlich ist. Wenn ein Neubau die Antwort ist, ist der Aufbau der Datenquellen einer der Punkte, an denen KI-gestützte Entwicklung tatsächlich Zeit spart, weil das Ableiten von Markup aus vorhandenen Daten reine Fleissarbeit ist.

Fazit

Nicht das Werkzeug entscheidet über die Qualität deiner strukturierten Daten, sondern die Anzahl der Stellen, die dasselbe behaupten dürfen. Ein Plugin, das als einzige Instanz schreibt und seine Werte aus einer einzigen Quelle zieht, liefert dasselbe Ergebnis wie handgeschriebener Code. Ein Code-Block, der eine zweite, handgepflegte Kopie der Firmendaten enthält, driftet genauso ab wie ein vergessenes Theme-Feld.

Der Grund, warum diese eher langweilige Ordnungsfrage gerade wichtiger wird, liegt im Konsummodell der Antwortsysteme. Eine klassische Suchergebnisseite zeigt dir zehn Quellen und überlässt dir die Bewertung. Eine KI-Antwort zeigt dir eine Aussage. Wer widersprüchliche Angaben ausliefert, überlässt die Entscheidung, welche davon stimmt, einem System, das ihn nicht fragen wird.