Schema markup: qué es y cómo validarlo 2026

Si has llegado hasta aquí es probable que te hayan dicho que «tienes que meter schema» en tu web, o que hayas visto en la competencia estrellas, precios o migas de pan en los resultados de Google y te preguntes cómo se consigue. En esta guía vas a entender qué es exactamente el schema markup, qué formatos existen, qué tipos merecen tu tiempo en 2026, qué ha cambiado en los resultados enriquecidos en los últimos años y, sobre todo, cómo validarlo paso a paso para no publicar marcado roto o, peor, marcado que Google considera engañoso.

No hace falta ser programador para seguirla. Los ejemplos de código están comentados y puedes copiarlos, adaptarlos y comprobarlos con herramientas gratuitas, incluido nuestro formateador de JSON, que te ayuda a detectar la coma que sobra antes de pasar el bloque por un validador.

Qué es el schema markup y qué es Schema.org

El schema markup (marcado de esquema) es un conjunto de anotaciones que añades al código de una página para describir su contenido de forma que una máquina lo entienda sin ambigüedad. Un humano ve «19,90 €» junto a una foto y sabe que es un precio; un rastreador ve una cadena de texto. Con datos estructurados le dices explícitamente: esto es un Product, su nombre es este, tiene una Offer con precio 19.90 y moneda EUR, y está disponible.

Schema.org es el vocabulario común que se usa para esas anotaciones. Nació en 2011 como iniciativa conjunta de Google, Microsoft (Bing) y Yahoo, a la que se sumó Yandex poco después, con un objetivo sencillo: que los webmasters no tuvieran que marcar su contenido de una forma distinta para cada buscador. Hoy lo mantiene una comunidad abierta con un proceso público de propuestas, y el vocabulario incluye cientos de tipos (Organization, Article, Event, Recipe, JobPosting…) y más de mil propiedades.

Conviene separar tres conceptos que se usan como sinónimos y no lo son:

Datos estructurados: la idea general de describir información con un formato estandarizado y legible por máquinas.
Schema.org: el vocabulario (los nombres de tipos y propiedades) que casi todo el mundo usa para ello en la web.
Resultados enriquecidos (rich results, antes llamados rich snippets): las presentaciones especiales que Google puede mostrar en su buscador cuando entiende esos datos y la página cumple sus requisitos. Son una posible consecuencia, no el objetivo único.

¿El schema markup mejora el posicionamiento?

Respuesta corta: no de forma directa. Google ha repetido en su documentación que los datos estructurados le ayudan a entender la página y pueden hacerla apta para resultados enriquecidos, pero no son un factor de ranking por sí mismos. Donde sí se nota es en la presentación: un resultado con migas de pan limpias, precio y disponibilidad o fecha de un evento ocupa más espacio y da más información antes del clic. Eso puede influir en el porcentaje de clics, aunque el efecto depende tanto de la consulta, del sector y de lo que muestren los competidores que no tiene sentido prometer una cifra concreta.

Hay una segunda razón para cuidarlo que gana peso cada año: los buscadores y los sistemas que generan respuestas a partir de la web se apoyan en entidades bien definidas. Que tu empresa, tu autor o tu producto estén descritos con coherencia (mismo nombre, misma URL, mismos perfiles enlazados con sameAs) ayuda a que se te identifique correctamente. No es magia ni garantiza nada, pero es trabajo que no se pierde.

Piensa en el schema como en el etiquetado de un almacén: no hace que tus productos sean mejores, pero evita que alguien confunda la caja de tornillos con la de clavos. Si la etiqueta miente, el problema es más grave que no tener etiqueta.

JSON-LD, microdatos y RDFa: los tres formatos

El vocabulario de Schema.org se puede escribir en tres sintaxis distintas. Google admite las tres, pero recomienda JSON-LD siempre que tu plataforma lo permita, porque separa el marcado del HTML visible y es mucho más fácil de mantener.

