Datos estructurados SEO: 13 reglas para auditar Schema.org markup, Article, Organization, FAQ, Product y Breadcrumb

Resumen: Los datos estructurados son el idioma que hablas directamente con Google. Cuando implementas Schema.org correctamente, no estás solo diciendo «tengo una página de producto»; le estás contando exactamente qué precio tiene, qué valoración le dan los usuarios y si está en stock. Esa información extra es la que convierte un resultado de búsqueda plano en un rich snippet que multiplica los clics. Esta guía detalla las 13 reglas que debes auditar para que tus datos estructurados abran la puerta a los resultados enriquecidos y aceleren tu ascenso en las SERPs.

Solicitar auditoría SEO gratuita → Ver servicios SEO →

Tabla de contenidos

¿Por qué los datos estructurados son equipamiento imprescindible?
Reglas 1–4: Los cimientos — formato, validez, tipo y campos
Regla 5: WebSite schema y el Sitelinks Searchbox
Regla 6: Organization — la identidad de tu marca
Regla 7: Article y BlogPosting — el contenido editorial
Regla 8: BreadcrumbList — las migas de pan en las SERPs
Regla 9: FAQPage — las preguntas frecuentes en el resultado
Regla 10: LocalBusiness — el negocio local en el mapa
Regla 11: Product — ficha de producto completa
Regla 12: Review y AggregateRating — las estrellas en las SERPs
Regla 13: VideoObject — el vídeo como resultado enriquecido
Cómo priorizar la implementación de datos estructurados
Checklist de las 13 reglas
Preguntas frecuentes

¿Por qué los datos estructurados son equipamiento imprescindible?

Cuando un buscador como Google rastrea tu web, lee el HTML de cada página e intenta deducir de qué trata el contenido. Lo hace razonablemente bien para texto plano, pero sin ayuda extra tiene que adivinar: ¿este número con símbolo de euro es un precio, un coste de envío o el año de fundación de la empresa? ¿Esta valoración de cuatro estrellas es de un producto, de un servicio o de un restaurante?

Los datos estructurados eliminan esa ambigüedad. Son fragmentos de código — habitualmente en formato JSON-LD — que añades al <head> de tus páginas para decirle explícitamente a Google: «esto es un artículo, tiene este autor, se publicó en esta fecha y trata sobre este tema». Google no tiene que adivinar nada. Y cuando Google entiende el contenido con precisión, puede presentarlo de formas mucho más ricas en los resultados de búsqueda.

Qué son los rich snippets y por qué disparan el CTR

Los rich snippets — o resultados enriquecidos — son el premio que Google entrega a las páginas con datos estructurados correctamente implementados. En lugar del clásico resultado de tres líneas (título, URL, descripción), puedes aparecer con:

Estrellas de valoración en resultados de producto o reseña
Precios directamente en la SERP
Preguntas y respuestas expandibles bajo tu resultado
Migas de pan en lugar de la URL completa
Fechas de publicación y nombre del autor en artículos
Miniaturas de vídeo junto al título

El impacto en el CTR es real y medible. Según datos de Search Engine Land, los rich snippets pueden incrementar el porcentaje de clics entre un 20% y un 30% respecto a resultados estándar. En nichos competitivos, esa diferencia en visibilidad puede ser la que te sitúe por delante de la competencia aunque ambos ocupéis posiciones similares.

El papel de Schema.org

Schema.org es el vocabulario que usan los datos estructurados. Es un proyecto colaborativo impulsado por Google, Microsoft (Bing), Yahoo y Yandex que define centenares de tipos de entidades — Article, Product, Organization, LocalBusiness, FAQPage y muchos más — con sus propiedades y relaciones. Cuando usas Schema.org como vocabulario y JSON-LD como formato, hablas el idioma que todos los grandes buscadores entienden.

Las tres formas de implementar datos estructurados son JSON-LD, Microdata y RDFa. Google recomienda explícitamente JSON-LD por su flexibilidad, facilidad de mantenimiento y porque se puede añadir al <head> sin modificar el HTML del cuerpo de la página.

Las 13 reglas que debes auditar

Un auditor SEO como SEOmator revisa 13 reglas específicas en la categoría de Structured Data. Cubren desde la elección del formato correcto hasta la implementación de tipos de schema específicos para los distintos tipos de contenido. Vamos a recorrerlas todas, con ejemplos de código reales para cada una.

Reglas 1–4: Los cimientos — formato, validez, tipo y campos

Antes de preocuparte por los tipos de schema específicos, hay cuatro reglas fundamentales que toda implementación debe superar. Son los cimientos sobre los que se construye el resto.

Regla 1: Usa JSON-LD, no RDFa ni Microdata

La primera pregunta que hace cualquier auditor de datos estructurados es: ¿en qué formato están implementados? Hay tres opciones disponibles, pero solo una es la recomendada por Google.

