JSON-LD roto no se ve: siete pruebas y tres campos que no se inventan

Si quieres que Google, o un asistente de inteligencia artificial, entienda a qué se dedica tu web, esta nota va de la pieza que se lo cuenta. Verás qué comprobamos en ella y qué dejamos en blanco a propósito.

Los datos estructurados son un bloque de texto dentro de la página que ninguna persona ve. Le dicen a un buscador, o a un modelo, quién eres, qué vendes y qué es cada página. Se escriben en un formato llamado JSON-LD, con el vocabulario de schema.org: la lista de términos que los buscadores entienden.

Si el bloque está roto, la página se ve igual y el build pasa igual. El único efecto es que un motor deja de entender el sitio. En silencio, durante meses.

Por eso el JSON-LD es la parte del sitio con más pruebas automáticas por línea de código: siete, para un archivo de doscientas líneas.

Todo va en un único <script> con @graph, no en varios bloques sueltos. Un @id es el identificador de cada ficha; si van juntas, unas se resuelven contra otras. Así el motor ve un grafo conectado, y no tres fichas que se parecen.

La tentación con schema.org es rellenar todos los campos posibles, porque algunos pintan estrellas y precios en el resultado de búsqueda. Tomamos tres decisiones en contra.

• Sin offers ni aggregateRating. El primero es el precio; el segundo, la nota media de las reseñas. El producto no tiene ni precio público ni reseñas. Son las dos propiedades que más tienta inventar, y además sería mentir en el único sitio de la web donde la mentira queda escrita en un formato que se lee solo. Una persona matiza una exageración de marketing; una máquina la toma literal.
• sameAs vacío. Ese campo enlaza los perfiles sociales que confirman que la empresa es quien dice ser. Un sameAs con una cuenta abandonada es peor que ninguno: le dice al buscador que esa cuenta te representa. Hasta que haya perfiles vivos, nada.
• BlogPosting y no Article. Son dos tipos distintos dentro del mismo vocabulario. Article exige una imagen y estas notas no la tienen. El tipo se elige por los campos que de verdad se pueden dar, no por el que suena más serio.

Un campo que existe no obliga a rellenarlo. Es una pregunta, y a veces la respuesta honesta es no contestar.

• Un Service distinto por página de servicio. Las cinco páginas de servicio comparten casi todo el texto visible, y eso es deliberado. El JSON-LD le da a cada una una descripción propia para la máquina. Es contenido único por página sin escribir una palabra nueva, y es la forma exacta en que un motor generativo lee «qué vende esta gente».
• about en cada nota, apuntando al servicio del que nace, dentro del grafo. Un enlace en el texto dice «relacionado»; un about con @id dice «la misma casa hablando de lo mismo».
• Migas de pan sin barra visible. Las migas son el rastro de dónde estás: sitio, sección, página. El nuestro no las enseña en pantalla y aun así las declara. Son lo que produce la línea «4dim › Notas › …» bajo el resultado, en vez de la URL cruda.
• alternateName. «4dimntion» se escribe mal a la primera. Declarar que «4dim» y «4dimntion» nombran a la misma empresa es la única respuesta técnica a un nombre que se rompe en las búsquedas.

Circula la idea de que los datos estructurados son lo que hace que un motor generativo te cite. No lo creemos, y el comentario del propio código lo dice: lo que trae una cita son las cifras con fuente.

Lo que el schema hace es que la cita, cuando llega, sea correcta. Que el motor sepa cuál es el nombre de la empresa, qué página es un servicio y cuál una nota, y de qué fecha es cada cosa. Un motor que te cita mal es peor que uno que no te cita.

• Probar el JSON-LD solo: que se pueda analizar, que las URL sean absolutas, que los @id cuadren, que se escape </.
• Un solo bloque con @graph por página.
• No inventar precios, reseñas ni perfiles. Dejar vacío lo que no existe.
• Generar el JSON-LD desde los mismos datos que generan la página visible.
• Esperar de él precisión, no visibilidad.