Welche Seitentypen sollten vor der Implementierung strukturierter Daten bestätigt werden?

Welche Seitentypen sollten vor der Implementierung strukturierter Daten bestätigt werden?

Wenn Teams über die Implementierung strukturierter Daten sprechen, denken sie zunächst oft an die Auswahl des Schema-Typs, das Schreiben von JSON-LD und die Nutzung von Validierungstools. In realen Projekten liegt das Problem jedoch häufig nicht darin, „wie man es schreibt“, sondern darin, „für wen man es schreibt“. Wenn Seitentypen nicht klar unterschieden sind, Inhaltsgrenzen instabil bleiben und Feldquellen nicht einheitlich sind, kann selbst eine noch so standardisierte Auszeichnung später zu unnötigem Aufwand werden. Besonders bei integrierten Projekten für Websites und Marketing übernehmen Seiten sowohl Aufgaben bei der Indexierung als auch bei der Conversion. Templates, Sprachversionen, Landingpages für Werbekampagnen und Blogseiten werden häufig im selben System verwaltet. Ohne eine vorherige Bestandsaufnahme der Seiten kann die Implementierung strukturierter Daten daher schnell unübersichtlich werden.

Bei der technischen Bewertung ist ein praxisnaher Ansatz, zunächst zu prüfen, welche Seitentypen über stabile, überprüfbare und wartbare Bedingungen für strukturierte Auszeichnungen verfügen. Produktseiten, Artikelseiten, Startseiten und Kategorieseiten gehören in der Regel zu den vier höchsten Prioritäten. Dennoch eignet sich nicht jede Website für eine vollständige Implementierung. Bei internationalen Unternehmenswebsites, grenzüberschreitenden Shops und mehrsprachigen Unternehmensseiten müssen außerdem Sprachumschaltung, Währungen, regionale Inhaltsunterschiede, die Wiederverwendung von Templates und die Einbindung von Marketingkomponenten gemeinsam betrachtet werden.

Nicht sofort implementieren, sondern zunächst die Seitentypen in „geeignet“ und „schwierig“ einteilen

Vor der Implementierung strukturierter Daten sollte man keinesfalls die Navigationslogik der Website mit der Logik der Seitentypen gleichsetzen. In der Navigation gibt es scheinbar nur „Produktzentrum, Newszentrum, Über uns und Kontakt“. Aus Sicht der Auszeichnung können sich dahinter jedoch mindestens Produktdetailseiten, Produktübersichtsseiten, Artikeldetailseiten, Artikel-Tagseiten, Markenseiten, Teamseiten und Formular-Landingpages sowie viele weitere Templates verbergen. Unterschiedliche Templates weisen unterschiedliche Feldstabilitäten auf und eignen sich daher für unterschiedliche Schema-Typen.

Bei der praktischen Bewertung empfiehlt es sich, die Seiten zunächst in drei Kategorien einzuteilen:

• Seiten mit klaren Inhaltsgrenzen und festen Kernfeldern, beispielsweise Produktdetailseiten und Artikeldetailseiten;
• Seiten zur Informationsaggregation, beispielsweise Kategorieseiten, Suchergebnisseiten und Themenseiten;
• Marken- und Funktionsseiten, beispielsweise Startseiten, Über-uns-Seiten, Kontaktseiten und Formularseiten.

Die erste Kategorie eignet sich normalerweise am besten für eine priorisierte Implementierung. Die zweite Kategorie ist nicht grundsätzlich ungeeignet, hängt jedoch von der Stabilität der Aggregationslogik ab. Die dritte Kategorie wird häufig überschätzt. Viele Teams möchten die Startseite von Anfang an besonders „vollständig“ gestalten und stapeln dort Organization, WebSite, Breadcrumb, FAQ, Product und sogar Review. Auf den ersten Blick wirkt das umfangreich, tatsächlich entstehen jedoch zahlreiche semantische Konflikte.

Produktseiten: besonders lohnenswert, aber auch besonders anfällig für Feldprobleme

