JSContact und RFC 10050: Kontaktdaten-Austausch für SEOs

JSContact ist das JSON-Gegenstück zu vCard. RFC 9553 definiert es als JSON-Darstellung von Kontaktdaten, und sein zentrales Objekt ist die Card. Eine Card enthält einen Namen, E-Mail-Adressen, Telefonnummern, Postanschriften, Online-Dienste und die Organisation, zu der eine Person gehört. Dasselbe Objekt kann eine Person, ein Unternehmen, eine Gruppe oder einen Ort beschreiben, denn jede Card trägt eine Eigenschaft kind, die angibt, um welche dieser Arten es sich handelt.

Dieser Leitfaden richtet sich an technische SEOs, die dem Begriff in einem Kundentermin, einem CRM-Export oder einem Standards-Feed begegnen und wissen wollen, wo er im Verhältnis zu den strukturierten Daten steht, die sie jede Woche prüfen. Er behandelt, was das Format ist, wie es sich in vCard umwandeln lässt, in welchem Verhältnis RFC 10050 zu den JSContact-Dokumenten steht und was sich an Ihrer Arbeit ändert. Die Kurzfassung: Es ändert sich sehr wenig, und wer den Grund kennt, vermeidet ein paar falsche Annahmen.

Was JSContact ist und warum es existiert

vCard gibt es seit Jahrzehnten. Die aktuell verbreitete Version, vCard 4.0, ist in RFC 6350 spezifiziert. Es ist ein zeilenbasiertes Textformat mit eigenen Escape-Regeln, Parametern und dem Umbruch langer Zeilen (Line Folding). Zum Lesen braucht man einen eigenen Parser, und von Hand geschrieben ist es fehleranfällig. Im Lauf der Jahre haben Implementierer außerdem eigene Eigenschaften ergänzt, sodass zwei Systeme, die beide vCard unterstützen, oft uneins darüber sind, was eine bestimmte Karte bedeutet. Ein Kontakt, der aus einem Adressbuch exportiert wird, kann in einem anderen mit fehlenden oder falsch platzierten Feldern ankommen.

JSON beseitigt das erste Problem unmittelbar. Fast jede Web-API sendet und empfängt bereits JSON, und jede gängige Programmiersprache bringt einen Parser dafür mit. Eine Card kann also dieselben Leitungen nutzen wie die übrigen Daten einer Anwendung. JSContact legt zudem die Struktur innerhalb des Objekts fest. Ein Name ist in typisierte Bestandteile zerlegt, und eine Sammlung wie die E-Mail-Liste ist eine Map mit expliziten Kennungen. Software muss nicht mehr raten, wo ein Eintrag endet und der nächste beginnt.

Beide Formate sollen nebeneinander bestehen. Ein Unternehmen, das Kontakte heute in vCard-Dateien speichert, muss nicht migrieren, und ein Dienst, der JSON spricht, kann über eine Konvertierungsschicht trotzdem Daten mit vCard-basierten Clients austauschen. Diese Konvertierungsschicht ist Thema des nächsten Abschnitts.

Wie sich eine JSContact-Card auf vCard abbilden lässt

RFC 9555 legt fest, wie eine JSContact-Card in eine vCard umgewandelt wird und zurück. Es ist eine Abbildungsspezifikation. Sie beschreibt, wie die Bedeutung einer Karte von einem Format ins andere übertragen wird, und sie verspricht nicht, dass ein Hin- und Rückweg identische Bytes liefert.

Die einfachen Felder entsprechen einander offensichtlich. Der Name einer Person entspricht den vCard-Eigenschaften N und FN, E-Mail-Adressen entsprechen EMAIL, Telefonnummern TEL, Organisationen ORG und Postanschriften ADR. Der strukturelle Unterschied zeigt sich sofort. vCard wiederholt eine Eigenschaft für jeden Wert, Zeile für Zeile, während JSContact zusammengehörige Werte in einer Map bündelt, die über eine Kennung adressiert wird. Jeder Eintrag trägt außerdem seinen eigenen Kontext, etwa beruflich oder privat, den vCard über Parameter an der Eigenschaft ausdrückt.

Interessant sind die Fälle, in denen ein Format ein Konzept kennt, das dem anderen fehlt:

