Datos estructurados SEO: guía práctica avanzada

¿Qué son los datos estructurados y por qué importan?

Los datos estructurados son un sistema de anotación semántica que añade contexto explícito a elementos de una página (por ejemplo: qué parte es un producto, cuál es su precio, qué texto corresponde a una pregunta, quién es el autor o cuál es el horario de un negocio). En SEO, se implementan normalmente con el vocabulario de Schema.org para que los motores de búsqueda interpreten el contenido con menos ambigüedad.

En la práctica, el marcado ayuda a que Google entienda entidades y relaciones: un Product con su Offer, una Organization como entidad editora, o un LocalBusiness con dirección y geocoordenadas. Esta capa semántica no sustituye al contenido ni al SEO on-page, pero reduce fricciones en el procesamiento: extracción de atributos, clasificación de tipo de página, y asociación entre páginas y entidades.

El efecto más visible de los datos estructurados son los resultados enriquecidos (rich results) cuando Google decide mostrarlos. El marcado correcto puede habilitar formatos de resultado con información adicional (por ejemplo, precio y disponibilidad en fichas de producto), lo que suele impactar en el CTR por cambios de presentación. El marcado, por sí mismo, no garantiza visualizaciones enriquecidas: depende de elegibilidad, calidad, consistencia y criterios de búsqueda. Los lineamientos y criterios oficiales se recogen en la documentación de Google Search Central.

Desde el punto de vista operativo, el marcado también aporta valor interno: normaliza atributos (por ejemplo, stock, moneda, rating), facilita QA automatizado, y permite monitorizar errores de implementación con señales de Search Console (informes de “Mejoras” y resultados enriquecidos). En entornos con muchas URLs (e-commerce, portales, directorios), la diferencia entre un marcado artesanal y uno gobernado por plantilla suele ser la diferencia entre tener un sistema mantenible o una fuente continua de incidencias.

Formatos y vocabularios: JSON-LD, Microdata y RDFa (comparativa rápida)

El vocabulario más habitual para SEO es Schema.org, mantenido de forma comunitaria y adoptado por buscadores. El vocabulario define tipos (Product, Article, FAQPage, etc.) y propiedades (name, image, price, address…). La referencia principal para tipos y propiedades está en Schema.org.

El vocabulario puede expresarse en distintos formatos de marcado:

JSON-LD encapsula el marcado como un bloque JSON independiente del HTML. Es el enfoque más común en SEO técnico porque:

Microdata incrusta atributos en el propio HTML (itemscope, itemtype, itemprop), acoplando el marcado a la estructura del DOM. Puede ser útil cuando el stack impide inyectar JSON-LD, pero tiende a ser más frágil ante cambios de maquetación.

RDFa también se integra en el HTML con atributos (typeof, property, vocab), es más generalista y usado en contextos semánticos más amplios. En SEO, suele verse menos que JSON-LD.

En implementaciones modernas, JSON-LD suele ser la opción por defecto por desacoplamiento, facilidad de plantillado y mejor compatibilidad con despliegues programáticos. Microdata o RDFa quedan como alternativas cuando el entorno técnico obliga a ello o cuando existe un legado muy estructurado que no se quiere tocar.

Tipos de schema más relevantes según tipo de web

La selección de tipos no debería partir de “marcar todo”, sino de marcar lo que la página representa y lo que Google puede usar como resultado enriquecido o como señal de comprensión. Conviene evitar el marcado decorativo (propiedades irrelevantes o inventadas) y priorizar consistencia entre páginas, plantillas y fuentes de datos (PIM/ERP/CRM).

Tipo de web	Tipos de schema habituales	Notas de implementación
Blog / contenidos	Article, BlogPosting, Organization, Person	Priorizar autoría, fecha, imagen principal, entidad editora y canonicalidad.
E-commerce	Product, Offer, AggregateRating, Review, BreadcrumbList	La coherencia precio/stock/moneda entre HTML y JSON-LD es crítica; evitar reviews no verificables.
Local / negocios	LocalBusiness, Organization, PostalAddress, OpeningHoursSpecification	Dirección y NAP consistentes; usar propiedades de geolocalización cuando aplique.
Servicios	Service, LocalBusiness, Organization	Marcar el servicio si existe entidad clara; evitar “inventar” precios si no están publicados.
Recetas / editorial específico	Recipe, HowTo, VideoObject	Propiedades específicas (tiempos, ingredientes) deben estar visibles en la página.
Eventos	Event, Offer, Place	Fechas en ISO 8601; controlar eventos pasados y su indexabilidad.
Empleo	JobPosting	Caducidad, ubicación, salario cuando exista; evitar duplicados en agregadores.