Wenn eine Website standardisierte Produktdetailseiten enthält, sollten diese bei der Implementierung strukturierter Daten bevorzugt geprüft werden. Der Grund ist einfach: Produktseiten haben in der Regel ein klar definiertes Thema und verfügen über relativ vollständige Attributfelder wie Name, Bild, Beschreibung, Marke, Modell, SKU, Preis und Lagerstatus. Das Problem besteht darin, dass viele B2B-Websites diese Felder nicht vollständig bereitstellen.

Bei Websites von exportorientierten Herstellern ist häufig folgende Situation anzutreffen: Die Seite wird als „Produktseite“ bezeichnet, ähnelt tatsächlich aber eher einer Leistungspräsentation. Sie enthält nur einige Bilder, eine Beschreibung des Anwendungsszenarios und eine Anfrage-Schaltfläche, jedoch keinen Preis oder Lagerbestand und keine Unterscheidung zwischen konkreten Modellen. Eine solche Seite kann grundsätzlich mit einer Product-Auszeichnung versehen werden, sollte dabei jedoch zurückhaltend behandelt werden. Informationen, die auf der Website nicht vorhanden sind, dürfen nicht künstlich ergänzt werden. Insbesondere Felder wie Preis, Bewertung und Rezensionen sollten nicht nur deshalb ausgefüllt werden, um eine vermeintliche „Vollständigkeit“ zu erreichen, wenn sie auf der Benutzeroberfläche nicht eindeutig dargestellt werden.

Bei einem grenzüberschreitenden Shop oder einer unabhängigen Website sollten bei der Bewertung von Produktseiten außerdem drei Punkte geprüft werden: Erstens die Variantenlogik – ob Farbe, Größe oder regionsabhängige Preise die Kernfelder verändern; zweitens die eindeutige Zuordnung von Währung und Länder-Website; und drittens die Echtzeitsynchronisierung von Lagerbestand und Aktionsinformationen. Wenn der Aktualisierungsmechanismus der Felder nicht Schritt hält, verlieren selbst gut umgesetzte strukturierte Daten schnell ihre Richtigkeit.

Aus diesem Grund verknüpfen viele integrierte Website- und Marketingplattformen heute Produktfelder, Template-Felder und Frontend-Auszeichnungen miteinander. Bei Plattformen wie 易营宝, die langfristig mehrsprachige Unternehmenswebsites, B2B-Websites für den Außenhandel und grenzüberschreitende Shops betreuen, liegt die eigentliche Herausforderung nicht darin, ob Schema unterstützt wird, sondern darin, ob sich Produktinformationen aus dem Backend, Sprachversionen, Seitentemplates und Regeln für die Sichtbarkeit in Suchmaschinen miteinander verbinden lassen. Bei der technischen Bewertung sollte daher geprüft werden, ob die „Quelle der Felder eindeutig“ ist.

Artikelseiten: scheinbar einfach, tatsächlich ein Test für das Content-System

Artikeldetailseiten haben normalerweise die zweithöchste Priorität, da ihre Struktur relativ stabil ist. Felder wie Titel, Veröffentlichungszeitpunkt, Autor, Titelbild und Hauptinhalt sind in der Regel verfügbar. Für Unternehmenswebsites, die langfristig SEO betreiben, eignen sich Artikelseiten außerdem gut für eine kontinuierliche Pflege.

Hier treten jedoch zwei häufige Missverständnisse auf. Das eine besteht darin, alle Inhalte als Article zu behandeln. Pressemitteilungen, Wissensartikel, Fallstudien, herunterladbare Dokumente und Veranstaltungsseiten befinden sich zwar möglicherweise alle im „Informationszentrum“, unterscheiden sich in ihrer tatsächlichen Inhaltseigenschaft jedoch deutlich. Das andere Missverständnis betrifft das Autorenfeld. Unternehmenswebsites tragen dort häufig direkt den Firmennamen oder einen vom System vorgegebenen Namen ein. Das ist nicht grundsätzlich unzulässig. Wenn die Website jedoch kein eigenes Autorensystem, keine Redaktionsinformationen oder keine Erklärung zur inhaltlich verantwortlichen Stelle besitzt, kann die spätere Pflege erschwert werden.

