Una p\u00e1gina web es un texto que el motor debe interpretar. Los datos estructurados eliminan esta interpretaci\u00f3n: declaran expl\u00edcitamente que este n\u00famero 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\u00f3n es el JSON-LD, un bloque de c\u00f3digo aislado en la cabecera de la p\u00e1gina, sin efecto en la visualizaci\u00f3n. <\/p>\n
El efecto directo en el ranking es nulo, y hay que decirlo claramente para evitar falsas expectativas. Ning\u00fan marcado hace subir una p\u00e1gina. Lo que produce es un marcado enriquecido en los resultados: estrellas de valoraci\u00f3n, precio, disponibilidad, preguntas desplegables, miga de pan legible, imagen de receta. Este formato ocupa m\u00e1s superficie y atrae m\u00e1s clics a igualdad de posici\u00f3n. <\/p>\n
El efecto indirecto es m\u00e1s profundo. Un sitio correctamente marcado se convierte en una fuente que los sistemas autom\u00e1ticos comprenden sin ambig\u00fcedad, lo cual cuenta cada vez m\u00e1s 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\u00f3n marginal, es la forma en que una organizaci\u00f3n se hace legible. <\/p>\n
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\u00e1gina. Un marcado que declara una informaci\u00f3n ausente en la p\u00e1gina es una infracci\u00f3n de las directrices de Google y te expone a una acci\u00f3n manual. <\/p>\n<\/div>\n
Hist\u00f3ricamente coexisten tres sintaxis para expresar lo mismo. Los microdatos y el RDFa se insertan en el HTML visible, a\u00f1adiendo atributos a las etiquetas existentes. El JSON-LD vive aparte, en un bloque aut\u00f3nomo. <\/p>\n
Google recomienda expl\u00edcitamente el JSON-LD desde hace varios a\u00f1os por una raz\u00f3n pr\u00e1ctica: 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\u00f3n evita que una modificaci\u00f3n editorial rompa el marcado sin que nadie se d\u00e9 cuenta. <\/p>\n
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\u00e1gina produce declaraciones concurrentes y resultados imprevisibles. Un solo formato por p\u00e1gina, y preferiblemente JSON-LD. <\/p>\n
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\u00e1ctica, una decena de tipos cubren casi todas las necesidades de un sitio profesional. <\/p>\n
Organization declara la propia empresa, su nombre, logotipo, datos de contacto y perfiles oficiales. LocalBusiness y sus subtipos precisan el establecimiento f\u00edsico, 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. <\/p>\n
El principio de elecci\u00f3n es sencillo: elige el tipo m\u00e1s preciso que exista. Declarar un restaurante como LocalBusiness funciona, pero declararlo como Restaurant transmite m\u00e1s. Una cl\u00ednica dental gana al usar Dentist en lugar de MedicalBusiness. Esta precisi\u00f3n cuesta el mismo esfuerzo y mejora la comprensi\u00f3n. <\/p>\n
Una p\u00e1gina bien marcada no declara tres bloques independientes, declara un conjunto de entidades conectadas entre s\u00ed. La estructura en grafo permite decir que este art\u00edculo tiene como autor a esta persona, la cual pertenece a esta organizaci\u00f3n, la cual edita este sitio. <\/p>\n
T\u00e9cnicamente, 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\u00f3n de una p\u00e1gina a otra en torno a los mismos identificadores. <\/p>\n
No todos los tipos producen una visualizaci\u00f3n especial. Aqu\u00ed tienes los que dan un resultado visible, por orden de frecuencia en sitios de empresa. <\/p>\n
Declara preguntas y sus respuestas, y permite una visualizaci\u00f3n desplegable bajo el resultado. La ganancia de superficie es clara y el coste de implementaci\u00f3n bajo, ya que el contenido ya existe en la p\u00e1gina. La condici\u00f3n que debes respetar es estricta: cada pregunta y cada respuesta declarada deben ser visibles para el visitante, incluso si est\u00e1n plegadas en un acorde\u00f3n. <\/p>\n
Sustituye la direcci\u00f3n bruta mostrada bajo el t\u00edtulo por una ruta legible. El efecto en el porcentaje de clics es modesto por s\u00ed solo, pero se aplica a todas las p\u00e1ginas del sitio y solo cuesta una generaci\u00f3n autom\u00e1tica desde la estructura. Es el marcado con mejor relaci\u00f3n entre esfuerzo y cobertura. <\/p>\n
Precio, disponibilidad, nota media y n\u00famero de opiniones aparecen directamente en los resultados. El impacto en el porcentaje de clics es el m\u00e1s fuerte de todos los marcados. La restricci\u00f3n es proporcional: las opiniones declaradas deben ser reales, recogidas en el sitio y visibles. Declarar una nota agregada sin opiniones mostradas es una infracci\u00f3n frecuente y sancionada. <\/p>\n
Consolida la entidad ante Google y cruza la informaci\u00f3n de la ficha de establecimiento. No activa una visualizaci\u00f3n espectacular, pero participa en la coherencia de las se\u00f1ales locales, tema detallado en nuestra gu\u00eda de SEO local<\/a>. <\/p>\n <\/p>\n <\/a><\/p>\n La sintaxis es sencilla, los errores son casi siempre l\u00f3gicos m\u00e1s que t\u00e9cnicos.<\/p>\n La primera regla es la correspondencia estricta entre el marcado y la p\u00e1gina. Un precio declarado debe ser el precio mostrado. Una fecha de publicaci\u00f3n declarada debe coincidir con la visible. Esta exigencia parece obvia y se viola constantemente con marcados generados autom\u00e1ticamente a partir de campos mal rellenados. <\/p>\n La segunda regla es la estabilidad de los identificadores. Una entidad conserva el mismo identificador de una p\u00e1gina a otra y de un a\u00f1o a otro. Cambiar el identificador de una organizaci\u00f3n en cada redise\u00f1o equivale a crear una nueva entidad y perder la consolidaci\u00f3n acumulada. <\/p>\n 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\u00e1 que mantener. Valen m\u00e1s cinco tipos bien rellenados que quince tipos incompletos. <\/p>\n 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\u00ednea codificarse. Un ampersand no tratado o una ap\u00f3strofe tipogr\u00e1fica mal codificada bastan para invalidar todo el bloque, y el fallo es silencioso: el motor simplemente ignora el marcado. <\/p>\n La validaci\u00f3n es el paso que todo el mundo se salta y el que revela la mitad de los problemas.<\/p>\n 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\u00f3n enriquecida, con las propiedades que Google exige adem\u00e1s de las que Schema.org autoriza. <\/p>\n Ambas son complementarias y un marcado puede pasar la primera fallando en la segunda. Utilizar las dos evita concluir demasiado r\u00e1pido que un marcado es correcto porque no aparece ning\u00fan error de sintaxis. <\/p>\n Es la precauci\u00f3n m\u00e1s importante y la m\u00e1s descuidada. Pegar tu c\u00f3digo en el validador prueba lo que has escrito. Probar la direcci\u00f3n online prueba lo que el servidor env\u00eda realmente, tras el paso de las extensiones, la cach\u00e9 y las posibles reescrituras. La diferencia entre ambos es frecuente, y es precisamente ah\u00ed donde se esconden los duplicados de declaraci\u00f3n. <\/p>\n Search Console proporciona despu\u00e9s un seguimiento en el tiempo, por tipo de marcado, con los errores detectados en el conjunto de las p\u00e1ginas rastreadas. Es el \u00fanico lugar donde ves que un problema afecta a cuatrocientas fichas de producto y no solo a la que has probado. <\/p>\n Seis errores se repiten en casi todas las auditor\u00edas que realizamos.<\/p>\n Ninguno de estos errores es dif\u00edcil de corregir. Persisten porque nadie mira el marcado una vez colocado, a pesar de que vive y se degrada como el resto del sitio. <\/p>\n Las prioridades difieren seg\u00fan la actividad. Esto es lo que instalamos sistem\u00e1ticamente seg\u00fan el perfil. <\/p>\n Organization para la entidad, LocalBusiness si un establecimiento recibe p\u00fablico, Service para cada prestaci\u00f3n con su zona de servicio, BreadcrumbList en todas partes, FAQPage en las p\u00e1ginas que las incluyan, y Person para el autor de los contenidos editoriales. Esta base cubre lo esencial y se genera desde la plantilla. <\/p>\n Product en cada ficha, con Offer para el precio y la disponibilidad, AggregateRating si existen opiniones reales, BreadcrumbList en la ruta de categor\u00edas, y Organization a nivel del sitio. El punto de atenci\u00f3n es la generaci\u00f3n autom\u00e1tica en miles de fichas: un error de plantilla se replica instant\u00e1neamente en todas partes. <\/p>\n Article o BlogPosting seg\u00fan la naturaleza, con autor identificado, fechas de publicaci\u00f3n y modificaci\u00f3n, e imagen. La declaraci\u00f3n del autor merece un cuidado especial porque participa directamente en las se\u00f1ales de experiencia, tema que tratamos en la prestaci\u00f3n de posicionamiento natural<\/a>. <\/p>\n El comercio concentra a la vez el mayor potencial de marcado enriquecido y el mayor riesgo de error masivo. Una declaraci\u00f3n de producto falsa no afecta a una p\u00e1gina, afecta a la totalidad del cat\u00e1logo en una sola subida. <\/p>\n El precio declarado debe coincidir con el precio efectivamente pagado, impuestos incluidos para clientes particulares, y la divisa debe ser expl\u00edcita. Las tiendas que muestran un precio sin impuestos en la fachada y declaran el mismo importe en su marcado producen resultados enga\u00f1osos que acaban siendo reportados. <\/p>\n La disponibilidad plantea un problema de sincronizaci\u00f3n. Un producto agotado que sigue declar\u00e1ndose disponible genera frustraci\u00f3n y degrada la confianza otorgada al dominio. La declaraci\u00f3n debe conectarse al estado real del stock, no a un valor fijo en la plantilla. <\/p>\n Por \u00faltimo, las variantes. Un producto con varias tallas o colores puede declararse como una entidad \u00fanica con un rango de precios, o como varias entidades distintas. La elecci\u00f3n depende de la estructura de direcciones elegida, que a su vez depende de la plataforma, tema tratado en nuestra comparativa WordPress o Shopify<\/a>. Ambos enfoques funcionan, mezclarlos en un mismo cat\u00e1logo no. <\/p>\n En cat\u00e1logos 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\u00e1pido como se propag\u00f3, pero hay que verlo. Es uno de los puntos de control de una prestaci\u00f3n de SEO e-commerce<\/a>. <\/p>\n Una observaci\u00f3n de m\u00e9todo v\u00e1lida 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\u00f3n arreglar\u00e1 una jerarqu\u00eda mal pensada. <\/p>\n Por eso tratamos el marcado en el momento en que se dise\u00f1a la arquitectura, con la misma l\u00f3gica expuesta en nuestro m\u00e9todo de cocoon sem\u00e1ntico<\/a>. Los identificadores de entidades, las relaciones entre p\u00e1ginas pilares y p\u00e1ginas hijas, la jerarqu\u00eda de categor\u00edas: todo eso se decide una vez y luego se traduce mec\u00e1nicamente al marcado. <\/p>\n En un proyecto nuevo, esta exigencia se formaliza en el pliego de condiciones del sitio web<\/a>, al igual que los umbrales de rendimiento. Entonces cuesta unas pocas horas. A\u00f1adida despu\u00e9s del lanzamiento, supone volver a cada plantilla y verificar cada tipo, lo que representa varios d\u00edas. <\/p>\n El caso de los sitios multiling\u00fces merece una menci\u00f3n. Cada versi\u00f3n ling\u00fc\u00edstica lleva su propio marcado, con el idioma declarado e identificadores de entidad compartidos entre las versiones. La organizaci\u00f3n sigue siendo la misma entidad independientemente del idioma, lo que la declaraci\u00f3n debe reflejar; de lo contrario, el motor ve cuatro organizaciones distintas con el mismo nombre. <\/p>\n La pregunta del presupuesto siempre llega, y la respuesta depende sobre todo del n\u00famero de plantillas, no del n\u00famero de p\u00e1ginas.<\/p>\n En un sitio de servicios cl\u00e1sico, cuenta con un d\u00eda para el inventario y la limpieza, un d\u00eda para dise\u00f1ar el grafo y asentar la base, y medio d\u00eda por cada plantilla espec\u00edfica restante. Un sitio web corporativo de veinte p\u00e1ginas con tres plantillas se gestiona en dos o tres d\u00edas. <\/p>\n En una tienda, a\u00f1ade la plantilla de producto y la de categor\u00eda, m\u00e1s el tiempo de verificaci\u00f3n en una muestra representativa. El cat\u00e1logo en s\u00ed no cambia el coste ya que el marcado se genera, lo que explica que una tienda de ochocientas referencias no cueste m\u00e1s de marcar que una de cincuenta. <\/p>\n Este presupuesto es modesto en relaci\u00f3n 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<\/a> salen todos con esta base instalada, lo que evita tener que volver a ello. <\/p>\n Una aclaraci\u00f3n \u00fatil, porque el tema atrae promesas excesivas.<\/p>\n El marcado no hace subir una p\u00e1gina en los resultados. Una p\u00e1gina mal escrita, en un sitio lento y sin autoridad, se quedar\u00e1 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\u00f3n. <\/p>\n Tampoco garantiza la visualizaci\u00f3n enriquecida. La elegibilidad es una condici\u00f3n necesaria, pero la visualizaci\u00f3n sigue siendo una decisi\u00f3n de Google tomada consulta por consulta. Una p\u00e1gina perfectamente marcada puede no mostrar ning\u00fan enriquecimiento durante meses y luego mostrarlo de repente. <\/p>\n Por \u00faltimo, no compensa ning\u00fan defecto t\u00e9cnico. Un sitio cuyas p\u00e1ginas tardan cinco segundos en mostrarse tiene un problema que el marcado no soluciona, y que debe tratarse primero, como se detalla en nuestro art\u00edculo sobre los Core Web Vitals<\/a>. El orden de prioridades cuenta: accesibilidad t\u00e9cnica, contenido, arquitectura y luego marcado. <\/p>\n El m\u00e9todo que aplicamos consta de cinco tiempos y suele extenderse de dos a tres d\u00edas de trabajo para un sitio de tama\u00f1o medio.<\/p>\n Primero, inventario: qu\u00e9 plantillas existen, qu\u00e9 marcado se produce ya y mediante qu\u00e9. Este paso revela casi siempre generaciones autom\u00e1ticas olvidadas, heredadas de una antigua extensi\u00f3n. <\/p>\n Despu\u00e9s, limpieza: desactivar las fuentes concurrentes para mantener un solo emisor por tipo. Es el paso que soluciona m\u00e1s problemas y no produce ning\u00fan contenido nuevo. <\/p>\n Dise\u00f1o del grafo: definir los identificadores estables de la organizaci\u00f3n, del establecimiento y de los autores, de una vez por todas. Estos identificadores se usar\u00e1n en todas las p\u00e1ginas y no deber\u00e1n cambiar m\u00e1s. <\/p>\n Implementaci\u00f3n por plantilla, empezando por la que cubra m\u00e1s p\u00e1ginas. Un marcado colocado en la plantilla de art\u00edculo cubre instant\u00e1neamente todo el blog, mientras que un marcado colocado p\u00e1gina por p\u00e1gina no se termina nunca. <\/p>\n Por \u00faltimo, validaci\u00f3n, en las direcciones online y no en el c\u00f3digo, y seguimiento mensual en Search Console durante el primer trimestre. Este \u00faltimo paso detecta las regresiones provocadas por las actualizaciones, que son la causa principal de degradaci\u00f3n a largo plazo. Forma parte de lo que cubre un contrato de mantenimiento<\/a> serio. <\/p>\n Una palabra sobre la documentaci\u00f3n interna. En los sitios donde intervienen varias personas, escribir una p\u00e1gina que describa los identificadores de entidades elegidos y el tipo esperado por plantilla evita que el siguiente desarrollador use otras convenciones. Esta p\u00e1gina ocupa media carilla y ahorra horas de desenredo dos a\u00f1os despu\u00e9s. <\/p>\n El JSON-LD declara expl\u00edcitamente lo que contiene una p\u00e1gina 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\u00e1ticos cuya importancia va en aumento. <\/p>\n Tres reglas bastan para evitar casi todos los problemas. No declarar m\u00e1s que lo que es visible en la p\u00e1gina. Tener una sola fuente de generaci\u00f3n por tipo. Probar la direcci\u00f3n online en lugar del c\u00f3digo escrito, porque la diferencia entre ambos es precisamente donde se alojan los errores. <\/p>\n Empieza por BreadcrumbList y FAQPage, que cubren muchas p\u00e1ginas con poco esfuerzo, y luego a\u00f1ade la base de Organization y LocalBusiness. El resto se trata plantilla por plantilla, por orden de n\u00famero de p\u00e1ginas cubiertas. Es una intervenci\u00f3n corta, medible y cuyo efecto se lee en Search Console en pocas semanas. <\/p>\n Una precisi\u00f3n sobre el mantenimiento del marcado. Los tipos y propiedades de Schema.org evolucionan, y las exigencias de Google para el marcado enriquecido cambian a\u00fan m\u00e1s r\u00e1pido: algunos tipos han perdido su elegibilidad, otros la han ganado. Una revisi\u00f3n anual del marcado, alineada con la revisi\u00f3n t\u00e9cnica del sitio, basta para estar al d\u00eda sin dedicarle un seguimiento permanente. Este control lleva una hora y evita descubrir a posteriori que una visualizaci\u00f3n ha desaparecido hace seis meses. <\/p>\nEscribir un marcado limpio, las reglas que evitan errores<\/h2>\n
Validar, y sobre todo validar el renderizado correcto<\/h2>\n
Las dos herramientas a utilizar, en este orden<\/h3>\n
Probar la URL online, no el c\u00f3digo pegado<\/h3>\n
Los errores de marcado m\u00e1s frecuentes<\/h2>\n
\n
El marcado por tipo de sitio<\/h2>\n
Sitio de prestaci\u00f3n de servicios<\/h3>\n
Tienda online<\/h3>\n
Sitio editorial y blog<\/h3>\n
El marcado en una tienda online, caso particular<\/h2>\n
El marcado se decide con la arquitectura, no despu\u00e9s<\/h2>\n
Lo que cuesta un marcado completo<\/h2>\n
Lo que el marcado no har\u00e1 por ti<\/h2>\n
Implementar el marcado en un sitio existente<\/h2>\n
Lo que debes recordar<\/h2>\n
Preguntas frecuentes<\/h2>\n
\n