En páginas de contenidos, el trío Article + Organization + BreadcrumbList suele cubrir la base. En e-commerce, el núcleo es Product + Offer, y a partir de ahí se añaden propiedades según disponibilidad real de datos (GTIN, SKU, shippingDetails, returnPolicy, etc.). En negocio local, LocalBusiness y su PostalAddress son el centro; horarios y geocoordenadas deben reflejar la realidad operativa.

Implementación paso a paso (para desarrolladores y no-desarrolladores)

Una implementación correcta sigue un criterio simple: el marcado debe ser veraz, completo para el tipo seleccionado, y consistente con lo que ve el usuario en la página. La parte técnica se reduce a ubicar el JSON-LD en un lugar estable y generar los campos desde fuentes fiables.

Generar JSON-LD manualmente (ejemplo mínimo operativo)

El JSON-LD se construye con tres piezas: @context, @type y propiedades. Para contenidos editoriales, un mínimo funcional suele incluir título, URL, imagen, fechas y editor. Conviene usar URLs absolutas y fechas en ISO 8601. Si el sitio publica autoría, es preferible marcar Person con URL de perfil.

Antes de añadir propiedades avanzadas, es recomendable garantizar que los campos básicos son correctos en todas las páginas del mismo tipo. La evolución típica es: base consistente → ampliar propiedades → automatizar validación → monitorizar errores.

Insertar JSON-LD en WordPress (plugins y temas)

En WordPress, la inserción puede hacerse con plugins SEO o con el propio tema. El riesgo operativo más común es la duplicidad: dos plugins o el tema generando el mismo tipo (por ejemplo, Article y Organization) con datos distintos. En esos casos, Google puede ignorar el marcado o seleccionar el menos deseable.

1. Auditar lo existente: revisar el código fuente y detectar si ya se emite JSON-LD (plugins SEO, WooCommerce, bloques del editor o el tema).
2. Definir una única “fuente” de schema por tipo de página: artículos desde el plugin/tema; producto desde WooCommerce + extensiones, evitando solapamientos.
3. Publicar cambios con QA: comprobar una muestra de URLs en entorno de staging o con una URL de prueba y validar antes de desplegar en todo el sitio.

Cuando el sitio usa WooCommerce, es importante revisar qué emite la plantilla de producto. Algunas extensiones añaden propiedades de Offer, shipping o returnPolicy; si se añaden manualmente, debe hacerse con conocimiento de lo que ya genera WooCommerce para evitar inconsistencias.

Insertar JSON-LD en sitios sin CMS (head template)

En sitios estáticos o aplicaciones (SSR/SSG), el patrón común es renderizar el JSON-LD desde la misma fuente de datos que construye la página (por ejemplo, un endpoint de catálogo) y colocarlo en el HTML entregado al bot. Si el sitio depende de renderizado en cliente, conviene confirmar que Google lo procesa de forma consistente y que el marcado se inserta sin condiciones.

1. Generar el objeto a partir del modelo de datos de la página (producto, artículo, negocio local).
2. Serializar a JSON y escapar caracteres donde aplique (por ejemplo, comillas en descripciones).
3. Inyectar en la plantilla de cabecera o al final del body, asegurando una sola instancia por tipo y URL.

En entornos multi-idioma, el marcado debe reflejar idioma y moneda de la página renderizada. Una fuente frecuente de errores es reutilizar el JSON-LD del idioma principal en todas las versiones, generando discrepancias con el contenido visible.

SEO Programático: generar y desplegar datos estructurados a escala

El cuello de botella del marcado a gran escala no es escribir JSON-LD, sino gobernar datos: de dónde salen, cómo se transforman, qué reglas se aplican y cómo se evita que cambios en PIM/ERP rompan el schema. En sitios con miles de URLs, el enfoque efectivo es tratar el schema como parte del sistema de publicación: plantillas parametrizadas, validación automática y observabilidad.

Arquitectura recomendada (PIM/CRM → plantilla JSON → build → CDN)

Un flujo robusto separa origen, transformación y publicación:

Origen: PIM/ERP para atributos de producto (SKU, GTIN, precio, stock), CMS para editorial (título, imagen, autor), CRM o sistema de tiendas para datos locales (horarios, dirección).