RDFa y Microdata requieren que modifiques el HTML de cada elemento de la página con atributos especiales. Esto crea un acoplamiento estrecho entre el marcado semántico y el HTML visual: si cambias la estructura de la página, tienes que actualizar también los datos estructurados. Además, es fácil cometer errores y difícil de mantener a escala.

JSON-LD funciona de manera completamente distinta: es un bloque de código JavaScript independiente que insertas en el <head> de la página y que Google procesa por separado del HTML visible. Puedes actualizar los datos estructurados sin tocar el diseño, y el diseño sin tocar los datos estructurados. Es limpio, modular y fácil de depurar.

Esta es la estructura mínima de un bloque JSON-LD:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "WebPage",
  "name": "Nombre de la página"
}
</script>

El atributo type="application/ld+json" le indica al navegador (y a Google) que este script no es JavaScript ejecutable sino un bloque de datos estructurados en formato JSON-LD. El campo @context siempre apunta a https://schema.org y le dice al procesador qué vocabulario estamos usando.

✅ Cómo auditarlo: comprueba el código fuente de tus páginas (Ctrl+U en el navegador) y busca <script type="application/ld+json">. Si ves atributos itemtype, itemscope o property="" dispersos por el HTML, estás usando Microdata o RDFa y deberías migrar a JSON-LD.

Regla 2: El JSON-LD debe ser sintácticamente válido

Tener JSON-LD en tu página es el primer paso. El segundo es que ese JSON-LD sea sintácticamente correcto. Un error tan simple como una coma sobrante, una llave sin cerrar o una comilla sin escapar puede invalidar todo el bloque y hacer que Google lo ignore por completo.

Los errores más comunes de sintaxis JSON son:

Coma trailing: una coma después del último elemento de un objeto o array ("name": "valor", antes del })
Comillas sin escapar: si el valor de un campo contiene comillas dobles, deben escribirse como \"
Propiedades sin entrecomillar: en JSON las claves siempre van entre comillas dobles, nunca sin ellas
Valores undefined o null mal formateados: si no tienes valor para un campo opcional, simplemente omite la propiedad

Esta es la diferencia entre JSON válido e inválido:

// ❌ JSON inválido — coma trailing y clave sin comillas
{
  "@context": "https://schema.org",
  @type: "Article",
  "name": "Mi artículo",
}

// ✅ JSON válido
{
  "@context": "https://schema.org",
  "@type": "Article",
  "name": "Mi artículo"
}

✅ Cómo auditarlo: usa la herramienta oficial Google Rich Results Test o el Schema Markup Validator de Schema.org. También puedes pegar el JSON-LD en jsonlint.com para validar la sintaxis antes de publicarlo.

Regla 3: El @type debe ser adecuado para el contenido

Una vez que el formato es JSON-LD y la sintaxis es válida, la tercera regla comprueba que estás usando el tipo correcto para cada página. El campo @type es el que le dice a Google qué clase de entidad es esta página, y elegir mal puede hacer que Google no reconozca el schema o, peor, que lo considere spam.

La norma es simple: el tipo de schema debe coincidir con lo que el usuario ve en la página. Si la página es un artículo, el tipo es Article o BlogPosting. Si es una página de producto, el tipo es Product. Si es la página de inicio de una empresa, el tipo adecuado es Organization o WebSite. Usar Product en una página de contacto, o FAQPage en una página sin preguntas reales, es exactamente el tipo de manipulación que Google penaliza.

Tipos de schema y las páginas donde aplican:

Tipo de página	@type recomendado
Página de inicio	`WebSite` + `Organization`
Artículo de blog	`BlogPosting` o `Article`
Página de producto	`Product`
Preguntas frecuentes	`FAQPage`
Negocio local	`LocalBusiness` (o subtipo específico)
Vídeo	`VideoObject`
Página con breadcrumbs	`BreadcrumbList`
Reseña	`Review` o `AggregateRating`

✅ Cómo auditarlo: revisa página a página que el @type en el JSON-LD coincide con el tipo real de contenido. Herramientas como SEOmator inspeccionan el DOM y cruzan el tipo declarado con el contenido detectado.

Regla 4: Los campos requeridos deben estar presentes

Cada tipo de schema tiene una lista de propiedades requeridas que Google necesita para poder mostrar el resultado enriquecido. Si falta alguna de ellas, Google puede procesar el schema pero no mostrará el rich snippet. La cuarta regla verifica que todos los campos obligatorios están presentes y tienen valores válidos.

Las propiedades requeridas varían por tipo. Algunas de las más importantes:

Article/BlogPosting: headline, image, datePublished, author
Product: name (precio y disponibilidad son necesarios para el rich snippet de precios)
FAQPage: la estructura correcta de mainEntity con Question y acceptedAnswer
Organization: name, url
LocalBusiness: name, address

Un error habitual es declarar el tipo correcto pero omitir propiedades porque «no son obligatorias según Schema.org». Hay que distinguir entre propiedades que Schema.org marca como requeridas en su especificación y propiedades que Google requiere para mostrar el rich snippet. Las directrices de Google para resultados enriquecidos son las que mandan desde el punto de vista de SEO.

