Datos estructurados: qué marcar y qué no

Los datos estructurados no suben posiciones: cambian el aspecto de tu resultado en la página de búsqueda, y un resultado con preguntas desplegables o migas de pan se lleva más clics desde la misma posición. Esa es toda la promesa, y es suficiente para que valga la pena hacerlo bien.

Lo que sí puede bajarte es marcar cosas que no están en la página. Google llama a eso spam de datos estructurados y lo trata como lo que es: prometer algo y no cumplirlo.

Qué formato usar

JSON-LD, en un <script type="application/ld+json">. Es el que recomienda Google y el único que se puede leer sin bucear en el HTML.

Las alternativas —microdatos y RDFa— van incrustadas en las etiquetas del contenido, lo que suena bien y en la práctica significa que un cambio de maquetación rompe el marcado sin avisar. Con JSON-LD el bloque está aparte y se genera de los mismos datos que pinta la página.

Los tipos que sirven de verdad

Hay cientos de tipos en schema.org y una minoría produce algún efecto visible. Estos son los que rinden:

Tipo	Para qué	Qué cambia en el resultado
Organization / WebSite	Una vez para todo el sitio	Panel de marca, caja de búsqueda
BreadcrumbList	Cualquier página con jerarquía	La ruta en vez de la URL cruda
FAQPage	Páginas con preguntas y respuestas	Preguntas desplegables bajo el resultado
HowTo	Guías paso a paso reales	Los pasos listados
Article / BlogPosting	Artículos	Fecha, autor, elegibilidad para agregadores
Product / Offer	Productos con precio	Precio y disponibilidad

Lo demás casi nunca compensa el esfuerzo. Y una advertencia: la elegibilidad para resultados enriquecidos cambia con el tiempo. Google ha reducido varias veces dónde muestra FAQPage y HowTo. Marcarlos sigue estando bien —también los leen los asistentes de IA—, pero no montes tu estrategia sobre que salga un formato concreto.

La regla que evita todos los problemas

Marca solo lo que la persona ve en la página.

Suena banal y resuelve el noventa por ciento de los casos:

• ¿El schema dice que hay cinco preguntas frecuentes? Tiene que haber cinco preguntas frecuentes visibles.
• ¿Dice que el artículo se actualizó ayer? Que la fecha aparezca en la página.
• ¿Declara HowTo con seis pasos? Que existan seis pasos numerados y visibles.

El fallo no es marcar de más de golpe: es la desincronización lenta. Alguien reescribe el artículo, quita dos preguntas, y el JSON-LD sigue prometiendo cinco porque vive en otro sitio.

Cómo se evita esa desincronización

La solución estructural es no escribir el schema a mano. Genéralo de la misma fuente que pinta el contenido.

En nuestro blog, por ejemplo, el FAQPage no se declara en la cabecera del artículo: se extrae del cuerpo del texto. El código busca la sección de preguntas frecuentes en el Markdown, lee las preguntas y sus respuestas, y con eso construye el JSON-LD. El efecto práctico es que si alguien borra una pregunta del artículo, desaparece del schema en el mismo commit. No hay forma de que digan cosas distintas.

Lo mismo con los pasos de un HowTo: se leen de los encabezados numerados del propio texto. Y con las migas de pan, que salen de la misma lista que pinta la navegación visible.

Es más trabajo la primera vez y elimina una clase entera de errores para siempre.

Errores concretos que se ven mucho

Marcar HowTo en algo que no es una guía. Numerar secciones es un recurso de redacción normal. «Los 7 límites que nadie lee» tiene encabezados numerados y no es un procedimiento: no se ejecutan en orden. Ese es ItemList, no HowTo.

Poner las mismas preguntas frecuentes en todas las páginas. Un bloque de FAQ repetido en el sitio entero no aporta nada y se lee como intento de manipular el formato del resultado.

Inventar valoraciones. Marcar AggregateRating con reseñas que no existen es de las pocas cosas que producen una acción manual. No lo hagas.

Marcar contenido detrás de una cuenta. Si el rastreador no puede ver lo que el schema describe, el marcado no vale nada.

Dejar varios bloques que se contradicen. Dos Article en la misma página con fechas distintas es peor que ninguno.

Cómo comprobarlo

Tres niveles, del más barato al más lento:

1. Que sea JSON válido. Suena a broma hasta que una comilla sin escapar rompe el bloque entero y nadie lo ve. Métetelo en el script de comprobación de SEO: recorre los bloques application/ld+json de cada página y prueba a parsearlos. Nosotros lo tenemos ahí, junto al resto de comprobaciones de SEO técnico.
2. La prueba de resultados enriquecidos de Google, para saber si el tipo es elegible.
3. El informe de mejoras de Search Console, semanas después, que es donde aparecen los errores en el sitio real.

Una ventaja que ya no es solo de Google

Los datos estructurados se escribieron para buscadores y ahora los leen también los asistentes de IA, que agradecen mucho un bloque JSON con los datos limpios frente a adivinarlos del HTML. Un FAQPage bien hecho es literalmente pares de pregunta y respuesta listos para citar.

Va en la misma dirección que el llms.txt y el resto de lo que contamos en cómo hacer que la IA cite tu sitio: darle a la máquina el dato masticado en vez de obligarla a extraerlo.

Preguntas frecuentes

¿Los datos estructurados mejoran el posicionamiento? No de forma directa: no son un factor de ranking. Lo que mejoran es cómo se ve tu resultado, y eso sube la tasa de clics con la misma posición. También ayudan a que un buscador o un asistente entienda de qué va la página, lo cual influye de forma indirecta.

¿Puedo poner varios bloques JSON-LD en una página? Sí, y es lo normal: uno para la organización, otro para las migas de pan, otro para el artículo. Lo importante es que no se contradigan entre ellos.

¿Qué pasa si marco algo que no está en la página? En el mejor caso Google ignora el marcado. En el peor, si el patrón se repite, llega una acción manual que retira los resultados enriquecidos de todo el sitio. No compensa.

¿Sigue funcionando FAQPage? Google ha reducido dónde lo muestra, así que no cuentes con las preguntas desplegables como algo garantizado. Aun así merece la pena marcarlo: es barato si se genera solo, y los asistentes de IA lo aprovechan.

¿Hace falta una biblioteca para generar JSON-LD? No. Son objetos que se serializan con JSON.stringify. Una función por tipo, alimentada de los mismos datos que pinta la plantilla, es todo lo que hace falta y evita la dependencia.