SEO & Discoverability

Qué tipos de schema.org influyen realmente en los resultados de búsqueda

Una guía práctica sobre los datos estructurados que pueden cambiar cómo aparecen tus páginas en la búsqueda, y el marcado que sobre todo ayuda a las máquinas a entenderte.

The Wux Webtools Team The Wux Webtools Team 15 min de lectura Asistido por IA, revisado por humanos
Structured data blocks connected to enhanced search result cards.
Tabla de contenido
  1. La respuesta breve
  2. Primero: los datos estructurados dan elegibilidad, no derecho adquirido
  3. Los tipos con el impacto más claro
  4. Product, Offer, AggregateRating y Review
  5. BreadcrumbList
  6. Article, NewsArticle y BlogPosting
  7. LocalBusiness y sus subtipos
  8. Event
  9. JobPosting
  10. Recipe
  11. VideoObject
  12. Organization, Logo y WebSite
  13. FAQPage: técnicamente admitido, rara vez visible para la mayoría de sitios
  14. DiscussionForumPosting y ProfilePage
  15. Tipos útiles pero a menudo sobrestimados
  16. JSON-LD suele ser el mejor formato de implementación
  17. Un modelo práctico de priorización
  18. Errores comunes que reducen el impacto
  19. Marcar el tipo de página equivocado
  20. Añadir propiedades que no son visibles
  21. Tratar la validación como éxito
  22. Implementar schema una vez y olvidarlo
  23. La recomendación tranquila

La respuesta breve

El marcado de Schema.org no mejora automáticamente el posicionamiento. Sin embargo, puede hacer que una página sea apta para apariencias de búsqueda mejoradas: resultados enriquecidos, paneles de producto, migas de pan, listados de eventos, módulos de empleo, vistas previas de vídeo y funciones similares.

Esa distinción importa. Schema.org es un vocabulario amplio para describir cosas en la web. Los motores de búsqueda solo admiten una parte de él, y cada función de búsqueda tiene sus propias reglas. Puedes marcar una página perfectamente con Thing, CreativeWork o Service y no ver ningún cambio visible en los resultados de búsqueda, porque quizá no exista una función de búsqueda vinculada a ese tipo.

Así que la pregunta útil no es “¿Qué tipos de schema existen?”. Es “¿Qué tipos de schema usan los motores de búsqueda para generar funciones de búsqueda visibles u operativas?”.

A continuación tienes la respuesta práctica.

Primero: los datos estructurados dan elegibilidad, no derecho adquirido

Los datos estructurados ofrecen pistas explícitas a los motores de búsqueda. No los obligan a mostrar nada.

Normalmente, una página necesita todo lo siguiente antes de que los datos estructurados tengan algún efecto visible:

  • El marcado debe coincidir con el contenido visible de la página.
  • Las propiedades obligatorias y recomendadas deben estar presentes.
  • La página debe ser indexable y no estar bloqueada por reglas de robots.
  • El contenido debe cumplir las políticas de calidad y spam.
  • El motor de búsqueda debe decidir que el resultado mejorado ayuda al usuario.

Por eso dos páginas técnicamente válidas pueden comportarse de forma distinta en la búsqueda. Una puede obtener un resultado enriquecido de producto; otra puede mostrarse como un enlace azul normal. El marcado es solo una señal.

También por eso perseguir tipos de schema poco conocidos suele ser una mala inversión de tiempo. Si no hay una función de búsqueda admitida asociada al tipo, el beneficio es principalmente semántico más que visual.

Los tipos con el impacto más claro

Product, Offer, AggregateRating y Review

Para páginas de ecommerce y software, el marcado de producto es una de las familias de datos estructurados más útiles a nivel visual.

Una página Product puede ser apta para funciones de precio, disponibilidad, valoración, envío, devoluciones y listados de comercio. Los tipos de apoyo más importantes suelen ser:

  • Offer para precio, moneda, disponibilidad e información del vendedor
  • AggregateRating para valoraciones resumidas
  • Review para reseñas individuales, cuando corresponda
  • Brand u Organization para el contexto del fabricante o vendedor