Formato	Cómo se escribe	Ventajas	Inconvenientes
JSON-LD	Un bloque `<script type="application/ld+json">` con un objeto JSON, en el `head` o en el `body`	No toca el HTML visible; fácil de generar desde plantillas o CMS; permite `@graph` e `@id` para relacionar entidades; formato recomendado por Google	Es fácil que el bloque diga una cosa y la página otra si no se sincronizan
Microdatos	Atributos `itemscope`, `itemtype` e `itemprop` sobre las propias etiquetas HTML	El dato marcado es literalmente el texto visible, así que es difícil que se desalineen	Ensucia el HTML; cualquier rediseño puede romper el anidamiento; difícil de leer y depurar
RDFa	Atributos `vocab`, `typeof` y `property` sobre el HTML	Estándar del W3C, útil si ya trabajas con otros vocabularios de la web semántica	Poco habitual en SEO práctico; mismos problemas de mantenimiento que los microdatos

Así se ve el mismo dato (el nombre de una organización y su web) en las tres sintaxis. Primero en JSON-LD:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Ferretería Ejemplo",
  "url": "https://www.ejemplo.com/"
}
</script>

En microdatos, las propiedades van pegadas al contenido visible:

<div itemscope itemtype="https://schema.org/Organization">
  <a itemprop="url" href="https://www.ejemplo.com/">
    <span itemprop="name">Ferretería Ejemplo</span>
  </a>
</div>

Y en RDFa:

<div vocab="https://schema.org/" typeof="Organization">
  <a property="url" href="https://www.ejemplo.com/">
    <span property="name">Ferretería Ejemplo</span>
  </a>
</div>

Nuestra recomendación: usa JSON-LD y genera el bloque desde los mismos datos que pintan la página (la base de datos del CMS, el fichero de producto, la plantilla). Así, cuando cambie el precio o la fecha en la página, cambia también en el marcado. El error más repetido en webs pequeñas no es la sintaxis, sino el JSON-LD pegado a mano hace dos años que ya no coincide con lo que ve el usuario.

Mezclar formatos: se puede, pero con cuidado

Es habitual que un tema de WordPress emita microdatos y un plugin SEO añada JSON-LD por su cuenta. Google puede leer ambos, pero si describen la misma entidad con datos distintos (dos nombres de organización, dos logos, dos precios), el resultado es confuso y los validadores te mostrarán dos objetos. Si detectas duplicados, deja una sola fuente: normalmente la del plugin, y desactiva el marcado del tema.

Los tipos de schema más útiles en 2026

Schema.org tiene cientos de tipos, pero Google solo usa un subconjunto para resultados enriquecidos y el resto le sirve, como mucho, para entender mejor la página. Estos son los que tienen sentido para la mayoría de webs. La columna de requisitos resume lo que Google pide en su documentación para cada función; consúltala siempre antes de publicar, porque los requisitos cambian.

Tipo	Para qué páginas	Propiedades clave	Qué puede aportar en Google
`Organization`	Home o página «sobre nosotros»	`name`, `url`, `logo`, `sameAs`, datos de contacto	Ayuda a identificar tu marca (logo, perfiles); no genera un resultado enriquecido propio en cada búsqueda
`Article` / `BlogPosting`	Noticias y entradas de blog	`headline`, `image`, `datePublished`, `dateModified`, `author`	Mejor interpretación de título, imagen, fechas y autoría
`Product` + `Offer`	Fichas de producto	`name`, `image`, `offers.price`, `offers.priceCurrency`, `offers.availability`	Precio, disponibilidad y, si hay reseñas reales, valoración
`BreadcrumbList`	Casi todas las páginas con jerarquía	`itemListElement` con `ListItem`, `position`, `name`, `item`	Ruta de navegación en lugar de la URL cruda
`LocalBusiness`	Negocios con local físico	`name`, `address`, `telephone`, `openingHoursSpecification`, `geo`	Refuerza los datos del negocio; la ficha de Google Business Profile sigue mandando
`Event`	Conciertos, cursos presenciales u online con fecha	`name`, `startDate`, `location`, `eventStatus`, `offers`	Fecha, lugar y entradas en experiencias de eventos
`Recipe`	Recetas	`name`, `image`, `recipeIngredient`, `recipeInstructions`, `totalTime`	Imagen, tiempo y valoración en carruseles de recetas

Organization: la base de todo

