Structured Data

Definicion rapida

Structured Data son datos estructurados y legibles por maquina dentro del codigo de una pagina web. Indican con mas precision a los motores de busqueda que aparece en la pagina: un producto, articulo, persona, organizacion, video, breadcrumb, evento, oferta de empleo o resena.

En SEO, Structured Data normalmente se implementa con el vocabulario Schema.org y el formato JSON-LD. Schema.org aporta los terminos, por ejemplo Product, Article u Organization. JSON-LD es el formato tecnico que se usa a menudo para anadir esas declaraciones al HTML.

La idea principal: Structured Data no es un truco de ranking. Es una capa de descripcion. Ayuda a los sistemas de busqueda a entender con mas claridad el contenido, las relaciones y los tipos de pagina. Eso puede hacer que una pagina sea elegible para ciertos rich results. Pero Google no garantiza un rich result solo porque el markup sea tecnicamente valido.

Explicacion sencilla

Una pagina web esta hecha primero para personas. Las personas ven encabezados, precios, autores, imagenes, valoraciones, fechas y navegacion. Los motores pueden inferir mucho desde HTML, texto, layout, enlaces y contexto. Pero no todo es evidente.

Structured Data anade una segunda capa. Esa capa no dice solo "hay texto aqui". Dice "este es el precio", "esta es la disponibilidad", "este es el autor", "esta es la fecha de publicacion" o "este es el camino dentro de la jerarquia del sitio".

Imagina etiquetas en un almacen bien organizado. El producto en si no cambia. Pero etiquetas claras ayudan a cada sistema a entender que es, donde pertenece y que propiedades importan.

Buen Structured Data no inventa informacion. Describe lo que los usuarios realmente pueden ver en la pagina o lo que pertenece de verdad a esa pagina. Cuando el contenido visible y el markup se separan, no aparece una ventaja SEO; aparece un problema de calidad.

Por que Structured Data importa para SEO

Structured Data hace que el significado sea mas explicito. Sin markup, un sistema de busqueda debe inferir: este numero es un precio, una valoracion o un ID de producto? Esta persona es autora, entrevistada o contacto? Esta lista es navegacion, instrucciones de receta o variantes de producto?

Con buen markup, el sistema recibe pistas estandarizadas. Eso puede apoyar procesamiento, aclarar entidades y alimentar apariencias de busqueda mas ricas. Ejemplos: informacion de producto, breadcrumbs, detalles de eventos, datos de organizacion, videos, metadatos de articulo y review snippets.

El valor es especialmente claro en sitios grandes. Un solo articulo de blog puede entenderse sin mucha ayuda. Pero en 10 000 paginas de producto, cientos de ubicaciones o muchos perfiles de autor, una estructura consistente se vuelve mucho mas importante. Structured Data hace que los templates sean mas faciles de interpretar a escala.

Aun asi, el markup no reemplaza buen contenido. Un feed de producto pobre no se vuelve bueno por tener schema. Una resena oculta no se vuelve confiable. Una pagina sin intencion de busqueda clara no se vuelve util porque contiene JSON-LD. Structured Data es una herramienta de comprension y presentacion, no un sustituto de sustancia.

Structured Data, Schema Markup y JSON-LD

Estos terminos se mezclan a menudo, pero no son identicos.

Structured Data es el concepto amplio. Significa que la informacion se ofrece en una forma estructurada para que las maquinas puedan leerla mas facilmente.

Schema Markup normalmente se refiere al uso practico del vocabulario Schema.org en SEO. Schema.org define tipos y propiedades como Product, Article, Organization, Person, BreadcrumbList, Event, VideoObject y FAQPage.

JSON-LD es un formato. Usa JSON y conceptos de linked data para colocar esas declaraciones en el codigo de la pagina. Google recomienda JSON-LD para datos estructurados cuando esta soportado para el tipo especifico. Microdata y RDFa tambien son formatos soportados para elegibilidad de rich results, pero JSON-LD suele ser mas facil de mantener.

En resumen: Structured Data es la idea, Schema.org es el idioma y JSON-LD suele ser la escritura.

Pequeno ejemplo JSON-LD

Un bloque Article simplificado puede verse asi:

``json { "@context": "https://schema.org", "@type": "Article", "headline": "Core Web Vitals explicado de forma sencilla", "datePublished": "2026-06-21", "dateModified": "2026-06-21", "author": { "@type": "Person", "name": "Matthias Ramahi" }, "publisher": { "@type": "Organization", "name": "Contextter" } } ``

El ejemplo muestra la idea central: la pagina no contiene solo texto. El codigo explica el papel de cada informacion. El titulo es una headline, la fecha es una fecha de publicacion, la persona es el autor y la organizacion es el publisher.

En la practica, el markup debe coincidir con el contenido visible y con la documentacion de Google para el tipo concreto. Si falta un campo obligatorio o un valor no encaja con la pagina, la pagina puede no ser elegible para el rich result.

