Cómo dejamos de tratar JSON-LD como una «sopa» de SEO y construimos una capa de conocimiento legible por máquinas para LLMs
Acabábamos de implementar lo que parecía un despliegue impecable de Schema.org para un cliente B2B de hardware. Cada validador mostraba marcas verdes. Google Search Console no reportaba ni un solo error y otorgaba rich snippets en todo el catálogo.
Luego hice una prueba en ChatGPT-4o, pidiéndole una comparativa de las especificaciones de su bomba industrial insignia.
Fracaso absoluto.
Alucinó la mitad de las tolerancias técnicas y extrajo las condiciones de garantía de la competencia. Estábamos tratando a los LLM como a los motores de búsqueda tradicionales, y nos estalló en la cara.
Por qué la tokenización destruye los formatos complejos
El problema de fondo es este:
Los LLM no leen páginas web. Leen tokens.
Cuando un bot de IA rastrea tu sitio, no ve un script JSON-LD perfectamente anidado como lo muestra un visor DOM. Despoja toda la elegancia estructural y descompone los caracteres en tokens de subpalabras.
Volcamos el marcado estándar de Schema.org en la página, asumiendo que la IA mantendría las jerarquías anidadas entre entidades de producto vinculadas.
No lo hizo.
En cambio, la tokenización aplanó esas relaciones explícitas. El modelo reconoció los términos aislados, pero perdió la lógica de predicados entre los nodos. Se convirtió en una sopa estadística.
Es como entregarle a alguien un glosario alfabético y esperar que deduzca la trama de un manual técnico.
El marcado SEO tradicional ya no es suficiente. Si el modelo no puede preservar las relaciones de entidades tras la tokenización, tus datos estructurados no sirven para nada.
Sinceramente, estoy harto de los consejos que dicen «añade más schema». Apilar plugins genéricos de SEO no va a resolver la degradación estructural durante la ingesta de tokens.
Si el LLM no puede reconstruir esas relaciones exactas a partir del flujo de bytes sin procesar, tu marca simplemente no existe en la respuesta generativa.
Por qué Schema.org tradicional falla en la optimización para motores generativos (GEO)
¿Realmente utilizan los LLM el esquema JSON-LD?
Los modelos de lenguaje actuales dependen de los datos estructurados JSON-LD cuando se combinan con marcos de razonamiento y grafos de conocimiento para extraer relaciones precisas entre entidades sin alucinar el contexto técnico.
Sí, los modelos de IA procesan datos estructurados. Pero no los consumen como un rastreador tradicional que construye un índice invertido.
La mayoría de los equipos tratan Schema.org como una simple lista de verificación: ponen una etiqueta de Article, meten un bloque de FAQ y rezan para obtener rich snippets. Eso funcionaba en Google hace años. Para la optimización de motores generativos hoy en día, está roto.
Los modelos no navegan por tu web buscando código estético. Minan conexiones explícitas entre nodos.
Incluso cuando los equipos de desarrollo entienden que los modelos leen schema, se sabotean con implementaciones sobrecargadas.
El conflicto de plugins: duplicación y sobrecarga
Pasé 3 horas anoche auditando un e-commerce enterprise con más de 15.000 referencias que no entendía por qué Perplexity ignoraba las especificaciones clave de sus productos.
¿Qué encontré? Un caos total en el código fuente.
Tenían tres plugins de WordPress activos al mismo tiempo: uno para metadatos globales, otro para reseñas automatizadas y un complemento antiguo de comercio electrónico. Cada uno inyectaba su propio bloque @context sin coordinar. Una sola página de producto servía tres definiciones contradictorias de @type: Organization y nodos de producto duplicados con monedas diferentes.
Debido a los bucles repetitivos de schema en variantes relacionadas, el payload de JSON-LD superaba los 400 KB antes de que el rastreador llegara al contenido real del cuerpo.
El problema es evidente: los rastreadores de IA son implacables con los límites de tokens y los tiempos de espera. Cuando un agente autónomo se topa con medio megabyte de JSON redundante, corta la carga útil o la descarta como ruido sin procesar.
Y eso nos lleva directo al problema de fondo:
La mayoría de los rastreadores de IA no ejecutan JavaScript del lado del cliente.
Si aplicas lazy loading a las opiniones de clientes o paginas señales de confianza con scripts dinámicos al final de la página, el bot de IA solo ve un cascarón vacío. El rastreador tradicional de Google podría renderizar scripts de cliente en una cola secundaria. Un bot de LLM bajo demanda que ejecuta recuperación en tiempo real no va a esperar.
Si los datos no están fijados en HTML estático y determinista desde el primer byte, la máquina no los detecta.
El cambio de paradigma: los datos estructurados como capa de conocimiento
Durante una década, tratamos JSON-LD como un truco visual. Añadías un fragmento de código, cruzabas los dedos y esperabas que Google mostrara estrellitas o un menú de FAQ en la SERP. Era un parche cosmético.
Esa etapa terminó.
Hoy, los datos estructurados no son un generador de resultados enriquecidos. Son la capa de conocimiento base para los modelos de lenguaje.
Cuando un motor de IA evalúa tu web, no busca imágenes de cabecera en alta resolución. Quiere hechos sin ambigüedades: nodos directos, propiedades validadas y relaciones concretas. Si confías solo en texto en lenguaje natural, obligas al modelo a adivinar tu significado mediante probabilidad estadística.
Más allá de la Generación Aumentada por Recuperación (RAG)
Muchos asumen que los pipelines RAG resuelven todo. Creen que basta con volcar posts desestructurados en una base de datos vectorial, aplicar similitud de coseno, recuperar los mejores fragmentos y dejar que el LLM se las arregle.
Falla constantemente.
Hicimos un benchmark directo: comparamos un pipeline RAG vectorial estándar frente a un grafo de conocimiento JSON-LD limpio y modelado por entidades, respondiendo consultas complejas sobre un catálogo B2B especializado.
La configuración RAG vectorial fue imprecisa. Extrajo fragmentos rotos, mezcló niveles de precios entre números de modelo parecidos y alucinó especificaciones porque el texto narrativo era ambiguo.
Luego le pasamos al modelo el grafo JSON-LD limpio.
Cero alucinaciones. Resolución de entidades instantánea. El modelo entendió jerarquías exactas, atributos anidados y relaciones entre productos sin gastar tokens de contexto innecesarios.
La similitud vectorial encuentra texto relevante, pero los datos estructurados entregan contexto legible por máquinas. RAG le da al LLM los ingredientes crudos; una estructura JSON-LD correcta le entrega el plano final de la obra. Si quieres que una IA cite tu marca con precisión absoluta, deja de alimentarla con bloques de texto caóticos y empieza a construir tu capa de conocimiento dentro de tu código.
El framework JSON-LD exacto que usamos para visibilidad en IA
¿Cómo comprobar si los LLM ven tu JSON Schema?
Para verificar si tu JSON Schema es visible para los LLM, debes analizar directamente los archivos de log de tu servidor e identificar los user-agents de rastreadores de IA (como GPTBot o ClaudeBot). Confirma que descargan con éxito el HTML estático que contiene tu bloque JSON-LD integrado, en lugar de confiar en Google Search Console, que solo mide la indexación tradicional.
Google Search Console no te dice nada sobre si los bots de OpenAI o Anthropic procesaron tu esquema de Organization. GSC solo rastrea Googlebot y las funciones clásicas de la SERP.
Nosotros ignoramos GSC para esto y creamos filtros automatizados en los logs para aislar peticiones de GPTBot, ClaudeBot y PerplexityBot. No monitoreamos el estado de indexación; monitoreamos la carga útil descargada.
Si el bot obtenía el HTML estático y esa respuesta contenía nuestro grafo JSON-LD consolidado, los datos se procesaban. ¿Si el JSON-LD se inyectaba vía JavaScript tras la hidratación del cliente? El bot registraba un 200 OK, leía un espacio en blanco y se marchaba.
Estructuración de Organization y FAQPage Schema para IA
Para que tu entidad aparezca sin fallos en motores generativos, necesitas una estructura determinista. Volcar todos los tipos de Schema disponibles en una sola página solo genera ruido.
Este es el patrón estructural que desplegamos:
- Organization Schema (El ancla): Inyectado globalmente en todo el dominio. Establece la identidad de la entidad, indicando al LLM quién habla y enlazando la entidad con IDs verificados de Wikidata y perfiles de autoridad externos mediante
sameAs. - Article / TechArticle Schema (El contexto): Sin texto innecesario. Priorizamos
author,datePublishedy matrices explícitas deabout/mentionsque vinculan los temas de la página con nodos de entidad definidos. - FAQPage Schema (La fuente directa): Los LLM procesan formatos de preguntas y respuestas deterministas con enorme fidelidad. Mapeamos especificaciones y parámetros técnicos como pares de Question/Answer dentro del JSON-LD.
La entrega del código es donde tropiezan casi todos los equipos de ingeniería.
No puedes depender del renderizado en cliente para los bots de IA.
Lo aprendimos por las malas con un cliente cuyo esquema de FAQ se montaba dinámicamente mediante React. Los rastreadores de IA leían la respuesta inicial del servidor y jamás ejecutaban el script del cliente.
La regla es directa: tu payload JSON-LD debe estar renderizado estáticamente en la respuesta HTML inicial desde el byte cero. Sin hidratación diferida ni inyecciones en cliente.
Deja de optimizar para Google, empieza a diseñar para entidades
El SEO tradicional está tocando techo. Centrarse solo en los enlaces azules ignora cómo opera la recuperación de información hoy. La transición operativa apunta a la comunicación máquina a máquina (M2M).
La realidad es clara: los compradores ya no hacen clic en tu sitio cuando un agente de IA sintetiza la respuesta completa, compara opciones y resuelve la intención directo en la interfaz. Si ese agente no puede verificar tus atributos y relaciones mediante marcado determinista, tu marca simplemente queda fuera de la respuesta.
El futuro del SEO M2M
Cuando el schema se trata como algo secundario—un script decorativo pegado sobre árboles DOM saturados—se agotan las ventanas de contexto. Procesar ruido de tokens desorganizados aumenta la latencia y obliga a los modelos a depender de probabilidades estadísticas en lugar de datos duros.
Si un bot de IA tiene que adivinar las relaciones de tus entidades a partir de texto desestructurado, alucinará citando a un competidor.
En AnswerShaper no tratamos el schema como un añadido de SEO, sino como una API explícita para modelos autónomos. Al mapear grafos densos e interconectados dentro del código estático, eliminas la ambigüedad y entregas datos verificados con una fracción del coste en tokens.
Si tu estrategia SEO no contempla la comunicación M2M, estás optimizando para un entorno que está desapareciendo. O estás dentro del prompt, o no existes. Construye tu capa de conocimiento legible por máquinas en tu infraestructura ahora o asume la invisibilidad en la web generativa. Conoce a fondo nuestro método en How We Stopped Burning Tokens and Mastered Knowledge Graph Optimization for AI para ver cómo diseñamos nuestra arquitectura de entidades.