Aunque no te dé un fragmento vistoso, Organization (o su subtipo más preciso, como OnlineStore o LocalBusiness) es lo primero que deberías marcar. Define quién publica el sitio, con qué logo y qué perfiles oficiales tiene. El truco es darle un @id estable y reutilizarlo en el resto de bloques como publisher, en lugar de repetir los datos en cada página con pequeñas variaciones.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://www.ejemplo.com/#organization",
  "name": "Ferretería Ejemplo",
  "url": "https://www.ejemplo.com/",
  "logo": "https://www.ejemplo.com/img/logo-512.png",
  "sameAs": [
    "https://www.linkedin.com/company/ejemplo",
    "https://www.instagram.com/ejemplo"
  ]
}
</script>

Article: autoría y fechas honestas

En un blog, el tipo Article (o BlogPosting) no tiene propiedades obligatorias para Google, pero sí recomendadas. Las que más importan son el titular, una imagen representativa, las fechas y el autor. Dos reglas de sentido común: la dateModified debe cambiar solo cuando el contenido cambia de verdad, no cada vez que se regenera la web; y el author debe ser quien lo firma en la página. Si el texto lo firma la redacción, el autor es la organización; inventarse un experto con cargo para parecer más fiable es exactamente el tipo de marcado engañoso que conviene evitar.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "headline": "Cómo elegir un taladro percutor",
  "image": "https://www.ejemplo.com/img/taladro-1200x630.jpg",
  "datePublished": "2026-03-10",
  "dateModified": "2026-09-01",
  "author": {
    "@type": "Organization",
    "name": "Redacción Ferretería Ejemplo",
    "url": "https://www.ejemplo.com/"
  },
  "publisher": { "@id": "https://www.ejemplo.com/#organization" }
}
</script>

Product y Offer: donde más errores se ven

Una ficha de producto es el caso clásico. Aquí el precio y la disponibilidad del marcado deben coincidir con lo que ve el comprador. Fíjate en tres detalles que dan muchos avisos: el precio va como número con punto decimal (19.90, no 19,90 €), la moneda en código ISO 4217 (EUR) y la disponibilidad como URL de Schema.org (https://schema.org/InStock, OutOfStock, PreOrder…).

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Taladro percutor 800 W",
  "image": "https://www.ejemplo.com/img/taladro.jpg",
  "sku": "TAL-800",
  "brand": { "@type": "Brand", "name": "MarcaEjemplo" },
  "offers": {
    "@type": "Offer",
    "url": "https://www.ejemplo.com/taladro-percutor-800w/",
    "price": "59.90",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "itemCondition": "https://schema.org/NewCondition"
  }
}
</script>

Observa lo que no lleva: ni aggregateRating ni review. Solo tiene sentido añadirlos si la página muestra reseñas reales de clientes que puedes respaldar. Poner una nota de 4,8 con cien votos que no existen es la forma más rápida de acabar con una acción manual en Search Console.

BreadcrumbList: poco esfuerzo, efecto visible

Las migas de pan son probablemente el marcado con mejor relación esfuerzo/beneficio. Describen la jerarquía de la página y Google puede mostrarlas en lugar de la URL. Solo necesitas que coincidan con la ruta de navegación visible y que cada item sea una URL real e indexable. La última miga (la página actual) puede ir sin item.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    { "@type": "ListItem", "position": 1, "name": "Inicio", "item": "https://www.ejemplo.com/" },
    { "@type": "ListItem", "position": 2, "name": "Herramientas", "item": "https://www.ejemplo.com/herramientas/" },
    { "@type": "ListItem", "position": 3, "name": "Taladro percutor 800 W" }
  ]
}
</script>

Un fallo típico: tener dos BreadcrumbList en la misma página, uno del tema y otro del plugin, con rutas distintas. Deja solo uno.

LocalBusiness: complemento, no sustituto

Si tienes un local físico, marca LocalBusiness o el subtipo que mejor te describa (Restaurant, Dentist, HardwareStore…). Incluye dirección postal completa, teléfono, horario y coordenadas. Ten claro que para aparecer en el mapa y en el paquete local lo que manda es tu perfil de empresa en Google; el marcado de tu web refuerza esos datos, así que ambos deben coincidir al carácter (mismo nombre, misma dirección, mismo teléfono).

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "HardwareStore",
  "name": "Ferretería Ejemplo",
  "url": "https://www.ejemplo.com/",
  "telephone": "+34 900 000 000",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Calle Mayor 1",
    "addressLocality": "Valencia",
    "postalCode": "46001",
    "addressCountry": "ES"
  },
  "openingHoursSpecification": [{
    "@type": "OpeningHoursSpecification",
    "dayOfWeek": ["Monday","Tuesday","Wednesday","Thursday","Friday"],
    "opens": "09:00",
    "closes": "20:00"
  }]
}
</script>