✅ Cómo auditarlo: consulta las guías de resultados enriquecidos de Google para cada tipo y verifica que tienes todos los campos marcados como «Required» en las directrices de Google (no solo en Schema.org).

El schema de tipo WebSite es uno de los menos conocidos pero de los que más impacto visual tienen en las SERPs. Cuando lo implementas correctamente en tu página de inicio con una SearchAction, le das a Google la información necesaria para mostrar el Sitelinks Searchbox: un cuadro de búsqueda directamente en tu resultado de Google que permite al usuario buscar dentro de tu web sin tener que entrar primero en ella.

El Sitelinks Searchbox aparece principalmente en búsquedas de marca (cuando alguien busca directamente el nombre de tu empresa). Google decide si mostrarlo o no, pero sin el schema nunca tendrás la oportunidad.

Este es el JSON-LD completo para WebSite con SearchAction:

{
  "@context": "https://schema.org",
  "@type": "WebSite",
  "name": "Escala14",
  "url": "https://escala14.com",
  "potentialAction": {
    "@type": "SearchAction",
    "target": {
      "@type": "EntryPoint",
      "urlTemplate": "https://escala14.com/buscar/?q={search_term_string}"
    },
    "query-input": "required name=search_term_string"
  }
}

El campo potentialAction describe la acción que el usuario puede realizar: una búsqueda. El urlTemplate debe apuntar a la URL de resultados de búsqueda de tu web, con el parámetro de búsqueda correctamente mapeado. Si tu web no tiene buscador interno, puedes omitir el potentialAction e implementar el schema WebSite sin él — aunque perderás la oportunidad del Sitelinks Searchbox.

Dónde va: exclusivamente en la página de inicio (/). No lo dupliques en páginas internas.

Qué consigues: la posibilidad de que aparezca el Sitelinks Searchbox en búsquedas de marca, y que Google entienda el nombre y URL canónica de tu sitio web.

✅ Cómo auditarlo: entra en Google Rich Results Test con tu URL de inicio y comprueba si detecta el schema WebSite. Comprueba también en Google Search Console si estás viendo el Sitelinks Searchbox en los datos de rendimiento de búsquedas de marca.

Regla 6: Organization — la identidad de tu marca

El schema Organization es el que define quién eres ante Google. Nombre, logo, datos de contacto, perfiles sociales, país de operación — toda esa información de identidad de marca va en este tipo. Es especialmente importante para el Knowledge Panel: el panel que aparece a la derecha de los resultados cuando alguien busca el nombre de tu empresa.

Un schema Organization completo incluye:

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Escala14",
  "url": "https://escala14.com",
  "logo": {
    "@type": "ImageObject",
    "url": "https://escala14.com/logo.webp",
    "width": 300,
    "height": 80
  },
  "description": "Agencia de marketing digital especializada en SEO, diseño web y branding para empresas.",
  "email": "[email protected]",
  "foundingDate": "2020",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Calle Ejemplo, 14",
    "addressLocality": "Almería",
    "addressRegion": "Andalucía",
    "postalCode": "04001",
    "addressCountry": "ES"
  },
  "sameAs": [
    "https://www.linkedin.com/company/escala14",
    "https://www.instagram.com/escala14",
    "https://twitter.com/escala14"
  ]
}

Hay varios puntos críticos en este schema:

El logo: debe ser una imagen real accesible por URL, con las dimensiones correctas. Google recomienda imágenes en formato cuadrado o rectangular con fondo no transparente. El campo ImageObject con url, width y height es más preciso que pasar solo la URL de la imagen como string.

sameAs: este array de URLs es uno de los campos más poderosos para la consolidación de entidad. Le dice a Google que todos esos perfiles son la misma organización. Incluye tus perfiles verificados en LinkedIn, Instagram, Twitter/X, Facebook, y especialmente tu entrada en Wikidata o Wikipedia si la tienes.

foundingDate: útil para el Knowledge Panel y para señales E-E-A-T (experiencia a lo largo del tiempo).

Dónde va: en la página de inicio, aunque también puedes incluirlo en el footer como bloque global para que esté disponible en todas las páginas.

✅ Cómo auditarlo: verifica en Google Rich Results Test que el schema Organization es detectado y válido. Comprueba especialmente que el campo logo apunta a una imagen accesible y que los URLs en sameAs son correctos y están activos.

Regla 7: Article y BlogPosting — el contenido editorial

Si publicas contenido de blog o artículos, el schema Article — o su subtipo más específico BlogPosting — es el que desbloquea los resultados enriquecidos para contenido editorial: fecha de publicación, nombre del autor y, en algunos casos, imagen destacada en las SERPs de Google Discover y en los resultados de Google News.

La diferencia entre Article y BlogPosting:

Article: para contenido periodístico o de noticias. Compatible con Google News.
BlogPosting: para entradas de blog. Subtipo de Article, hereda todas sus propiedades.
NewsArticle: específico para medios de comunicación con noticias de actualidad.

Para la mayoría de blogs de empresas y agencias, BlogPosting es el tipo más preciso.

Este es un ejemplo completo para un artículo de blog:

{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Datos estructurados SEO: 13 reglas para auditar Schema.org markup",
  "description": "Aprende a implementar y auditar las 13 reglas de datos estructurados más críticas en SEO.",
  "image": {
    "@type": "ImageObject",
    "url": "https://escala14.com/images/datos-estructurados-schema-markup.webp",
    "width": 1200,
    "height": 630
  },
  "datePublished": "2026-03-18T00:00:00+01:00",
  "dateModified": "2026-03-18T00:00:00+01:00",
  "author": {
    "@type": "Person",
    "name": "Equipo Escala14",
    "url": "https://escala14.com/agencia-seo/"
  },
  "publisher": {
    "@type": "Organization",
    "name": "Escala14",
    "logo": {
      "@type": "ImageObject",
      "url": "https://escala14.com/logo.webp",
      "width": 300,
      "height": 80
    }
  },
  "mainEntityOfPage": {
    "@type": "WebPage",
    "@id": "https://escala14.com/datos-estructurados-schema-markup-seo/"
  },
  "wordCount": 9000,
  "inLanguage": "es-ES"
}

Puntos clave a no descuidar:

headline: debe coincidir con el <title> de la página o ser muy similar. Google verifica la coherencia. Longitud máxima recomendada: 110 caracteres.

image: es obligatorio para que Google muestre la imagen en Google Discover y en resultados de AMP. Debe tener mínimo 1200 px de ancho y estar indexable.

datePublished vs dateModified: si actualizas el artículo, actualiza dateModified pero mantén datePublished con la fecha original. No cambies datePublished para fingir que el artículo es más reciente — es una práctica que Google penaliza.

author: el campo @type puede ser Person o Organization. Para artículos de noticias o YMYL (Your Money Your Life), Google valora especialmente que el autor sea una persona real con perfil propio.

publisher: describe la organización que publica el contenido, con su logo incluido.

✅ Cómo auditarlo: en Google Rich Results Test, el schema de Article o BlogPosting debe aparecer sin errores. Verifica especialmente que el campo image está presente y que la imagen tiene las dimensiones correctas.

Regla 8: BreadcrumbList — las migas de pan en las SERPs

Las migas de pan (breadcrumbs) son la navegación jerárquica que muestra la posición de una página dentro de la estructura del sitio: Inicio > Categoría > Artículo. Cuando implementas el schema BreadcrumbList, Google puede mostrar esa ruta directamente en el resultado de búsqueda, sustituyendo la URL cruda por una ruta más legible y comprensible para el usuario.

El impacto visual es significativo. En lugar de ver https://escala14.com/campamento-base/datos-estructurados-schema-markup-seo/, el usuario ve Escala14 > Blog > SEO técnico. Eso comunica contexto, mejora la comprensión del resultado y, según varios estudios de CTR, tiende a incrementar los clics porque el usuario entiende mejor dónde va a aterrizar.

Este es el JSON-LD para breadcrumbs:

{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "name": "Inicio",
      "item": "https://escala14.com/"
    },
    {
      "@type": "ListItem",
      "position": 2,
      "name": "Campamento Base",
      "item": "https://escala14.com/campamento-base/"
    },
    {
      "@type": "ListItem",
      "position": 3,
      "name": "Datos estructurados SEO",
      "item": "https://escala14.com/datos-estructurados-schema-markup-seo/"
    }
  ]
}

Reglas esenciales para el BreadcrumbList:

El campo position debe ser un número entero que empieza en 1 y sigue en orden ascendente
Cada elemento item debe ser una URL válida y accesible
El último elemento de la lista es la página actual — algunos implementadores omiten el item del último elemento (es opcional), pero incluirlo es más seguro
El campo name debe coincidir con el texto visible del breadcrumb en la página

Error frecuente: usar el breadcrumb visual de la página pero no implementar el schema correspondiente, o implementar el schema pero con URLs que no coinciden con las reales de la web.

✅ Cómo auditarlo: verifica que en cada página con breadcrumbs visuales existe también el schema BreadcrumbList correspondiente. Comprueba que position, name e item son coherentes con la jerarquía real del sitio.

Regla 9: FAQPage — las preguntas frecuentes en el resultado

El schema FAQPage es uno de los más valorados en SEO porque tiene el potencial de triplicar el espacio visual de tu resultado en las SERPs. Cuando Google decide mostrarlo, despliega hasta 3 preguntas con sus respuestas directamente bajo tu resultado, empujando los resultados de la competencia hacia abajo en la pantalla.