Este marcado es más útil cuando la página trata realmente sobre un producto específico, no sobre una categoría o una página de servicio vaga. Los motores de búsqueda son cada vez más estrictos con el abuso de reseñas y valoraciones, especialmente las reseñas interesadas. Si la valoración no es visible para los usuarios en la página, no la marques.

El schema de producto puede influir tanto en los snippets orgánicos clásicos como en superficies de estilo comercial. Para minoristas, suele ser una de las implementaciones de datos estructurados con mayor retorno.

BreadcrumbList no es vistoso, pero es práctico. Puede influir en la visualización de la URL/ruta en los resultados de búsqueda, sustituyendo una URL desordenada por una jerarquía más clara.

El marcado de migas de pan es útil para:

  • Páginas de categoría y producto de ecommerce
  • Sitios de documentación
  • Blogs y publicaciones grandes
  • Centros de ayuda SaaS

Rara vez crea un resultado enriquecido espectacular, pero puede mejorar la comprensión. Los usuarios pueden ver dónde encaja una página antes de hacer clic. Los motores de búsqueda también obtienen una visión más clara de la estructura del sitio.

Si tu sitio tiene una navegación profunda, merece la pena implementar el marcado de migas de pan pronto.

Article, NewsArticle y BlogPosting

Article, NewsArticle y BlogPosting pueden ayudar a los motores de búsqueda a entender el titular, el autor, la fecha, la imagen y la información del editor. Para los editores, esto puede afectar la elegibilidad para funciones orientadas a artículos, especialmente cuando se combina con buena rastreabilidad, actualidad y calidad de contenido.

No esperes que el schema de artículo convierta una entrada de blog ordinaria en un resultado de noticias. No compensará una cobertura débil, la falta de información de autor o el contenido superficial.

Dicho esto, el marcado de artículo sigue siendo sensato para sitios editoriales. Úsalo para dejar claros los datos básicos:

  • Titular
  • Autor u organización
  • Fecha de publicación y fecha de modificación
  • Imagen principal
  • Editor
  • URL canónica

Si tu equipo usa publicación asistida por IA, los datos estructurados no sustituyen la divulgación ni la responsabilidad editorial. Tratamos el lado humano de esto en cómo es una divulgación honesta de IA en un sitio web pequeño. Los sistemas de búsqueda pueden interpretar tu marcado, pero los lectores juzgan la página en sí.

LocalBusiness y sus subtipos

Para organizaciones locales, LocalBusiness y sus subtipos —como Restaurant, Dentist, Store o ProfessionalService— pueden ayudar a conectar un sitio web con datos de negocio: nombre, dirección, número de teléfono, horario de apertura, coordenadas geográficas y perfiles same-as.

El impacto visible es menos predecible que el marcado de producto o receta, porque la búsqueda local depende mucho de las fichas de negocio, la proximidad, la prominencia, las reseñas y la intención del usuario. Aun así, un marcado de negocio local coherente es una buena práctica de higiene.

Úsalo en la página que representa la ubicación del negocio, no de forma aleatoria en cada entrada del blog. Si tienes varias ubicaciones, marca cada página de ubicación con su propia dirección y horario de apertura.

Event

El marcado Event puede hacer que las páginas aptas aparezcan con fechas, ubicaciones e información de entradas en funciones de búsqueda relacionadas con eventos.

Encaja bien para:

  • Conciertos
  • Conferencias
  • Webinars
  • Clases
  • Festivales
  • Eventos comunitarios

La clave es la especificidad. Una página sobre “nuestro programa anual de formación” no es lo mismo que una página para un evento con fecha, hora de inicio, ubicación, organizador y modo de asistencia.

Para eventos online, incluye detalles de asistencia virtual. Para eventos físicos, incluye información del recinto. Mantén actualizados los eventos cancelados, pospuestos y reprogramados; un marcado de evento obsoleto es peor que no tener marcado.

JobPosting

JobPosting es uno de los ejemplos más claros de datos estructurados que impulsan una experiencia de búsqueda específica. Las páginas de empleo correctamente marcadas pueden ser aptas para funciones de búsqueda de empleo, incluyendo puesto, ubicación, salario, tipo de empleo y fecha de publicación.

