JSContact y RFC 10050: intercambio de datos de contacto para SEOs

JSContact es el equivalente en JSON de vCard. El RFC 9553 lo define como una representación en JSON de datos de contacto, y su objeto central es la Card. Una Card contiene un nombre, direcciones de correo electrónico, números de teléfono, direcciones postales, servicios en línea y la organización a la que pertenece una persona. El mismo objeto puede describir a una persona, una empresa, un grupo o un lugar, porque cada Card incluye una propiedad kind que indica de cuál se trata.

Esta guía está escrita para SEOs técnicos que se topan con el término en una reunión con un cliente, en una exportación de CRM o en un feed de estándares, y quieren saber qué lugar ocupa frente a los datos estructurados que auditan cada semana. Explica qué es el formato, cómo se convierte a vCard, cómo se relaciona el RFC 10050 con los documentos de JSContact y qué cambia en su trabajo. La versión corta: cambia muy poco, y entender por qué le evita algunas suposiciones erróneas.

Qué es JSContact y por qué existe

vCard existe desde hace décadas. La versión en uso actual, vCard 4.0, está especificada en el RFC 6350. Es un formato de texto basado en líneas, con sus propias reglas de escape, parámetros y plegado de líneas largas. Leerlo requiere un analizador dedicado, y escribirlo a mano es propenso a errores. Con los años, además, los implementadores añadieron propiedades propias, de modo que dos sistemas que dicen admitir vCard suelen discrepar sobre lo que significa una tarjeta concreta. Un contacto exportado desde una libreta de direcciones puede llegar a otra con campos omitidos o mal ubicados.

JSON elimina el primer problema de forma directa. Casi todas las API web ya envían y reciben JSON, y todos los lenguajes habituales incluyen un analizador para él, así que una Card puede viajar por los mismos canales que el resto de los datos de una aplicación. JSContact también fija la estructura interna del objeto. Un nombre se divide en componentes tipados, y una colección como la lista de correos es un mapa con identificadores explícitos. El software ya no tiene que adivinar dónde termina una entrada y empieza la siguiente.

Se espera que ambos formatos coexistan. Una empresa que hoy guarda sus contactos en archivos vCard no tiene que migrar, y un servicio que habla JSON puede seguir intercambiando datos con clientes basados en vCard mediante una capa de conversión. Esa capa de conversión es el tema de la siguiente sección.

Cómo se asigna una Card de JSContact a vCard

El RFC 9555 define cómo se convierte una Card de JSContact en una vCard y viceversa. Es una especificación de correspondencia. Describe cómo trasladar el significado de una tarjeta de un formato al otro, y no promete que un viaje de ida y vuelta devuelva exactamente los mismos bytes.

Los campos simples se corresponden de manera evidente. El nombre de una persona equivale a las propiedades N y FN de vCard, las direcciones de correo a EMAIL, los teléfonos a TEL, las organizaciones a ORG y las direcciones postales a ADR. La diferencia estructural se ve de inmediato. vCard repite una propiedad por cada valor, una línea tras otra, mientras que JSContact agrupa los valores relacionados en un mapa indexado por un identificador. Cada entrada lleva además su propio contexto, como trabajo o privado, que vCard expresa mediante parámetros de la propiedad.

Los casos interesantes son aquellos en los que un formato tiene un concepto que el otro no tiene:

• Las propiedades que existen en vCard pero no tienen un campo propio en JSContact necesitan un lugar donde alojarse en la tarjeta convertida, para que un conversor pueda restaurarlas después.
• Las funciones que solo existen en JSContact, como los valores con variantes de idioma, necesitan una regla que indique cómo debe representarlas una salida en vCard.
• Los parámetros que un formato define y el otro no deben trasladarse a una ubicación de extensión o descartarse.
• El texto libre de vCard a veces cae en un punto donde JSContact espera un valor estructurado, así que el conversor debe interpretar la cadena o conservarla tal como está escrita.

Los nombres exactos de estas propiedades y la regla para cada caso están en el texto del RFC 9555. Tómelos de allí y no de un resumen, incluido este, porque la tabla a nivel de campo es donde los conversores se diferencian. Que una herramienta concreta pierda información depende de qué propiedades usen sus datos y de cuán completamente implemente el documento. Si un proveedor anuncia una conversión sin pérdidas, tome una muestra de sus propias tarjetas, conviértalas en ambos sentidos y compare los resultados con la lista de propiedades del RFC 9555.

Dos documentos complementarios completan la familia. El RFC 9554 define las extensiones de vCard que JSContact necesita, y el RFC 9555 depende de ellas al convertir. Todo lo que lea sobre JSContact como formato remite a estos tres números.

Dónde encaja el RFC 10050

El RFC 10050 es el número del tema de búsqueda de esta guía, y el RFC Editor publica su encabezado en rfc-editor.org/rfc/rfc10050. Ese encabezado determina cómo se relaciona el documento con la familia JSContact. Indica un título, una fecha de publicación, un estado y los campos Updates y Obsoletes. Una línea Updates u Obsoletes que nombre el RFC 9553, 9554 o 9555 sitúa el documento dentro de la familia JSContact, y el resumen explica entonces qué modifica: el objeto Card, un registro o las reglas de conversión.