La clave está en que el schema debe reflejar contenido real de la página. Si implementas FAQPage en una página que no tiene preguntas y respuestas visibles, Google no lo mostrará — y en casos extremos puede penalizarte por markup engañoso. Las preguntas deben estar presentes en el HTML de la página, no solo en el JSON-LD.

Este es el JSON-LD para FAQPage:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "¿Qué son los datos estructurados en SEO?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Los datos estructurados son fragmentos de código — habitualmente en formato JSON-LD — que añades al HTML de tus páginas para comunicarle a Google de forma explícita qué tipo de contenido es cada elemento: un artículo, un producto, una pregunta frecuente, un negocio local. Esta información permite a Google mostrar rich snippets en los resultados de búsqueda."
      }
    },
    {
      "@type": "Question",
      "name": "¿Cuál es el formato recomendado por Google para datos estructurados?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Google recomienda explícitamente JSON-LD como formato para implementar datos estructurados. Es más fácil de mantener que Microdata o RDFa porque no requiere modificar el HTML visible de la página."
      }
    },
    {
      "@type": "Question",
      "name": "¿Los datos estructurados son un factor de ranking directo?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "No son un factor de ranking directo, pero mejoran el CTR a través de los rich snippets, lo que a su vez puede incrementar el tráfico orgánico y las señales de comportamiento que Google sí usa para el ranking."
      }
    }
  ]
}

Directrices de Google para FAQPage:

Las preguntas y respuestas deben ser únicas: no copies las mismas FAQs en múltiples páginas
Las respuestas deben ser texto: Google acepta HTML básico en el campo text (negritas, listas), pero no JavaScript ni iframes
No uses FAQPage en contenido generado por usuarios (tipo foros o comentarios) — en ese caso usa QAPage
La longitud de las respuestas no tiene límite técnico, pero respuestas de 50-300 palabras funcionan mejor para los snippets

Cuándo usar FAQPage: en páginas de servicios con preguntas frecuentes, páginas de producto, artículos de guía y cualquier página con una sección de preguntas y respuestas real.

✅ Cómo auditarlo: verifica que las preguntas del schema están visibles en la página. Usa Google Rich Results Test para confirmar que el schema es válido y elegible para rich results.

Regla 10: LocalBusiness — el negocio local en el mapa

Si tu empresa tiene presencia física o atiende a clientes en una zona geográfica concreta, el schema LocalBusiness es imprescindible. Es el que refuerza la relevancia local de tu web y complementa tu ficha de Google Business Profile para que Google entienda exactamente dónde estás, qué horas abres y cómo contactar contigo.

LocalBusiness es un subtipo de Organization con propiedades adicionales específicas para negocios físicos. Schema.org define cientos de subtipos más específicos: Restaurant, MedicalClinic, LegalService, DigitalMarketingAgency… Usar el subtipo más preciso siempre es preferible al tipo genérico.

Este es un ejemplo completo:

{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "name": "Escala14",
  "description": "Agencia de marketing digital especializada en SEO, diseño web y branding.",
  "url": "https://escala14.com",
  "telephone": "+34 600 000 000",
  "email": "[email protected]",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Calle Ejemplo, 14",
    "addressLocality": "Almería",
    "addressRegion": "Andalucía",
    "postalCode": "04001",
    "addressCountry": "ES"
  },
  "geo": {
    "@type": "GeoCoordinates",
    "latitude": 36.8340891,
    "longitude": -2.4637136
  },
  "openingHoursSpecification": [
    {
      "@type": "OpeningHoursSpecification",
      "dayOfWeek": ["Monday", "Tuesday", "Wednesday", "Thursday", "Friday"],
      "opens": "09:00",
      "closes": "18:00"
    }
  ],
  "priceRange": "€€",
  "areaServed": {
    "@type": "GeoCircle",
    "geoMidpoint": {
      "@type": "GeoCoordinates",
      "latitude": 36.8340891,
      "longitude": -2.4637136
    },
    "geoRadius": "50000"
  },
  "sameAs": [
    "https://www.google.com/maps/place/Escala14",
    "https://www.linkedin.com/company/escala14"
  ]
}

Campos de mayor impacto para el SEO local:

geo: las coordenadas geográficas exactas. Google las usa para determinar la proximidad en búsquedas locales («agencia SEO cerca de mí»). Puedes obtenerlas desde Google Maps.

openingHoursSpecification: los horarios de apertura. Mucho más preciso que el campo openingHours en formato texto. Permite especificar horarios diferentes para cada día.

areaServed: si eres una agencia que trabaja online con clientes de toda España, este campo te permite indicar el área geográfica que cubres, no solo donde estás físicamente.

priceRange: una indicación del nivel de precios con símbolos de euro (€, €€, €€€). Es un campo que aparece en el Knowledge Panel y en ciertos resultados locales.

✅ Cómo auditarlo: comprueba que el schema LocalBusiness coincide con los datos de tu Google Business Profile. Inconsistencias entre ambos (nombre diferente, dirección distinta) pueden crear confusión en los sistemas de Google sobre la identidad de tu negocio.

