Ir al contenido

Glosario Schema.org

¿Qué es Schema.org? Vocabulario y JSON-LD explicados

Manuel Riveiro Rodriguez
Manuel Riveiro Rodriguez

CEO & Digital Strategist

8 min revisado el 08.08.2026

Definición

Schema.org es el vocabulario estandarizado que Google, Bing, Yahoo y Yandex mantienen en conjunto para describir el contenido de una página mediante datos estructurados. No es un formato de código: es un diccionario compartido de tipos y propiedades que después se incorpora al HTML mediante JSON-LD, Microdata o RDFa.

Un acoplamiento metálico normalizado en el extremo de una manguera, junto al título Schema.org
El acoplamiento es estándar; la manguera que traigas, no
En esta página 5
  1. Vocabulario vs. JSON-LD: dos cosas que no son lo mismo
  2. Los tipos de schema más relevantes para una empresa
  3. ¿Es Schema.org un factor de posicionamiento?
  4. Buenas prácticas
  5. Errores frecuentes
En breve

Schema.org define QUÉ información describir (un producto, una empresa, una receta). JSON-LD define CÓMO insertarla en el código, y es el formato que Google recomienda desde 2015. El marcado correcto no mejora el posicionamiento por sí mismo, pero es el requisito técnico para que Google pueda mostrar rich results y para que los sistemas de IA generativa interpreten una página con mayor fiabilidad. El error más común es tratar ambos conceptos como sinónimos: un JSON-LD con sintaxis perfecta pero que usa un tipo de Schema.org que no existe sigue sin servir de nada.

Un acoplamiento metálico normalizado en el extremo de una manguera, junto al título Schema.org
El acoplamiento es estándar; la manguera que traigas, no

Vocabulario vs. JSON-LD: dos cosas que no son lo mismo

Es habitual mezclar dos conceptos que resuelven problemas distintos. Schema.org es el vocabulario: una colección pública de tipos (Product, Article, Organization, Recipe) y propiedades (name, price, author, datePublished) que Google, Bing, Yahoo y Yandex fundaron en 2011 y mantienen de forma conjunta desde entonces. El proyecto nació precisamente para resolver un problema previo: antes de 2011 cada motor de búsqueda promovía su propio sistema de marcado, con microformatos y RDFa dispersos, y quien publicaba una web tenía que duplicar el mismo dato en varios formatos distintos para cubrir a todos los buscadores. Ese vocabulario define qué se puede describir en una página y bajo qué etiquetas, pero no dice nada sobre cómo escribir ese código. JSON-LD, Microdata y RDFa son los tres formatos con los que ese vocabulario se traduce en HTML. JSON-LD (JavaScript Object Notation for Linked Data) es hoy el formato que Google recomienda para la mayoría de casos: se escribe en un bloque <script type="application/ld+json"> independiente, sin tocar el HTML visible de la página. Microdata, en cambio, obliga a añadir atributos (itemscope, itemprop) directamente sobre las etiquetas existentes, lo que complica el mantenimiento cada vez que cambia el diseño. La consecuencia práctica es esta: dos páginas pueden usar exactamente el mismo vocabulario de Schema.org, el mismo tipo Product y las mismas propiedades, y diferir solo en el formato elegido para incluirlo. Google procesa los tres formatos, pero su documentación de Search Central prioriza JSON-LD porque es más fácil de generar de forma dinámica desde un CMS y de validar sin riesgo de romper el maquetado visible. Un ejemplo ayuda a ver la diferencia. El tipo Organization con las propiedades name, url y logo es el mismo vocabulario en cualquier página que lo use. Su implementación en JSON-LD se ve así: 
<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Nombre de la empresa",
  "url": "https://ejemplo.com",
  "logo": "https://ejemplo.com/logo.png"
}
</script>
La misma información en Microdata exige repartir esos atributos por varias etiquetas HTML visibles, algo que en plantillas dinámicas genera más errores de sintaxis que un bloque JSON-LD centralizado y aislado del resto del código. Para el detalle técnico de cada formato, ver JSON-LD y Datos Estructurados.

Los tipos de schema más relevantes para una empresa