Transformación: una capa de mapeo que convierte el modelo interno al modelo Schema.org. Aquí se normalizan formatos (moneda, decimales, ISO 8601), se aplican reglas (no emitir rating si no existe), y se definen defaults (imagen fallback).

Publicación: el JSON-LD se genera en build (SSG), en render de servidor (SSR), o en un servicio de edge. En e-commerce con cambios frecuentes, el SSR o edge reduce desfases entre precio/stock y el HTML visible.

Cuando se usa CDN o edge, conviene vigilar el caching de páginas que incluyen precio/stock: una caché agresiva puede servir marcado desactualizado aunque la API ya tenga el dato nuevo, provocando inconsistencias y avisos en Search Console.

Ejemplo de automatización con n8n y pseudocódigo

Una automatización típica recoge datos del catálogo, aplica un mapeo y publica el resultado en un repositorio o un bucket consumido por el front. En entornos con control de cambios, la generación de schema puede quedar como artefacto versionado.

// Pseudoflujo (ejemplo hipotético)
// 1) Trigger: actualización de producto en PIM
// 2) HTTP Request: GET /api/products/{id}
// 3) Function: mapear modelo interno -> Schema.org Product
// 4) Validate: comprobar propiedades mínimas y tipos
// 5) Output: guardar JSON en storage y notificar pipeline

function mapToSchemaProduct(p) {
  return {
    "@context": "https://schema.org",
    "@type": "Product",
    "name": p.title,
    "sku": p.sku,
    "gtin13": p.gtin13 || undefined,
    "image": Array.isArray(p.images) ? p.images : [p.mainImage],
    "description": p.shortDescription,
    "brand": p.brand ? { "@type": "Brand", "name": p.brand } : undefined,
    "offers": {
      "@type": "Offer",
      "priceCurrency": p.currency,
      "price": String(p.price),
      "availability": p.inStock ? "https://schema.org/InStock" : "https://schema.org/OutOfStock",
      "url": p.canonicalUrl
    }
  };
}

function validateMinimalProduct(s) {
  const required = ["@context", "@type", "name", "offers"];
  for (const k of required) if (!s[k]) throw new Error("Missing " + k);
  if (!s.offers.price || !s.offers.priceCurrency) throw new Error("Offer incomplete");
  return true;
}

El punto crítico es la validación previa: una automatización que “publica siempre” termina propagando errores a miles de URLs. Es preferible bloquear la publicación cuando falten campos obligatorios y emitir alertas internas para corregir el origen.

En catálogos con variantes (talla/color), puede ser necesario elegir entre marcar el producto padre o una variante seleccionada. En esos casos, conviene alinear el marcado con la URL canónica y con lo que se muestra por defecto.

Integración en pipelines CI/CD y pruebas automáticas (linting)

Para equipos de desarrollo, el schema se puede tratar como “código”: cambios en plantillas de marcado pasan por revisión, tests y despliegue controlado. Un pipeline básico incluye:

Linting del JSON-LD (JSON válido, tipos esperados, URLs absolutas), tests de contrato (propiedades mínimas por tipo de página), y smoke tests sobre una muestra de URLs renderizadas (extraer el JSON-LD del HTML generado y validarlo).

# Pseudocomandos (ejemplo hipotético) en CI
# 1) Validar que la salida es JSON
node scripts/validate-json.js dist/schema/*.json

# 2) Reglas mínimas por tipo
node scripts/schema-contract-tests.js --type Product --minProps name,offers.price,offers.priceCurrency

# 3) Smoke test sobre HTML renderizado
node scripts/extract-jsonld-from-html.js dist/pages/**/*.html | node scripts/validate-json.js -

Cuando el sitio emite schema dinámico, el test sobre HTML puede ejecutarse contra un entorno de preproducción y una lista de URLs representativas (artículos, categorías, fichas con stock, fichas sin stock, productos con descuento). La cobertura por casos reduce incidencias típicas: precios con coma, moneda ausente, availability incorrecta, imágenes relativas o URLs no canónicas.

Validación y monitorización (operativa)

La validación del marcado tiene dos niveles: validez sintáctica (JSON correcto, propiedades con tipos adecuados) y elegibilidad para resultados enriquecidos según criterios del buscador. Un JSON-LD puede ser válido y, aun así, no generar resultados enriquecidos por falta de cumplimiento de directrices o por señales de calidad insuficientes.