Regla 11: Product — ficha de producto completa

Para tiendas online y páginas de productos, el schema Product es el que habilita los Shopping Rich Results: los resultados con precio, disponibilidad y valoraciones de estrellas que aparecen tanto en la búsqueda estándar como en Google Shopping. Un Product bien implementado puede transformar un resultado plano en una ficha visual que compite directamente con los anuncios de pago.

Google ha ido incrementando los requisitos para mostrar los Product rich snippets. Desde 2023, para aparecer en los resultados de productos gratuitos de Google Shopping, necesitas tener la información de precio y disponibilidad en el schema, no solo en el texto de la página.

Este es un schema Product completo:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Auditoría SEO Completa",
  "description": "Auditoría técnica y de contenido para detectar y priorizar todos los factores que frenan el posicionamiento de tu web.",
  "image": [
    "https://escala14.com/images/auditoria-seo.webp"
  ],
  "brand": {
    "@type": "Brand",
    "name": "Escala14"
  },
  "offers": {
    "@type": "Offer",
    "url": "https://escala14.com/agencia-seo/",
    "priceCurrency": "EUR",
    "price": "497",
    "priceValidUntil": "2026-12-31",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  },
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.9",
    "reviewCount": "47",
    "bestRating": "5",
    "worstRating": "1"
  }
}

Propiedades críticas para el schema Product:

offers: es el objeto que contiene la información de precio y disponibilidad. Sin él, no hay Product rich snippet. availability debe usar los valores de Schema.org: InStock, OutOfStock, PreOrder, LimitedAvailability.

priceCurrency: siempre en formato ISO 4217 (EUR, USD, GBP). No uses el símbolo directo (€).

priceValidUntil: la fecha hasta la que el precio es válido. Google puede descalificar el rich snippet si la fecha expiró, así que mantenla actualizada.

aggregateRating: si tienes valoraciones de usuarios, añade este objeto dentro del Product. Los campos ratingValue y reviewCount son los mínimos requeridos. Incluye bestRating y worstRating para mayor precisión.

✅ Cómo auditarlo: en Google Rich Results Test, selecciona el test de «Product» y verifica que el schema pasa la validación. Presta especial atención a si el precio y la disponibilidad son coherentes con lo que se ve en la página.

Regla 12: Review y AggregateRating — las estrellas en las SERPs

Las estrellas de valoración en los resultados de búsqueda son uno de los elementos visuales más poderosos para aumentar el CTR. Un resultado con 4.8 estrellas y 127 reseñas llama mucho más la atención que el texto plano de sus competidores. Los schema Review y AggregateRating son los que hacen posible ese efecto.

Hay una distinción importante entre ambos:

Review: representa una reseña individual de un usuario específico, con su autor, fecha y texto de la reseña
AggregateRating: representa la media de todas las valoraciones, con la nota media y el número total de valoraciones

Para mostrar las estrellas en los resultados, Google requiere que el AggregateRating forme parte de otro tipo de schema: Product, LocalBusiness, Course, Recipe, u otros. No puedes usar AggregateRating de forma independiente.

Ejemplo de AggregateRating dentro de un Product:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Servicio de SEO mensual",
  "aggregateRating": {
    "@type": "AggregateRating",
    "ratingValue": "4.8",
    "reviewCount": "89",
    "bestRating": "5",
    "worstRating": "1"
  },
  "review": [
    {
      "@type": "Review",
      "reviewRating": {
        "@type": "Rating",
        "ratingValue": "5",
        "bestRating": "5"
      },
      "author": {
        "@type": "Person",
        "name": "María García"
      },
      "reviewBody": "Empezamos a trabajar con Escala14 hace seis meses y los resultados han sido increíbles. Pasamos de la segunda página a los tres primeros resultados en nuestras palabras clave principales.",
      "datePublished": "2026-02-15"
    }
  ]
}

Regla de oro de las reseñas en schema: las valoraciones deben ser reales y verificables. Google ha dejado muy claro que no mostrará rich snippets de valoraciones si:

Las reseñas son generadas por la propia empresa sin participación de usuarios reales
El schema de valoraciones aparece en páginas donde no hay reseñas visibles en el HTML
Los valores del schema no coinciden con las valoraciones reales que se muestran en la página
Las valoraciones provienen de pagos u otros incentivos no divulgados

El riesgo de manipular este schema no es solo perder el rich snippet: Google puede penalizar manualmente el sitio.

✅ Cómo auditarlo: verifica que los valores de ratingValue y reviewCount coinciden con los datos reales de tus sistemas de reseñas. Comprueba que las reseñas individuales en el schema son reales y están visibles en la página.

Regla 13: VideoObject — el vídeo como resultado enriquecido