Event: fechas en ISO 8601 y estado del evento

Para eventos, la fecha es lo crítico. Usa el formato ISO 8601 con zona horaria (2026-11-14T19:30+01:00) y marca eventStatus si el evento se aplaza o se cancela, en vez de borrar el marcado. Si es online, la location es un VirtualLocation con la URL, y el eventAttendanceMode indica si es presencial, online o mixto.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Event",
  "name": "Taller de bricolaje para principiantes",
  "startDate": "2026-11-14T10:00+01:00",
  "endDate": "2026-11-14T13:00+01:00",
  "eventStatus": "https://schema.org/EventScheduled",
  "eventAttendanceMode": "https://schema.org/OfflineEventAttendanceMode",
  "location": {
    "@type": "Place",
    "name": "Ferretería Ejemplo",
    "address": {
      "@type": "PostalAddress",
      "streetAddress": "Calle Mayor 1",
      "addressLocality": "Valencia",
      "addressCountry": "ES"
    }
  },
  "offers": {
    "@type": "Offer",
    "price": "15.00",
    "priceCurrency": "EUR",
    "availability": "https://schema.org/InStock",
    "url": "https://www.ejemplo.com/talleres/"
  }
}
</script>

Recipe: el tipo más exigente

Las recetas son de los pocos casos donde el marcado sigue teniendo una presentación muy rica. A cambio, Google pide imagen y nombre como mínimo, y recomienda ingredientes, pasos, tiempos (en formato de duración ISO 8601, por ejemplo PT45M para 45 minutos), raciones y, si las tienes, valoraciones reales. Los pasos van mejor como lista de HowToStep que como un bloque de texto único.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Recipe",
  "name": "Tortilla de patatas",
  "image": "https://www.ejemplo.com/img/tortilla.jpg",
  "recipeYield": "4 raciones",
  "totalTime": "PT45M",
  "recipeIngredient": ["5 huevos", "600 g de patatas", "1 cebolla", "Aceite de oliva", "Sal"],
  "recipeInstructions": [
    { "@type": "HowToStep", "text": "Pela y corta las patatas y la cebolla en láminas finas." },
    { "@type": "HowToStep", "text": "Fríelas a fuego medio hasta que estén tiernas y escúrrelas." },
    { "@type": "HowToStep", "text": "Bate los huevos, mezcla y cuaja la tortilla por ambos lados." }
  ]
}
</script>

Resultados enriquecidos: qué muestra Google y qué ha cambiado

Los resultados enriquecidos son la parte visible del esfuerzo, pero también la más cambiante. Google decide qué funciones ofrece, para qué sitios y en qué dispositivos, y las ha ido recortando para simplificar la página de resultados. Tenerlo presente evita invertir horas en marcado que ya no se muestra.

FAQ y HowTo: lo que cambió en 2023

Durante años, marcar preguntas frecuentes con FAQPage era la forma más rápida de ocupar espacio en los resultados: aparecían desplegables con preguntas bajo el enlace. En agosto de 2023 Google anunció que limitaba ese resultado enriquecido a sitios gubernamentales y sanitarios con autoridad reconocida, y que dejaba de mostrar los resultados de HowTo (primero en móvil y después también en ordenador). En la práctica, para un blog, una tienda o una web de herramientas, el marcado FAQ ya no produce desplegables en Google.

¿Significa que debes borrarlo? No necesariamente. Google indicó que el marcado no es perjudicial por estar presente y otros buscadores o sistemas pueden seguir leyéndolo. Lo que sí debes hacer es no contar con él como fuente de tráfico y, si lo mantienes, asegurarte de que las preguntas y respuestas están visibles en la página y coinciden al pie de la letra con el JSON-LD.

Otras retiradas y simplificaciones

No han sido las únicas. En 2024 Google retiró el cuadro de búsqueda de enlaces de sitio (el que se activaba con WebSite + SearchAction) y en 2025 anunció que dejaba de mostrar varios resultados enriquecidos poco usados. La lección es clara: antes de marcar un tipo pensando en un efecto visual concreto, revisa la galería de resultados enriquecidos de la documentación de Google Search Central, que es la referencia actualizada de lo que se sigue mostrando.