Este marcado solo es útil en páginas de ofertas de empleo reales. No lo apliques a páginas genéricas de carreras que enumeran varios puestos sin páginas de detalle diferenciadas.

Los campos importantes incluyen:

  • Título del puesto
  • Organización contratante
  • Ubicación o estado remoto
  • Fecha de publicación
  • Fecha de validez
  • Tipo de empleo
  • Compensación, cuando esté disponible

Las ofertas caducadas deben eliminarse, redirigirse adecuadamente o marcarse como ya no válidas. A los motores de búsqueda no les gusta enviar usuarios a vacantes cerradas.

Recipe

El marcado Recipe sigue siendo uno de los casos clásicos de resultados enriquecidos. Puede influir en miniaturas de imagen, valoraciones, tiempo de cocción, ingredientes, nutrición y experiencias guiadas de recetas.

También es una de las áreas de datos estructurados más abusadas. Si la página es principalmente un ensayo personal con una receta enterrada al final, el marcado aun así debe describir con precisión la receta visible. Los datos estructurados no deberían afirmar una preparación de cinco minutos si las instrucciones dicen lo contrario.

Las páginas de recetas dependen mucho de las imágenes, así que los datos estructurados son solo parte del trabajo. Buenas imágenes, compresión sensata y texto alternativo útil también importan. Si estás limpiando imágenes de comida, producto o contenido editorial, una guía pragmática sobre texto alternativo de imágenes en 2026 es un buen complemento al trabajo de schema.

VideoObject

El marcado VideoObject puede afectar las vistas previas de vídeo, momentos clave, miniaturas, duración, fecha de subida e indexación de vídeo. Es útil cuando el vídeo es una parte significativa de la página, no un incrustado incidental al final.

Como mínimo, proporciona:

  • Nombre
  • Descripción
  • URL de la miniatura
  • Fecha de subida
  • Duración
  • URL de inserción o de contenido

Para vídeos instructivos o de formato largo, los momentos clave pueden ayudar a los motores de búsqueda a entender las secciones del vídeo. Esto puede mejorar cómo aparece el vídeo en la búsqueda, aunque, de nuevo, no garantiza la ubicación.

Organization, Logo y WebSite

El marcado Organization ayuda a definir la entidad detrás de un sitio. WebSite puede respaldar la comprensión a nivel de sitio y, en algunos casos, funciones como el cuadro de búsqueda de enlaces de sitio cuando el motor de búsqueda decide mostrarlo.

Este marcado es fundacional más que llamativo. Puede ayudar a aclarar:

  • Identidad del sitio oficial
  • Logotipo
  • Perfiles sociales
  • Información de contacto
  • Relaciones de matriz o subsidiaria

Toda empresa seria, publicación, organización sin ánimo de lucro y compañía de producto debería tener un marcado de organización limpio en algún lugar estable, normalmente la página de inicio o una página “acerca de”.

No lo rellenes con todas las propiedades posibles. El objetivo es claridad de entidad, no un volcado de base de datos.

FAQPage: técnicamente admitido, rara vez visible para la mayoría de sitios

FAQPage merece una nota especial porque antes era una victoria fácil. Durante años, el marcado FAQ podía expandir snippets con acordeones de preguntas y respuestas. Eso lo hacía atractivo y, como era previsible, se abusó de él.

Más tarde, Google restringió mucho los resultados enriquecidos de FAQ, mostrándolos por lo general solo para sitios gubernamentales y de salud conocidos y con autoridad. Otros motores de búsqueda pueden seguir usando el marcado FAQ de forma distinta, y el marcado todavía puede ayudar a las máquinas a entender la estructura del contenido, pero la mayoría de sitios comerciales y editoriales no deberían esperar resultados enriquecidos FAQ visibles.

Usa el marcado FAQ solo cuando la página contenga realmente una sección de preguntas frecuentes. No añadas bloques Q&A falsos solo para ganar espacio en la búsqueda.

DiscussionForumPosting y ProfilePage

