Schema Markup Types: elegir datos estructurados que encajan de verdad

Definicion rapida

Los Schema Markup Types son tipos de datos estructurados que describen el contenido de una pagina con un vocabulario estandarizado. Ayudan a los motores a entender si una pagina es un articulo, producto, curso, video, negocio local, breadcrumb, perfil de persona u otra entidad. El vocabulario mas comun es Schema.org; para Google Search, JSON-LD suele ser el formato recomendado porque es mas facil de mantener que Microdata o RDFa.

La idea clave es simple: Schema Markup no inventa la verdad. Describe la verdad visible en la pagina. Si una pagina no vende un producto, Product markup esta mal. Si no hay reviews reales visibles, Review markup es riesgoso. Si una FAQ esta escondida solo para buscadores, FAQPage no es una implementacion limpia. Buen markup es menos un truco y mas una disciplina editorial.

Terminos cubiertos aqui

• Article Schema
• FAQPage Schema
• HowTo Schema
• Product Schema
• Review y AggregateRating
• Organization, LocalBusiness y Person
• BreadcrumbList, WebSite e ItemList
• VideoObject y SpeakableSpecification
• Course y SoftwareApplication
• MedicalWebPage
• JSON-LD, rich results y validacion

Explicacion simple

Piensa en Schema Markup como etiquetas en un almacen bien organizado. Una caja no dice solo "contenido"; dice "producto", "precio", "disponibilidad", "rating" e "imagen". Otra dice "articulo", "autor", "fecha" e "imagen principal". Esas etiquetas no hacen mejor la mercancia, pero aclaran su significado.

Para SEO eso vale porque los motores deben clasificar el contenido, no solo renderizarlo. Los datos estructurados pueden hacer posibles rich results, aclarar entidades y exponer problemas de templates. No garantizan visualizacion. Google deja claro que markup valido no garantiza rich result. El algoritmo decide si una funcion encaja con la experiencia de busqueda.

JSON-LD: el default practico

Google soporta JSON-LD, Microdata y RDFa, pero recomienda JSON-LD cuando la configuracion del sitio lo permite. La razon es practica: JSON-LD esta separado del HTML visible en un bloque script con type application/ld+json. Es mas facil de generar, probar y versionar. En CMS modernos, ecommerce y frameworks suele ser mas robusto que mantener atributos por todo el arbol HTML.

Aun asi, JSON-LD es solo el formato. La calidad real viene del mapeo. Cual es la entidad principal de la pagina? Que entidades son visibles? Que propiedades se pueden probar? Que datos cambian a menudo y necesitan automatizacion? Un markup puede ser tecnicamente valido y aun asi malo si describe precios viejos, ratings antiguos o contenido que el usuario no ve.

Schemas de contenido: Article, FAQPage y HowTo

Article Schema encaja con articulos editoriales, noticias, posts de blog y paginas parecidas. Campos utiles son headline, autor, fecha, imagen y publisher. Ayuda a Google a entender la pagina como contenido publicado. Para entradas de glosario, Article o un modelo mas especifico tipo CreativeWork o DefinedTerm puede encajar segun el sistema, pero para rich results de Google Article aplica sobre todo a articulos reales.

FAQPage y HowTo requieren cuidado en 2026. FAQPage sigue siendo un tipo Schema.org valido: una pagina con preguntas y respuestas puede describirse asi. Pero Google documento en mayo y junio de 2026 que los FAQ rich results ya no aparecen en Google Search. HowTo tambien sigue siendo un tipo Schema.org valido, pero Google ya habia retirado la documentacion de HowTo rich result porque ese resultado ya no se muestra. Conclusion practica: FAQPage y HowTo pueden ayudar a claridad semantica, busqueda interna u otros consumidores, pero no deberian venderse como palancas principales de visibilidad en Google.

Schemas comerciales: Product, Review, SoftwareApplication y Course

Product Schema es fuerte cuando una pagina describe realmente un producto: nombre, imagenes, ofertas, precio, disponibilidad, variantes, reviews e informacion de vendedor. Tambien es un area donde los datos malos se notan rapido. Precio, disponibilidad y ratings deben estar actualizados y ser visibles para usuarios.

Review Snippet markup describe Review y AggregateRating. No debe usarse para estrellas inventadas, ocultas o autopromocionales. Google tiene reglas especificas; si se incumplen, la elegibilidad de rich result puede perderse. SoftwareApplication encaja con paginas de apps o software cuando sistema operativo, categoria, rating y oferta estan presentes. Course markup es especialmente relevante para listas de cursos; un bloque comercial generico sin datos reales de curso no es buen candidato.

Organization, LocalBusiness y Person

Organization Markup ayuda a Google a entender detalles administrativos e identidad: nombre, URL, logo, contacto, direccion, perfiles sociales e identificadores. Suele pertenecer a la home o a una pagina About central, no ciegamente a cada URL con datos contradictorios.