Herramientas para validar (Search Console, Rich Results Test)

La validación operativa se apoya en dos herramientas principales:

El Rich Results Test permite analizar una URL o un fragmento de código y ver si el marcado es elegible para resultados enriquecidos, además de listar errores y avisos. La herramienta oficial está en Rich Results Test.

Google Search Console aporta visión de conjunto: incidencias agrupadas por tipo, tendencias, URLs afectadas y estados tras corrección. Su valor es operativo: priorizar qué errores tienen más impacto por volumen y por tipología de página.

En validaciones repetibles, conviene separar:

Error: propiedad obligatoria ausente, tipo incorrecto, URL inválida, fecha mal formada.

Aviso: propiedad recomendada ausente, campo no crítico o potencial mejora.

Discrepancia: el marcado no coincide con el contenido visible (por ejemplo, precio o disponibilidad). Aunque algunas discrepancias no aparecen como “error” de herramienta, suelen correlacionar con ignorado del marcado o incidencias posteriores.

Dashboard en Looker Studio y métricas GA4 (impresiones, CTR, rich results)

La monitorización del impacto no se reduce a “hay o no hay rich results”. El enfoque útil es conectar señales de búsqueda con señales de comportamiento y con control de calidad del marcado.

Un dashboard operativo suele cruzar:

Search Console: impresiones, clics, CTR y posición por página o por tipo de resultado cuando aplique; además, volumen de URLs con errores/avisos en informes de mejoras.

GA4: sesiones orgánicas, tasa de interacción, conversiones por landing page; segmentación por tipo de página (producto, artículo, local).

Control de cambios: anotaciones internas de despliegues (fecha de release del schema) para correlacionar variaciones con releases y evitar atribuciones incorrectas.

Para instrumentación adicional, el etiquetado puede ayudar a registrar variantes de plantilla o flags de marcado (por ejemplo, si una ficha emite Product con Offer completo). En GA4, esa información se suele enviar como evento o como dimensión. Un ejemplo hipotético de envío a dataLayer (para Tag Manager) podría ser:

<script>
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: "schema_state",
    page_type: "product",
    schema_emitted: true,
    schema_types: ["Product", "BreadcrumbList"],
    offer_state: "complete",
    currency: "EUR"
  });
</script>

En ese patrón, no se envían datos personales y se evita incorporar identificadores sensibles. El objetivo es habilitar segmentación: comparar rendimiento orgánico de páginas con “Offer completo” frente a páginas con “Offer incompleto”, o detectar plantillas que no están emitiendo schema tras una actualización.

La fuente de verdad de resultados enriquecidos sigue siendo Search Console y el propio SERP. GA4 se utiliza como capa de negocio y comportamiento, no como verificación de elegibilidad.

Ejemplos y snippets JSON-LD

Los ejemplos siguientes son genéricos y deben adaptarse a cada web. Las propiedades deben corresponder a contenido visible. Cuando no exista un dato (por ejemplo, rating), es preferible omitirlo a inventarlo.

Snippet base para Article (comentado)

Este ejemplo hipotético incluye campos habituales en contenidos editoriales. En publicaciones con varias imágenes, se recomienda incluir varias URLs en image para mejorar compatibilidad.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://ejemplo.es/datos-estructurados-seo-implementacion/"
  },
  "headline": "Datos estructurados SEO: guía práctica y programática avanzada",
  "image": [
    "https://ejemplo.es/wp-content/uploads/2026/01/datos-estructurados-seo.jpg"
  ],
  "datePublished": "2026-03-06T09:00:00+01:00",
  "dateModified": "2026-03-06T09:00:00+01:00",
  "author": {
    "@type": "Person",
    "name": "Autor/a"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Marca",
    "logo": {
      "@type": "ImageObject",
      "url": "https://ejemplo.es/wp-content/uploads/2026/01/logo.png"
    }
  }
}
</script>

Si el contenido es tutorial con pasos verificables y material necesario, puede ser más apropiado un HowTo complementario. Si el sitio utiliza un plugin SEO, hay que comprobar qué campos genera automáticamente para Article y evitar emitir dos objetos incompatibles para la misma URL.

Snippet para Product (propiedades obligatorias y opcionales)

