Guía detallada

Guía de Marcado Schema.org: Datos Estructurados Completos

13 de julio de 20267 min de lectura

Ver contenido

Guía de Marcado Schema.org: Referencia Técnica Completa de Datos Estructurados

Introducción

Los datos estructurados son un vocabulario estandarizado—schema.org—que se agrega al HTML para describir explícitamente el contenido de una página a los motores de búsqueda: qué es (un artículo, un producto, una receta), quién lo creó y qué propiedades tiene. El UXR SEO Analyzer evalúa la presencia, validez y cobertura de tipos de datos estructurados en cada página analizada.

Esta guía cubre el formato recomendado, los tipos más usados, un ejemplo de implementación completo y los errores que más frecuentemente invalidan el marcado.

Por Qué Importan los Datos Estructurados

Sin datos estructurados, un motor de búsqueda debe inferir el significado del contenido a partir de señales indirectas: la posición del texto, las etiquetas HTML genéricas, el contexto circundante. Con datos estructurados, esa inferencia se vuelve una declaración explícita: "esto es un producto, cuesta 29.990 pesos, y tiene 89 reseñas con un promedio de 4.5 estrellas". Esa precisión no solo habilita resultados enriquecidos tradicionales—también es la forma en que sistemas de respuesta basados en IA extraen hechos verificables de una página en lugar de tener que interpretarlos.

JSON-LD Es el Formato Recomendado

Existen tres sintaxis para implementar schema.org: JSON-LD, Microdata y RDFa. Google recomienda explícitamente JSON-LD porque se declara en un bloque <script> separado del HTML visible, lo que facilita mantenerlo, generarlo dinámicamente y validarlo sin tocar el marcado de la página:

Sintaxis	Dónde Vive	Facilidad de Mantenimiento
JSON-LD	Bloque `<script>` independiente	Alta—se genera y actualiza sin tocar el HTML visible
Microdata	Atributos `itemscope`/`itemprop` en línea	Baja—mezclado con el marcado visual
RDFa	Atributos `vocab`/`typeof` en línea	Baja—requiere plantillas especializadas

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Título del artículo",
  "author": {
    "@type": "Person",
    "name": "Nombre del autor"
  },
  "datePublished": "2026-07-13",
  "dateModified": "2026-07-13"
}
</script>

Tipos Más Usados en SEO

Tipo	Uso Principal	Resultado Enriquecido
`Article` / `BlogPosting` / `NewsArticle`	Contenido editorial	Carrusel de noticias, autor y fecha visibles
`Product`	Páginas de producto e-commerce	Precio, disponibilidad y reseñas en el snippet
`FAQPage`	Secciones de preguntas frecuentes	Preguntas expandibles en el resultado de búsqueda
`BreadcrumbList`	Ruta de navegación de la página	Migas de pan en lugar de la URL cruda
`Organization`	Identidad de marca a nivel de sitio	Logo y datos de la entidad en el Knowledge Panel
`LocalBusiness`	Negocios con ubicación física	Horario, dirección y teléfono en el snippet

La Regla Más Importante: Marcar Solo Contenido Visible

La política de Google es explícita: los datos estructurados deben describir contenido que el usuario realmente puede ver en la página. Si el JSON-LD declara un precio de producto, ese precio debe existir en el contenido visible; si el FAQPage contiene preguntas y respuestas, esas preguntas y respuestas deben estar en la página. Marcar contenido que no es visible es una violación de las directrices y puede resultar en una acción manual.

Combinando Varios Tipos en Una Sola Página

Una página real casi nunca lleva un solo tipo de schema.org—normalmente combina varios bloques JSON-LD independientes que describen distintos aspectos de la misma página. Un artículo de blog típico incluye:

Article o BlogPosting para el contenido editorial en sí
BreadcrumbList para la ruta de navegación (Inicio > Blog > Categoría > Artículo)
Organization para identificar la marca editora, generalmente reutilizado en todas las páginas del sitio

Cada bloque puede vivir en su propio <script type="application/ld+json">, o combinarse en un arreglo @graph cuando las entidades se referencian entre sí mediante @id. Lo importante es que los identificadores sean consistentes: si el Organization tiene "@id": "https://ejemplo.com/#organization", el Article debe referenciar exactamente esa misma URL al declarar su publisher.

Datos Estructurados para E-commerce (Product)

Los sitios de e-commerce enfrentan una validación adicional: Google Merchant Center ejecuta su propia verificación de datos estructurados enfocada en Product, distinta de la Prueba de Resultados Enriquecidos genérica. Esa verificación detecta problemas que la prueba genérica no captura, como GTIN faltantes, discrepancias de precio entre el feed de productos y el marcado JSON-LD, o estados InStock declarados para productos que en realidad están agotados. Mantener el precio y la disponibilidad sincronizados entre el HTML visible, el JSON-LD y el feed de Merchant Center es esencial para evitar suspensiones.