Si publicas vídeos en tu web (ya sea alojados en tu propio servidor, en YouTube o en otras plataformas), el schema VideoObject habilita los Video Rich Results: resultados con miniatura de vídeo, duración y fecha de publicación directamente en la SERP. Los resultados con miniaturas de vídeo tienen tasas de clics significativamente más altas que los resultados de texto plano, especialmente en búsquedas desde dispositivos móviles.

Esto es especialmente relevante para páginas que incrustan vídeos de YouTube: aunque Google puede rastrear el vídeo de YouTube por su cuenta, el schema VideoObject en tu página le indica que ese vídeo es parte integral del contenido de esa URL, lo que refuerza la asociación.

{
  "@context": "https://schema.org",
  "@type": "VideoObject",
  "name": "Cómo implementar datos estructurados en tu web — Tutorial JSON-LD",
  "description": "Guía paso a paso para implementar Schema.org markup en JSON-LD: Article, Product, FAQPage, Organization y más.",
  "thumbnailUrl": "https://escala14.com/images/thumbnail-video-schema.webp",
  "uploadDate": "2026-03-18T00:00:00+01:00",
  "duration": "PT12M30S",
  "contentUrl": "https://www.youtube.com/watch?v=ejemplo123",
  "embedUrl": "https://www.youtube.com/embed/ejemplo123",
  "publisher": {
    "@type": "Organization",
    "name": "Escala14",
    "logo": {
      "@type": "ImageObject",
      "url": "https://escala14.com/logo.webp",
      "width": 300,
      "height": 80
    }
  },
  "interactionStatistic": {
    "@type": "InteractionCounter",
    "interactionType": "https://schema.org/WatchAction",
    "userInteractionCount": 1547
  }
}

Campos imprescindibles:

thumbnailUrl: la imagen de miniatura del vídeo. Debe tener mínimo 1200 × 675 px para aparecer en el carrusel de vídeos de Google. Google rechaza thumbnails demasiado pequeñas.

uploadDate: la fecha de publicación en formato ISO 8601. Es obligatoria para el Video rich result.

duration: la duración en formato ISO 8601 (PT12M30S significa 12 minutos y 30 segundos). Es requerida para el rich result. PT = Period Time, H = horas, M = minutos, S = segundos.

contentUrl vs embedUrl: contentUrl es la URL del archivo de vídeo en sí (o la URL de YouTube). embedUrl es la URL del reproductor incrustable. Para vídeos de YouTube, el embedUrl es https://www.youtube.com/embed/{id}.

✅ Cómo auditarlo: verifica que el campo thumbnailUrl apunta a una imagen accesible con las dimensiones correctas. Comprueba que duration y uploadDate son precisos. Usa Google Rich Results Test para validar el schema completo.

Cómo priorizar la implementación de datos estructurados

Implementar los 13 tipos de schema de golpe no es la estrategia más eficiente. Aquí tienes una hoja de ruta ordenada por impacto y facilidad de implementación:

Fase 1: Los cimientos (primera semana)

Antes de cualquier tipo específico, asegúrate de que el formato, la validez, el @type y los campos requeridos son correctos en todos los schemas que ya tienes. Un JSON-LD inválido es peor que no tener JSON-LD — consume presupuesto de rastreo sin generar ningún beneficio.

Audita todos los schemas existentes con Google Rich Results Test
Corrige errores de sintaxis y campos requeridos faltantes
Migra de RDFa o Microdata a JSON-LD si es necesario

Fase 2: Schemas universales (segunda semana)

Estos schemas van en todas las webs, independientemente del sector:

WebSite + SearchAction → página de inicio
Organization → página de inicio o layout global
BreadcrumbList → todas las páginas internas

Fase 3: Schemas según el tipo de negocio

Implementa solo los que aplican a tu modelo de negocio:

Tipo de negocio	Schemas prioritarios
Blog / medio de comunicación	`BlogPosting` / `Article`
E-commerce	`Product`, `AggregateRating`, `Review`
Negocio local	`LocalBusiness`, `OpeningHoursSpecification`
Agencia de servicios	`Service`, `FAQPage`, `Organization`
Canal con vídeos	`VideoObject`
Cualquier web con FAQ	`FAQPage`

Fase 4: Validación y monitorización

Una vez implementados todos los schemas relevantes:

Valida con Google Rich Results Test y el Schema Markup Validator
Comprueba en Google Search Console → Mejoras → Resultados enriquecidos que no hay errores
Espera 2-4 semanas para que Google procese los cambios
Monitoriza el CTR en GSC por páginas para detectar incrementos tras la aparición de rich snippets

Checklist de las 13 reglas

Usa esta lista para auditar los datos estructurados de cualquier web:

Cimientos (reglas 1–4)

Regla 1 — Formato JSON-LD: todos los schemas usan <script type="application/ld+json">, no RDFa ni Microdata
Regla 2 — Validez: el JSON-LD es sintácticamente válido (sin comas trailing, sin claves sin entrecomillar)
Regla 3 — @type adecuado: el tipo de schema coincide con el contenido real de cada página
Regla 4 — Campos requeridos: todos los campos obligatorios según las directrices de Google están presentes