LocalBusiness es mas especifico. Encaja con ubicaciones fisicas o sucursales con direccion, horarios, telefono y atributos locales. Una empresa SaaS sin lugar publico no deberia forzar LocalBusiness. Person Markup encaja con autores, perfiles expertos, fundadores o contenido revisado por especialistas cuando la persona es visible y relevante. Cuanto mas depende una pagina de confianza, mas importa la claridad de entidades.

Navegacion y estructura: BreadcrumbList, WebSite e ItemList

BreadcrumbList es uno de los tipos mas practicos porque describe la posicion de una pagina en la jerarquia del sitio. Es util para sitios grandes, tiendas, glosarios y hubs de contenido. Buenos breadcrumbs son visibles en la interfaz, no solo escondidos en JSON-LD.

WebSite Markup puede describir el sitio completo. Antes se asociaba a Sitelinks Search Box, pero Google retiro esa documentacion. WebSite puede seguir siendo semantico si representa bien el dominio. ItemList describe listas ordenadas o curadas: categorias, rankings, listas de cursos, colecciones o comparativas. El error es inflar cualquier bloque de enlaces como ItemList.

Medios, casos especiales y contenido sensible

VideoObject es correcto cuando hay un video visible e importante en la pagina. Titulo, descripcion, thumbnail, fecha de subida, duracion e informacion de embed deben coincidir. Sin video visible, VideoObject es enganoso. SpeakableSpecification existe en Schema.org y en el ecosistema de Google, pero no es un estandar SEO generico para cada pagina. Solo se usa si los requisitos especificos se cumplen de verdad.

MedicalWebPage es un buen ejemplo de tipo sensible. El contenido medico necesita exactitud, revision, autoria clara y cero promesas enganosas. Schema puede estructurar esas senales, pero no reemplaza calidad medica. En temas YMYL, markup incorrecto es peor que no tener markup.

Que tipos generan mas valor?

El tipo mas valuable es el que describe correctamente el contenido principal y esta soportado para la superficie de busqueda que importa. Para una pagina de ecommerce, Product suele ser central. Para una clinica local, LocalBusiness. Para un hub de contenido, BreadcrumbList, Article y entidades Organization o Person limpias. Para una pagina de video, VideoObject. Para un directorio de cursos, Course e ItemList.

Orden practico: revisar datos visibles requeridos, comprobar soporte de Google, generar JSON-LD, probar con Rich Results Test y URL Inspection, y despues monitorizar Search Console. Schema no es una casilla unica. Precios, reviews, disponibilidad, autores y URLs cambian.

Errores frecuentes

• El markup describe contenido que usuarios no ven.
• Todas las paginas reciben el mismo bloque Organization sin contexto.
• Las estrellas Review son inventadas o autopromocionales.
• FAQPage se sigue vendiendo en 2026 como palanca de FAQ rich result en Google.
• Product se usa en categorias o paginas lead sin vender un producto unico.
• Breadcrumb no coincide con la navegacion visible.
• JSON-LD se olvida, duplica o sale con URLs antiguas tras un relanzamiento.
• Validar sin errores se confunde con garantia de rich result.

Angulo Contextter

Contextter trata Schema Markup como problema de estructura de contenido, no solo como capa tecnica. Los datos estructurados utiles nacen de estructura util: entidades claras, secciones coherentes, autoria real, datos de producto exactos, preguntas visibles, medios reales y enlaces internos consistentes. Cuando el brief ya aclara que entidad explica la pagina y que hechos son visibles, JSON-LD se vuelve mas facil, limpio y honesto.

Fuentes para revision

• Intro to structured data: https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data
• General structured data guidelines: https://developers.google.com/search/docs/appearance/structured-data/sd-policies
• Search Gallery: https://developers.google.com/search/docs/appearance/structured-data/search-gallery
• Article structured data: https://developers.google.com/search/docs/appearance/structured-data/article
• Breadcrumb structured data: https://developers.google.com/search/docs/appearance/structured-data/breadcrumb
• Product structured data: https://developers.google.com/search/docs/appearance/structured-data/product
• Review snippet structured data: https://developers.google.com/search/docs/appearance/structured-data/review-snippet
• Organization structured data: https://developers.google.com/search/docs/appearance/structured-data/organization
• Local business structured data: https://developers.google.com/search/docs/appearance/structured-data/local-business
• Video structured data: https://developers.google.com/search/docs/appearance/structured-data/video
• Software app structured data: https://developers.google.com/search/docs/appearance/structured-data/software-app
• Course list structured data: https://developers.google.com/search/docs/appearance/structured-data/course
• FAQ rich result removal: https://developers.google.com/search/updates#removing-faq-rich-result
• FAQPage type: https://schema.org/FAQPage
• HowTo type: https://schema.org/HowTo
• MedicalWebPage type: https://schema.org/MedicalWebPage
• SpeakableSpecification type: https://schema.org/SpeakableSpecification
• ItemList type: https://schema.org/ItemList