Anidamiento de Tipos

Los tipos de schema.org se anidan entre sí para describir relaciones. Un Article anida un Person como autor; un Product anida una Offer para el precio y un AggregateRating para las reseñas:

{
  "@type": "Product",
  "name": "Nombre del producto",
  "offers": {
    "@type": "Offer",
    "price": "29.990",
    "priceCurrency": "CLP",
    "availability": "https://schema.org/InStock"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.5",
    "reviewCount": "89"
  }
}

Cómo Elegir el Tipo Correcto

Un error habitual es forzar un tipo genérico cuando existe uno más específico. Antes de marcar una página, pregúntate: ¿el contenido es editorial (usa Article), es un ítem comprable (usa Product), responde preguntas explícitas visibles en la página (usa FAQPage), o describe un negocio con ubicación física (usa LocalBusiness)? La documentación de la Galería de Búsqueda de Google lista, para cada resultado enriquecido soportado, exactamente qué tipo y qué propiedades usar—consultarla antes de improvisar evita la mayoría de los errores de tipo incorrecto.

Validación

Antes de publicar, todo marcado debe pasar por herramientas de validación: la Prueba de Resultados Enriquecidos de Google detecta errores críticos (propiedades requeridas faltantes) y advertencias no críticas (propiedades recomendadas ausentes) que igualmente conviene resolver para maximizar la elegibilidad de resultados enriquecidos. La Galería de Búsqueda de Google documenta, tipo por tipo, qué propiedades son obligatorias y cuáles son recomendadas.

Flujo de Trabajo de Validación Recomendado

Escribir el marcado JSON-LD junto al contenido visible que describe, nunca de forma aislada
Validar sintaxis JSON (comillas, comas, llaves) antes de probarlo contra las directrices de Google
Ejecutar la Prueba de Resultados Enriquecidos y resolver todos los errores críticos
Revisar las advertencias no críticas y evaluar si conviene añadir propiedades recomendadas
Publicar y monitorear el informe de Resultados Enriquecidos en Search Console para detectar regresiones

Errores Comunes

Contenido inventado: declarar un ratingValue o un precio que no aparece en la página
Propiedades requeridas faltantes: por ejemplo, un Article sin headline o sin datePublished
Tipo incorrecto: usar Article genérico cuando el contenido es claramente una Recipe o un Product
Múltiples bloques JSON-LD contradictorios: dos scripts que describen la misma entidad con datos distintos
@id inconsistentes: referencias cruzadas entre entidades que no resuelven al mismo identificador
Datos de ejemplo obsoletos: dejar nombres de autor, precios o fechas de placeholder de una plantilla que nunca se reemplazaron con contenido real

Datos Estructurados y Presupuesto de Rastreo

Los datos estructurados en sí no consumen presupuesto de rastreo de forma distinta al HTML normal—pero bloques JSON-LD inflados o duplicados añaden peso a la página, y las páginas con marcado roto que provocan re-rastreos repetidos para verificar si ya se corrigió pueden ralentizar indirectamente la frecuencia con que Google revisita las páginas más importantes de un sitio. Mantener el JSON-LD mínimo, válido desde el primer intento y sin bloques duplicados es una buena práctica tanto para los motores de búsqueda como para el rendimiento de carga de la página.

Mantenimiento a Largo Plazo

El marcado schema.org no es un ejercicio de una sola vez. Los sitios que generan páginas dinámicamente (CMS, e-commerce, plantillas de plantilla) deben tratar el JSON-LD como parte del template, no como un parche manual—de lo contrario, cada nueva página corre el riesgo de heredar valores de ejemplo o placeholders que nunca se reemplazaron con datos reales. Es recomendable incluir una verificación de datos estructurados en el proceso de revisión antes de publicar contenido nuevo, exactamente lo que automatiza el UXR SEO Analyzer.

Qué Revisa el UXR SEO Analyzer

La herramienta identifica qué tipos de schema.org están presentes en la página, valida que las propiedades requeridas existan, detecta bloques JSON-LD mal formados (JSON inválido) y señala cuándo el contenido marcado no coincide con el contenido visible en el HTML.

Referencias

Schema.org - Tipo Product
Schema.org - Tipo Offer
Schema.org - Tipo AggregateRating
Schema.org - Tipo CreativeWork (headline, datePublished, publisher)
Schema.org - Tipo Organization
Schema.org - Tipo BreadcrumbList
Google Search Central - Marcado de Datos Estructurados para Article
Google Search Central - Galería de Búsqueda de Datos Estructurados
Google Search Central - Datos Estructurados para Páginas de Preguntas y Respuestas