Die Optimierung strukturierter Daten bedeutet nicht, am Seitenende einen Abschnitt mit JSON-LD-Code hinzuzufügen, und sie ist auch nicht gleichbedeutend damit, dass nach dem Hinzufügen von Markierungen Rich Results erscheinen. Ihr Kern besteht darin, die auf der Seite tatsächlich vorhandenen Produkte, Preise, Lieferarten, Leistungsumfänge und Beziehungen zwischen Entitäten mithilfe des Schema.org-Vokabulars und von durch Suchmaschinen lesbaren Eigenschaften eindeutig zu beschreiben. Für technische Prüfer liegt der Schwerpunkt nicht darauf, möglichst viele Markierungstypen zu verwenden, sondern darauf, ob die Felder korrekt sind, mit den sichtbaren Seiteninhalten übereinstimmen und sich die Daten bei geschäftlichen Änderungen stabil aktualisieren lassen.
E-Commerce-Seiten und Serviceseiten werden häufig mit derselben Vorlage verarbeitet, unterscheiden sich in der Praxis jedoch deutlich. Erstere bilden Entitätsbeziehungen rund um „konkret kaufbare oder angebotspflichtige Produkte“ ab; letztere müssen häufig den Dienstleister, den Leistungsinhalt, das Versorgungsgebiet, den Buchungszugang und die fachliche Kompetenz erläutern. Werden Dienstleistungen zwangsweise als Produkte behandelt oder allen Seiten massenhaft nicht vorhandene Bewertungen, Lagerbestände und Preise hinzugefügt, wirkt dies kurzfristig zwar vollständig, führt langfristig jedoch zu Datenverfälschungen und Wartungsrisiken.
Vor der Umsetzung empfiehlt es sich, zunächst eine einfache Frage zu stellen: Was ist das zentrale überprüfbare Objekt, das Nutzer nach dem Aufruf dieser URL vorfinden? Handelt es sich um ein bestimmtes Modell, eine Spezifikation oder eine unabhängig bestellbare SKU, sollte Product im Mittelpunkt stehen. Geht es auf der Seite um individuelle Beratung, Anlagenwartung, internationales Marketing oder Designlieferungen, ist in der Regel Service der richtige Ausgangspunkt. Seiten, die die Gesamtkompetenz eines Unternehmens vorstellen, eignen sich eher für Organisations- und Website-Informationen und sollten nicht zwanghaft mit Produktfeldern überladen werden.
Eine Seite kann mehrere Entitäten enthalten, jedoch müssen Haupt- und Nebenrollen klar getrennt werden. Auf einer Produktdetailseite ist beispielsweise Product die Hauptentität, Offer beschreibt die Kaufbedingungen, Brand die Markenzugehörigkeit, und Review oder AggregateRating sollten nur verwendet werden, wenn die Seite tatsächlich öffentlich zugängliche und regelkonforme Bewertungsinhalte zeigt. Eine Serviceseite kann die Dienstleistung mit Service beschreiben und über provider mit Organization oder LocalBusiness verknüpfen. Bei klaren Buchungs- oder Angebotsprozessen können sichtbare Kontakt- und Buchungsinformationen ergänzt werden; „Lösung nach Formularübermittlung erhalten“ sollte jedoch nicht als Festpreis getarnt werden.
Bei Seiten mit tatsächlichen Transaktionseigenschaften sollten die grundlegenden Felder zunächst name, description, image, url, sku und brand abdecken. Der Name muss mit der Hauptüberschrift der Seite und der tatsächlichen Produktbezeichnung übereinstimmen. Die Beschreibung sollte nicht den werblichen Text der gesamten Website kopieren, sondern Modell, Material, Verwendungszweck oder wesentliche Spezifikationen zusammenfassen. Die Bild-URL muss crawlbar sein und dem aktuellen Produkt entsprechen, nicht einem allgemeinen Banner. Insbesondere bei Produkten mit mehreren Varianten muss klar sein, ob die Seite das übergeordnete Produkt oder eine konkrete Variante zeigt und ob unterschiedliche Farben, Größen und Verpackungseinheiten jeweils eigene Preise und Lagerbestände haben.
Transaktionsinformationen werden üblicherweise in Offer angegeben. Die gängigen Prioritäten sind: price, priceCurrency, availability, itemCondition, url sowie, falls zutreffend, die Gültigkeitsdauer des Preises. Der Preis muss mit dem Preis übereinstimmen, den Nutzer auf der Seite tatsächlich sehen; die Währung darf nicht auf Vermutungen beruhen. Auch der Lagerstatus sollte aus verfügbaren Daten des Shops, ERP-Systems oder Lagerverwaltungssystems stammen. In B2B-Szenarien mit „Angebot nach Mindestbestellmenge“ muss price nicht zwanghaft ausgefüllt werden, wenn kein öffentlicher und fester Preis vorliegt. Verlässlicher ist es, Spezifikationen, Mindestbestellbedingungen, Lieferumfang und den Anfragezugang klar darzustellen.