Ein weiterer leicht übersehener Punkt ist, dass Breadcrumbs, die Zuordnung zu Rubriken und der Bereich für verwandte Artikel möglichst der tatsächlichen Seitenhierarchie entsprechen sollten. Manche Websites ordnen denselben Artikel aus Marketinggründen gleichzeitig mehreren Rubriken zu, sodass URL, Titel und Aggregationsbeziehungen instabil werden. Selbst wenn die Auszeichnung auf der einzelnen Seite korrekt ist, kann die Gesamtsemantik dadurch zerstreut werden.

Die Startseite ist nicht ungeeignet – sie sollte nur kein „Universalkontainer“ sein

Die Startseite eignet sich für marken- und websitebezogene Informationen, beispielsweise Auszeichnungen im Zusammenhang mit Organization oder WebSite. Voraussetzung ist jedoch, dass die Startseite tatsächlich als zentraler Einstiegspunkt der Marke dient. Bei Websites für Werbekampagnen oder Veranstaltungen kann die Startseite lediglich eine temporäre Übersichtsseite sein: Heute steht der Shop im Mittelpunkt, morgen eine Produktneuheit oder Themenseite. In solchen Fällen ist die Stabilität der Felder auf der Startseite häufig geringer als auf einer Markenseite.

Ein weiteres praktisches Problem besteht darin, dass die Startseiten mehrsprachiger Websites nicht unbedingt denselben Inhalt haben. Auf der englischen Website können Produktlösungen im Vordergrund stehen, auf der japanischen Website die Unternehmensqualifikationen und auf der Website für den Nahen Osten möglicherweise lokale Serviceinformationen. Technisch kann ein einheitliches Template verwendet werden. Auf der Ebene der Auszeichnung sollte jedoch nicht einfach dieselbe Gruppe von Markenbeschreibungen kopiert werden. Wenn sich Seitensprache, Kontaktinformationen, Social-Media-Konten oder Servicegebiete unterscheiden, sollten die strukturierten Daten entsprechend angepasst werden.

Für Unternehmen mit internationalem Marketing ist dieser Punkt besonders wichtig. Es reicht nicht aus, dass eine Website „geöffnet werden kann“ und „Code enthält“. Markenseite, Startseite, Landingpage und Produktseite haben im Suchsystem unterschiedliche Rollen. Plattformen wie 易营宝, die Website-Erstellung, SEO, Werbeschaltung und mehrsprachige Content-Pflege miteinander verbinden, eignen sich für eine strukturierte Verwaltung nicht deshalb besser, weil sie mehr Module anbieten, sondern weil sie die Aufgaben verschiedener Seitentypen trennen können, anstatt ein einziges Template auf alle Szenarien anzuwenden.

Kategorie- und Übersichtsseiten: eine häufig überschätzte Kategorie

Ob sich die Auszeichnung einer Kategorieseite lohnt, hängt davon ab, ob sie tatsächlich eine „aggregierte Liste“ oder eine „Rubrik mit eindeutigem Thema“ ist. Wenn lediglich mehrere Produkte oder Artikel automatisch nach Systemregeln abgerufen werden, der Titel mechanisch generiert wird und die Beschreibung kaum eigene Inhalte enthält, ähnelt die Seite eher einer Browsing-Seite als einer semantisch starken Seite. Selbst wenn eine solche Seite Breadcrumbs oder eine Liste von Elementen enthält, sollte sie nicht mit zu umfangreichen Auszeichnungen versehen werden.

Anders sieht es aus, wenn die Kategorieseite eine klare Kategorieerklärung, eine stabile Filterlogik und eine eindeutige URL-Hierarchie besitzt und langfristig einen bestimmten Suchbedarf abdeckt. Solche Seiten sollten in die Bewertung aufgenommen werden. Beispiele sind etwa Seiten von Industrieprodukt-Websites zur „Kategorisierung nach Anwendungsszenarien“ oder Markensammlungsseiten von grenzüberschreitenden Shops, die selbst eine wichtige Funktion bei der Informationsorganisation übernehmen.