Una empresa típica, una tienda online, una consultora, un despacho, no necesita implementar los más de 800 tipos que existen en Schema.org. Seis de ellos, bien aplicados, cubren la mayoría de los casos.

Organization identifica a la empresa como entidad: nombre legal, logo, redes sociales y datos de contacto. Es el tipo base que Google usa para construir el Knowledge Panel.

Product describe artículos en venta: precio, disponibilidad, valoraciones. Es el tipo que habilita las estrellas y el precio directamente en los resultados de búsqueda.

FAQPage marca preguntas y respuestas visibles en la página. Google lo usa, cuando lo usa, para desplegar el contenido plegable bajo el resultado, aunque desde 2023 limita su aparición sobre todo a dominios gubernamentales y de salud en la mayoría de mercados.

Article se aplica a contenido editorial: fecha de publicación, autor, imagen destacada. Es relevante tanto para Google Discover como para que los sistemas de IA generativa atribuyan la fuente correctamente.

LocalBusiness extiende Organization con horario, dirección y área de servicio. Es el tipo que conecta la web con la ficha de Google Business Profile.

BreadcrumbList reproduce la ruta de navegación (Inicio > Categoría > Producto) y es lo que genera las migas de pan visibles en el resultado de búsqueda en lugar de la URL completa.

Estos tipos no son excluyentes entre sí. Una página de producto bien construida puede combinar Product, BreadcrumbList y Organization en el mismo bloque JSON-LD mediante la propiedad @graph, de modo que Google reciba en una sola llamada toda la información relevante de esa URL sin repetir el contexto en cada tipo por separado.

¿Es Schema.org un factor de posicionamiento?

No. Google lo ha confirmado varias veces en su documentación: añadir datos estructurados no mejora directamente la posición de una página en los resultados. Lo que hace es habilitar la elegibilidad para funciones visuales adicionales, los rich results, que sí pueden mejorar el CTR al ocupar más espacio en la SERP o al mostrar información extra como estrellas, precio o tiempo de preparación.

La palabra clave es elegibilidad, no garantía. Cumplir la sintaxis y las directrices de un tipo concreto no obliga a Google a mostrar el rich result correspondiente; la decisión depende de un proceso adicional de calidad de contenido, de la autoridad de la página y de la disponibilidad de esa función en el mercado y dispositivo del usuario. Es habitual implementar correctamente el marcado de FAQPage o Product y no ver nunca el resultado enriquecido, mientras que otra página similar sí lo consigue.

Search Console permite comprobar esto con datos reales: el informe de cada tipo de rich result, por ejemplo "Fragmentos de producto" o "Preguntas frecuentes", muestra cuántas páginas tienen el marcado válido frente a cuántas de ellas obtienen realmente la función visual en los resultados. No es raro ver que el cien por cien del marcado es válido y que, aun así, solo una fracción de esas URLs muestra el rich result, precisamente porque la elegibilidad no implica aparición garantizada.

Donde el papel de Schema.org sí está creciendo es en GEO (Generative Engine Optimization). Los sistemas de IA generativa, ChatGPT, Perplexity, AI Overviews de Google, necesitan extraer hechos concretos (precio, autor, fecha, ubicación) de páginas web para construir sus respuestas. Un texto libre obliga al modelo a inferir esos datos del contexto; un bloque JSON-LD se los entrega ya etiquetados y sin ambigüedad. No hay evidencia pública de que estos sistemas prioricen contenido marcado con Schema.org sobre contenido sin marcar, pero sí reduce el margen de error al citar cifras o atributos de un producto. Ver GEO para el detalle de cómo optimizar contenido para estos sistemas, y Rich Results y Featured Snippet para las funciones concretas que el marcado puede habilitar en buscadores tradicionales.