• Eigenschaften, die in vCard existieren, aber kein eigenes JSContact-Feld haben, brauchen in der umgewandelten Karte einen Platz, damit ein Konverter sie später wiederherstellen kann.
• Funktionen, die es nur in JSContact gibt, etwa Werte mit Sprachvarianten, brauchen eine Regel dafür, wie eine vCard-Ausgabe sie darstellt.
• Parameter, die ein Format definiert und das andere nicht, müssen an eine Erweiterungsstelle verschoben oder verworfen werden.
• Freitext aus vCard landet manchmal an einer Stelle, an der JSContact einen strukturierten Wert erwartet, sodass der Konverter die Zeichenfolge interpretieren oder unverändert übernehmen muss.

Die genauen Namen dieser Eigenschaften und die Regel für jeden Fall stehen im Text von RFC 9555. Entnehmen Sie sie dort und nicht einer Zusammenfassung, auch nicht dieser, denn in der Tabelle auf Feldebene unterscheiden sich die Konverter. Ob ein bestimmtes Werkzeug Informationen verliert, hängt davon ab, welche Eigenschaften Ihre Daten nutzen und wie vollständig das Werkzeug das Dokument umsetzt. Wirbt ein Anbieter mit verlustfreier Konvertierung, nehmen Sie eine Stichprobe Ihrer eigenen Karten, wandeln Sie sie in beide Richtungen um und vergleichen Sie die Ergebnisse mit der Eigenschaftsliste in RFC 9555.

Zwei Begleitdokumente vervollständigen die Familie. RFC 9554 definiert vCard-Erweiterungen, die JSContact benötigt, und RFC 9555 stützt sich bei der Umwandlung darauf. Alles, was Sie über JSContact als Format lesen, führt auf diese drei Nummern zurück.

Wo RFC 10050 einzuordnen ist

RFC 10050 ist die Nummer im Suchthema dieses Leitfadens, und der RFC Editor veröffentlicht ihren Kopfbereich unter rfc-editor.org/rfc/rfc10050. Dieser Kopfbereich entscheidet, in welchem Verhältnis das Dokument zur JSContact-Familie steht. Er nennt einen Titel, ein Veröffentlichungsdatum, einen Status sowie die Felder Updates und Obsoletes. Nennt eine Updates- oder Obsoletes-Zeile RFC 9553, 9554 oder 9555, gehört das Dokument zur JSContact-Familie, und die Zusammenfassung (Abstract) sagt dann, was es ändert: das Card-Objekt, ein Register oder die Konvertierungsregeln.

Solange Sie diesen Kopfbereich nicht gelesen haben, zitieren Sie für alles, was das Card-Format selbst betrifft, RFC 9553. Es ist die Basisspezifikation, und ein späteres Dokument, das sie aktualisiert, verweist darauf zurück. Auch die Statuszeile ist wichtig. Proposed Standard, Informational und Experimental haben unterschiedliches Gewicht, und ein Anbieter, der die Unterstützung des RFC behauptet, sollte sagen können, welcher Status gilt.

Für technische SEOs lautet die nützliche Frage, was eine Änderung an dieser Familie betreffen würde. Eine Aktualisierung der JSContact-Dokumente ändert, was die Entwickler von Kontaktsystemen implementieren: CRMs, Adressbücher, Mailserver und die Bibliotheken dazwischen. Sie ändert nicht das HTML Ihrer Seiten und nicht die strukturierten Daten, die Google daraus liest. Das bleibt das schema.org-Vokabular, das der nächste Abschnitt beschreibt.

Was JSContact für die SEO-Arbeit bedeutet

Auf einer Webseite zählt das schema.org-Vokabular. ContactPoint und Organization beschreiben dort ein Unternehmen. Sie binden sie als JSON-LD oder Microdata ein, und ein Crawler liest sie aus dem HTML. Die Search-Central-Dokumentation von Google erklärt das Organization-Markup und listet die Eigenschaften auf, die Google auswertet. Das Vokabular existiert, damit eine Suchmaschine eine Seite mit einer benannten Entität verbinden kann, zu der eine Telefonnummer, eine E-Mail-Adresse und Servicezeiten gehören.

JSContact hat eine andere Aufgabe. Eine Card ist ein JSON-Objekt, das eine Anwendung an eine andere übergibt: ein CRM, das einen Kundendatensatz exportiert, ein Mailserver, der ein Adressbuch synchronisiert, eine Kontakte-App, die eine Datei importiert. Die Daten laufen über eine API zwischen Systemen, die beide das Format erwarten. An diesem Austausch ist keine öffentliche Webseite und kein Crawler beteiligt.

Beide sind JSON, und beide enthalten Namen, E-Mail-Adressen und Telefonnummern. Ein Kunde, der im Termin von strukturierten Kontaktdaten gehört hat, nimmt deshalb womöglich an, das eine decke das andere ab. Das tut es nicht. Ein ContactPoint auf Ihrer Kontaktseite beschreibt die Seite gegenüber einer Suchmaschine. Eine JSContact-Card beschreibt eine Person gegenüber einem Mailprogramm.