Formatos de Structured Data

JSON-LD

JSON-LD normalmente se anade como un bloque script en el HTML. Esta separado del HTML visible. Eso facilita el mantenimiento en CMS modernos, React, Next.js y sistemas de templates.

La gran ventaja es que los datos pueden generarse directamente desde el CMS, catalogo de productos, perfiles de autor o tablas de navegacion. Los desarrolladores no tienen que pegar atributos a cada elemento HTML visible. Si el modelo de datos esta limpio, JSON-LD puede publicarse de forma consistente en muchas paginas.

Microdata

Microdata se integra directamente en elementos HTML visibles. Puede funcionar en paginas simples, pero se vuelve mas dificil de gestionar en layouts complejos. Cuando un disenador o desarrollador cambia despues la estructura HTML, el markup puede romperse sin querer.

RDFa

RDFa tambien esta basado en HTML y puede expresar declaraciones estructuradas. Es menos comun en el SEO diario que JSON-LD. Lo importante es que Google soporta varios formatos para rich results, siempre que se respeten las directrices tecnicas y de calidad.

Que significan realmente los rich results

Los rich results son resultados de busqueda que van mas alla del enlace azul clasico. Pueden incluir imagenes, precios, valoraciones, breadcrumbs, datos de producto, informacion de eventos u otros elementos visuales.

Structured Data puede calificar una pagina para esas apariencias. "Calificar" es la palabra importante. No significa que Google siempre mostrara el rich result. La apariencia real puede variar por consulta, dispositivo, ubicacion, contexto de busqueda, calidad, politicas y decision de Google.

Por eso conviene tener expectativas sanas. Structured Data tiene exito cuando describe de forma correcta, actual, completa y consistente lo que hay en la pagina. El rich result es un resultado posible, no la unica definicion de exito.

Tipos de markup que suelen ser utiles

Article, BlogPosting y NewsArticle

Estos tipos ayudan con contenido editorial. Pueden aclarar headline, autor, fecha de publicacion, fecha de modificacion, imagenes y publisher. Para blogs, paginas de conocimiento, glosarios y noticias, suele ser una capa base.

Product y Offer

Product markup puede describir nombre, imagen, precio, disponibilidad, valoracion, marca y variantes. En ecommerce es especialmente valioso. Pero los datos deben ser exactos. Precios obsoletos o resenas inventadas no son solo errores tecnicos; danan la confianza.

BreadcrumbList

Breadcrumb markup describe la posicion de una pagina en la estructura del sitio. No es espectacular, pero es util porque hace explicita la jerarquia y la navegacion.

Organization, LocalBusiness y Person

Estos tipos ayudan a estructurar identidad. Pueden describir nombres, logos, puntos de contacto, ubicaciones, perfiles y relaciones. Importan para comprension de entidades y senales de identidad consistentes, incluso cuando no crean snippets llamativos de inmediato.

VideoObject, Event, JobPosting y otros tipos especializados

Los tipos especializados pueden ser potentes cuando el tipo de pagina realmente encaja. Por eso los equipos siempre deberian revisar la Search Gallery actual de Google antes de implementar. No todos los tipos de Schema.org producen un rich result de Google, y las features soportadas pueden cambiar.

Directrices que conviene tomar en serio

La regla mas importante es simple: marca solo informacion que encaja con la pagina y que es visible o logicamente disponible para usuarios. Si JSON-LD describe una valoracion, autor, precio o evento, la pagina tambien deberia mostrar claramente esa informacion.

Las expectativas de calidad de Google incluyen informacion actual, relevancia con el contenido principal, nada enganoso, nada irrelevante y ningun intento de enganar a usuarios o sistemas de busqueda. Cada tipo de rich result tambien puede tener sus politicas especificas.

Tecnicamente, Google debe poder rastrear la pagina y los recursos relevantes. Structured Data en paginas bloqueadas por noindex, robots.txt o controles de acceso no puede procesarse de forma util para Search. Las imagenes referenciadas en markup tambien deberian ser rastreables e indexables.

La completitud es otro punto subestimado. Si un tipo de rich result tiene campos obligatorios, deben estar presentes. Los campos recomendados no siempre son obligatorios, pero pueden hacer que el resultado sea mas util para usuarios.

Implementar como modelo de datos, no como copy-paste

Mal Structured Data suele empezar con copy-paste. Alguien toma un ejemplo de documentacion, cambia algunos valores y deja el resto hardcoded. Puede funcionar para una pagina de prueba, pero escala mal.

Un mejor enfoque empieza con el modelo de datos. El tipo de pagina decide que tipos schema hacen falta. Los valores vienen de fuentes reales: precio desde el feed de producto, autor desde el CMS, breadcrumb desde navegacion, fecha de evento desde la base de eventos, datos de organizacion desde una fuente central de marca.

