Construí un sistema que genera automáticamente un Knowledge Graph con JSON-LD en cada post de este blog. Cinco entidades conectadas: WebSite, Organization, Person, WebPage y BlogPosting. Detección automática de temas, relaciones entre posts, traducciones en tres idiomas. Todo en una función PHP que corre en cada carga de página.

Quería saber qué tan bien funciona desde la perspectiva de los modelos de IA que lo leen. Así que copié el bloque JSON-LD de un post publicado y se lo pasé a tres modelos con el mismo prompt, palabra por palabra. Pedí un score de 1 a 10 para visibilidad de citación por IA, qué está bien implementado, qué falta y qué debería cambiar.

Gemini dio 9 de 10. ChatGPT dio 8.2 de 10. Perplexity dio 7.5 de 10.

El mismo schema. El mismo prompt. Tres evaluaciones diferentes.

En qué coincidieron las tres

Las tres confirmaron que la arquitectura @graph con entidades conectadas por @id es correcta. No es el enfoque que la mayoría de tutoriales de JSON-LD enseñan (objetos anidados sin identificadores), pero es el que los sistemas de knowledge graph prefieren. Cada entidad tiene un @id persistente que se reutiliza en todas las páginas del sitio. Cuando una máquina lee la página principal y luego un post, reconoce al mismo autor, la misma organización, el mismo sistema de conocimiento.

Las tres también validaron la separación entre about y mentions. about declara los temas principales del artículo. mentions declara herramientas y referencias que aparecen en el contenido. Esta distinción ayuda a los modelos de IA a categorizar correctamente. Un artículo sobre Knowledge Graph que menciona a Claude no debería ser categorizado bajo Claude.

La propiedad workTranslation que conecta las versiones en español, inglés y japonés también recibió aprobación unánime. La mayoría de sitios multilingües tratan cada idioma como una isla separada. Las traducciones conectadas consolidan la autoridad en vez de fragmentarla.

Lo que las tres marcaron como problema

Cuatro problemas aparecieron en las tres auditorías.

Primero, la contaminación del headline. El título incluía "| Shinobis" al final. Gemini y ChatGPT lo marcaron explícitamente: el nombre del sitio pertenece al tag HTML title para navegadores, no a la propiedad headline del schema. Los modelos de IA usan el headline para matching semántico. Un nombre de marca al final agrega ruido sin información.

Segundo, la confusión Person versus Organization. El sameAs de la entidad Person apuntaba a la página de LinkedIn de la empresa en vez de un perfil personal. Las tres auditorías lo detectaron. Si la Person y la Organization comparten el mismo perfil de LinkedIn, los sistemas de knowledge graph no pueden distinguir las dos entidades. La solución es usar el perfil personal de LinkedIn para la Person y el perfil de empresa para la Organization.

Tercero, el nombre de la entidad Person. ChatGPT y Perplexity sugirieron invertir los nombres: usar "Diego Sanchez" como name y "Shinobis" como alternateName. La razón: la Organization ya se llama "Shinobis". Si la Person también se llama "Shinobis", los knowledge graphs no pueden resolver la ambigüedad. El humano es el nombre real. El alias es el alternativo.

Cuarto, la estadística de interacción. El schema incluía interactionStatistic con un conteo de 2 likes. ChatGPT y Perplexity lo marcaron como potencialmente dañino: un número bajo puede señalar baja autoridad en vez de engagement. La recomendación fue eliminar la propiedad hasta tener números significativos.

Donde divergieron

Aquí es donde se pone interesante. Cada modelo priorizó aspectos diferentes.

Gemini se enfocó en la propiedad audience y en hasPart para secciones del artículo. Su perspectiva: los sistemas RAG (Retrieval-Augmented Generation) necesitan saber para quién es el contenido cuando los usuarios hacen preguntas específicas por rol. "¿Qué debería hacer un diseñador UX sobre GEO?" es una consulta diferente de "¿Qué debería hacer un SEO sobre GEO?" La propiedad audience ayuda al modelo a decidir cuál servir.

