Datos estructurados en 2026: qué marcar y qué no

Desde que las respuestas generativas se comieron una parte de los clics, el marcado con Schema.org se ha vuelto a vender como la llave maestra: márcalo todo y la IA te citará. Es una promesa cómoda y no se sostiene con los datos que hay hoy.

Lo que sigue separa las tres cosas que la gente mezcla: lo que el marcado consigue de verdad, lo que no consigue, y el orden en el que conviene implementarlo si el tiempo es limitado.

Para qué sirve el marcado hoy

Los datos estructurados son una capa de JSON-LD que le dice a una máquina qué es cada cosa de tu página: esto es un producto, esto su precio, esto una valoración media, esto el autor del artículo. Sirven para tres cosas y ninguna es mágica:

• Optar a resultados enriquecidos. Estrellas, precio, disponibilidad, migas de pan, fechas. Es el beneficio directo y medible: mismo puesto, más superficie en pantalla y más clics.
• Eliminar ambigüedad. Un precio dentro de offers.price no se puede confundir con un número suelto en un párrafo. Para un sistema que extrae datos, eso es la diferencia entre entender y adivinar.
• Dejar constancia de entidades. Quién publica, quién firma, con qué otras entidades se relaciona. Es la parte que conecta con la discusión sobre E-E-A-T: no la demuestra, pero la hace legible.

Lo que midió el estudio de 1.885 páginas

Aquí está el dato que falta en casi todos los artículos sobre el tema. Ahrefs siguió 1.885 páginas que añadieron JSON-LD entre agosto de 2025 y marzo de 2026 y comparó sus citas en asistentes antes y después. El resultado: ninguna subida relevante en ninguna plataforma, y en AI Overviews una caída del 4,6 %, pequeña pero estadísticamente significativa.

Enfrente hay cifras mucho más entusiastas circulando —un 73 % más de probabilidad de ser seleccionado, un 317 % más de citas combinando marcado y contenido multimodal— que salen de paneles de terceros sin grupo de control. Cuando un estudio con antes y después dice una cosa y una correlación sin control dice la contraria, la apuesta razonable es la primera.

La postura oficial encaja con eso: Google confirmó en 2026 que el marcado sigue siendo valioso para resultados enriquecidos aunque no hace falta ningún marcado especial para aparecer en las respuestas generativas.

Qué marcar y en qué orden

Con tiempo limitado, este es el orden que maximiza retorno:

1. Organization en todo el sitio. Nombre, logo, URL, perfiles oficiales. Una vez, en la plantilla base, y con un @id estable al que puedan apuntar los demás bloques.
2. BreadcrumbList en cada página interior. Barato, sale en resultados y describe tu arquitectura mejor que ninguna otra señal.
3. El tipo principal de tu contenido. Product con offers si vendes (el resto del trabajo de una tienda está en la guía de SEO para tiendas online); Article con autor y fechas si publicas; LocalBusiness con horario y dirección si atiendes en un local —lo que además alimenta las recomendaciones de los asistentes, como cuenta la guía de SEO local con IA—; JobPosting, Event o Recipe si es lo tuyo.
4. ItemList en los listados. Categorías, colecciones, índices. Describe el conjunto en vez de dejar que se infiera de un montón de enlaces.
5. FAQPage, con expectativas bajas. Ya casi no genera desplegable en resultados, pero cuesta cero si ya tienes las preguntas escritas.

Y una regla que ahorra discusiones: si no está visible en la página, no se marca. El marcado describe el contenido, no lo sustituye ni lo adorna.

Generar el JSON-LD con IA sin inventar propiedades

Este es uno de los trabajos donde un modelo de lenguaje rinde bien: es transformación de formato con un esquema conocido. También es uno donde alucina con elegancia, inventando propiedades que suenan perfectas y no existen en el vocabulario.

El prompt que evita casi todos los problemas tiene cuatro piezas: tipo exacto, datos reales pegados, prohibición explícita de rellenar huecos y formato de salida.

Prompt base. «Genera JSON-LD de tipo Product para esta ficha. Te pego el HTML visible. Usa solo propiedades del vocabulario oficial de Schema.org para ese tipo. Si un dato no está en el HTML, omite la propiedad: no la inventes ni pongas un valor de ejemplo. Devuelve solo el bloque JSON, sin explicación.»

Las dos frases centrales son las que hacen el trabajo. Sin ellas obtendrás un aggregateRating de 4,8 sobre 127 opiniones en una ficha que no tiene ni una, que es exactamente el tipo de marcado que sí acarrea una acción manual. El mecanismo por el que un modelo rellena huecos con material verosímil está explicado en la guía de alucinaciones.

Dos usos más donde compensa:

• Auditar lo que ya tienes. Pégale el JSON-LD actual y pídele que liste propiedades obsoletas, valores que no cuadran con el HTML y campos recomendados que faltan.
• Convertir la plantilla, no la página. Si tienes mil fichas, lo que se genera una vez es la función que produce el bloque; pedir mil bloques uno a uno es tirar tiempo y dinero. La lógica es la misma que en el SEO programático.

Cómo validarlo antes de publicar

Media hora, en este orden:

1. Validador de resultados enriquecidos para saber si tu tipo es apto y qué falta. Los avisos amarillos son propiedades recomendadas; los rojos, impedimentos reales.
2. Validador de Schema.org para la sintaxis y las propiedades inventadas, que es donde caza los errores de los modelos.
3. Compara con la página renderizada. Cada valor del JSON tiene que existir en el HTML que ve la persona. Si tu sitio pinta el contenido con JavaScript, comprueba también que el bloque llega en el HTML inicial: en una aplicación sin renderizado en servidor es fácil emitirlo solo en cliente, y ahí no lo ve nadie. Cómo detectarlo está en la auditoría técnica.
4. Search Console, dos semanas después. El informe de mejoras dice qué se ha validado de verdad. Es el único veredicto que cuenta.

Cómo está montado en este sitio

Por si sirve de referencia concreta: este sitio es una aplicación de página única, así que todo el marcado se emite desde el servidor, nunca desde los componentes de la interfaz. Cada página comparte un bloque de Organization con identificador estable, sus migas de pan, el tipo que le corresponde —Article en las guías, ItemList en los listados— y un FAQPage cuando hay preguntas de verdad.

La regla interna es que el marcado no vive en dos sitios: si estuviera también en el cliente se duplicaría, y un bloque duplicado con valores distintos es peor que ninguno. Merece la pena revisar esto en cualquier proyecto con framework moderno, porque es el fallo más común y el más silencioso.

Errores que cuestan avisos o posiciones

1. Marcar lo que no se ve. Valoraciones sin opiniones, precios que no son los del carrito, autores inventados. Es la vía rápida a una acción manual.
2. Copiar un bloque de ejemplo con sus datos. Pasa más de lo que parece: fichas en producción declarando ser un producto de demostración a 19,99 €.
3. Emitirlo solo en el cliente. Si el bloque aparece después de ejecutar JavaScript, media internet no lo lee.
4. Marcarlo todo. Veinte tipos anidados no multiplican nada; multiplican el mantenimiento y la probabilidad de contradicciones.
5. Esperar que sustituya al contenido. El marcado describe lo que hay. Si lo que hay no aporta nada, el JSON-LD no lo arregla.