Eine Card als JSON-LD-Block auf einer Seite zu veröffentlichen bringt deshalb nichts. JSON-LD funktioniert, weil Suchmaschinen das im Kontext deklarierte Vokabular lesen, und schema.org ist das Vokabular, das sie lesen. Hinter einem JSContact-Objekt steht keine solche Vereinbarung, der Block bliebe also ungelesen in Ihrem HTML. Er könnte zudem die persönlichen Angaben einer namentlich genannten Person jedem Scraper offenlegen, der die Seite besucht.

Zu Google im Besonderen: Die Search-Central-Seiten beschreiben schema.org-Markup, und JSContact kommt in der Organization-Dokumentation nicht vor. Es ist nicht veröffentlicht, wie Google das Format intern behandelt, deshalb macht dieser Leitfaden dazu keine Aussage. Es gibt auch nichts Veröffentlichtes, das Ihnen einen Grund zum Handeln lieferte.

Der praktische Gewinn liegt im Vokabular. Betreibt ein Kunde ein CRM, ein gemeinsames Adressbuch oder einen JMAP-basierten Maildienst, bringen die Menschen, die diese Systeme betreuen, vielleicht JSContact, vCard oder Kontaktexport zur Sprache. Sie können diese Begriffe jetzt einordnen: Sie beschreiben, wie Kontaktdatensätze zwischen internen Werkzeugen wandern, und sie liegen außerhalb Ihres Audit-Umfangs.

Fragt derselbe Kunde, warum die Telefonnummer auf der Website von der in seinem Google-Unternehmensprofil abweicht, sind Sie wieder auf vertrautem Terrain. Das ist ein Problem der ContactPoint-Daten und der Konsistenz lokaler Daten, und Sie prüfen es wie immer: indem Sie vergleichen, was die Seiten sagen, mit dem, was die anderen Einträge sagen.

Grenzen, personenbezogene Daten und ein Schritt für heute

JSContact verändert Ihre Rankings nicht. Dasselbe gilt für jeden RFC, der es aktualisiert: Ein Standard zum Austausch von Adressbuchdaten zwischen Systemen gibt einer Suchmaschine keinen Grund, Ihre Seiten besser zu platzieren. Wer ihn als Ranking-Taktik verkauft, rät nur. Eine Card in eine Seite einzufügen kostet Aufwand und bringt nichts.

Personenbezogene Daten setzen eine zweite Grenze. Eine Kontaktkarte kann Namen, private Telefonnummern, Wohnanschriften und E-Mail-Adressen enthalten. Berührt ein Crawl oder ein Export Seiten oder Dateien mit solchen Daten, können die DSGVO oder ein vergleichbares nationales Gesetz dafür gelten, wie Sie sie erheben, speichern und weitergeben. Dieser Leitfaden trifft keine rechtliche Aussage dazu, was Ihr Fall erfordert. Bevor Sie Kontaktfelder von der Website eines Kunden in eine Tabelle oder einen gemeinsamen Bericht exportieren, fragen Sie den Datenschutzansprechpartner des Kunden, was er erlaubt. Wenn Sie Crawl-Daten auf Ihrem eigenen Rechner halten, verringert das die Zahl der Stellen, an denen diese Daten abfließen können, die rechtliche Frage lässt es aber offen.

Die Diskussion um JSContact kann Ihre Audits über eine Tür erreichen: die strukturierten Daten, die Sie auf Seiten mit Kontaktangaben prüfen. Dort kostet eine Abweichung etwas, und es ist eine Prüfung, die Sie heute durchführen können. Öffnen Sie Ihre Kontaktseite und die Startseite und sehen Sie sich das JSON-LD im Quelltext an. Bestätigen Sie, dass Name, Telefonnummer und E-Mail-Adresse der Organization mit dem übereinstimmen, was Besucher auf der Seite sehen, und dass jeder ContactPoint einen korrekten contactType trägt. Führen Sie dieselbe Prüfung dann bei den anderen Templates durch, die Kontaktdaten ausgeben, etwa dem Footer, den Standortseiten und der Über-uns-Seite. Beheben Sie Abweichungen zuerst im Markup, denn die können Suchmaschinen lesen.

Öffnen Sie jetzt den Quelltext Ihrer Kontaktseite und vergleichen Sie die Telefonnummer im JSON-LD mit der Nummer, die auf der Seite steht.