GTIN, MPN, SKU und Marke: Produktkennungen auswählen

Scope und erwartetes Verhalten

Dieses rule-Dokument behandelt GTIN, MPN, SKU und Marke: Produktkennungen auswählen im Cluster Produkt-, E-Commerce- und Merchant-Markup. Die Abnahmegrenze ist bewusst eng: Genau diese Entity, Property oder diesen Workflow am öffentlichen Output prüfen, ohne benachbarte Schema-Themen in dieselbe Regel zu ziehen. Der Sollzustand muss im gerenderten HTML oder auf der öffentlichen Search-relevanten Seite sichtbar sein und darf nicht nur in CMS, Plugin oder Template existieren.

Google dokumentiert dieses Thema als Structured-Data- oder verwandte Search-Funktion. Eligibility setzt weiterhin korrekten sichtbaren Content, crawlbare Seiten, valide Implementierung und die jeweiligen Richtlinien voraus; eine Darstellung wird nie garantiert.

Vor einer Änderung Page Class, Canonical-URL, Locale, sichtbare Source of Truth, erwarteten Structured-Data-Node und den erzeugenden Generator dokumentieren. Zusätzlich einen bereits korrekten Kontrollfall und einen Edge Case festlegen. So beschreibt PASS/FAIL eine reproduzierbare technische Eigenschaft und nicht nur einen Validator-Score.

Datenmodell und Evidenz

Für dieses Thema sind besonders gtin, mpn, sku, brand, identifier uniqueness, variant identity zu prüfen. Nicht jedes Feld ist in jedem Google-Feature gleich gewichtet, aber jedes verwendete Feld braucht eine nachvollziehbare Source of Truth. Gerenderten Wert, sichtbaren Wert, zuständiges Anwendungsfeld und Validator-Ergebnis gemeinsam speichern.

url,entity_id,property,rendered_value,visible_value,generator,validator,decision
https://example.com/page,#entity,property,value,value,template-v3,checked,PASS

Seite, Entity und Generator als drei getrennte Ebenen behandeln. Ein valides CMS-Feld beweist nicht, dass derselbe Wert im gerenderten HTML ankommt; gerendertes HTML beweist wiederum nicht, dass der Wert semantisch wahr ist.

Bei verschachtelten Entities @id-Beziehungen und Parent-Child-Verknüpfungen erhalten. Bei schnell veränderlichen Daten wie Preis, Availability, Jobstatus, Eventzeit oder Öffnungszeiten zusätzlich Crawl-Zeitpunkt und Zeitstempel der Business- oder Feed-Quelle erfassen. Syntaktisch valider, aber veralteter Output ist fachlich falsch.

Technische Diagnose

Immer die öffentliche URL abrufen und nicht nur Datenbank oder Plugin-Konfiguration lesen. Alle application/ld+json-Blöcke extrahieren, jeden Block als JSON parsen und @type, @id, URL sowie die themenspezifischen Properties inventarisieren. Wenn zusätzlich Microdata oder RDFa ausgegeben werden, auch diese Formate aufnehmen, damit zwei Generatoren dieselbe Entity nicht unbemerkt widersprüchlich beschreiben.

Ein minimaler Capture kann so starten:

curl -sS -L --compressed https://example.com/page > page.html
python -m json.tool example.json >/dev/null

Der zweite Befehl prüft nur die JSON-Syntax eines extrahierten Objekts; er beweist keine Google-Eligibility. Danach strukturierte Werte mit sichtbarem Content und Feature-Dokumentation vergleichen. Optionale Properties nicht allein deshalb als Fehler behandeln, weil ein Audit-Tool eine Warning ausgibt.

Für GTIN, MPN, SKU und Marke gezielt gtin, mpn, sku, brand, identifier uniqueness, variant identity prüfen. Bei gemeinsamer Template-Quelle mindestens eine weitere Seite desselben Templates kontrollieren. Bei Produkt-, Event-, Job- oder Profildaten mit dem maßgeblichen Datensatz vergleichen und nicht nur mit einer weiteren abgeleiteten Kopie.

Implementierungsmuster

Das folgende JSON-LD ist ein minimales themenspezifisches Modell. Es ist bewusst unvollständig, wenn die Feature-Dokumentation weitere Pflichtfelder verlangt; übernommen werden soll das Datenmodell, nicht die Beispielorganisation.

{
  "@context": "https://schema.org",
  "@type": "Product",
  "gtin": "0123456789012",
  "mpn": "MPN-1001",
  "sku": "SKU-EXAMPLE-01",
  "brand": "example"
}

Die Änderung an der kleinsten verlässlichen Quelle umsetzen: Produktmodell, Article-Template, Organisationssettings, Eventdatensatz, Locale-Transformer, Schema-Graph-Builder oder serverseitig gerenderte Component. Einzelne String-Patches pro Seite vermeiden, wenn derselbe Fehler von einem Shared Generator erzeugt wird. Stabile Entity-Identität über Deployments erhalten.

Fehlt ein Wert, weil Unternehmen oder Seite diese Information tatsächlich nicht besitzen, Property weglassen statt Platzhalter zu erfinden. Leere Strings, kopierte Defaults, erfundene Reviews, geschätzte Koordinaten oder generische Beispielwerte erzeugen eine falsche maschinenlesbare Behauptung.

Themenspezifische Fehlermuster