Buenas prácticas

  • Usa JSON-LD como formato por defecto: es el que Google prioriza y el más fácil de mantener desde un CMS.
  • Valida cada página con la Prueba de Resultados Enriquecidos de Google antes de publicar, no solo con un validador genérico de sintaxis.
  • Marca únicamente lo que el usuario puede ver en la página. Si el precio del JSON-LD no coincide con el precio visible, Google puede ignorar o penalizar el marcado.
  • Actualiza el schema cuando cambie el contenido: un producto agotado con "InStock" en el JSON-LD genera desconfianza y puede provocar la retirada del rich result.
  • Usa el tipo más específico disponible: Recipe en vez de CreativeWork para una receta, LocalBusiness en vez de Organization para un negocio con local físico.
  • Combina varios tipos cuando tenga sentido: una página de producto puede llevar Product y BreadcrumbList a la vez, sin conflicto entre ellos.
  • Versiona el schema igual que el resto del código: un bloque JSON-LD que se olvida en el siguiente rediseño puede mostrar precios o autores desactualizados durante meses.

Errores frecuentes

  • Marcar datos que no están en el contenido visible: valoraciones, precios o disponibilidad que solo existen en el JSON-LD. Google lo clasifica como spam de datos estructurados y puede aplicar una acción manual.
  • Copiar el JSON-LD de una plantilla o de un competidor sin adaptar los valores: nombres de marca o URLs que no corresponden a la página actual.
  • Dejar campos obligatorios vacíos o con datos de relleno ("Lorem ipsum", precio 0), algo que la Prueba de Resultados Enriquecidos no siempre marca como error crítico.
  • Apilar el mismo tipo dos veces en la misma página con valores distintos, lo que genera ambigüedad sobre cuál es el correcto.
  • Usar FAQPage o HowTo esperando el rich result correspondiente sin comprobar antes si Google sigue mostrando esa función en el mercado y la categoría de la página.
Manuel Riveiro Rodriguez CEO & Digital Strategist

Una auditoría técnica revisa esto y el resto en un solo paso.

Solicitar auditoría

Preguntas frecuentes

¿Es obligatorio usar JSON-LD o puedo usar Microdata?

No es obligatorio. Google procesa los tres formatos, JSON-LD, Microdata y RDFa, siempre que la sintaxis sea correcta. JSON-LD es la recomendación porque separa el marcado del HTML visible y reduce errores al actualizar la plantilla, pero un sitio con Microdata bien implementado no pierde por ello elegibilidad para rich results.

¿Añadir Schema.org garantiza que aparezca un rich result?

No. El marcado correcto hace que la página sea elegible, no que Google la seleccione. La decisión final depende de factores adicionales de calidad y de la disponibilidad de esa función en el mercado del usuario, algo que Google no controla ni garantiza en su documentación oficial.

¿Cuál es la diferencia entre Schema.org y datos estructurados?

Datos estructurados es el término general para cualquier información organizada en un formato que una máquina puede leer. Schema.org es el vocabulario concreto, el conjunto de tipos y propiedades más usado para generar esos datos estructurados en la web.

¿Cómo compruebo si el marcado de mi web es correcto?

Con la Prueba de Resultados Enriquecidos de Google (search.google.com/test/rich-results), que valida la sintaxis y muestra qué funciones son elegibles para esa URL. El informe de Datos Estructurados en Search Console complementa esa prueba con datos reales de rastreo.

¿Schema.org sirve también para la IA generativa, no solo para Google?

Sí. Al ser un vocabulario abierto, cualquier sistema que rastree la web, incluidos los crawlers de ChatGPT o Perplexity, puede leer el mismo JSON-LD. No hay confirmación pública de que estos sistemas lo prioricen sobre el texto plano, pero facilita que extraigan datos concretos sin ambigüedad.

¿Afecta el marcado de Schema.org a Google Discover o a las AI Overviews?

Indirectamente. Article y sus propiedades (autor, fecha, imagen) ayudan a que Google identifique mejor el contenido editorial para Discover, y los mismos datos bien etiquetados facilitan que las AI Overviews citen la fuente con precisión. En ningún caso el marcado por sí solo garantiza aparecer en ninguna de las dos funciones.

¿Por qué se dice que Schema.org es de Google, Bing, Yahoo y Yandex, y no solo de Google?

Porque así se fundó: en 2011 los cuatro motores de búsqueda acordaron un vocabulario común en vez de mantener cada uno el suyo por separado. En la práctica, Google es quien publica más documentación y herramientas de prueba sobre él, lo que explica que el proyecto se asocie casi siempre solo a Google, aunque su mantenimiento sigue siendo compartido a través de la organización sin ánimo de lucro que lo gestiona.