Llevo más de una década metiendo las manos en el <head> de webs ajenas, y si algo he aprendido es que el schema markup se explica mal casi siempre. Se presenta como un trámite técnico, una casilla que marcar antes de publicar, cuando en realidad es una de las pocas palancas de SEO que sigue produciendo resultados medibles en un entorno donde Google cada vez regala menos clics.
Voy a intentar contar esto sin la solemnidad habitual. Ni es magia ni es opcional. Es un lenguaje intermedio entre tu contenido y las máquinas que lo van a leer antes que cualquier persona.
Un fragmento de código que nadie lee, salvo un rastreador
El schema markup, o datos estructurados, es un vocabulario compartido —normalmente basado en Schema.org— que permite anotar el contenido de una página para que buscadores como Google, Bing o los asistentes de voz entiendan de qué trata cada elemento sin tener que inferirlo del texto visible.
Cuando escribes «María Dolores, chef con dos estrellas Michelin desde 2019», tú sabes que María Dolores es una persona, que «chef» es su profesión y que 2019 es una fecha relevante. Un rastreador, en cambio, ve una cadena de caracteres. El marcado estructurado traduce esa frase a algo parecido a esto:
{ «@context»: «https://schema.org», «@type»: «Person», «name»: «María Dolores», «jobTitle»: «Chef», «award»: «Dos estrellas Michelin»}
Ese fragmento no lo ve nadie navegando. Vive en el código fuente, normalmente en formato JSON-LD dentro de una etiqueta <script>, y su único destinatario es la máquina. Ahí está la primera confusión que conviene desmontar: el schema no mejora la experiencia visual de tu página ni la hace más bonita. Mejora la conversación que mantienes con el buscador, y esa conversación tiene consecuencias visibles después, en forma de resultados enriquecidos.
La diferencia entre marcar y decorar
Aquí viene mi primer matiz, que sé que a algunos compañeros de profesión no les va a hacer gracia: el schema markup no es, por sí mismo, un factor de posicionamiento directo. Google lo ha repetido varias veces y le creo. Lo que hace es habilitar rich snippets: estrellas de valoración, precios, disponibilidad, preguntas frecuentes desplegables, migas de pan visibles en el SERP. Ese aumento de visibilidad eleva el CTR, y un CTR más alto sí que termina influyendo, indirectamente, en cómo se comporta tu página en el tiempo.
He visto artículos que prometen «subir posiciones con schema» como si fuera un interruptor. No es así. Lo que sí puedo decir, con datos de proyectos propios, es que una ficha de producto con Product y AggregateRating bien implementado suele mover el CTR entre un 15 % y un 30 % en búsquedas comerciales, dependiendo de la competencia visual del sector. En un cliente de electrodomésticos con el que trabajé en 2022, pasar de cero marcado a un esquema completo de producto y reseñas subió el CTR medio de las fichas de un 2,1 % a un 3,4 % en ocho semanas, según Search Console. No cambió el ranking de un día para otro. Cambió cuánta gente decidía entrar cuando ya aparecía en esa posición.
Ese matiz importa porque mucha gente instala schema esperando un efecto que el marcado no está diseñado para producir, se decepciona a los tres meses y lo abandona. El error no es el schema. Es la expectativa.
Tipos que de verdad se usan en el día a día
Schema.org tiene cientos de tipos documentados, la inmensa mayoría irrelevantes para un proyecto normal. En la práctica, un consultor SEO trabaja con un puñado reducido, una y otra vez:
- Article / NewsArticle / BlogPosting, para contenido editorial.
- Product junto a Offer y AggregateRating, para ecommerce.
- LocalBusiness y sus subtipos (Restaurant, MedicalClinic, Dentist…), para negocios físicos.
- FAQPage y HowTo, para contenido instructivo.
- Organization y Person, para señales de autoridad y EEAT.
- BreadcrumbList, casi siempre infravalorado frente a los demás.
Esa es una de las dos únicas listas que verás en este artículo, y la incluyo porque aquí sí aporta claridad real frente a párrafos largos enumerando lo mismo.
Cada tipo tiene propiedades obligatorias, recomendadas y opcionales, y ahí es donde la mayoría de implementaciones fallan sin que nadie se dé cuenta. Un Product sin price, priceCurrency y availability no es candidato a rich snippet aunque técnicamente esté «marcado». Google necesita las señales mínimas para confiar en el dato, y confiar es la palabra clave: si detecta discrepancias entre lo marcado y lo que ve un usuario real en la página, deja de mostrar el enriquecido y, en casos reincidentes, puede aplicar una acción manual por marcado engañoso. Esto último ocurre más de lo que se piensa en fichas de producto donde el precio del schema no coincide con el precio real mostrado tras aplicar impuestos o gastos de envío.
JSON-LD ganó la guerra, y con razón
Durante años convivieron tres sintaxis: microdatos, RDFa y JSON-LD. La discusión técnica ya está cerrada. Google recomienda JSON-LD desde hace tiempo, y en la práctica es lo único que merece la pena implementar salvo excepción muy justificada.
La razón es puramente operativa. Los microdatos obligan a entrelazar atributos itemprop dentro del HTML visible, lo que significa que cualquier cambio de diseño puede romper el marcado sin que nadie lo note hasta que Search Console empieza a lanzar errores semanas después. JSON-LD, en cambio, vive aislado en un bloque de script independiente del HTML de presentación. Puedes rediseñar la página entera y el schema sigue funcionando igual, porque no depende de la estructura visual sino de un objeto de datos separado.
Para un negocio con equipo de desarrollo rotativo, agencias externas o rediseños frecuentes —que es la inmensa mayoría—, esa independencia vale más que cualquier ventaja marginal que pudieran tener las otras sintaxis en teoría.
Implementación real: dónde se tuerce todo
Aquí es donde la teoría se separa del trabajo de campo. La mayoría de guías sobre schema markup terminan en el punto anterior, con el código de ejemplo y el «ya está». La realidad de implementarlo en un proyecto vivo tiene más matices.
Primero, la validación. Google Rich Results Test y el validador de Schema.org no dicen lo mismo. El primero valida específicamente contra lo que Google reconoce como elegible para rich snippets; el segundo valida contra la especificación completa de Schema.org, que incluye tipos y propiedades que Google ignora sin avisar. He visto marcados «perfectos» según el validador general que Google simplemente no procesaba porque usaban propiedades de una versión del vocabulario que el buscador no soporta en ese tipo concreto. La única prueba que importa de verdad es el Rich Results Test, y aun así conviene revisar Search Console semanas después, porque la validación sintáctica no garantiza que Google decida mostrar el enriquecido.
Segundo, la consistencia entre el dato marcado y el dato visible. Esto no es una recomendación estética, es una norma explícita de las directrices para webmasters de Google, y su incumplimiento es la causa más habitual de que un marcado deje de generar resultados enriquecidos de un día para otro sin previo aviso. Si tu FAQPage dice que la pregunta es «¿cuál es el horario de atención?» y la respuesta visible en la página dice otra cosa, o directamente esa pregunta no aparece en el contenido visible, estás en zona de riesgo.
Tercero, y esto lo digo con la tranquilidad de quien ya se ha llevado el golpe: el marcado no es «ponlo una vez y olvídalo». Cambia el producto, cambia el precio, cambia la disponibilidad, y si el schema se genera de forma manual y no dinámica, se desincroniza en cuestión de semanas. La solución técnicamente correcta es que el marcado se genere desde la misma fuente de datos que alimenta la página —la base de datos del CMS, el feed del ecommerce—, nunca como un bloque estático copiado y pegado. Cuando trabajo con clientes que usan WordPress con WooCommerce, por ejemplo, prefiero mil veces un plugin que genere el JSON-LD dinámicamente desde los campos del producto antes que cualquier solución manual, por elegante que parezca al principio.
FAQPage, el caso que más ha cambiado en los últimos dos años
Merece un apartado propio porque es donde más ha evolucionado el criterio de Google recientemente. Durante bastante tiempo, cualquier página con un bloque de preguntas frecuentes podía aspirar a que Google desplegara esas preguntas directamente en el resultado de búsqueda, ocupando un espacio considerable en el SERP.
Google restringió esa visibilidad de forma notable en 2023, limitando los rich snippets de FAQPage prácticamente a sitios gubernamentales y de salud reconocidos. Para el resto de sectores, la elegibilidad se redujo drásticamente. Esto generó bastante frustración en la comunidad SEO, y entiendo el enfado, pero también creo que la medida tenía sentido: el abuso había sido tan sistemático —FAQs añadidas artificialmente solo para ocupar espacio visual, sin aportar información real— que Google optó por reducir el incentivo antes que perseguir caso por caso.
Mi recomendación práctica, y aquí discrepo un poco del entusiasmo que sigue viendo en foros: sigue marcando tus FAQ con FAQPage si el contenido es genuino y responde a dudas reales de tus usuarios, porque aunque hoy no obtengas el rich snippet en la mayoría de sectores, el marcado sigue ayudando a que los motores de IA generativa —Perplexity, la propia Google AI Overview, ChatGPT cuando navega— extraigan y citen tu contenido con mayor precisión. Ese es un beneficio que no aparecía hace tres años y que hoy pesa casi tanto como el rich snippet clásico.
HowTo, otro tipo en horas bajas
Algo parecido, aunque menos drástico, le ha pasado a HowTo. Google dejó de mostrar sus resultados enriquecidos en la búsqueda de escritorio de forma general, manteniéndolos de forma más limitada en algunos contextos. La lección de fondo se repite: los tipos de schema no tienen un valor fijo en el tiempo. Lo que hoy genera un resultado visual espectacular puede perder esa capacidad en dieciocho meses sin que cambie una coma de tu código.
Esto tiene una implicación estratégica que casi nadie menciona: no construyas tu arquitectura de contenido alrededor de un tipo de rich snippet concreto. Constrúyela alrededor de la utilidad real del contenido para el usuario, y usa el schema como capa adicional de comunicación con el buscador, no como el objetivo en sí mismo. Los clientes que mejor han resistido estos cambios de criterio de Google son, sin excepción, los que nunca dependieron de un solo tipo de rich snippet para justificar su estrategia de contenidos.
LocalBusiness y la señal que Google trata distinto
En proyectos de negocio local —clínicas, restaurantes, despachos, comercios físicos— el marcado LocalBusiness con sus subtipos específicos suele ser el que más impacto tangible produce, precisamente porque se cruza con Google Business Profile y con el paquete local (el «3-pack» de mapas).
Aquí el matiz técnico importa: el NAP —nombre, dirección, teléfono— marcado en el schema debe coincidir exactamente con el que aparece en Google Business Profile y en cualquier directorio donde el negocio esté listado. No de forma aproximada. Exactamente. «C/ Alcalá, 45» y «Calle Alcalá 45» son, para un sistema de verificación de coherencia, dos direcciones potencialmente distintas, y esa discrepancia mínima puede debilitar la confianza que el algoritmo deposita en la entidad completa. En un proyecto de clínica dental con tres sedes que gestioné hace un par de años, unificar el formato exacto del NAP entre el schema de cada sede, el perfil de empresa de Google y los directorios sectoriles principales coincidió con una mejora sostenida en la visibilidad del paquete local en las semanas siguientes. No puedo probar causalidad al cien por cien —ningún SEO honesto puede probarla nunca del todo—, pero la correlación temporal fue demasiado clara para ser casual.
El vínculo con EEAT que casi nadie explica bien
Se habla mucho de EEAT —experiencia, pericia, autoridad, confianza— como si fuera un factor que Google mide directamente. No lo hace, al menos no como una puntuación única. Es un marco que las directrices para evaluadores de calidad usan para valorar contenido, y el schema markup es una de las formas más directas de darle a un sistema automatizado las pistas que un evaluador humano detectaría leyendo con atención.
Marcar Person para el autor de un artículo, con propiedades como jobTitle, worksFor o sameAs enlazando a perfiles profesionales verificables, no «engaña» al algoritmo para que piense que hay más autoridad de la que existe. Lo que hace es traducir a un formato legible por máquina algo que ya debería estar presente en el contenido: quién lo escribe y por qué esa persona tiene criterio sobre el tema. Si esa autoridad no existe de verdad, el marcado no la crea de la nada. Simplemente comunica con más precisión lo que ya hay, para bien o para mal.
Un caso donde el schema no sirvió de nada
Prometo honestidad, así que toca contar un fracaso. Hace un tiempo implementé un Product completo, con AggregateRating real basado en reseñas verificadas, para el ecommerce de un cliente de menaje del hogar. Validación perfecta, propiedades completas, coherencia total entre dato marcado y dato visible. El resultado enriquecido nunca apareció en más del 40 % de las fichas de producto, pese a semanas de espera.
La causa, tras revisar con Search Console y comparar con competidores que sí obtenían el snippet, resultó ser la profundidad del catálogo: Google prioriza mostrar rich snippets de producto en dominios con volumen de tráfico y confianza acumulada suficientes, y este era un catálogo relativamente joven, con menos de un año de indexación estable. El schema estaba impecable. Lo que faltaba era historial. Esa experiencia me enseñó algo que pocas guías mencionan: el marcado estructurado es condición necesaria pero no suficiente. Puede ser perfecto y aun así no producir el resultado visual esperado si el dominio no ha acumulado la confianza que Google exige para ese tipo de despliegue visual.
Herramientas que uso, sin adornos
Para quien empieza, el camino más corto y menos propenso a errores pasa por generadores dedicados —Merkle, Schema Markup Generator de Sean Kelly, o el propio asistente de datos estructurados de Google, con las limitaciones que tiene desde que redujo funciones hace un tiempo—. Para quien gestiona volumen, la generación dinámica desde el CMS es obligatoria, no opcional: WordPress con plugins como Rank Math o Yoast (con matices, porque no siempre generan el marcado más completo por defecto), Shopify con apps específicas de schema, o desarrollo a medida cuando el volumen de producto lo justifica.
Y para la validación, insisto: Rich Results Test primero, validador de Schema.org como comprobación secundaria, y revisión de Search Console pasadas dos o tres semanas, porque es ahí donde se ve si Google realmente decidió usar el marcado, no solo si lo entendió sintácticamente.
Lo que viene, y por qué el marcado importa más, no menos
Hay quien piensa que con la llegada de la búsqueda generativa el schema markup va a perder relevancia, porque los modelos de lenguaje «ya entienden» el contenido sin necesidad de anotaciones explícitas. Creo exactamente lo contrario, y es la opinión con la que quiero cerrar esto.
Un modelo de lenguaje entiende prosa, sí, pero entenderla no es lo mismo que confiar en ella lo suficiente como para citarla como fuente en una respuesta generada. Los sistemas de recuperación aumentada que alimentan estas respuestas siguen dependiendo, en gran medida, de señales estructuradas para decidir qué fragmento de qué página es lo bastante fiable y lo bastante concreto como para extraerlo. El dato marcado —precio, fecha, autor, valoración, disponibilidad— sigue siendo la forma más barata y más verificable de comunicarle a cualquier sistema automatizado, sea un rastreador clásico o un motor generativo, que ese dato concreto es exacto y no una inferencia del modelo sobre un texto ambiguo.
La pregunta que de verdad importa para los próximos años no es si el schema markup seguirá siendo relevante. Es si los negocios que hoy lo tratan como un trámite técnico de última hora entenderán a tiempo que la estructura de sus datos va a decidir, cada vez más, si existen o no en la conversación que sus clientes potenciales mantienen con una máquina antes de mantenerla con ellos.