GEO Avanzado: Entidades, Schema JSON-LD y arquitectura de datos para IA

Hay una diferencia fundamental entre una web que habla de algo y una web que es una entidad reconocible sobre ese algo. La primera puede tener el mejor contenido del mundo. La segunda es la que cita la IA.

El salto entre ambas no es de volumen de contenido ni de densidad de keywords. Es de arquitectura de entidades: la capacidad de declarar explícitamente quién eres, qué haces y cómo te relacionas con otras entidades del ecosistema — de forma que un modelo de lenguaje pueda verificarlo sin tener que inferirlo.

Esa declaración se implementa mediante Schema JSON-LD. Este artículo es una guía técnica de cómo hacerlo bien.

Qué es una entidad y por qué cambia la lógica del GEO

En el lenguaje de los modelos de lenguaje, una entidad es un concepto único, inequívoco y conectable. Tu empresa es una entidad. Un servicio específico es una entidad. Un caso de éxito documentado es una entidad. Una persona con nombre y trayectoria verificable en fuentes externas es una entidad.

El SEO tradicional funcionaba con palabras clave: si tu página tenía suficiente densidad de «agencia webflow madrid», Google la priorizaba. Los LLMs no funcionan así. Ellos mapean relaciones entre entidades: quién eres, qué haces, a quién has ayudado y quién más habla de ti.

Si esas relaciones no están declaradas explícitamente en tu código, la IA tiene que inferirlas. Y cuando infiere, se equivoca, te ignora o cita a otro. El Schema JSON-LD es el lenguaje con el que eliminas esa ambigüedad.

La implementación base: Organization, Service y WebSite

El punto de partida de cualquier arquitectura GEO sólida son tres bloques de Schema en la página principal. El primero es Organization: nombre legal, descripción, logo, país, perfiles sociales verificados mediante el campo sameAs, área de servicio y contacto. Este bloque le dice a la IA quién eres con precisión suficiente para que no te confunda con nadie más.

El segundo es Service: uno por cada servicio que ofreces, con nombre, descripción, proveedor (tu Organization), área geográfica y, si procede, precio orientativo. La especificidad importa: «servicios web» es ruido para un LLM; «desarrollo Webflow bajo metodología Client-First para agencias de diseño» es una entidad con significado único.

El tercero es WebSite: con SearchAction si tienes buscador interno, y siempre con el nombre del sitio y la URL canónica. Es el contenedor que une y referencia los demás bloques, convirtiendo tres piezas aisladas en un grafo coherente.

El poder del campo sameAs

El atributo sameAs es probablemente el más subestimado del Schema. Le dice a la IA que tu entidad en esta URL es la misma que aparece en LinkedIn, en Google Business, en Crunchbase o en cualquier otra fuente verificable de alta autoridad.

Cuando un LLM encuentra que la misma entidad aparece de forma consistente en múltiples fuentes, su confianza en ella aumenta dramáticamente. No es magia: es la misma lógica con la que funciona la reputación humana. Las referencias verificables de terceros valen más que la autodescripción.

"sameAs": [
  "https://www.linkedin.com/company/literal-studio",
  "https://g.co/kgs/...",
  "https://www.instagram.com/literal.studio"
]

Cada URL del array debe ser un perfil verificado y actualizado. Un sameAs que apunta a un LinkedIn con tres conexiones y sin actividad no suma autoridad: la resta.

Contenido citable: TechnicalArticle y FAQPage

Los artículos del blog no deberían marcarse como Article genérico. Si el contenido es técnico y especializado — como los que componen este blog — el tipo correcto es TechnicalArticle, que incluye campos específicos como proficiencyLevel y dependencies. Esto le indica a la IA que el contenido es documentación experta, no opinión general. La diferencia de tratamiento en cómo los LLMs priorizan la fuente es significativa.

Las páginas con preguntas frecuentes deben implementar FAQPage con cada pregunta marcada como Question y cada respuesta como acceptedAnswer. Estas son las piezas que los modelos de lenguaje extraen directamente para generar sus respuestas sintéticas. Si no están marcadas, la IA tiene que adivinar dónde empieza y termina cada respuesta. Si están marcadas con precisión, se las sirves en bandeja en el formato exacto que necesita para citarte.

El grafo interno: cómo conectar entidades entre sí

La arquitectura de entidades no es una colección de bloques JSON aislados. Es un grafo. Cada entidad debe referenciar a las demás mediante sus URLs canónicas, creando una red de relaciones declaradas que los LLMs pueden recorrer y verificar.

El TechnicalArticle del blog referencia al Organization como autor mediante el campo author. El Service referencia a los casos de éxito relacionados como workExample. Los casos de éxito, a su vez, referencian las tecnologías utilizadas como entidades externas — Webflow, Figma y WordPress tienen sus propias entidades en Wikidata, y enlazar a ellas es añadir credibilidad verificable al grafo.

Este grafo conectado es lo que convierte un activo digital en una fuente de autoridad verificable. La IA no necesita inferir relaciones porque están declaradas explícitamente en el código. Cuantas más relaciones correctamente declaradas tenga el grafo, más confianza genera la entidad en su conjunto.

Errores comunes que anulan el trabajo de Schema

Implementar Schema JSON-LD incorrectamente puede ser peor que no implementarlo. Los errores más frecuentes que invalidan el trabajo son: usar tipos incorrectos para el contenido (marcar un artículo técnico como BlogPosting genérico en lugar de TechnicalArticle), dejar campos obligatorios vacíos o con valores genéricos, y crear bloques JSON-LD que no se referencian entre sí, lo que produce fragmentos aislados en lugar de un grafo coherente.

El segundo error más dañino es la inconsistencia entre el Schema y el contenido visible. Si el Organization declara un área de servicio que no aparece en ningún otro elemento de la página, los modelos de lenguaje detectan la discrepancia y reducen la confianza en la entidad. El Schema no es una capa separada del contenido: es la declaración formal de lo que el contenido dice.

Conclusión: JSON-LD no es SEO técnico, es infraestructura de marca

Implementar Schema JSON-LD avanzado no es una tarea de SEO que se delega al último momento del proyecto. Es una decisión de arquitectura que determina si tu marca existe para la IA o no existe.

La diferencia entre una web que la IA conoce y una que ignora no siempre está en la calidad del contenido. Está en si ese contenido está empaquetado de forma que una máquina pueda procesarlo, verificarlo y citarlo con confianza. El Schema JSON-LD es ese empaquetado. Y la precisión con la que se implementa — los tipos correctos, los campos completos, el grafo conectado, la coherencia con el contenido visible — es lo que separa a las marcas que la IA cita de las que simplemente tienen una web.

En Literal, lo tratamos exactamente así: como infraestructura, no como metadato. Porque la infraestructura de marca que construyes hoy es la autoridad que acumulas mañana.