El contenido de comunidades se ha vuelto más prominente en los resultados de búsqueda, y los datos estructurados pueden ayudar a identificar hilos de foros y páginas de perfil.

DiscussionForumPosting puede ser útil para foros, comunidades de preguntas y respuestas, y plataformas de discusión donde el contenido principal es conversación generada por usuarios. ProfilePage puede ayudar a identificar páginas sobre personas o colaboradores, especialmente cuando la experiencia, la autoría o la identidad comunitaria importan.

Esto no es apropiado para testimonios de marketing ordinarios ni comentarios de blog. El tipo de página debe coincidir con la experiencia real.

Tipos útiles pero a menudo sobrestimados

Algunos tipos de schema.org son razonables semánticamente, pero rara vez producen mejoras visibles de búsqueda por sí solos.

Algunos ejemplos:

  • Service
  • Thing
  • CreativeWork
  • Person
  • Place
  • ImageObject
  • WebPage
  • AboutPage
  • ContactPage

No son tipos “malos”. Pueden ayudar a describir una página con más precisión y pueden ser útiles en contextos más amplios de grafo de conocimiento. Pero si tu objetivo es un cambio visible en los resultados de búsqueda, normalmente son secundarios.

Por ejemplo, marcar una página de consultoría como Service no creará de forma fiable un resultado enriquecido especial de servicio. Una página bien estructurada, con texto claro, enlaces internos, renderizado rápido y evidencia creíble, hará más por el rendimiento en búsqueda que un marcado elaborado pero no admitido.

Del mismo modo, ImageObject puede describir imágenes, pero el rendimiento en la búsqueda de imágenes también depende del texto circundante, nombres de archivo, pies de foto, calidad de imagen, indexación y accesibilidad. Schema no sustituye los fundamentos.

JSON-LD suele ser el mejor formato de implementación

Los motores de búsqueda pueden leer varios formatos de datos estructurados, incluidos Microdata y RDFa, pero JSON-LD suele ser la opción más limpia.

Mantiene el marcado separado de la presentación HTML, es más fácil de probar y es menos probable que se rompa cuando los diseñadores cambian plantillas. Para la mayoría de equipos, JSON-LD en el head o el body de la página es la opción práctica por defecto.

Un ejemplo simple de producto se ve así:

{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Acme Carbon Tripod",
  "image": "https://example.com/images/tripod.jpg",
  "description": "A lightweight carbon tripod for travel photography.",
  "brand": {
    "@type": "Brand",
    "name": "Acme"
  },
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "149.00",
    "availability": "https://schema.org/InStock",
    "url": "https://example.com/products/carbon-tripod"
  }
}

El ejemplo es deliberadamente sencillo. La mayoría de los datos estructurados deberían ser aburridos. La precisión gana a la astucia.

Un modelo práctico de priorización

Si estás decidiendo qué implementar primero, usa este orden:

  1. Empieza por los tipos de página que se corresponden con funciones de búsqueda admitidas. El marcado de producto, receta, evento, empleo, vídeo, migas de pan, artículo y negocio local suele merecer atención antes que los tipos oscuros.
  2. Marca solo lo que los usuarios pueden ver. Las afirmaciones ocultas son una razón común por la que los datos estructurados dejan de ser aptos o se vuelven arriesgados.
  3. Corrige plantillas, no páginas individuales. Los datos estructurados son más fáciles de mantener cuando se generan desde tu CMS o base de datos de productos.
  4. Valida y luego monitoriza. Usa herramientas oficiales de resultados enriquecidos y validación de schema, y después observa los informes de mejoras de Search Console cuando estén disponibles.
  5. No ignores la experiencia de página. Los resultados enriquecidos pueden ayudar a la presentación, pero los usuarios siguen aterrizando en la página. Si los informes de rendimiento ponen nervioso a tu equipo, lee los informes de Lighthouse sin entrar en pánico antes de convertir schema en otra distracción.

Errores comunes que reducen el impacto

Marcar el tipo de página equivocado

Una página de categoría no es una página de producto. Una página de entrada de carreras no es una oferta de empleo. Una lista de próximos webinars no es necesariamente un evento.