Marca lo que describe honestamente tu contenido, no lo que crees que te dará un efecto visual. Los efectos visuales cambian cada pocos meses; una descripción fiel de tu página sigue siendo útil.

Por qué a veces no aparece el resultado enriquecido

Es la duda más frecuente. Tienes el marcado validado sin errores y Google no muestra nada especial. Las causas habituales son:

La función no existe para tu caso: por ejemplo, FAQ en una web comercial después de 2023.
Google no lo considera útil para esa consulta: el resultado enriquecido es elegible, pero no está garantizado. Puede mostrarse para unas búsquedas y no para otras.
Calidad general del sitio: Google puede ignorar el marcado de sitios que considera de baja calidad o con historial de marcado engañoso.
No ha recrawleado la página: los cambios pueden tardar días o semanas en reflejarse, según la frecuencia con que Google visite tu web.
Problemas técnicos: la página está bloqueada en robots.txt, lleva noindex, el marcado se inyecta con JavaScript que falla, o la URL canónica es otra.

Políticas de Google contra el marcado engañoso

Este apartado es el que más se salta y el que más disgustos da. Google tiene unas directrices generales de datos estructurados que se aplican a todos los tipos, y su incumplimiento puede acabar en una acción manual por datos estructurados que retira los resultados enriquecidos de todo el sitio hasta que lo corrijas y pidas reconsideración.

El contenido marcado tiene que estar visible

La regla de oro: todo lo que dices en el marcado debe estar en la página y ser visible para el usuario. No vale marcar preguntas frecuentes que no aparecen, precios que no se muestran o reseñas que el visitante no puede leer. Tampoco marcar contenido oculto con CSS solo para el buscador. Si el dato no está en la página, no lo pongas en el JSON-LD.

Reseñas autoasignadas y valoraciones inventadas

Desde 2019, Google no muestra estrellas de reseñas para LocalBusiness y Organization cuando las reseñas sobre esa entidad las publica la propia entidad en su web (las llamadas reseñas autoasignadas o self-serving). Si quieres que se vean tus opiniones de clientes en Google, el camino es el perfil de empresa de Google o plataformas de terceros, no marcar tu propia página con una nota.

Es marcado engañoso de manual, además de un problema de confianza con tus usuarios. Si no tienes reseñas reales que se puedan leer en la página, no hay aggregateRating.

Otros casos que Google considera engañosos

Marcar como Product una página de categoría que lista muchos productos para intentar sacar un precio.
Marcar un evento que en realidad es una oferta o un cupón.
Atribuir el contenido a un autor con credenciales que no se puedan comprobar o que no firme la página.
Marcar un JobPosting de una oferta que ya no está vigente, o que no permite solicitar el empleo.
Usar datos estructurados de un tipo que no corresponde al contenido principal de la página (una receta marcada en una página que vende sartenes).

Si dudas de si un marcado es engañoso, hazte una pregunta: ¿se sentiría engañado un usuario que ve el resultado en Google y luego entra en la página? Si la respuesta es sí o quizá, no lo marques.

Cómo validar el schema markup de tu web paso a paso

Validar no es un paso único, sino tres comprobaciones distintas que responden a preguntas diferentes. Conviene hacer las tres, en este orden.

Herramienta	Qué comprueba	Cuándo usarla	Limitaciones
Prueba de resultados enriquecidos (Google)	Si la página o el código es apto para los resultados enriquecidos que Google admite hoy, con errores y advertencias	Antes de publicar (pegando código) y justo después (con la URL)	Solo evalúa los tipos que generan resultados enriquecidos; el resto no aparece aunque sea válido
Schema Markup Validator (validator.schema.org)	Que la sintaxis sea correcta y que tipos y propiedades existan en el vocabulario de Schema.org	Para cualquier tipo, incluidos los que Google no usa para resultados enriquecidos	No dice si Google mostrará algo ni aplica sus requisitos específicos
Google Search Console (informes de mejoras y de resultados enriquecidos)	Qué marcado ha detectado Google al rastrear tu sitio, con recuento de elementos válidos, con advertencias y no válidos	Seguimiento continuo de todo el sitio	Los datos llegan con retraso y dependen del rastreo; solo cubre tipos con informe propio
Inspección de URLs (Search Console)	El HTML renderizado que ve Google y los datos estructurados detectados en una URL concreta	Cuando el marcado se inyecta con JavaScript o sospechas que Google ve otra cosa	URL por URL; hay un límite diario de solicitudes de indexación