En producto, la pieza más sensible es offers: precio, moneda, URL y disponibilidad. Los valores deben coincidir con la página renderizada para usuarios. En e-commerce con precios dinámicos, conviene minimizar desfases por caché.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Zapatillas Running Modelo X",
  "image": [
    "https://ejemplo.es/media/producto-x-1.jpg",
    "https://ejemplo.es/media/producto-x-2.jpg"
  ],
  "description": "Ejemplo hipotético de descripción corta visible en la ficha.",
  "sku": "SKU-12345",
  "brand": {
    "@type": "Brand",
    "name": "MarcaEjemplo"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://ejemplo.es/producto/modelo-x/",
    "priceCurrency": "EUR",
    "price": "89.90",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.4",
    "reviewCount": "112"
  }
}
</script>

Advertencia: rating y reviews requieren consistencia con el sistema real de valoraciones y con el contenido visible. Si no existe un módulo de reseñas, no deben añadirse propiedades de review/aggregateRating.

Para catálogos con múltiples vendedores o múltiples ofertas, es común emitir un array de offers. En esos casos, se recomienda controlar el tamaño del JSON-LD para evitar inflar el HTML y limitarse a ofertas relevantes para la URL canónica.

Snippet para LocalBusiness y FAQ

Para negocio local, el objetivo es reflejar la entidad y sus atributos estables: dirección, teléfono de atención si se publica, horarios y geolocalización. Los horarios suelen ser un foco de errores por formato o por cambios estacionales.

Sobre FAQPage, Google ha ajustado su tratamiento de resultados enriquecidos en distintos periodos. El marcado puede seguir siendo útil para comprensión, pero la decisión de mostrarlo en SERP depende de criterios del buscador y del contexto de consulta. Si se implementa, debe reflejar preguntas y respuestas visibles, sin contenido promocional ni respuestas que no estén en la página.

Errores comunes y cómo solucionarlos (lista de verificación)

Los problemas más frecuentes aparecen por inconsistencias entre capas (HTML vs JSON-LD), por duplicidad de emisores (plugin + tema + app), o por datos incompletos en el origen. La corrección suele ser más rápida cuando existe una única plantilla responsable por tipo de página y un conjunto de tests automatizados.

• Marcado duplicado del mismo tipo con valores distintos. Solución: definir un único generador por tipo de página y desactivar módulos solapados.
• URLs relativas en image, logo o url. Solución: emitir URLs absolutas con protocolo y dominio canónico.
• Precio/stock desalineados por caché o render. Solución: unificar fuente de datos, ajustar TTL de caché para fichas, o render SSR para atributos dinámicos.
• Fechas mal formateadas o incoherentes (dateModified anterior a datePublished). Solución: ISO 8601 y reglas de negocio claras en CMS.
• Propiedades inventadas o fuera de Schema.org. Solución: ceñirse a tipos/propiedades documentadas y validar con herramientas.
• Contenido no visible marcado como si existiera (reviews, FAQ, precios). Solución: alinear marcado con el DOM visible para usuarios.
• Uso incorrecto de tipos (Article en una categoría, Product en un listado). Solución: mapear tipo por plantilla real, no por intención.
• Idioma/moneda incorrectos en sitios multi-idioma. Solución: generar marcado por versión y no reutilizar JSON-LD del idioma principal.

En correcciones masivas, conviene empezar por el error con mayor superficie: tipo de página más voluminoso y propiedades obligatorias. Los avisos pueden priorizarse después, siempre que el marcado sea consistente y no cause ignorado.

Herramientas recomendadas

La selección de herramientas depende del stack y de si el marcado se gestiona desde CMS o desde un sistema de publicación propio. Para el flujo de trabajo de SEO técnico, suelen usarse:

• Google Search Console para incidencias, cobertura y seguimiento de mejoras relacionadas con datos estructurados.
• Rich Results Test para validar elegibilidad de resultados enriquecidos por URL o fragmento de código.
• Validadores de Schema y documentación del vocabulario para confirmar tipos y propiedades aceptadas.
• GA4 para segmentación de rendimiento orgánico por tipo de página y análisis de comportamiento posterior al clic.

Para implementaciones orientadas a calidad, es habitual incorporar validación en CI y checks de render (extraer JSON-LD del HTML generado, validar JSON y comprobar propiedades mínimas). En stacks con Tag Manager, la instrumentación ayuda a detectar plantillas que dejan de emitir marcado tras un cambio.

La documentación de medición y configuración de eventos en GA4 está en Google Analytics Developers, útil para estandarizar eventos y dimensiones sin introducir datos sensibles.