Diese Fehlerklassen getrennt testen:

1. Presence Failure: erwarteter Node oder Property erreicht die gerenderte öffentliche Seite nicht.
2. Value Failure: Markup existiert, aber gtin oder ein verwandter Wert widerspricht sichtbarem Content oder Source of Truth.
3. Identity Failure: zwei Nodes beschreiben dieselbe Entity mit unterschiedlicher @id, URL, Name oder Kennung.
4. Eligibility Failure: Schema.org ist valide, die Seite erfüllt aber die Google-Feature-Grenze oder Richtlinie nicht.
5. Freshness Failure: Cache oder Feed hinkt Preis, Availability, Datum, Rolle, Standort oder Status hinterher.
6. Template Failure: derselbe Generator schreibt Werte auf Page Classes, auf denen die Entity gar nicht vorhanden ist.

Nicht automatisch jede empfohlene Property ergänzen. Required und recommended Properties hängen vom konkreten Feature ab, und auch vollständig valides Markup garantiert kein Rich Result. Der Fix muss die nachgewiesene fachliche oder technische Abweichung beseitigen.

Edge Cases und Fälle ohne Markup-Änderung

Mehrere legitime Entities und mehrere JSON-LD-Blöcke auf einer Seite sind nicht automatisch ein Fehler. Problematisch sind widersprüchliche Beschreibungen derselben realen Entity. Ebenso ist eine Warning zu einer recommended Property nicht identisch mit einem invalid Item; Schema.org-Properties ohne eigenes Google-Rich-Result können für andere Consumer weiterhin nützlich sein.

Lokalisierte Seiten dürfen sichtbaren Text übersetzen und trotzdem dieselbe reale Entity-Identität behalten. Produktvarianten können eine gemeinsame Gruppenidentität teilen und eigene Kennungen behalten. Article-Autoren können auf stabile Profile verweisen. Events, Jobs, Produkte und Business-Daten benötigen wegen schneller Änderungen strengere Freshness-Kontrollen als statische Organization-Daten.

Ist das Markup korrekt, aber ein Feature nicht verfügbar, deprecated, auf andere Site-Typen beschränkt oder nicht garantiert sichtbar, kann keine Markup-Änderung die richtige Entscheidung sein. Dann Eligibility-Grenze dokumentieren und falsche interne Erwartungen korrigieren.

Verifikation und Regressionstest

Nach Deployment dieselbe öffentliche URL erneut abrufen und den extrahierten Node mit der Baseline vergleichen. Erst generische Syntax/Schema-Prüfung, dann den Google-spezifischen Test oder Search-Console-Bericht verwenden, wenn das Feature dort tatsächlich unterstützt wird. Zusätzlich Canonical, Robots, noindex, Authentifizierung und Rendering prüfen.

Bei wiederholten Templates Originalfehler, korrekten Kontrollfall, bewusste Ausnahme und eine weitere Seite desselben Generators testen. Bei dynamischen Daten den Test nach einer echten Datenänderung wiederholen, damit klar ist, dass die strukturierte Ebene automatisch folgt und nicht nur nach manuellem Cache-Purge korrekt ist.

PASS / FAIL Kriterien

| Prüfung | PASS | FAIL | | --- | --- | --- | | Öffentlicher Output | erwarteter Node und Werte sind gerendert vorhanden | Daten existieren nur in CMS oder Source Code | | Semantik | gtin und verwandte Werte beschreiben sichtbare Realität | Markup widerspricht Seite oder Source of Truth | | Identität | stabile IDs und URLs beschreiben dieselbe Entity konsistent | doppelte oder widersprüchliche Identitäten | | Eligibility | Feature-Grenze ist bekannt und dokumentiert | valides Schema wird als garantierte Search-Darstellung verkauft | | Freshness | dynamische Werte folgen ihrer Source of Truth | Cache oder Kopien bleiben veraltet | | Regression | Kontrollseiten und Nachbartemplates bleiben korrekt | Fix erzeugt Markup auf falschen Seiten | | Evidenz | zweite Person kann PASS reproduzieren | Ergebnis hängt nur von einem Tool-Score ab |

1. Page Class, Entity, Locale, Canonical-URL und erwartetes Verhalten für GTIN, MPN, SKU und Marke festlegen.
2. Gerenderte Structured Data extrahieren und gtin, mpn, sku, brand zusammen mit dem zuständigen Generator erfassen.
3. JSON-Syntax, Schema.org-Semantik und Google-Feature-Eligibility getrennt prüfen und nicht in einen einzigen Score zusammenziehen.
4. Jeden wesentlichen Wert mit sichtbarem Seitencontent und der maßgeblichen Anwendungs- oder Business-Quelle vergleichen.
5. Einen bekannten Kontrollfall und einen bewussten Edge Case prüfen, bevor Shared Template oder Graph Builder geändert werden.
6. Kleinsten Source-of-Truth-Fix umsetzen und fehlende Daten weglassen statt Platzhalter zu erfinden.
7. Öffentliche Seite erneut abrufen, dieselbe Extraktion und anwendbare Google-Prüfung wiederholen und Nachbartemplates/Locales auf Regression testen.
8. PASS: öffentlicher Output ist syntaktisch valide, semantisch wahr, korrekt zum Feature abgegrenzt, aktuell, reproduzierbar und an der richtigen Quelle wartbar.