Las funciones de búsqueda suelen estar diseñadas alrededor de intenciones de página específicas. Ajusta el marcado al propósito dominante de la página.

Añadir propiedades que no son visibles

Si la página no muestra una valoración, no incluyas aggregateRating. Si la página de empleo no menciona salario, ten cuidado con inventar marcado de compensación. Si un producto está agotado, no lo marques como disponible.

Los datos estructurados deben facilitar el procesamiento de hechos visibles, no crear una versión paralela de la página.

Tratar la validación como éxito

Pasar un validador solo significa que la sintaxis es aceptable y que quizá estén presentes los campos obligatorios. No significa que la página vaya a recibir un resultado enriquecido.

Piensa en la validación como el suelo, no como el resultado.

Implementar schema una vez y olvidarlo

Los precios cambian. Las ofertas caducan. Los eventos se posponen. Los autores se van. Los logotipos se rediseñan.

Los datos estructurados generados a partir de campos obsoletos pueden volverse inexactos silenciosamente. Revísalos siempre que cambies plantillas, campos del CMS o fuentes de datos de negocio.

<!-- tool-cta:start -->

💡 Prueba esto: Antes de investigar qué tipos de esquema importan realmente, limpia tu JSON-LD con el JSON Formatter para que la estructura sea fácil de auditar.

<!-- tool-cta:end -->

La recomendación tranquila

Para la mayoría de sitios, la estrategia de schema debería ser modesta y deliberada.

Implementa los tipos que coincidan con tu contenido real y se correspondan con funciones de búsqueda admitidas. Mantén los datos precisos. Genéralos desde fuentes fiables. Valídalos. Monitoriza los resultados. Luego detente.

No necesitas marcar cada sustantivo de la página. No necesitas doce tipos de schema anidados porque una checklist lo dijo. Y definitivamente no necesitas datos estructurados que digan más que la propia página.

Schema.org es más útil cuando elimina ambigüedad. Los resultados de búsqueda mejoran cuando esa claridad se alinea con una función que los motores de búsqueda realmente admiten.

Preguntas frecuentes

¿El marcado de schema.org mejora el posicionamiento?
No directamente. Los datos estructurados ayudan a los motores de búsqueda a entender el contenido de la página y pueden hacer que las páginas sean aptas para resultados enriquecidos. Esas apariencias más ricas pueden mejorar las tasas de clics, pero el marcado por sí solo no es un atajo de posicionamiento.
¿Qué tipo de schema deberían implementar primero la mayoría de sitios web?
Empieza con el marcado que coincida con tus tipos de página principales. Los sitios de ecommerce deberían priorizar Product y BreadcrumbList. Los editores deberían usar Article o BlogPosting. Los negocios locales deberían usar LocalBusiness. Los sitios con vídeo, eventos, empleos o recetas deberían priorizar esos tipos específicos.
¿Sigue mereciendo la pena usar schema FAQ?
Solo cuando la página tiene realmente una sección de preguntas frecuentes. Los resultados enriquecidos FAQ son mucho menos visibles que antes, especialmente para sitios comerciales ordinarios. No añadas secciones FAQ artificiales solo para perseguir funciones de búsqueda.
¿Debería usar JSON-LD, Microdata o RDFa?
JSON-LD suele ser la mejor opción para sitios web modernos. Es más fácil de mantener, está menos enredado con las plantillas y los motores de búsqueda lo recomiendan ampliamente para datos estructurados admitidos.
¿Puedo añadir schema para contenido que los usuarios no pueden ver?
En general, no. Los datos estructurados deben describir contenido visible y preciso en la página. Valoraciones ocultas, precios inventados, disponibilidad falsa o datos de eventos engañosos pueden hacer que las páginas no sean aptas para resultados enriquecidos o infrinjan las políticas de búsqueda.

Fuentes y lecturas adicionales

  1. Google Search Central: Structured data markup that Google Search supports
  2. Google Search Central: Intro to structured data markup in Google Search
  3. Schema.org Documentation
  4. Google Search Central Blog: Changes to HowTo and FAQ rich results
Sobre el autor
The Wux Webtools Team

Última actualización:

Sigue leyendo