Hay una diferencia entre que un modelo de IA infiera quién sos y que vos se lo declares. Esa diferencia se llama JSON-LD, y es probablemente el artefacto técnico más subestimado en toda la conversación sobre GEO.
Todos hablan de contenido. De prompts. De “aparecer en ChatGPT”. Casi nadie habla del bloque de código que decide si el modelo entiende tu empresa o la confunde con otra. Vamos a eso.
Qué es JSON-LD, sin vueltas
JSON-LD (JavaScript Object Notation for Linked Data) es un formato estándar de datos estructurados, basado en el vocabulario de schema.org, que se inserta en el código de tu sitio para declararle explícitamente a las máquinas qué es cada cosa: qué organización sos, a qué te dedicás, qué productos ofrecés, qué preguntas frecuentes respondés.
No es contenido visible. El usuario humano no lo ve. Vive en el <head> o el <body> de tu página como un bloque que solo leen los parsers: buscadores, crawlers, y ahora los modelos generativos.
Los buscadores lo usan desde hace años, es lo que genera los rich results de Google, las estrellitas de reviews, los FAQ desplegables en los resultados. Eso ya lo sabías si venís de SEO. Lo nuevo es que los LLMs lo aprovechan para entender la entidad detrás del sitio sin tener que adivinarla del texto.
Por qué importa ahora (y no importaba tanto antes)
Acá está el cambio de fondo. Un buscador tradicional te manda tráfico: el usuario busca, ve links, clickea, llega a tu sitio, y tu sitio se explica a sí mismo. Tenías una segunda oportunidad , la página entera de hecho, para que la persona entendiera quién sos.
Un motor generativo no funciona así. Responde directo. Solo 1% de usuarios clickea links dentro de respuestas AI (Pew Research, 2025). Eso significa que el modelo te describe a vos, con sus palabras, sin que el usuario llegue nunca a tu home. Si el modelo entendió mal quién sos, no tenés una segunda oportunidad para corregirlo. La respuesta ya se dio.
Y los modelos entienden mal seguido. 62% de marcas son invisibles para modelos AI (Fuel Online, 2026). Invisible no siempre significa que no apareciste, si no que a veces significa que apareciste tan ambiguo que el modelo no supo qué hacer con vos.
Pensalo desde el parser. Un humano entra a tu home y entiende en tres segundos: “esto es una empresa de logística B2B en México que hace ruteo de última milla”. Lo entiende por el diseño, el logo, las fotos, el tono, el contexto visual. El parser no ve nada de eso. El parser ve HTML. Si en ese HTML no está escrito, en un formato que pueda extraer, “organización: X / industria: logística / región: México / producto: ruteo última milla”, entonces para el modelo sos texto suelto del que tiene que inferir. Y la inferencia falla.
JSON-LD es el lugar donde dejás de depender de la inferencia.
La asimetría que casi nadie ve
Esto es lo que hace a JSON-LD particularmente desigual en B2B, y por qué tu competidor que lo implementó tiene una ventaja que vos no estás midiendo.
En B2C, las categorías son obvias. “Zapatillas para correr”, “café en grano”, “hotel en Cancún” — el modelo tiene millones de ejemplos de entrenamiento, entiende la categoría sin ayuda. En B2B la categoría es angosta, técnica, a veces nueva. “Plataforma de reconciliación de pagos para fintech”, “software de trazabilidad para agroexportación”, “GEO intelligence engine”. El modelo tiene mucho menos con qué anclarte. Tu margen de ambigüedad es enorme.
En ese margen, el que declara gana. Si vos dejás que el modelo infiera y tu competidor declara explícitamente vía structured data qué es, qué hace y para quién, el competidor le dio al modelo una respuesta limpia y vos le diste un acertijo. El modelo va a elegir lo que entiende.
Eso es lo más contraintuitivo de GEO: la ventaja no siempre se la lleva el que tiene mejor contenido, sino el que es más fácil de parsear.
Lo que JSON-LD le declara a un LLM (los tres bloques que importan en B2B)
No todo schema sirve igual. Para una empresa B2B, tres tipos de declaración hacen el trabajo pesado:
La organización. Quién sos como entidad: nombre, qué hacés, dónde operás, con qué otras entidades te relacionás. Es la base. Es la diferencia entre que el modelo sepa que “Clicon” es una empresa de GEO para LATAM y que crea que es un typo de otra cosa.
Los productos o servicios. Qué vendés, declarado como entidad propia y no escondido en un párrafo de marketing. En B2B esto importa el doble porque tus productos suelen tener nombres propios que el modelo no conoce (“Lotus”, “el módulo de X”) y necesita que se los expliques.
Las preguntas frecuentes. Acá está el oro que casi nadie aprovecha en B2B. Cuando un usuario le pregunta a ChatGPT “¿qué herramienta uso para X?”, está haciendo, en esencia, una pregunta frecuente de tu categoría. Si vos tenés esas preguntas declaradas en structured data, con tus respuestas, le estás dando al modelo material exacto para citarte cuando esa pregunta aparece.
No es magia. Es lógica de máquina: el modelo prefiere la fuente que ya viene estructurada en el formato de la pregunta.
El error que vas a cometer (y por qué no alcanza con instalarlo)
Acá viene la parte incómoda para el que ya tiene algo de schema puesto.
Tener JSON-LD no es lo mismo que tener JSON-LD que refleje la verdad de tu negocio hoy. La mayoría de los sitios B2B que tienen structured data lo pusieron una vez, con un plugin, en 2021, declarando cosas genéricas. El negocio cambió. Salieron productos nuevos. La categoría se redefinió. El schema quedó congelado describiendo una empresa que ya no existe.
Y peor: tu competencia se mueve. Si tu competidor actualizó su declaración de entidad la semana pasada para capturar la categoría nueva donde vos también jugás, vos no te enteraste. No aparece en tu analytics. No baja un ranking. Simplemente, de a poco, el modelo empieza a citarlo a él para las preguntas que antes eran territorio compartido.
JSON-LD no es un artefacto que instalás una vez. Es un artefacto que tenés que mantener calibrado contra lo que el modelo entiende y contra lo que tu competencia declara. Esa segunda parte —saber qué declaró tu competidor y cuándo— es información que no vas a sacar de un plugin de WordPress.
Cómo encaja esto con tu SEO
Una aclaración necesaria, porque siempre aparece la pregunta: GEO no reemplaza SEO. Lo complementa. SEO te posiciona en Google; GEO asegura que los LLMs te citen. Y JSON-LD es uno de los pocos artefactos que trabaja para los dos a la vez — el mismo bloque de structured data que mejora tus rich results en el buscador es el que le declara tu entidad al modelo generativo.
Es de las pocas inversiones técnicas en esta categoría que no te obliga a elegir entre el mundo viejo y el nuevo. Sirve para ambos.
El paso que falta
Entender qué es JSON-LD y por qué importa es el 20% del trabajo. El 80% es generar el código correcto para tu entidad, tus productos y tu categoría y mantenerlo vivo mientras el mercado se mueve.
Eso es exactamente lo que hace Lotus. No te entrega un PDF con recomendaciones de “implementá structured data”. Genera el código ejecutable, calibrado contra tu negocio real y contra lo que tu competencia está declarando, listo para deployar. Y mide, en USD, cuánto revenue estás dejando sobre la mesa mientras tu entidad sigue siendo un acertijo para los modelos.
Si querés ver tu caso concreto: lo corremos sobre tu dominio real, te mostramos tu bleed en USD y los artefactos listos para deployar.
GEO (Generative Engine Optimization) es la disciplina de optimizar un sitio para que los motores generativos —ChatGPT, Gemini, Perplexity, Claude, Google AI Overviews— lo citen en sus respuestas. Es a los LLMs lo que SEO es a los buscadores: no lo reemplaza, lo complementa. Clicon construye Lotus, el AI Revenue Protection Engine nativo para LATAM y en español.