Esto reduce drift. Cuando cambia un precio, tambien cambia el markup. Cuando se actualiza un perfil de autor, la salida estructurada sigue consistente. Cuando falta un campo CMS, el template puede avisar o saltar markup invalido en vez de publicar malos datos.

Testing y validacion

Rich Results Test

El Rich Results Test de Google comprueba si una URL o fragmento de codigo es valido para rich results soportados por Google. Es el test mas importante cuando el objetivo es un rich result de Google.

URL Inspection en Search Console

URL Inspection muestra como Google ve una URL especifica. Ayuda despues del deploy porque prueba el contexto rastreado de una pagina real, no solo un snippet aislado.

Schema Markup Validator

Schema Markup Validator comprueba de forma mas amplia si el markup Schema.org se entiende sintactica y estructuralmente. Es util cuando el markup no esta ligado directamente a un rich result de Google o cuando quieres validar la capa Schema.org por separado.

Informes de Search Console

Search Console puede mostrar informes para ciertos tipos de datos estructurados cuando Google detecta markup relevante. Estos informes importan porque revelan patrones por grupos de URL. Un error de template puede afectar cientos de URLs.

Ejemplo realista

Un ecommerce tiene 8 000 paginas de producto. Nombre, imagenes, precio, disponibilidad, marca y resenas son visibles. El equipo SEO quiere publicar Product markup para que Google procese la informacion con mas claridad y las paginas puedan ser elegibles para apariencias de producto relevantes.

En vez de copiar JSON-LD manualmente dentro de templates, el equipo define un mapping: name viene del titulo de producto, image de imagenes aprobadas, offers.price del precio actual, offers.availability del estado de stock, y aggregateRating solo cuando existen resenas reales y visibles.

Durante la validacion con Rich Results Test, algunos productos antiguos no tienen disponibilidad. El equipo no inventa un valor. Arregla la fuente de datos. Luego prueba varios escenarios: disponible, agotado, variante, precio rebajado, producto sin resenas. Solo despues despliega el template.

Eso es buen trabajo de Structured Data: no perseguir snippets, sino traducir informacion real de pagina a un formato legible por maquina.

Errores frecuentes

• Marcar informacion que los usuarios no pueden ver en la pagina.
• Elegir el rich result mas atractivo aunque el tipo de pagina no encaje.
• Hardcodear precios, valoraciones o disponibilidad.
• Probar una sola URL ejemplo cuando el template tiene muchas variantes.
• Ignorar warnings hasta que un update de template los convierte en errores.
• Generar markup desde campos CMS vacios, eliminados u obsoletos.
• Confundir validez Schema.org con elegibilidad para rich result de Google.
• Vender Structured Data como booster directo de ranking.
• No revisar si documentacion, features o requisitos de Google cambiaron.
• Publicar varios bloques JSON-LD de plugins distintos que se contradicen.

Mini workflow

1. Define el tipo de pagina y el proposito del markup. 2. Revisa la documentacion actual de Google y el tipo Schema.org relevante. 3. Elige JSON-LD cuando el tipo lo soporte para Google Search. 4. Conecta cada propiedad con una fuente real de datos. 5. Asegura que la informacion marcada sea visible o logicamente disponible. 6. Prueba varias variantes de template, no solo una URL. 7. Valida con Rich Results Test y Schema Markup Validator. 8. Usa URL Inspection para URLs reales live despues del deploy. 9. Monitoriza informes de Search Console y tendencias de errores. 10. Documenta campos obligatorios, fuentes de datos y responsables.

Perspectiva Contextter

Contextter trata Structured Data como parte de una cadena mas amplia de calidad SEO. Una pagina no esta terminada solo porque el texto sea bueno. Tambien necesita entidades claras, metadatos limpios, informacion creible de autores y fuentes, estructura interna adecuada y senales tecnicas que los sistemas de busqueda puedan procesar.

Para equipos de contenido, esto importa mucho. Structured Data no deberia pegarse al final como ticket de desarrollo. Pertenece temprano al brief y al modelo de contenido: que entidades aparecen, quien es el autor, que datos deben mantenerse, que tipos de paginas deberian escalar de forma limpia.

Entonces el markup se convierte en infraestructura, no en decoracion. Ayuda a que el buen contenido sea claro no solo para humanos, sino tambien para sistemas que lo rastrean, interpretan, resumen y ubican en experiencias de busqueda.

Terminos relacionados

Estos terminos son buenos siguientes pasos:

• schema-markup
• rich-snippet
• knowledge-graph
• technical-seo-advanced
• content-optimization

Fuentes para la revision

• Google Search Central: Intro to structured data markup
• Google Search Central: General structured data guidelines
• Google Search Central: Search Gallery
• Google Search Central: Generate structured data with JavaScript
• Google Search Central: Rich Results Test
• Schema.org: Getting started with schema.org
• Schema.org: validator