Schema.org

Qué es Schema.org

Schema.org es un vocabulario compartido para describir información de una forma que puedan procesar buscadores y otras aplicaciones. Define nombres para tipos de entidades —como Person, Organization, Article o Event— y para las propiedades que las describen —como name, datePublished o location—.

No es un plugin, un formato de archivo ni una función exclusiva de Google. Es un proyecto comunitario cuyo vocabulario puede expresarse con distintas sintaxis. La guía inicial de Schema.org explica sus conceptos de tipos, propiedades, valores y relaciones.

Una frase visible dice “este contenido fue publicado por una organización”. El marcado puede expresar de forma explícita que:

• el elemento principal es un Article;
• su propiedad author apunta a una Organization o Person;
• la propiedad datePublished contiene una fecha;
• la propiedad headline corresponde al titular.

El código no reemplaza esa información. La representa de manera estructurada para que una máquina no dependa únicamente de interpretar el diseño o una frase ambigua.

Schema.org, datos estructurados y JSON-LD no son lo mismo

Los términos suelen utilizarse como sinónimos, pero cumplen funciones distintas.

Concepto	Qué es	Ejemplo
Schema.org	Vocabulario de tipos y propiedades	Article, author, datePublished
Datos estructurados	Información organizada según reglas explícitas	Un artículo relacionado con su autor y fecha
JSON-LD	Formato para escribir datos enlazados en JSON	Un bloque <script type="application/ld+json">
Microdata	Sintaxis integrada en atributos HTML	itemscope, itemtype, itemprop
RDFa	Sintaxis de atributos para describir recursos y relaciones	typeof, property, resource
Resultado enriquecido	Presentación especial que un buscador puede mostrar	Migas, producto, evento o receta cuando la función es compatible

Una implementación puede usar Schema.org en JSON-LD sin ser elegible para un resultado enriquecido. También puede ser válida para el vocabulario y contener información falsa o incoherente. Validez sintáctica, precisión factual y compatibilidad con una función de búsqueda son controles diferentes.

Esta página explica el vocabulario. La definición de datos estructurados se centra en la información codificada y su implementación dentro del SEO.

Cómo se organiza el vocabulario

Schema.org utiliza una jerarquía. El tipo más general es Thing; debajo aparecen tipos más concretos y sus subtipos. Una entidad puede heredar propiedades de sus tipos superiores.

Pieza	Función	Ejemplo
Tipo	Indica qué clase de entidad se describe	Organization
Subtipo	Describe una clase más específica	OnlineStore, subtipo relacionado con organización
Propiedad	Añade un atributo o relación	name, url, logo
Tipo esperado	Indica qué clase de valor admite una propiedad	Text, URL, Date o una entidad
Enumeración	Limita el valor a opciones definidas	Estados de disponibilidad o condición
Identificador	Permite referirse a la misma entidad desde varios nodos	Un @id estable en JSON-LD

Tipos y subtipos

La regla práctica es elegir el tipo más específico que represente honestamente la entidad. Eso no significa escoger el nombre más largo ni el que parece más comercial. Si un subtipo no describe la operación real, el tipo general es más preciso.

Propiedades y valores

Cada tipo muestra propiedades que puede utilizar y valores esperados. name puede recibir texto; url, una URL; author, una entidad que represente a la persona u organización responsable. Antes de añadir una propiedad, comprueba en Schema.org:

1. en qué tipos puede utilizarse;
2. qué clase de valor espera;
3. si está dentro del vocabulario principal o en estado de desarrollo;
4. si el consumidor que te interesa la admite y exige reglas adicionales.

Relaciones entre entidades

El valor no está únicamente en listar atributos. También puedes conectar un artículo con su autor, una página con sus migas, una oferta con un producto o un término con el conjunto de definiciones al que pertenece.

Estas relaciones deben existir de verdad y mantenerse estables. Utilizar @id permite referirse a una misma entidad desde distintos nodos de un gráfico JSON-LD sin duplicar descripciones contradictorias.

Qué formatos pueden usar Schema.org

Google admite tres formatos para datos estructurados en páginas web:

Formato	Cómo se integra	Ventaja operativa	Riesgo habitual
JSON-LD	Bloque JSON separado del contenido visible	Fácil de generar desde plantillas y mantener centralizado	Que el código deje de coincidir con el HTML
Microdata	Atributos añadidos a los elementos HTML	Vincula el marcado directamente con lo visible	Puede volver compleja la plantilla y el anidamiento
RDFa	Atributos HTML orientados a recursos y relaciones	Expresa relaciones y vocabularios enlazados	Requiere una implementación cuidadosa

La documentación de Google sobre datos estructurados indica que los tres formatos son aceptables cuando están bien implementados. En la práctica, JSON-LD suele resultar más sencillo para proyectos con plantillas, pero no convierte información incorrecta en información válida.

No mezcles formatos por accidente para describir dos veces la misma entidad con datos distintos. Si el CMS, un plugin y el tema generan marcado, haz primero un inventario de todos los bloques presentes antes de añadir uno nuevo.

Cómo elegir tipos y propiedades

La implementación empieza con la página y el consumidor, no con una lista de schemas populares.

1. Define el contenido principal

Pregunta qué puede ver y utilizar una persona en la URL. Una página de artículo, una ficha de producto y una página de organización cumplen propósitos distintos. El tipo principal debe representar el foco real, no un fragmento secundario.

2. Identifica quién utilizará el marcado

Schema.org define el vocabulario general. Cada consumidor decide qué interpreta. Si el objetivo incluye Google Search, su documentación debe considerarse definitiva para propiedades requeridas, recomendadas, políticas y funciones compatibles.

Un tipo puede existir en Schema.org y no tener un rich result en Google. Del mismo modo, Google puede exigir propiedades o condiciones adicionales para una presentación concreta.

3. Elige el tipo más específico que sea verdadero

Comienza por una entidad general y comprueba si existe un subtipo adecuado. No utilices LocalBusiness, Product, Review o Event solo porque tienen resultados llamativos. La página y la operación deben cumplir la definición y las políticas correspondientes.

4. Completa primero lo verificable

Prioriza propiedades requeridas por la función y datos que tienen una fuente interna clara. Añadir más campos no compensa valores inventados, desactualizados o vacíos.

Dato	Fuente responsable posible	Control antes de publicar
Nombre de una entidad	Registro de marca o contenido aprobado	Coincide con lo visible
Autor	Sistema editorial	Identidad y responsabilidad reales
Fecha	CMS	Formato correcto y misma fecha visible
Precio o disponibilidad	Catálogo o sistema comercial	Actualización sincronizada
Dirección u horario	Operación de una ubicación verificada	Sede real, elegible y atendida
Reseña o calificación	Sistema de opiniones verificables	No es inventada, seleccionada ni agregada de forma engañosa

5. Modela relaciones sin duplicar identidades

Utiliza nodos relacionados y @id estables cuando varias páginas hablan de la misma organización, persona o recurso. Evita crear una entidad distinta en cada URL por una variación de nombre, protocolo o barra final.

6. Diseña el mantenimiento antes de publicar

Define qué campo del CMS alimenta cada propiedad, quién lo actualiza y qué sucede cuando falta. Si un dato obligatorio no existe, el componente debe omitir el tipo o detener la publicación; no rellenarlo con un valor verosímil.

Ejemplo de Schema.org en JSON-LD

Este ejemplo técnico simplificado describe el término visible en esta página:

{
  "@context": "https://schema.org",
  "@type": "DefinedTerm",
  "name": "Schema.org",
  "description": "Vocabulario compartido de tipos y propiedades para describir información estructurada.",
  "url": "https://seolocal.com.mx/recursos/glosario/schema-org/",
  "inDefinedTermSet": "https://seolocal.com.mx/recursos/glosario/"
}

Campo	Qué expresa
@context	Vocabulario utilizado para interpretar tipos y propiedades
@type	Clase de entidad descrita
name	Nombre visible del término
description	Definición que coincide con el contenido de la página
url	URL canónica de la entidad descrita
inDefinedTermSet	Relación con el glosario que contiene el término

El ejemplo es pequeño a propósito. Una implementación mantenible utiliza únicamente las propiedades que puede sostener y las amplía cuando existe una necesidad real.

Qué relación tiene con Google y los resultados enriquecidos

Google utiliza principalmente el vocabulario Schema.org para sus datos estructurados, pero admite solo un subconjunto de tipos y propiedades para funciones específicas. La galería de funciones de búsqueda indica qué presentaciones están disponibles y enlaza sus requisitos.

Una página correctamente marcada puede:

• aportar pistas explícitas sobre entidades, atributos y relaciones;
• ser elegible para una función enriquecida cuando Google admite el tipo;
• facilitar controles automáticos de consistencia en un sitio;
• ofrecer datos reutilizables a otros consumidores compatibles.

No garantiza:

• una posición determinada;
• que Google muestre un rich result;
• que el buscador crea datos contradictorios con el contenido visible;
• que cualquier tipo de Schema.org tenga una presentación especial;
• que una validación técnica equivalga a cumplimiento editorial.

Las directrices generales de datos estructurados exigen que el marcado represente el contenido principal, esté actualizado, sea visible para el usuario y no resulte engañoso. Google puede no mostrar un resultado enriquecido aunque el código supere la prueba técnica.

Un ejemplo importante: FAQPage

FAQPage existe en Schema.org y puede ser una representación válida de preguntas y respuestas visibles. Eso no significa que cualquier sitio obtenga una FAQ desplegable en Google. La compatibilidad y las políticas de una función cambian; revisa la guía vigente del buscador en vez de tratar un ejemplo antiguo como promesa.

Cómo validar una implementación

La validación debe cubrir cuatro capas. Superar solo una deja errores sin detectar.

1. Sintaxis

Comprueba que JSON, atributos y URLs sean válidos. Un error de coma, comillas o anidamiento puede impedir que el bloque se procese.

2. Vocabulario Schema.org

Usa el Schema Markup Validator para revisar los tipos, propiedades y valores del vocabulario. Esta herramienta no decide por sí sola si Google mostrará una función.

3. Compatibilidad con Google

La prueba de resultados enriquecidos comprueba los tipos que Google utiliza para esas presentaciones y señala propiedades requeridas o recomendadas. Un aviso no siempre impide la elegibilidad; un error crítico puede hacerlo.

4. Página publicada y contenido visible

Después del despliegue, inspecciona la URL en Search Console. Verifica lo que recibe Googlebot y compara cada valor con la página visible, la canónica y la fuente interna. Revisa también los informes de resultados enriquecidos disponibles para el sitio.

Resultado de una herramienta	Pregunta siguiente
Código válido	¿Describe la entidad y la página correctas?
Sin errores para Google	¿Cumple las políticas específicas del tipo?
Con advertencias	¿Falta información recomendada que realmente existe?
Elegible	¿La URL está indexada y el contenido sigue actualizado?
Rich result observado	¿Aporta clics o acciones útiles y se mantiene estable?

Qué errores conviene evitar

Marcar contenido que no existe o no se ve

No añadas una reseña, precio, disponibilidad, pregunta o evento únicamente en JSON-LD. La información estructurada debe corresponder con el contenido que la persona puede consultar.

Inventar información para completar propiedades

Una plantilla no debe fabricar autores, imágenes, teléfonos, direcciones, horarios, reseñas o calificaciones. Si falta un dato real, omite la propiedad cuando sea opcional o impide emitir el tipo cuando sea necesario.

Elegir un tipo por su apariencia potencial

No conviertas una página de servicio en Product, una lista de instrucciones en Recipe ni una organización remota en LocalBusiness para intentar obtener otra presentación. La especificidad solo ayuda cuando es verdadera.

Confundir validez con elegibilidad

El validador de Schema.org revisa el vocabulario; la prueba de Google revisa funciones compatibles; las políticas revisan calidad y relevancia. Un bloque puede superar una capa y fallar otra.

Duplicar nodos contradictorios

Temas, plugins y gestores de etiquetas pueden emitir varios bloques para la misma entidad. Audita todo el HTML renderizado, no solo el fragmento que acabas de añadir. Unifica identificadores y decide qué sistema es la fuente responsable.

Dejar el marcado fuera del ciclo editorial

Una fecha, precio, disponibilidad, autor o ubicación puede cambiar. El dato estructurado debe actualizarse desde la misma fuente que modifica la página, no en una copia manual que nadie revisa.

Publicar sin monitoreo

Prueba primero una muestra de plantillas, despliega de forma controlada y revisa Search Console. Cuando cambien el CMS, el diseño o los requisitos de Google, repite las validaciones.

Una implementación de SEO técnico convierte Schema.org en una capa mantenible del sitio: modelo de entidades, mapeo con campos reales, generación en plantillas, pruebas automáticas y revisión posterior al despliegue.