Paso 1: comprueba el JSON antes que el schema

La mayoría de errores «graves» son de JSON, no de Schema.org: una coma final después del último elemento, comillas tipográficas (“ ”) en lugar de rectas ("), una llave sin cerrar o un salto de línea dentro de una cadena. Un validador de schema te dirá que hay un error de análisis, pero no siempre dónde. Pega el contenido del bloque (sin las etiquetas <script>) en nuestro formateador y validador de JSON: si lo indenta sin quejarse, la sintaxis es correcta y puedes pasar al siguiente paso. Si quieres repasar las reglas del formato, tienes la guía JSON: qué es y cómo formatearlo.

Paso 2: Prueba de resultados enriquecidos

Entra en la Prueba de resultados enriquecidos de Google (search.google.com/test/rich-results) y elige entre analizar una URL publicada o pegar código. Antes de publicar, pega el HTML completo o el bloque JSON-LD; después de publicar, usa la URL, porque así Google renderiza la página como lo haría su rastreador (incluido el JavaScript) y detecta problemas que no verías con el código suelto.

El resultado te dirá qué elementos ha detectado (por ejemplo, «Fragmentos de producto» o «Rutas de exploración») y si son válidos. Distingue bien entre:

Errores: faltan propiedades obligatorias o hay valores no válidos. Ese elemento no es apto para resultados enriquecidos hasta que lo corrijas.
Advertencias: faltan propiedades recomendadas. El elemento es apto, pero podría mostrarse con menos información. Corrígelas si el dato existe y es real; no te inventes un dato para silenciar una advertencia.

Si la herramienta dice que no ha detectado ningún resultado enriquecido pero tu JSON es correcto, probablemente el tipo que usas no genera resultados enriquecidos (por ejemplo, Organization o WebPage). No es un error: pasa al siguiente validador.

Paso 3: Schema Markup Validator

El validador de Schema.org (validator.schema.org) sustituyó a la antigua herramienta de prueba de datos estructurados de Google. Analiza cualquier tipo del vocabulario, en JSON-LD, microdatos o RDFa, y te muestra el árbol de entidades que ha extraído. Es la mejor forma de ver cosas que la prueba de Google no enseña:

Propiedades mal escritas (datepublished en lugar de datePublished: el vocabulario distingue mayúsculas).
Propiedades que no pertenecen a ese tipo.
Entidades duplicadas procedentes de distintos plugins.
Relaciones por @id que no apuntan a nada.

Paso 4: Search Console para todo el sitio

Las dos herramientas anteriores revisan páginas sueltas. Para el conjunto del sitio necesitas Google Search Console. En el menú verás informes por tipo de resultado enriquecido detectado (fichas de producto, rutas de exploración, eventos, recetas…), con el recuento de elementos válidos y no válidos y ejemplos de URLs afectadas. Trabaja así:

Abre el informe del tipo que te interesa y ordena los problemas por número de elementos afectados.
Abre una URL de ejemplo, reproduce el error con la Prueba de resultados enriquecidos y corrígelo en la plantilla, no en la página suelta.
Cuando lo hayas desplegado, pulsa «Validar corrección». Google volverá a rastrear las URLs afectadas y actualizará el estado; el proceso puede llevar días.
Revisa también el apartado de acciones manuales. Si aparece una por datos estructurados, corrige el marcado engañoso en todo el sitio antes de solicitar la reconsideración.

Si la página no está en Search Console o no tienes acceso, la Prueba de resultados enriquecidos con la URL publicada es la alternativa más fiable.

Paso 5: vuelve a validar cuando cambie algo

Un cambio de tema, la actualización de un plugin SEO o una migración pueden duplicar, romper o borrar el marcado sin que nadie lo note. Añade la validación a tu lista de comprobaciones tras cualquier cambio de plantilla y revisa los informes de Search Console al menos una vez al mes.

Errores típicos al añadir schema markup

Estos son los fallos que más se repiten cuando se revisa el marcado de webs pequeñas y medianas. La mayoría se detectan en minutos con los validadores anteriores.

Error	Cómo se detecta	Cómo se arregla
JSON inválido (coma final, comillas tipográficas)	Error de análisis en ambos validadores	Pasar el bloque por un formateador de JSON y corregir la línea señalada
Precio con coma o símbolo (`"19,90 €"`)	Advertencia o error en `price`	Número con punto (`"19.90"`) y moneda aparte en `priceCurrency`
Fechas en formato local (`14/11/2026`)	Valor no válido en fechas	ISO 8601: `2026-11-14` o con hora y zona
Marcado que no coincide con la página	Revisión manual; a veces acción manual	Generar el JSON-LD desde los mismos datos que la página
Dos bloques del mismo tipo con datos distintos	Entidades duplicadas en el validador de Schema.org	Dejar una única fuente (plugin o tema, no ambos)
`aggregateRating` sin reseñas visibles	No lo detecta el validador; lo detecta Google al revisar	Eliminarlo hasta tener reseñas reales visibles
URLs relativas en `image`, `url` o `item`	Valores no válidos o imagen no encontrada	Usar URLs absolutas con protocolo
Imágenes bloqueadas o demasiado pequeñas	Advertencia en la propiedad `image`	Imagen rastreable, indexable y de buen tamaño
`dateModified` que cambia a diario sin cambios reales	No lo marca ningún validador	Actualizarla solo al modificar el contenido

El JSON-LD dentro de la página equivocada

Otro clásico de las webs generadas con plantillas: el bloque de schema de una página se copia en otra y nadie cambia el headline, la url o el @id. El validador no se queja porque la sintaxis es perfecta, pero Google recibe datos de otra página. La única defensa es revisar a mano, al menos una vez, que los valores del marcado describen la página en la que están.

Marcado inyectado con JavaScript

Google puede leer JSON-LD añadido con JavaScript (por ejemplo, desde Google Tag Manager), pero depende de que el renderizado funcione y llega más tarde que el HTML inicial. Si puedes, sírvelo en el HTML. Si no, comprueba con la Inspección de URLs de Search Console que el HTML renderizado contiene el bloque, y ten en cuenta que otros buscadores y herramientas pueden no ejecutar tu JavaScript.

Cómo organizar el marcado de una web completa

Cuando pasas de una página a un sitio entero, conviene pensar el marcado como un pequeño grafo de entidades y no como bloques sueltos. Un esquema razonable para una web de contenidos o una tienda pequeña:

En todo el sitio: Organization (con @id fijo) y, si quieres, WebSite con el nombre del sitio.
En cada página con jerarquía: un único BreadcrumbList que coincida con las migas visibles.
En artículos: Article o BlogPosting con publisher apuntando al @id de la organización.
En fichas: Product con su Offer, sin valoraciones salvo que existan.
En páginas especiales: LocalBusiness, Event o Recipe solo donde el contenido principal sea eso.

Puedes agrupar varias entidades en un solo bloque con @graph, lo que facilita las referencias cruzadas:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.ejemplo.com/#organization",
      "name": "Ferretería Ejemplo",
      "url": "https://www.ejemplo.com/"
    },
    {
      "@type": "WebSite",
      "@id": "https://www.ejemplo.com/#website",
      "name": "Ferretería Ejemplo",
      "url": "https://www.ejemplo.com/",
      "publisher": { "@id": "https://www.ejemplo.com/#organization" }
    }
  ]
}
</script>