ChatGPT se enfocó en la tipificación de entidades. El feedback más fuerte fue sobre los objetos Thing anónimos. Cada entidad about y mentions era un Thing genérico con solo un name. ChatGPT sugirió cambiar a DefinedTerm con sameAs apuntando a Wikipedia. "Knowledge Graph" como Thing es una cadena de texto. "Knowledge Graph" como DefinedTerm con sameAs a Wikipedia es un concepto identificable que los modelos pueden resolver contra su propia base de conocimiento. También propuso crear @id persistentes para cada concepto (como /entity/geo) y reutilizarlos en todos los posts y todos los idiomas.

Perplexity fue el más granular. Pidió affiliation explícita conectando Person con Organization, hasOccupation estructurado en vez de solo jobTitle, timeRequired para que los modelos evalúen la profundidad del contenido, y señaló que author y publisher dentro de BlogPosting deberían usar referencias @id en vez de objetos inline. El punto sobre @id versus inline es técnicamente correcto: las referencias @id son más limpias para resolución de grafos. Pero Google Rich Results Test a veces no resuelve referencias @id, por lo que el enfoque actual (ambos: @id más propiedades inline como fallback) es intencional.

Lo que implementé

De las tres auditorías combinadas, implementé seis cambios.

Limpié el headline eliminando "| Shinobis" de la propiedad. El nombre del sitio se mantiene en el browser_title del HTML pero no contamina el schema.

Separé los perfiles de sameAs. La Person ahora apunta a perfiles personales. La Organization apunta a perfiles de empresa.

Invertí los nombres. name es "Diego Sanchez", alternateName es "Shinobis".

Eliminé interactionStatistic hasta que los números sean significativos.

Agregué la propiedad citation con enlaces a las fuentes que cada post referencia. Los tres modelos la pidieron. Es la señal de confianza más fuerte que faltaba.

Agregué audience con los roles específicos para los que cada post es relevante.

Lo que descarté

Tres sugerencias no implementé.

La entidad Blog conectando los 52 posts. ChatGPT y Perplexity la pidieron. Es técnicamente correcta pero agrega complejidad significativa al generador PHP. Cada post tendría que incluir los @id de los 52 artículos. En un blog que crece cada semana, eso significa regenerar el schema de todos los posts existentes cada vez que se publica uno nuevo. El beneficio no justifica la complejidad por ahora.

BreadcrumbList. Los tres la mencionaron. Es útil para navegación pero mi blog tiene una estructura plana (no hay categorías jerárquicas). Un breadcrumb de Home > Blog > Artículo no agrega información que el schema existente no tenga.

DefinedTerm con @id persistentes para cada concepto. La idea de ChatGPT es brillante en teoría: crear /entity/geo como un @id que se reutiliza en todos los posts y todos los idiomas. En la práctica, requiere un sistema de gestión de entidades que no tengo. Es una mejora para el futuro, no para ahora.

Qué revela la diferencia de puntajes

Gemini dio el puntaje más alto (9/10) y fue el menos detallado en las mejoras. ChatGPT dio 8.2/10 con el feedback más arquitectónico. Perplexity dio 7.5/10 con el feedback más granular y técnico.

La diferencia no significa que uno sea mejor auditor que otro. Significa que evalúan con criterios diferentes. Gemini prioriza la estructura general y las relaciones de alto nivel. ChatGPT prioriza la resolución de entidades y la tipificación semántica. Perplexity prioriza las propiedades individuales y la completitud del schema.

Si hubiera pedido la auditoría solo a Gemini, habría pensado que estaba casi perfecto. Si solo a Perplexity, habría pensado que tenía problemas serios. La realidad es que el schema era sólido en arquitectura pero débil en granularidad. Las tres perspectivas juntas dieron una imagen más completa que cualquiera por separado.

Esto es Cogitare Debes aplicado a estructura técnica. No le preguntas a una IA. Le preguntas a tres. Implementas lo que coincide. Evalúas lo que diverge. Descartas lo que no justifica la complejidad.

El schema actualizado corre en producción. Cada post de este blog genera el JSON-LD automáticamente con los seis cambios implementados. Si quieres auditar tu propio schema, copia el bloque JSON-LD de cualquier página y pégalo en ChatGPT, Gemini y Perplexity con el mismo prompt. Los tres van a encontrar cosas diferentes. Ese es exactamente el punto.