Bei der technischen Bewertung sollte die entscheidende Frage nicht „Wird es unterstützt?“, sondern „Wie wird es gepflegt?“ lauten

Viele Projekte können strukturierte Daten bereits in der Präsentationsphase „umsetzen“. Schwieriger ist es, ihre Richtigkeit auch sechs Monate nach dem Go-live sicherzustellen. Bei der technischen Bewertung empfiehlt es sich, die Aufmerksamkeit auf vier Pflegefragen zu richten.

Erstens die Feldquelle: Stammen die Felder aus dem CMS, der Produktdatenbank, manueller Eingabe oder einer Zusammensetzung im Frontend? Je stärker die Quellen verteilt sind, desto höher ist die Fehlerwahrscheinlichkeit. Zweitens der Umfang der Template-Wiederverwendung: Dient ein Template gleichzeitig der Unternehmenswebsite, dem Shop und den Landingpages? Falls ja, müssen die Bedingungen eindeutig definiert sein. Drittens der Mehrsprachigkeitsmechanismus: Werden Übersetzungen, Währungen, Markennamen und regionale Kontaktdaten jeweils separat gepflegt? Viertens der Veröffentlichungsprozess: Werden strukturierte Daten bei Änderungen am Inhalt automatisch mitaktualisiert oder ist eine zweite manuelle Bearbeitung erforderlich?

Darin liegt auch der Unterschied zwischen integrierten Projekten für Websites und Marketing und der Erstellung einer klassischen Einzelwebsite. Bei Ersteren werden Seiten häufiger aktualisiert, es gibt mehr Werbekampagnen, und Content-, Technik- sowie运营steams greifen auf die Website-Daten zu. Wenn auf der Basisebene kein Konzept für die Datenverwaltung vorhanden ist, können strukturierte Daten nach mehreren Überarbeitungen schnell unwirksam werden.

Manche Seiten sollten lieber später umgesetzt werden, als zunächst falsch umgesetzt zu werden

FAQ-Seiten, Bewertungsseiten, Videoseiten, Veranstaltungsseiten und Downloadseiten werden häufig als „zusätzliche Pluspunkte“ priorisiert. Die Projekterfahrung zeigt jedoch, dass diese Seiten oft stärker von Inhaltsstandards als von der technischen Anbindung selbst abhängen. Wenn beispielsweise die Fragen auf einer FAQ-Seite nicht den tatsächlichen Interessen der Nutzer entsprechen, sondern lediglich aus Marketingtexten herausgelöste Sätze sind; wenn eine Bewertungsseite keine öffentlich zugängliche und nachvollziehbare Quelle für Rezensionen besitzt; oder wenn eine Videoseite lediglich einen Link zu einem Player eines Drittanbieters einbettet, sind diese Seiten nicht für eine übereilte Umsetzung geeignet.

Bei der Implementierung strukturierter Daten geht es im Wesentlichen darum, dem Suchsystem eine klarere Semantik der Seite bereitzustellen, nicht darum, der Website zur bloßen Erhöhung der Anzahl „Etiketten“ aufzukleben. Wenn der Seitentyp richtig bestimmt wurde, sind die nachfolgenden Auszeichnungen sinnvoll. Wird der Seitentyp falsch bestimmt, können übermäßige Aktivitäten im Gegenteil zu technischen Altlasten führen.

Wenn für die Bewertung vor der Implementierung nur eine besonders praktische Maßnahme festgelegt werden soll, sollte zunächst eine Liste der Website-Templates erstellt werden. Für jedes Template sind Inhaltsgrenzen, Feldquellen, zuständige Personen für die Aktualisierung und Unterschiede zwischen den Sprachversionen zu kennzeichnen. Seiten, für die diese Fragen eindeutig beantwortet werden können, gelangen anschließend in die Entwicklung der Auszeichnungsstrategie. Bei Seiten, für die dies nicht möglich ist, sollte zunächst die Seite selbst optimiert werden. Dieser Ablauf wirkt auf den ersten Blick etwas langsamer, spart in der Praxis jedoch Nacharbeit.