Strukturierte Daten für KI und GEO: Was wirklich sinnvoll ist.

Kurz erklärt

Strukturierte Daten sind maschinenlesbare Angaben nach einem gemeinsamen Vokabular wie Schema.org. Für GEO sind vor allem korrekte Organization- oder LocalBusiness-Daten, Article-Markup, Breadcrumbs und passende Seitentypen hilfreich. Das JSON-LD muss den sichtbaren Inhalt wahrheitsgemäß abbilden, auf kanonische URLs zeigen und technisch validiert werden. Mehr Markup ist nicht automatisch besser und garantiert keine Nennung in KI-Antworten.

Was strukturierte Daten leisten – und was nicht

Strukturierte Daten beschreiben Entitäten und Beziehungen in einem standardisierten Format. Statt nur den sichtbaren Text Webstatt, eine URL und ein Logo unabhängig voneinander zu lesen, kann ein System erkennen, dass diese Angaben zu derselben Organisation gehören. JSON-LD ist dafür im Web besonders verbreitet, weil das Markup getrennt vom sichtbaren HTML eingebunden werden kann.

Google verwendet unterstützte strukturierte Daten unter bestimmten Bedingungen für erweiterte Suchdarstellungen und zum besseren Verständnis von Seiten. Andere Systeme können Schema.org-Angaben ebenfalls auswerten, veröffentlichen aber nicht zwingend, welche Typen und Eigenschaften sie wie gewichten. Daraus folgt: Korrektes Markup ist eine robuste technische Grundlage, aber kein belegter universeller GEO-Rankingfaktor.

Jede ausgezeichnete Information muss zur Seite und zum realen Unternehmen passen. Unsichtbare Keyword-Listen, erfundene Bewertungen oder falsche Standorte bleiben auch in syntaktisch perfektem JSON-LD irreführend.

Organization für Marke und Unternehmen

Organization beschreibt die Organisation hinter einer Website oder Marke. Google empfiehlt die Angaben auf der Startseite oder einer zentralen Unternehmensseite. Sinnvolle Eigenschaften sind Name, alternative Bezeichnung, kanonische URL, Logo, Beschreibung, Kontaktinformationen, Anschrift und offizielle Profile. Es müssen nur Angaben verwendet werden, die tatsächlich zutreffen.

Wenn Produktmarke und rechtlicher Anbieter unterschiedlich heißen, kann die Beziehung transparent modelliert und vor allem sichtbar erklärt werden. Das Impressum nennt den Vertragspartner, während die Marke als Produkt geführt wird. Unklare oder gegensätzliche Bezeichnungen ohne Erklärung erschweren Nutzern und Systemen die Zuordnung.

`sameAs` verbindet offizielle Profile, nicht beliebige Seiten, auf denen der Name vorkommt. Logo-URLs müssen öffentlich abrufbar und dauerhaft sein. Relative oder veraltete URLs sowie ein Logo auf der alten Domain sollten nach einem Domainwechsel aktualisiert werden.

• name und gegebenenfalls alternateName
• url und logo auf der kanonischen HTTPS-Domain
• description mit realer Positionierung
• address und contactPoint, wenn öffentlich vorhanden
• sameAs nur für eindeutig zugehörige offizielle Profile

LocalBusiness für reale lokale Unternehmen

LocalBusiness ist ein Untertyp von Organization für Unternehmen mit lokaler Präsenz. Verwende möglichst einen spezifischen Untertyp, wenn er das reale Geschäft korrekt beschreibt. Zu den wichtigen Angaben gehören Name, Adresse, URL, Telefonnummer, Öffnungszeiten, Bild und gegebenenfalls Geo-Koordinaten.

Bei mehreren echten Niederlassungen sollte jede Standortseite ihre eigenen Daten erhalten. Einzugsgebiete sind nicht dasselbe wie Geschäftsadressen. Erzeuge keine LocalBusiness-Objekte für Städte, in denen lediglich Leistungen angeboten werden, aber kein Standort besteht.

Sichtbarer Inhalt und Markup müssen übereinstimmen. Wenn Öffnungszeiten nur im JSON-LD aktualisiert werden, die Kontaktseite aber alte Zeiten zeigt, entsteht kein Qualitätsgewinn. Ein geregelter Pflegeprozess ist wichtiger als die einmalige Implementierung.

• Passenden spezifischen LocalBusiness-Untertyp wählen
• Pro realem Standort eine eindeutige Seite pflegen
• Adresse, Telefon und Öffnungszeiten sichtbar anzeigen
• Einzugsgebiete nicht als Niederlassungen ausgeben
• Rich Results Test und URL-Prüfung nach Deployment verwenden

Article, Breadcrumb und weitere Seitentypen

Ratgeber und redaktionelle Inhalte können als Article oder passender Untertyp beschrieben werden. Headline, Beschreibung, Veröffentlichungs- und Änderungsdatum, Autor und Herausgeber sollten sichtbar nachvollziehbar sein. Ein aktualisiertes Datum wird nicht automatisiert geändert, wenn der Inhalt unverändert blieb.