Hasta que haya leído ese encabezado, cite el RFC 9553 para todo lo relativo al formato de la Card. Es la especificación base, y un documento posterior que la actualiza remite a ella. La línea de estado también importa. Proposed Standard, Informational y Experimental tienen distinto peso, y un proveedor que afirma admitir el RFC debería poder decirle cuál corresponde.

Para un SEO técnico, la pregunta útil es qué alcanzaría un cambio en esta familia. Una actualización de los documentos de JSContact cambia lo que implementan los desarrolladores de sistemas de contactos: CRM, libretas de direcciones, servidores de correo y las bibliotecas intermedias. No cambia el HTML de sus páginas ni los datos estructurados que Google lee en ellas. Eso sigue siendo el vocabulario de schema.org, que describe la siguiente sección.

Qué significa JSContact para el trabajo SEO

En una página web, el vocabulario que importa es schema.org. ContactPoint y Organization describen allí a una empresa. Se incrustan como JSON-LD o microdatos, y un crawler los lee desde el HTML. La documentación de Search Central de Google explica el marcado Organization y enumera las propiedades que lee. El vocabulario existe para que un buscador pueda vincular una página con una entidad con nombre, con teléfono, correo electrónico y horario de atención.

JSContact tiene otra función. Una Card es un objeto JSON que una aplicación entrega a otra: un CRM que exporta el registro de un cliente, un servidor de correo que sincroniza una libreta de direcciones, una aplicación de contactos que importa un archivo. Los datos viajan por una API entre sistemas que esperan ambos el formato. En ese intercambio no participa ninguna página web pública ni ningún crawler.

Ambos son JSON y ambos contienen nombres, correos y teléfonos, así que un cliente que oyó hablar de datos de contacto estructurados en una reunión puede suponer que uno cubre al otro. No es así. Un ContactPoint en su página de contacto describe la página ante un buscador. Una Card de JSContact describe a una persona ante un cliente de correo.

Publicar una Card en una página como bloque JSON-LD, por tanto, no aporta nada. JSON-LD funciona porque los buscadores leen el vocabulario declarado en su contexto, y schema.org es el vocabulario que leen. Un objeto JSContact no tiene detrás un acuerdo semejante, de modo que el bloque quedaría en su HTML sin que nadie lo lea. Además, podría exponer los datos personales de un individuo con nombre a todo scraper que visite la página.

En lo que respecta a Google, las páginas de Search Central describen el marcado schema.org, y JSContact no aparece en la documentación de Organization. Nada publicado dice cómo trata Google el formato internamente, así que esta guía no afirma nada al respecto. Tampoco hay nada publicado que le dé un motivo para actuar.

La ganancia práctica es de vocabulario. Si un cliente usa un CRM, una libreta de direcciones compartida o un servicio de correo basado en JMAP, quienes mantienen esos sistemas pueden mencionar JSContact, vCard o la exportación de contactos. Usted ya puede ubicar esos términos: describen cómo circulan los registros de contacto entre herramientas internas y quedan fuera del alcance de su auditoría.

Cuando ese mismo cliente pregunte por qué el teléfono del sitio difiere del que aparece en su Perfil de Empresa de Google, vuelve a terreno conocido. Es un problema de ContactPoint y de coherencia de datos locales, y se comprueba como siempre: comparando lo que dicen las páginas con lo que dicen los demás listados.

Límites, datos personales y un paso para hoy

JSContact no cambia su posicionamiento. Lo mismo vale para cualquier RFC que lo actualice: un estándar para mover datos de libretas de direcciones entre sistemas no le da a un buscador ningún motivo para premiar sus páginas. Quien lo venda como táctica de posicionamiento está adivinando. Pegar una Card en una página cuesta esfuerzo y no devuelve nada.

Los datos personales añaden un segundo límite. Una tarjeta de contacto puede contener nombres, teléfonos personales, domicilios y direcciones de correo. Si un rastreo o una exportación toca páginas o archivos con esos datos, el RGPD o una ley nacional equivalente puede aplicarse a cómo los recopila, almacena y comparte. Esta guía no hace ninguna afirmación legal sobre lo que exige su caso. Antes de exportar campos de contacto del sitio de un cliente a una hoja de cálculo o a un informe compartido, pregunte al responsable de protección de datos del cliente qué permite. Mantener los datos de rastreo en su propio equipo reduce los lugares desde los que pueden filtrarse, y deja abierta la cuestión legal.

La conversación sobre JSContact puede llegar a sus auditorías por una sola puerta: los datos estructurados que inspecciona en páginas que muestran datos de contacto. Ahí es donde una discrepancia le cuesta algo, y es una comprobación que puede hacer hoy. Abra su página de contacto y la página de inicio, y revise el JSON-LD en el código fuente. Confirme que el nombre de la Organization, el teléfono y el correo coinciden con lo que ven los visitantes en la página, y que todo ContactPoint tenga un contactType correcto. Luego haga la misma comprobación en las demás plantillas que muestran datos de contacto, como el pie de página, las páginas de sucursales y la página “Acerca de”. Corrija primero las discrepancias en el marcado, porque son las que los buscadores pueden leer.

Abra ahora el código fuente de su página de contacto y compare el teléfono de su JSON-LD con el que aparece impreso en la página.