Organization Identifier Markup: USt-ID, Steuer- und Geschäftskennungen

Scope und erwartetes Verhalten

Dieses rule-Dokument behandelt Organization Identifier Markup: USt-ID, Steuer- und Geschäftskennungen im Cluster Local-Business- und Organisations-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.

Dieses Vokabular kann maschinenlesbare Bedeutung verbessern, ist aber kein eigenständiges Versprechen für ein Google-Rich-Result. Schema.org-Validität, Google-Feature-Eligibility und die tatsächliche Darstellung in Search müssen getrennt bewertet werden.

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 identifier, PropertyValue, taxID, vatID, legalName, privacy and necessity 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

Einen negativen Kontrollfall verwenden, der ähnlich aussieht, aber absichtlich gültig ist. Damit fallen zu breite Regeln besonders bei Varianten, Locales, wiederholten Templates und mehreren Standorten schnell auf.

Themenspezifischer Deep Dive

Organisationskennungen wie taxID, vatID oder Identifier beziehungsweise PropertyValue nur veröffentlichen, wenn sie angemessen, nicht sensibel und aus einer maßgeblichen Quelle belegt sind. Zuerst festlegen, welche reale Kennung das Unternehmen veröffentlicht und warum ein Machine Consumer sie benötigt. Interne Datenbank-IDs, CRM-Nummern, Analytics-IDs oder Kampagnen-Codes nicht als öffentliche rechtliche Kennung zweckentfremden. Bei jurisdiktionsspezifischen Kennungen Issuer- oder Kontextinformationen erhalten, statt eine nackte mehrdeutige Nummer auszugeben.

QA umfasst Datenschutz und Notwendigkeit ebenso wie Syntax. Den Wert mit der rechtlichen oder businessseitigen Source of Truth vergleichen, sicherstellen, dass dieselbe Kennung nicht mehreren Organisationen zugewiesen ist, und bei Multi-Site oder Localization prüfen, dass nicht versehentlich Parent-Kennungen in Subsidiaries landen. Wenn die Site eine Kennung nicht öffentlich braucht oder zeigen soll, kann Weglassen korrekt sein. PASS ist eine wahrheitsgemäße, stabile und richtig abgegrenzte Kennung, nicht maximale Property-Anzahl.

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 Organization Identifier Markup gezielt identifier, PropertyValue, taxID, vatID, legalName, privacy and necessity 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": "LocalBusiness",
  "identifier": "example",
  "PropertyValue": "example",
  "taxID": "example",
  "vatID": "example",
  "legalName": "Example LocalBusiness"
}

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 identifier 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 | identifier 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 Organization Identifier Markup festlegen.
2. Gerenderte Structured Data extrahieren und identifier, PropertyValue, taxID, vatID 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.