js

Schema markup: cómo le contás a Google qué es lo que está leyendo

Schema markup es vocabulario estructurado que vive dentro del HTML para decirle a un buscador qué tipo de cosa es cada bloque de contenido. Sin schema, Google infiere. Con schema, Google sabe — y eso cambia cómo aparece tu página en SERP, en rich results y en respuestas de IA.

Tipo · concepto técnicoCategoría · Schema y SERPActualizado · 2026

Qué es y por qué importa más en 2026

Schema markup es el implementación práctica del vocabulario de Schema.org, un proyecto colaborativo entre Google, Bing, Yahoo y Yandex. La idea es simple: el HTML describe estructura visual (un h1, un párrafo, una imagen), pero no describe semántica (qué tipo de entidad es, cómo se relaciona con otras). Schema agrega esa capa.

Una página de producto sin schema es para Google “una página con texto, una imagen y un botón”. Una página de producto con schema bien implementado es “un Producto, marca X, precio Y, en stock, con 4.7 estrellas en 312 reviews”. La diferencia no es estética — es elegibilidad para rich results, presencia en Google Shopping, citas en AI Overviews y mejor comprensión semántica del sitio entero.

En 2026 schema dejó de ser un “nice to have de SEO técnico” para convertirse en uno de los principales mecanismos por los que los modelos de búsqueda generativa entienden de qué trata una página. Los crawlers de ChatGPT, Perplexity y Gemini no inventan — leen schema cuando está disponible y lo usan para citar con más confianza.

JSON-LD: el formato que Google recomienda

Schema se puede implementar en tres formatos: Microdata (atributos en HTML), RDFa (similar) y JSON-LD (un bloque de JavaScript separado). Google recomienda explícitamente JSON-LD desde 2017 y es el único formato que mantengo en producción para clientes — los otros dos generan código inline acoplado al markup, que se rompe en cada rediseño.

// Ejemplo mínimo: Article schema en JSON-LD <script type=”application/ld+json”> { “@context”: “https://schema.org”, “@type”: “Article”, “headline”: “Cómo se mide el LCP”, “author”: { “@type”: “Person”, “name”: “Sebastián Querelos” }, “datePublished”: “2026-04-28” } </script>

El bloque va dentro del <head> o al final del <body>, no afecta render, no compite con el contenido visual. Si la página se rediseña, el JSON-LD sigue intacto. Si hay que sumar properties, se editan en el bloque sin tocar el resto del HTML. Esa separación es la razón técnica por la que JSON-LD ganó la pulseada.

Rich results: el premio visible

Rich results son los resultados que Google muestra con formato extendido en SERP — estrellas de review, precio, breadcrumbs visuales, FAQ desplegable, eventos con fecha, recetas con foto y tiempo de cocción. Cada tipo de rich result depende de un schema específico bien implementado. Sin el schema correcto, no hay elegibilidad — Google no inventa el rich result, lo construye desde lo que vos declaraste.

El detalle importante: tener el schema implementado no garantiza el rich result. Google decide cuándo mostrarlo, basado en confianza, calidad de la página y query. Pero no tener el schema garantiza no tenerlo. Es el primer filtro de elegibilidad.

Tipo · Producto

Product schema

Precio, stock, marca, rating. Eligible para rich result en SERP comercial y para Google Shopping orgánico.

Tipo · Editorial

Article schema

Headline, autor, fecha. Eligible para Top Stories, Discover, citas en AI Overviews. Esencial para todo contenido editorial.

Tipo · Servicios

Service schema

Tipo de servicio, área servida, proveedor. Útil para B2B y profesionales — ayuda a desambiguación local.

Tipo · Q&A

FAQPage schema

Pregunta + respuesta estructuradas. En 2023 Google restringió rich result a sitios autoritativos, pero el schema sigue siendo útil para AI Overviews y citas conversacionales.

Errores que veo todo el tiempo

El error más común es declarar properties que no se cumplen en la página. Decir “hasOffers: 99 USD” en JSON-LD cuando el precio visible al usuario es otro genera spam structured data — Google lo detecta, manda warning en Search Console y eventualmente desconfía del resto del schema del sitio. Schema declara lo que la página efectivamente muestra, no lo que querrías que dijera.

El segundo error es duplicar entidades. Una misma página con dos JSON-LD declarando dos Article distintos confunde al parser y algunos crawlers descartan ambos. La regla: una página primaria, un schema primario, y schemas secundarios solo para componentes (BreadcrumbList, Organization sitewide).

El tercero es no validar. La Rich Results Test de Google y el Schema Markup Validator son obligatorios antes de publicar. No es opcional, no es extra-mile, es básico — ahorra horas de debug post-deploy.

Cómo se aplica en la práctica

En proyectos enterprise el schema se diseña como sistema, no como página. Definís qué entidades existen (Organization sitewide, WebSite con SearchAction, Article para cada nota, Product para cada SKU), las relacionás con @id propios, y el sitio entero gana coherencia semántica. Eso es lo que hago en consultorías de arquitectura SEO. Si querés ver casos reales, hay ejemplos en /casos/.