Bewertungen gehören zu den am häufigsten falsch verwendeten Feldgruppen. AggregateRating erfordert echte, öffentliche und nachvollziehbare zusammengefasste Bewertungen. Review muss den auf der Seite tatsächlich dargestellten Rezensionen entsprechen; Kunden-E-Mails, mündliche Rückmeldungen des Vertriebs oder Inhalte anderer Plattformen dürfen nicht beliebig zusammengefügt werden. Bei Websites für Branchen wie Papierherstellung, Verpackung und Umweltlösungen sind die Beschaffungsentscheidungszyklen lang. Auf solchen Seiten finden sich häufiger Fallkompetenzen, Zertifizierungsunterlagen, technische Fragen und Antworten sowie Terminvereinbarungen. In diesem Fall sind vollständige Produktattribute und Dokumentenlinks meist wertvoller als zwanghaft hinzugefügte Bewertungen.
Die Schwierigkeit bei Service-Markierungen besteht darin, dass Dienstleistungen leicht zu abstrakt beschrieben werden. „Digitale Marketingdienstleistungen“ oder „Website-Erstellungsdienstleistungen“ reichen nicht für ein präzises Verständnis aus. Name und Beschreibung der Dienstleistung sollten einen für Nutzer beurteilbaren Umfang benennen, beispielsweise den Aufbau mehrsprachiger unabhängiger Websites, die Erstellung von Werbe-Landingpages, technische SEO-Audits oder die Betreuung von Social-Media-Inhalten im Ausland. Gleichzeitig sollten im sichtbaren Fließtext Zielgruppen, Leistungsgrenzen, Sprach- oder Marktabdeckung und die Frage, ob fortlaufender Betrieb und Wartung enthalten sind, erläutert werden. Strukturierte Daten können nur vorhandene Fakten extrahieren und die Erklärung auf der Seite selbst nicht ersetzen.
Informationen zum Dienstleister sollten einheitlich unter Organization zusammengeführt werden: Name, offizielle Website, Kennzeichnung, Kontaktdaten und Social-Media-Konten müssen seitenübergreifend konsistent bleiben. Besteht für die Dienstleistung eine eindeutige stationäre Geschäftsadresse, können je nach tatsächlicher Situation Eigenschaften von LocalBusiness verwendet werden. Richtet sich das Geschäft hauptsächlich an mehrere Länder oder wird die Leistung online erbracht, kann areaServed den Abdeckungsbereich ausdrücken; Regionen, in denen noch keine Tätigkeit erfolgt oder keine Leistung erbracht werden kann, dürfen jedoch nicht mit aufgenommen werden. Für Projekte mit festen Leistungspaketen und auf der Seite veröffentlichten Preisen kann Offer verwendet werden. Bei projektbezogen bewerteten Dienstleistungen sollten dagegen keine erfundenen Standardangebote erzeugt werden.
Am Beispiel von Websites in Branchen wie Papierherstellung, Verpackung und Umweltschutz wird deutlich, dass Unternehmenswebsites häufig gleichzeitig der Markenpräsentation, der Erläuterung von Lösungen und der Gewinnung geschäftlicher Anfragen dienen. Module wie industrielle Luftaufnahmen, ökologische Landschaften, Grafiken zu technischen Zusagen und Bewertungs-Karussells zur globalen Präsenz können das Informationsverständnis verbessern. Bei der Markierung muss jedoch weiterhin auf die Seitenfakten zurückgegriffen werden: Lösungsseiten werden mit Service, konkrete Produktseiten mit Product ausgezeichnet, und Buchungsformulare beschreiben nur tatsächlich ausführbare Kontakt- oder Buchungsaktionen. Ein visuell grünes oder khakifarbenes Markendesign stellt keine eigenständig auszeichnungsfähige geschäftliche Eigenschaft dar.
Für strukturierte Daten wird technisch im Allgemeinen JSON-LD empfohlen, da es sich leicht von Seitentemplates entkoppeln lässt. Dennoch darf es nicht vom Content-System getrennt werden. Ein ausgereifterer Ansatz besteht darin, Produkttitel, SKU, Preis, Lagerbestand, Bilder und Währung über dieselbe Datenquelle für Seite und Markierung zu steuern. Auch Name, Region, Telefonnummer und Buchungslink von Serviceseiten sollten über eine einheitliche Konfiguration verwaltet werden. Die häufigste Folge manuell kopierten Codes ist: Der Preis auf der Seite wurde bereits aktualisiert, während das Skript weiterhin den alten Betrag enthält; auf mehrsprachigen Seiten wurde der Fließtext übersetzt, im Schema steht jedoch weiterhin die Ausgangssprache.
Vor der Veröffentlichung sollten mindestens drei Prüfebenen abgeschlossen werden: Auf der Syntaxebene wird bestätigt, dass JSON und die Attributstruktur analysierbar sind; auf der semantischen Ebene wird geprüft, ob Typen, Feldwerte und Verschachtelungsbeziehungen den Schema.org-Definitionen entsprechen; auf der Seitenebene werden sichtbare Nutzerinhalte, kanonische URL, Sprachversionen und die Zuordnung zu canonical einzeln abgeglichen. Die von Suchmaschinen bereitgestellten Testwerkzeuge können helfen, technische Probleme zu erkennen, doch ein bestandener Test bedeutet nicht, dass zwingend ein bestimmtes Darstellungsformat erzielt wird. Die Berechtigung zur Anzeige wird zudem von Seitenqualität, Indexierungsstatus, Suchkontext und Änderungen der Plattformrichtlinien beeinflusst.
Bei Websites für Auslandsmärkte besteht ein häufiges Problem nicht darin, dass „keine Markierung vorhanden ist“, sondern darin, dass die mehrsprachigen Versionen dieselben englischen oder chinesischen Felder teilen. URLs in unterschiedlichen Sprachen sollten jeweils name, description, offer-Texte und sichtbare Seiteninhalte in der entsprechenden Sprache enthalten. Währung, Hinweise zu Steuern, Lieferbereich und Preisbedeutung müssen entsprechend dem Zielmarkt und den tatsächlichen Transaktionsregeln behandelt werden. Es darf nicht allein aufgrund europäischer Besucher standardmäßig eine bestimmte Steuer- oder Lieferzusage eingetragen werden; diese Inhalte müssen gemeinsam von Vertrieb, Betrieb und Rechtsabteilung abgestimmt werden.
Auch Werbe-Landingpages sollten nicht zur Erlangung umfangreicher Markierungen Produktdetailseiten eines Shops kopieren. Ist das Ziel einer Landingpage die Gewinnung von Terminvereinbarungen, sollten Leistungsinhalt, Dienstleister, Ansprechpartner und Formularprozess im Mittelpunkt stehen. Führt die Werbung direkt zu einer verkaufbaren SKU, können Produkt- und Angebotsinformationen ergänzt werden. Yiyingbao betreut langfristig Außenhandelsunternehmen, Produktionsstätten und grenzüberschreitende Verkäufer. Einer der tatsächlichen Werte seines Systems für intelligente Website-Erstellung, grenzüberschreitende Shops und AI+SEO/GEO-Optimierung besteht darin, Website-Daten, Content-Pflege und Marketingseiten in einen einheitlich verwaltbaren Prozess zu integrieren und Abweichungen zu verringern, die dadurch entstehen, dass Marketing- und Technikteams jeweils eigene Informationsstände pflegen.
Yiyingbao Information Technology (Beijing) Co., Ltd. wurde 2013 gegründet und hat seinen Hauptsitz in Beijing. Das Unternehmen bietet umfassende digitale Dienstleistungen rund um intelligente Website-Erstellung, Suchoptimierung, Anzeigenplatzierung und Social-Media-Betrieb. Für Unternehmen, die Nordamerika, Europa, Südostasien, den Nahen Osten und andere Auslandsmärkte abdecken müssen, sollten strukturierte Daten keine einmalige Entwicklungsaufgabe sein, sondern in die routinemäßige Abnahmeliste für Veröffentlichungen, Überarbeitungen, Produktaktualisierungen und mehrsprachige Erweiterungen aufgenommen werden.
Vorrangig behandelt werden sollten nicht die Anzahl der Felder, sondern die echten Transaktions- und Serviceinformationen auf hochwertigen Seiten: Bei Produkten sind zunächst Preis, Lagerbestand und Spezifikationen zu prüfen, bei Dienstleistungen zuerst Umfang, Entität und Kontaktweg. Nach Abschluss dieses Schritts können je nach Seitentyp schrittweise Felder für Bewertungen, Varianten, Lieferung oder Buchungen ergänzt werden. Dies ist in der Regel verlässlicher, als alle Schema-Typen auf einmal vollständig auszulegen.
Verwandte Artikel
Verwandte Produkte