BreadcrumbList bildet die sichtbare oder logische Navigationshierarchie ab und unterstützt die Einordnung innerhalb der Website. WebPage, AboutPage, ContactPage, Product oder Service können je nach tatsächlicher Seite sinnvoll sein. Die Auswahl richtet sich nach dem Hauptzweck, nicht nach der Anzahl möglicher Eigenschaften.

FAQPage darf nur Fragen und Antworten enthalten, die Nutzer auf der Seite sehen können. Google zeigt FAQ-Erweiterungen inzwischen nur eingeschränkt an. Das Markup kann dennoch die Struktur beschreiben, darf aber nicht als Versprechen für ein Rich Result oder eine KI-Zitation verkauft werden.

• Article für redaktionelle Leitfäden mit echten Datumsangaben
• BreadcrumbList für die nachvollziehbare Seitenhierarchie
• WebPage-Untertypen passend zum Hauptzweck einsetzen
• Product oder Service nur bei tatsächlich beschriebenem Angebot
• FAQ ausschließlich für sichtbare, hilfreiche Antworten

JSON-LD technisch sauber implementieren

JSON-LD wird in einem Script-Element mit dem Typ application/ld+json eingebunden. Jede Entität kann eine stabile `@id` erhalten, beispielsweise die kanonische Unternehmens-URL mit einem Fragment. Verweise zwischen Website, Organisation, Artikel und Breadcrumbs können dadurch eindeutiger werden.

URLs sind absolut und verwenden die kanonische Domain. Sonderzeichen werden korrekt serialisiert. Daten dürfen serverseitig oder clientseitig erzeugt werden; bei dynamischen Anwendungen muss jedoch geprüft werden, ob Crawler die endgültige Ausgabe zuverlässig erhalten. Vorgerenderte öffentliche Inhalte reduzieren diese Unsicherheit.

Vermeide mehrere widersprüchliche Plugins, die parallel Organization-Objekte mit unterschiedlichen Namen oder Logos erzeugen. Lege eine verantwortliche Quelle für Stammdaten fest und kontrolliere die gerenderte Seite, nicht nur das Eingabefeld im CMS.

Strukturierte Daten validieren und abnehmen

Nutze den Rich Results Test für von Google unterstützte Darstellungen und den Schema.org Validator für allgemeine Syntax. Die Search Console zeigt später erkannte strukturierte Daten und mögliche Probleme. Kein Werkzeug bestätigt jedoch automatisch, dass eine Unternehmensbehauptung inhaltlich wahr ist.

Zur fachlichen Abnahme gehört deshalb ein Vergleich mit der sichtbaren Seite: Stimmen Name, URL, Logo, Adresse, Telefon, Preis, Autor und Datum? Sind referenzierte Bilder erreichbar? Verweist die Canonical-URL auf dieselbe Domain? Wird ein Standort ausgezeichnet, der tatsächlich existiert?

Nach größeren Domain-, Marken- oder CMS-Änderungen wird erneut geprüft. Automatisierte Tests können sicherstellen, dass Canonicals, Pflichtfelder und JSON-Syntax nicht unbemerkt verschwinden.

• JSON-Syntax und Schema.org-Typen prüfen
• Google-spezifische Anforderungen separat validieren
• Markup mit dem sichtbaren Inhalt vergleichen
• Alle URLs und Bilder live abrufen
• Nach Deployments und Stammdatenänderungen erneut testen

Umsetzungsbriefing für Website-Dienstleister

Definiere zuerst eine zentrale Datenquelle für Name, Domain, Logo und Kontakt. Implementiere auf der Start- oder Unternehmensseite ein Organization-Objekt und bei realen lokalen Standorten passende LocalBusiness-Objekte. Artikel erhalten Article und BreadcrumbList. Jede URL verwendet die kanonische Domain.

Das Abnahmekriterium lautet nicht Schema eingebaut, sondern: keine kritischen Syntaxfehler, keine widersprüchlichen Entitäten, alle Eigenschaften sichtbar oder sachlich nachvollziehbar, alle URLs erreichbar und Ausgabe im finalen HTML vorhanden. Dokumentiere, welches Template welchen Typ erzeugt.

Ergänze Regressionstests für Canonical, Logo-URL, Veröffentlichungsdaten und die wichtigsten Schema-Typen. So bleibt die Implementierung auch bei neuen Seiten oder einem Domainwechsel konsistent.

Häufige Fragen zu GEO

Verbessert Schema.org automatisch die KI-Sichtbarkeit?

Nein. Strukturierte Daten können Informationen eindeutiger machen, garantieren aber keine Nennung, Empfehlung oder besondere Darstellung.

Welches Format sollte ich verwenden?

JSON-LD ist weit verbreitet und wird von Google für strukturierte Daten empfohlen. Entscheidend bleiben korrekte Typen und wahrheitsgemäße Angaben.

Braucht jede Seite Organization-Markup?

Google empfiehlt Organization-Informationen auf der Startseite oder einer zentralen Unternehmensseite. Eine identische Wiederholung auf jeder Seite ist nicht erforderlich.

Darf ich Bewertungen meines eigenen Unternehmens auszeichnen?

Bewertungs-Markup unterliegt genauen Richtlinien. Selbstdienliche oder erfundene Bewertungsangaben sind problematisch und sollten nicht als neutraler Beleg dargestellt werden.