Si usas WordPress, plugins como Yoast SEO o Rank Math ya generan un grafo parecido de forma automática. En ese caso tu trabajo es configurar bien los datos de la organización, revisar que el tema no duplique marcado y añadir solo los tipos específicos que falten. En una web estática o hecha a medida, genera el bloque desde la plantilla y valida una página de cada tipo.

El marcado es solo una pieza del SEO técnico. Si estás revisando el resto, te puede servir nuestra guía de herramientas SEO gratuitas para 2026, la selección de herramientas de texto para SEO y la guía de meta tags, complementada con el generador de meta tags. Todas nuestras utilidades para desarrolladores están en la sección SEO dev.

Checklist rápida antes de publicar

El tipo elegido describe el contenido principal de la página.
El JSON es válido (pásalo por un formateador).
Todos los datos del marcado están visibles en la página y coinciden con ella: nombre, precio, fechas, autor.
No hay reseñas, valoraciones ni autores que no puedas respaldar.
URLs absolutas, fechas ISO 8601, precios con punto y moneda ISO 4217.
Un solo bloque por entidad: sin duplicados de tema y plugin.
La Prueba de resultados enriquecidos no muestra errores con la URL publicada.
El validador de Schema.org muestra el árbol de entidades esperado.
La página es indexable, no está bloqueada y su canónica es ella misma.
Search Console está vigilado para detectar errores tras el rastreo.

