Schema.org es un vocabulario compartido para describir entidades y relaciones; los datos estructurados son el marcado que aplica ese vocabulario en una página. Google puede usar ciertos tipos para comprender contenido y habilitar resultados enriquecidos, pero implementarlos no garantiza que aparezcan. La selección correcta empieza por la función de la página y la información visible.
El error más común es buscar “qué schema posiciona” y añadir tipos sin relación con la página. Un marcado útil funciona como dato de producción: refleja hechos, conserva identificadores, se genera desde una fuente confiable, valida y se mantiene cuando cambia el contenido.
Qué es Schema.org
Schema.org define tipos como Organization, Person, Product, Article y Event, junto con propiedades para describirlos. El vocabulario puede expresarse en formatos como JSON-LD, Microdata o RDFa. Los consumidores deciden qué partes interpretan.
Schema.org y Google no son lo mismo. Un tipo puede existir en el vocabulario y no habilitar una función visual en Google. Para SEO se consultan ambas documentaciones: significado semántico y requisitos del buscador.
Qué son los datos estructurados
Son información en un formato predecible que clasifica el contenido. En una receta pueden identificar ingredientes y tiempo; en un producto, nombre, oferta y disponibilidad; en una organización, nombre y datos oficiales. Deben corresponder con lo que el usuario puede verificar.
Ayudan a reducir ambigüedad, pero no convierten una página deficiente en relevante. Google explica que pueden habilitar resultados más atractivos, sujeto a indexación, calidad, políticas y decisión del sistema.
Por qué suele usarse JSON-LD
JSON-LD coloca un bloque de datos separado de la presentación y facilita generar relaciones complejas. Google lo admite y suele ser más sencillo de mantener que marcar cada elemento visual. El código debe producir JSON válido y escapar contenido dinámico.
No edites manualmente cientos de páginas si el CMS puede generar desde campos. Centraliza plantilla, conserva excepciones y añade pruebas. Un error en una variable puede propagarse a todo el sitio.
Cómo elegir el tipo correcto
- Define qué tarea cumple la URL.
- Identifica entidad principal y secundarias.
- Comprueba que los datos sean visibles.
- Revisa el tipo y propiedades en Schema.org.
- Consulta si Google soporta una función relacionada.
- Implementa solo propiedades verdaderas.
- Valida código, políticas y resultado publicado.
No combines tipos porque “parecen SEO”. Relaciónalos mediante identificadores y propiedades cuando existe una relación real.
Organization y LocalBusiness
Organization describe una entidad. LocalBusiness y sus subtipos agregan contexto de negocio local cuando existe ubicación que atiende clientes. No declares todas las páginas como LocalBusiness. Mantén nombre, URL, logo e identificadores consistentes.
Dirección, teléfono y horarios deben corresponder a datos públicos y actuales. Para múltiples sedes, cada ubicación necesita identidad y página útiles si se marca individualmente. No inventes oficina para aparecer en búsquedas locales.
WebSite, WebPage y BreadcrumbList
WebSite representa el sitio; WebPage, una página; BreadcrumbList, la ruta jerárquica visible o comprensible. Se pueden conectar con @id. La miga debe seguir una arquitectura real y enlaces válidos.
El breadcrumb no arregla una estructura confusa. Define primero categorías y rutas. Evita que nombre, URL canónica y breadcrumb se contradigan.
Article, BlogPosting y NewsArticle
Usa el subtipo que corresponde al contenido. Incluye titular, autor, fechas e imagen cuando sean reales. dateModified debe cambiar por una actualización sustancial, no por una ejecución automática.
Conecta autor con Person y editor con Organization cuando existan perfiles fiables. Una firma visible y una biografía útil aportan más confianza que un nombre escondido solo en código.
Product, Offer y AggregateOffer
Product describe el producto; Offer, una oferta concreta con precio, moneda, disponibilidad y vendedor. AggregateOffer resume rango y conteo cuando existen varias ofertas. El marcado debe coincidir con la opción que el usuario puede comprar.
Variantes requieren decisión: una entidad con variantes o productos separados. Conserva SKU, GTIN u otros identificadores válidos cuando correspondan. Sincroniza precio e inventario desde la misma fuente que la interfaz.
Service y páginas de servicio
Service puede describir un servicio, proveedor y área, pero no toda página de servicio obtiene un resultado enriquecido. Úsalo por claridad semántica, no como promesa visual. Evita precio o valoración si no son visibles y verificables.
Una página comercial necesita alcance, proceso, evidencia y contacto. El schema complementa ese contenido. Para revisar arquitectura consulta el servicio de SEO.
FAQPage y preguntas frecuentes
FAQPage describe preguntas con una respuesta de la organización. Google ha limitado la visualización de FAQ enriquecidas y mantiene requisitos específicos. No añadas preguntas ocultas, duplicadas o generadas únicamente para ocupar espacio.
Que el marcado valide no significa que aparecerá. Las FAQ deben ayudar al lector y mantenerse actualizadas; si no aportan, no son obligatorias.
Review, Rating y reputación
Las valoraciones deben provenir de usuarios reales, corresponder a la entidad marcada y estar visibles. No copies estrellas de otra plataforma ni marques una puntuación interna como reseña pública. Google aplica políticas sobre reseñas autorreferenciales y tipos elegibles.
Conserva procedencia, escala y conteo. Una reseña falsa expone a usuarios y marca, aunque el código sea correcto.
Eventos, empleos, recetas y otros tipos
Event necesita evento real con fecha, lugar o modalidad y estado. JobPosting requiere oferta vigente y proceso de aplicación. Recipe exige una receta completa. Cada función tiene propiedades y políticas propias que cambian.
No uses un tipo especializado como analogía. Un webinar grabado sin nueva fecha no es un evento futuro; una página corporativa no es una oferta laboral.
Construir un grafo con identificadores
@id permite referirse a la misma entidad desde varios nodos. Una página puede relacionar Organization, WebSite, WebPage, BreadcrumbList y Article sin repetir definiciones contradictorias. Usa identificadores estables y URLs absolutas.
Más nodos no significan mejor SEO. El grafo debe poder explicarse en lenguaje simple: quién publica qué, en qué página y sobre qué entidad.
Fuente de verdad y actualización
Asigna una fuente a cada propiedad. En ecommerce, precio y disponibilidad deberían provenir del catálogo transaccional; autor y fechas, del CMS; identidad corporativa, de una configuración gobernada. Copiar valores manualmente al marcado crea divergencias.
Define qué evento invalida la caché y regenera JSON-LD. Prueba cambios masivos, importaciones y zonas horarias. Si una promoción termina a medianoche, contenido visible y Offer deben cambiar juntos. Conserva registros técnicos sin exponer información de clientes.
Para varias plantillas, usa componentes con pruebas y versiones. Un equipo editorial puede controlar campos, mientras desarrollo asegura tipos y serialización. Documenta propiedades opcionales para que una ausencia legítima no se rellene con valores ficticios.
Correspondencia con contenido visible
Google indica que no se marque información inexistente para el usuario. Si el JSON-LD dice un precio distinto del mostrado, el problema es de datos, no solo SEO. Lo mismo aplica a autor, disponibilidad, fecha y valoración.
Genera marcado desde la fuente que pinta la página. Si una caché separa ambas salidas, define invalidación conjunta. Prueba estados sin stock, promociones vencidas y traducciones.
Herramientas y niveles de validación
El Rich Results Test verifica tipos compatibles y puede mostrar errores o advertencias. Schema Markup Validator revisa vocabulario más amplio. Un validador JSON detecta sintaxis. Search Console reporta grupos en propiedades verificadas.
Pasar una prueba no garantiza elegibilidad ni visualización. Después de publicar, inspecciona la URL canónica y el HTML público. Valida muestras de cada plantilla y estado.
Errores y advertencias
Un error suele bloquear una función o invalidar parte del marcado; una advertencia señala una propiedad recomendada o mejora posible. Lee el detalle del tipo actual. No agregues valores falsos solo para eliminar una advertencia.
Prioriza errores en plantillas de alto volumen, cambios recientes y datos comerciales. Registra cuándo aparecieron y qué despliegue los causó.
Schema en WordPress, Shopify y otros CMS
Temas, núcleo y plugins pueden generar bloques simultáneos. Inventaría primero. Dos plugins podrían declarar organizaciones o productos incompatibles. Decide una fuente por entidad y desactiva duplicación de manera controlada.
No confíes en la pantalla de configuración. Revisa código público, caché y variantes. Actualizaciones del tema pueden cambiar salida; incluye pruebas en cada release.
Ejemplo de modelado
Una guía publicada por una agencia puede usar BlogPosting como entidad principal, enlazada con WebPage, BreadcrumbList, Person autora y Organization editora. La imagen, título y fechas coinciden con la página; la canonical identifica la URL.
Si incluye un CTA de auditoría, eso no convierte el artículo completo en Service. La entidad principal sigue siendo el contenido. El servicio puede enlazarse de forma visible sin distorsionar el propósito.
Monitoreo y mantenimiento
Rastrea presencia, errores, cambios de plantilla y coherencia de campos. Al modificar URL, autor, precio o inventario, actualiza marcado. Revisa documentación oficial porque funciones y políticas evolucionan.
Mide impresiones y CTR por tipo de página sin atribuir cambios solo a schema. Elegibilidad, demanda, ranking y presentación también intervienen.
Datos estructurados en una migración
Antes de migrar, captura tipos, identificadores y cobertura por plantilla. En el nuevo sitio, actualiza URLs, canonicals, imágenes y relaciones sin crear una identidad corporativa nueva por accidente. Los @id pueden cambiar de host de forma coordinada.
Valida primero un conjunto pequeño con estados distintos. Después del lanzamiento rastrea producción y compara conteos. Una vista previa correcta no demuestra que CDN, minificador o plugin entregue el mismo código públicamente.
Cómo priorizar una implementación
Empieza por plantillas con entidades claras, datos confiables y valor para usuarios: productos comprables, artículos con autor o sedes reales. Corrige primero errores que contradicen contenido o afectan muchas URLs. Después amplía el grafo.
No midas progreso por cantidad de tipos. Mídelo por cobertura válida, reducción de contradicciones y capacidad para mantener datos. Una implementación pequeña conectada a fuentes estables es mejor que un bloque enorme que nadie sabe actualizar.
Checklist antes de publicar
- Entidad principal coincide con la página.
- Propiedades son visibles y verdaderas.
- URL y canonical son coherentes.
- JSON-LD es válido.
- No hay bloques contradictorios.
- Se cumplen políticas del tipo.
- Producción coincide con vista previa.
- Existe responsable de actualización.
Una auditoría SEO técnica debe revisar plantillas y datos de origen. Para un diagnóstico puedes contactar a SEOMOS.
Fuentes consultadas
Documentación consultada el 10 de septiembre de 2026.
Preguntas frecuentes sobre schema
¿Qué es schema en SEO?
Es el uso del vocabulario Schema.org en datos estructurados para describir entidades y relaciones de una página.
¿Schema mejora rankings?
No garantiza posiciones. Puede ayudar a comprender contenido y habilitar funciones cuando se cumplen requisitos.
¿Qué formato conviene?
JSON-LD suele ser mantenible y es admitido por Google, pero debe generarse y validarse correctamente.
¿Puedo marcar información oculta?
No debe marcarse información que el usuario no pueda ver o verificar en la página.
¿Validar garantiza rich results?
No. La prueba confirma aspectos técnicos; la visualización depende también de calidad, políticas e indexación.
¿Cuándo revisarlo?
Después de cambios de plantilla o datos y periódicamente frente a errores y documentación oficial.
