Lo que los datos estructurados cambian realmente
Una página web es un texto que el motor debe interpretar. Los datos estructurados eliminan esta interpretación: declaran explícitamente que este número es un precio, que esta fecha es la de un evento, que esta persona es el autor. El formato elegido por Google para esta declaración es el JSON-LD, un bloque de código aislado en la cabecera de la página, sin efecto en la visualización.
El efecto directo en el ranking es nulo, y hay que decirlo claramente para evitar falsas expectativas. Ningún marcado hace subir una página. Lo que produce es un marcado enriquecido en los resultados: estrellas de valoración, precio, disponibilidad, preguntas desplegables, miga de pan legible, imagen de receta. Este formato ocupa más superficie y atrae más clics a igualdad de posición.
El efecto indirecto es más profundo. Un sitio correctamente marcado se convierte en una fuente que los sistemas automáticos comprenden sin ambigüedad, lo cual cuenta cada vez más a medida que los motores generan respuestas en lugar de listas de enlaces. Declarar limpiamente tu entidad, tus servicios y tus autores ya no es una optimización marginal, es la forma en que una organización se hace legible.
El JSON-LD se coloca en una etiqueta de script dedicada, generalmente en la cabecera del documento. No es visible ni se indexa como texto, y no sustituye al contenido de la página. Un marcado que declara una información ausente en la página es una infracción de las directrices de Google y te expone a una acción manual.
Los tres formatos y por qué solo uno cuenta
Históricamente coexisten tres sintaxis para expresar lo mismo. Los microdatos y el RDFa se insertan en el HTML visible, añadiendo atributos a las etiquetas existentes. El JSON-LD vive aparte, en un bloque autónomo.
Google recomienda explícitamente el JSON-LD desde hace varios años por una razón práctica: al estar el marcado separado del contenido, se genera, se modifica y se valida sin tocar la plantilla. En un sitio donde el contenido lo producen varias personas, esta separación evita que una modificación editorial rompa el marcado sin que nadie se dé cuenta.
Los otros dos formatos se siguen leyendo e interpretando, por lo que no hay urgencia en migrar un sitio que los utilice correctamente. En cambio, mezclar dos formatos en la misma página produce declaraciones concurrentes y resultados imprevisibles. Un solo formato por página, y preferiblemente JSON-LD.
El vocabulario Schema.org y cómo orientarse
Schema.org es un vocabulario compartido, mantenido conjuntamente por los principales motores. Define cientos de tipos y miles de propiedades, lo que desanima a la primera lectura. En la práctica, una decena de tipos cubren casi todas las necesidades de un sitio profesional.
Los tipos que realmente necesitarás
Organization declara la propia empresa, su nombre, logotipo, datos de contacto y perfiles oficiales. LocalBusiness y sus subtipos precisan el establecimiento físico, sus horarios y la zona de servicio. Article cubre los contenidos editoriales, Product las fichas de producto, FAQPage las preguntas frecuentes, BreadcrumbList la miga de pan, Person los autores y Service las prestaciones.
El principio de elección es sencillo: elige el tipo más preciso que exista. Declarar un restaurante como LocalBusiness funciona, pero declararlo como Restaurant transmite más. Una clínica dental gana al usar Dentist en lugar de MedicalBusiness. Esta precisión cuesta el mismo esfuerzo y mejora la comprensión.
El grafo, para evitar declaraciones huérfanas
Una página bien marcada no declara tres bloques independientes, declara un conjunto de entidades conectadas entre sí. La estructura en grafo permite decir que este artículo tiene como autor a esta persona, la cual pertenece a esta organización, la cual edita este sitio.
Técnicamente, esto consiste en agrupar las entidades en una tabla y darles identificadores estables, para luego referenciarlas mediante esos identificadores en lugar de copiar sus propiedades. La ganancia es doble: el archivo sigue siendo legible y los motores consolidan la información de una página a otra en torno a los mismos identificadores.
Los marcados que activan un formato enriquecido
No todos los tipos producen una visualización especial. Aquí tienes los que dan un resultado visible, por orden de frecuencia en sitios de empresa.
FAQPage, el más rentable de implementar
Declara preguntas y sus respuestas, y permite una visualización desplegable bajo el resultado. La ganancia de superficie es clara y el coste de implementación bajo, ya que el contenido ya existe en la página. La condición que debes respetar es estricta: cada pregunta y cada respuesta declarada deben ser visibles para el visitante, incluso si están plegadas en un acordeón.
BreadcrumbList, discreto pero sistemático
Sustituye la dirección bruta mostrada bajo el título por una ruta legible. El efecto en el porcentaje de clics es modesto por sí solo, pero se aplica a todas las páginas del sitio y solo cuesta una generación automática desde la estructura. Es el marcado con mejor relación entre esfuerzo y cobertura.
Product y AggregateRating, para el comercio
Precio, disponibilidad, nota media y número de opiniones aparecen directamente en los resultados. El impacto en el porcentaje de clics es el más fuerte de todos los marcados. La restricción es proporcional: las opiniones declaradas deben ser reales, recogidas en el sitio y visibles. Declarar una nota agregada sin opiniones mostradas es una infracción frecuente y sancionada.
LocalBusiness, para los establecimientos
Consolida la entidad ante Google y cruza la información de la ficha de establecimiento. No activa una visualización espectacular, pero participa en la coherencia de las señales locales, tema detallado en nuestra guía de SEO local.
Escribir un marcado limpio, las reglas que evitan errores
La sintaxis es sencilla, los errores son casi siempre lógicos más que técnicos.
La primera regla es la correspondencia estricta entre el marcado y la página. Un precio declarado debe ser el precio mostrado. Una fecha de publicación declarada debe coincidir con la visible. Esta exigencia parece obvia y se viola constantemente con marcados generados automáticamente a partir de campos mal rellenados.
La segunda regla es la estabilidad de los identificadores. Una entidad conserva el mismo identificador de una página a otra y de un año a otro. Cambiar el identificador de una organización en cada rediseño equivale a crear una nueva entidad y perder la consolidación acumulada.
La tercera es la completitud razonada. Rellenar las propiedades obligatorias y luego las recomendadas es suficiente. Amontonar decenas de propiedades facultativas no aporta nada y alarga un archivo que habrá que mantener. Valen más cinco tipos bien rellenados que quince tipos incompletos.
La cuarta se refiere a los caracteres especiales. Un marcado es JSON, por lo que las comillas internas deben escaparse y los saltos de línea codificarse. Un ampersand no tratado o una apóstrofe tipográfica mal codificada bastan para invalidar todo el bloque, y el fallo es silencioso: el motor simplemente ignora el marcado.
Validar, y sobre todo validar el renderizado correcto
La validación es el paso que todo el mundo se salta y el que revela la mitad de los problemas.
Las dos herramientas a utilizar, en este orden
El validador de Schema.org controla la conformidad con el vocabulario: tipos existentes, propiedades autorizadas, valores correctamente tipados. La prueba de resultados enriquecidos de Google controla otra cosa: la elegibilidad para una visualización enriquecida, con las propiedades que Google exige además de las que Schema.org autoriza.
Ambas son complementarias y un marcado puede pasar la primera fallando en la segunda. Utilizar las dos evita concluir demasiado rápido que un marcado es correcto porque no aparece ningún error de sintaxis.
Probar la URL online, no el código pegado
Es la precaución más importante y la más descuidada. Pegar tu código en el validador prueba lo que has escrito. Probar la dirección online prueba lo que el servidor envía realmente, tras el paso de las extensiones, la caché y las posibles reescrituras. La diferencia entre ambos es frecuente, y es precisamente ahí donde se esconden los duplicados de declaración.
Search Console proporciona después un seguimiento en el tiempo, por tipo de marcado, con los errores detectados en el conjunto de las páginas rastreadas. Es el único lugar donde ves que un problema afecta a cuatrocientas fichas de producto y no solo a la que has probado.
Los errores de marcado más frecuentes
Seis errores se repiten en casi todas las auditorías que realizamos.
- Declarar un contenido ausente en la página. Preguntas marcadas que no aparecen en ninguna parte, o una nota agregada sin opiniones visibles. Es la infracción más sancionada.
- Dejar que dos fuentes generen el mismo tipo. La extensión SEO y la plantilla producen cada una su bloque, y los dos se contradicen.
- Marcar la página de inicio como un Article. No lo es, es una WebPage o una Organization según lo que presente.
- Olvidar actualizar la fecha de modificación. Un artículo revisado que sigue declarando su fecha de origen pierde el beneficio de la frescura.
- Utilizar un tipo demasiado general. LocalBusiness cuando existe Restaurant, Dentist o HomeAndConstructionBusiness.
- No volver a validar nunca tras una actualización. Una actualización de extensión a veces cambia el marcado generado, sin previo aviso.
Ninguno de estos errores es difícil de corregir. Persisten porque nadie mira el marcado una vez colocado, a pesar de que vive y se degrada como el resto del sitio.
El marcado por tipo de sitio
Las prioridades difieren según la actividad. Esto es lo que instalamos sistemáticamente según el perfil.
Sitio de prestación de servicios
Organization para la entidad, LocalBusiness si un establecimiento recibe público, Service para cada prestación con su zona de servicio, BreadcrumbList en todas partes, FAQPage en las páginas que las incluyan, y Person para el autor de los contenidos editoriales. Esta base cubre lo esencial y se genera desde la plantilla.
Tienda online
Product en cada ficha, con Offer para el precio y la disponibilidad, AggregateRating si existen opiniones reales, BreadcrumbList en la ruta de categorías, y Organization a nivel del sitio. El punto de atención es la generación automática en miles de fichas: un error de plantilla se replica instantáneamente en todas partes.
Sitio editorial y blog
Article o BlogPosting según la naturaleza, con autor identificado, fechas de publicación y modificación, e imagen. La declaración del autor merece un cuidado especial porque participa directamente en las señales de experiencia, tema que tratamos en la prestación de posicionamiento natural.
El marcado en una tienda online, caso particular
El comercio concentra a la vez el mayor potencial de marcado enriquecido y el mayor riesgo de error masivo. Una declaración de producto falsa no afecta a una página, afecta a la totalidad del catálogo en una sola subida.
El precio declarado debe coincidir con el precio efectivamente pagado, impuestos incluidos para clientes particulares, y la divisa debe ser explícita. Las tiendas que muestran un precio sin impuestos en la fachada y declaran el mismo importe en su marcado producen resultados engañosos que acaban siendo reportados.
La disponibilidad plantea un problema de sincronización. Un producto agotado que sigue declarándose disponible genera frustración y degrada la confianza otorgada al dominio. La declaración debe conectarse al estado real del stock, no a un valor fijo en la plantilla.
Por último, las variantes. Un producto con varias tallas o colores puede declararse como una entidad única con un rango de precios, o como varias entidades distintas. La elección depende de la estructura de direcciones elegida, que a su vez depende de la plataforma, tema tratado en nuestra comparativa WordPress o Shopify. Ambos enfoques funcionan, mezclarlos en un mismo catálogo no.
En catálogos grandes, la regla de prudencia es probar la plantilla en tres productos representativos antes de desplegarla, y luego verificar en Search Console durante las dos semanas siguientes. Un error replicado en ochocientas fichas se corrige tan rápido como se propagó, pero hay que verlo. Es uno de los puntos de control de una prestación de SEO e-commerce.
El marcado se decide con la arquitectura, no después
Una observación de método válida para todos los proyectos. El marcado expresa la estructura del sitio, no la crea. Un sitio cuya estructura es confusa produce una miga de pan confusa, y ninguna declaración arreglará una jerarquía mal pensada.
Por eso tratamos el marcado en el momento en que se diseña la arquitectura, con la misma lógica expuesta en nuestro método de cocoon semántico. Los identificadores de entidades, las relaciones entre páginas pilares y páginas hijas, la jerarquía de categorías: todo eso se decide una vez y luego se traduce mecánicamente al marcado.
En un proyecto nuevo, esta exigencia se formaliza en el pliego de condiciones del sitio web, al igual que los umbrales de rendimiento. Entonces cuesta unas pocas horas. Añadida después del lanzamiento, supone volver a cada plantilla y verificar cada tipo, lo que representa varios días.
El caso de los sitios multilingües merece una mención. Cada versión lingüística lleva su propio marcado, con el idioma declarado e identificadores de entidad compartidos entre las versiones. La organización sigue siendo la misma entidad independientemente del idioma, lo que la declaración debe reflejar; de lo contrario, el motor ve cuatro organizaciones distintas con el mismo nombre.
Lo que cuesta un marcado completo
La pregunta del presupuesto siempre llega, y la respuesta depende sobre todo del número de plantillas, no del número de páginas.
En un sitio de servicios clásico, cuenta con un día para el inventario y la limpieza, un día para diseñar el grafo y asentar la base, y medio día por cada plantilla específica restante. Un sitio web corporativo de veinte páginas con tres plantillas se gestiona en dos o tres días.
En una tienda, añade la plantilla de producto y la de categoría, más el tiempo de verificación en una muestra representativa. El catálogo en sí no cambia el coste ya que el marcado se genera, lo que explica que una tienda de ochocientas referencias no cueste más de marcar que una de cincuenta.
Este presupuesto es modesto en relación al efecto, y eso lo convierte en una de las intervenciones con mejor rendimiento en un proyecto de posicionamiento. Los sitios que entregamos en nuestros trabajos salen todos con esta base instalada, lo que evita tener que volver a ello.
Lo que el marcado no hará por ti
Una aclaración útil, porque el tema atrae promesas excesivas.
El marcado no hace subir una página en los resultados. Una página mal escrita, en un sitio lento y sin autoridad, se quedará en su sitio independientemente de la calidad de sus declaraciones. Las ganancias observadas tras un marcado provienen de la mejora en el porcentaje de clics, no de un cambio de posición.
Tampoco garantiza la visualización enriquecida. La elegibilidad es una condición necesaria, pero la visualización sigue siendo una decisión de Google tomada consulta por consulta. Una página perfectamente marcada puede no mostrar ningún enriquecimiento durante meses y luego mostrarlo de repente.
Por último, no compensa ningún defecto técnico. Un sitio cuyas páginas tardan cinco segundos en mostrarse tiene un problema que el marcado no soluciona, y que debe tratarse primero, como se detalla en nuestro artículo sobre los Core Web Vitals. El orden de prioridades cuenta: accesibilidad técnica, contenido, arquitectura y luego marcado.
Implementar el marcado en un sitio existente
El método que aplicamos consta de cinco tiempos y suele extenderse de dos a tres días de trabajo para un sitio de tamaño medio.
Primero, inventario: qué plantillas existen, qué marcado se produce ya y mediante qué. Este paso revela casi siempre generaciones automáticas olvidadas, heredadas de una antigua extensión.
Después, limpieza: desactivar las fuentes concurrentes para mantener un solo emisor por tipo. Es el paso que soluciona más problemas y no produce ningún contenido nuevo.
Diseño del grafo: definir los identificadores estables de la organización, del establecimiento y de los autores, de una vez por todas. Estos identificadores se usarán en todas las páginas y no deberán cambiar más.
Implementación por plantilla, empezando por la que cubra más páginas. Un marcado colocado en la plantilla de artículo cubre instantáneamente todo el blog, mientras que un marcado colocado página por página no se termina nunca.
Por último, validación, en las direcciones online y no en el código, y seguimiento mensual en Search Console durante el primer trimestre. Este último paso detecta las regresiones provocadas por las actualizaciones, que son la causa principal de degradación a largo plazo. Forma parte de lo que cubre un contrato de mantenimiento serio.
Una palabra sobre la documentación interna. En los sitios donde intervienen varias personas, escribir una página que describa los identificadores de entidades elegidos y el tipo esperado por plantilla evita que el siguiente desarrollador use otras convenciones. Esta página ocupa media carilla y ahorra horas de desenredo dos años después.
Lo que debes recordar
El JSON-LD declara explícitamente lo que contiene una página para que el motor no tenga que adivinarlo. No hace ganar posiciones, hace ganar superficie y clics, y hace que la empresa sea legible para sistemas automáticos cuya importancia va en aumento.
Tres reglas bastan para evitar casi todos los problemas. No declarar más que lo que es visible en la página. Tener una sola fuente de generación por tipo. Probar la dirección online en lugar del código escrito, porque la diferencia entre ambos es precisamente donde se alojan los errores.
Empieza por BreadcrumbList y FAQPage, que cubren muchas páginas con poco esfuerzo, y luego añade la base de Organization y LocalBusiness. El resto se trata plantilla por plantilla, por orden de número de páginas cubiertas. Es una intervención corta, medible y cuyo efecto se lee en Search Console en pocas semanas.
Una precisión sobre el mantenimiento del marcado. Los tipos y propiedades de Schema.org evolucionan, y las exigencias de Google para el marcado enriquecido cambian aún más rápido: algunos tipos han perdido su elegibilidad, otros la han ganado. Una revisión anual del marcado, alineada con la revisión técnica del sitio, basta para estar al día sin dedicarle un seguimiento permanente. Este control lleva una hora y evita descubrir a posteriori que una visualización ha desaparecido hace seis meses.