Preguntas frecuentes sobre schema markup

¿Qué es el schema markup en palabras sencillas?

Es un código que añades a tu página para explicar a los buscadores qué significa su contenido: que este texto es el nombre de un producto, esta cifra su precio o esta fecha la de un evento. Usa el vocabulario de Schema.org y normalmente se escribe en formato JSON-LD.

¿Es lo mismo schema markup que rich snippets?

No. El schema markup es el código que añades; los rich snippets o resultados enriquecidos son la presentación especial que Google puede mostrar gracias a ese código si tu página cumple sus requisitos. Puedes tener un marcado perfecto y no obtener ningún resultado enriquecido.

¿Qué formato de datos estructurados recomienda Google?

JSON-LD. Google admite también microdatos y RDFa, pero recomienda JSON-LD porque es más fácil de añadir y mantener sin tocar el HTML visible.

¿Dónde se pone el JSON-LD, en el head o en el body?

Funciona en ambos. Lo habitual es colocarlo en el head, pero Google también lo lee dentro del body. Lo importante es que esté en el HTML de la página (o se inyecte correctamente) y que sea válido.

¿Cómo sé si mi web ya tiene schema markup?

Pega la URL en el validador de Schema.org o en la Prueba de resultados enriquecidos de Google. También puedes ver el código fuente de la página y buscar application/ld+json, itemtype o typeof.

¿Cuánto tarda Google en mostrar los cambios?

Depende de cuándo vuelva a rastrear la página. En sitios que Google visita a menudo pueden ser días; en otros, semanas. Puedes solicitar la indexación desde la Inspección de URLs de Search Console, pero no hay un plazo garantizado.

¿Sigue sirviendo marcar las preguntas frecuentes con FAQPage?

Para la mayoría de webs ya no produce desplegables en Google, porque desde 2023 ese resultado enriquecido se reserva a sitios gubernamentales y sanitarios de autoridad. El marcado no perjudica si las preguntas están visibles y coinciden, pero no cuentes con él para ganar espacio en los resultados.

¿Puedo poner estrellas de valoración con mis propias reseñas?

Solo si son reseñas reales de clientes visibles en la página y del tipo que Google admite (por ejemplo, productos). Para tu propio negocio u organización, Google no muestra estrellas basadas en reseñas publicadas en tu propia web. Inventarlas puede provocar una acción manual.

¿Qué diferencia hay entre la Prueba de resultados enriquecidos y validator.schema.org?

La prueba de Google comprueba si eres apto para los resultados enriquecidos que Google ofrece hoy. El validador de Schema.org comprueba que la sintaxis y el vocabulario sean correctos para cualquier tipo, aunque Google no lo use. Lo ideal es pasar las dos.

¿El schema markup es obligatorio para posicionar?

No. Puedes posicionar sin datos estructurados, y añadirlos no te sube posiciones por sí solo. Lo que hacen es ayudar a Google a entender la página y hacerla apta para presentaciones más completas, que pueden atraer más clics.

¿Qué hago si Search Console me muestra una acción manual por datos estructurados?

Revisa todo el marcado del sitio, no solo las URLs de ejemplo: elimina reseñas inventadas, datos que no estén visibles y tipos que no correspondan al contenido. Después solicita la reconsideración desde el propio informe explicando qué has corregido.

Conclusión

El schema markup no es un truco para subir posiciones, sino una forma de describir tu contenido con precisión. Hecho bien, con JSON-LD generado desde los mismos datos que la página, sin reseñas ni autores inventados y validado con las tres herramientas en su orden (JSON, Prueba de resultados enriquecidos y validador de Schema.org, más Search Console para el sitio completo), te da una base técnica sólida que aguanta los cambios de Google. Empieza por Organization y BreadcrumbList, añade el tipo específico de cada plantilla y revisa los informes cada mes. Y cuando un validador se queje de un error de sintaxis, pasa el bloque por el formateador de JSON antes de perder media tarde buscando la coma.