Schemas universales (reglas 5–6)

Regla 5 — WebSite: la página de inicio tiene schema WebSite con potentialAction + SearchAction (si hay buscador interno)
Regla 6 — Organization: la página de inicio tiene schema Organization con name, url, logo y sameAs

Schemas de contenido (reglas 7–9)

Regla 7 — Article/BlogPosting: todos los artículos y posts tienen schema con headline, image, datePublished y author
Regla 8 — BreadcrumbList: las páginas internas con breadcrumbs tienen el schema BreadcrumbList correspondiente
Regla 9 — FAQPage: las páginas con preguntas frecuentes visibles tienen el schema FAQPage con la estructura correcta de mainEntity

Schemas de negocio (reglas 10–13)

Regla 10 — LocalBusiness: los negocios locales tienen schema con address, geo, openingHoursSpecification y telephone
Regla 11 — Product: las páginas de producto tienen schema con offers (precio, disponibilidad, priceCurrency)
Regla 12 — Review/AggregateRating: los schemas de valoración reflejan reseñas reales visibles en la página
Regla 13 — VideoObject: las páginas con vídeo tienen schema con thumbnailUrl, duration y uploadDate

Preguntas frecuentes

¿Los datos estructurados mejoran directamente el ranking en Google?

No son un factor de ranking directo. Google ha confirmado que implementar Schema.org markup no te sube posiciones por sí solo. El beneficio es indirecto: los rich snippets incrementan el CTR, y una mayor tasa de clics puede mejorar las señales de comportamiento que Google sí considera en su algoritmo. Además, algunos tipos de schema (como Article) pueden mejorar la elegibilidad para Google Discover, que sí tiene un impacto en el tráfico.

¿Cuánto tarda Google en procesar los datos estructurados?

Depende de la frecuencia de rastreo de tu sitio. En webs con buena autoridad y rastreo frecuente, los cambios en schemas pueden procesarse en 1-2 semanas. En sitios más pequeños puede tardar 4-6 semanas. Puedes acelerar el proceso enviando las URLs afectadas a través de Google Search Console → Inspección de URL → Solicitar indexación.

¿Qué pasa si el contenido del schema no coincide con el contenido visible de la página?

Google puede desactivar el rich snippet para esa página e incluso emitir una acción manual si considera que el schema es engañoso. Las directrices de Google son claras: el contenido del schema debe reflejar fielmente lo que el usuario ve en la página. Nunca añadas información en el schema (precios, valoraciones, disponibilidad) que no esté también visible en el HTML.

¿Puedo tener múltiples schemas en una misma página?

Sí, y es habitual y recomendable. Una página de artículo puede tener simultáneamente BlogPosting, BreadcrumbList, FAQPage y Organization. Puedes usar múltiples bloques <script type="application/ld+json"> independientes (uno por tipo) o agruparlos en un array JSON-LD. Ambos enfoques son válidos.

¿Debo usar `@graph` para organizar múltiples schemas?

@graph es una propiedad de JSON-LD que permite agrupar múltiples entidades en un único bloque y definir relaciones entre ellas con IDs internos. Es útil para implementaciones complejas donde las entidades están relacionadas (por ejemplo, un Article que referencia una Organization como publisher). Para implementaciones sencillas, múltiples bloques JSON-LD independientes son más fáciles de mantener y funcionan igualmente bien.

¿Qué herramientas puedo usar para testear mis datos estructurados?

Las herramientas principales son tres. Google Rich Results Test es la herramienta oficial de Google para comprobar si una URL es elegible para resultados enriquecidos — muestra qué rich snippets puede mostrar Google y qué errores o advertencias tiene el schema. Schema Markup Validator de Schema.org valida contra la especificación de Schema.org (más permisivo que Google). Y Google Search Console → Mejoras muestra en producción qué páginas tienen errores en datos estructurados y cuántas tienen rich snippets activos.

El equipamiento que marca la diferencia en la SERP

Los datos estructurados son como el equipamiento técnico de un alpinista: no te hacen más rápido por sí solos, pero sin él no puedes afrontar las rutas más exigentes. Un artículo bien escrito con un schema BlogPosting correcto llega más lejos que el mismo artículo sin él; una ficha de producto con AggregateRating compite en un plano diferente al de las fichas sin estrellas.

La implementación completa de estas 13 reglas no es un proyecto de un día, pero tampoco es una expedición de meses. Con una auditoría inicial bien hecha, las correcciones de los cimientos y la implementación progresiva de los schemas según el tipo de contenido, puedes tener todo en orden en pocas semanas.

Si quieres que auditemos los datos estructurados de tu web y creemos un plan de implementación a medida, escríbenos. Juntos trazaremos la ruta perfecta para que tus páginas lleguen a la cima de los resultados enriquecidos.

Solicitar auditoría SEO gratuita → Ver nuestros servicios SEO →