Wikidata y el Google Knowledge Graph: la capa de entidades detrás de los Knowledge Panels y las respuestas de IA

La mayoría de las personas que nos preguntan sobre «aparecer en el Google Knowledge Panel» o «mostrarse correctamente en ChatGPT» creen que están haciendo una pregunta sobre contenido. No es así. Están preguntando sobre entidades — si las máquinas que impulsan la búsqueda y la IA reconocen su empresa, fundador o producto como algo distinto en el mundo, con una identidad estable y un conjunto conocido de hechos.

Esa capa de reconocimiento tiene un nombre. En realidad tiene varios nombres, y la mayoría de la gente los usa indistintamente cuando significan cosas muy diferentes. Wikipedia no es Wikidata. Wikidata no es el Google Knowledge Graph. Y ninguno de ellos garantiza un Knowledge Panel.

Este artículo desenreda todo eso. Es la explicación que enviamos a los clientes que llegan convencidos de que necesitan un artículo de Wikipedia cuando lo que realmente necesitan — al menos en primer lugar — es una entidad de Wikidata limpia. Es honesto sobre lo que puede hacer la capa de entidades y directo sobre lo que no puede.

Tres cosas diferentes, claramente definidas

Separemos los tres sistemas que se confunden constantemente, porque casi todos los errores que vienen después provienen de mezclarlos.

Wikipedia es una enciclopedia. Es prosa — artículos escritos por humanos, párrafos, referencias, punto de vista neutral. Para tener un artículo en Wikipedia, un tema debe superar la notabilidad (Wikipedia:Notability — criterio de admisibilidad que exige cobertura significativa en fuentes secundarias independientes y fiables): cobertura significativa en fuentes secundarias independientes y fiables. El listón es alto y cada vez más alto. La mayoría de las empresas no califican, y eso es por diseño. Wikipedia es para temas sobre los que el mundo ya ha escrito extensamente.

Wikidata es una base de datos estructurada. No es prosa; son hechos en un formato legible por máquinas. Donde Wikipedia tiene un artículo sobre la Torre Eiffel, Wikidata tiene un elemento — un registro con un identificador (Q243) y una lista de afirmaciones: es una instancia de «torre», está ubicada en París, fue diseñada por Gustave Eiffel, su altura es de 330 metros, etcétera. Cada uno de esos hechos es un par propiedad-valor, respaldado idealmente por una referencia. Wikidata es un proyecto hermano de Wikipedia, gestionado por la misma Wikimedia Foundation, pero es algo fundamentalmente diferente — y crucialmente, tiene un listón de inclusión más bajo. Más sobre eso a continuación.

El Google Knowledge Graph es la propia base de datos privada de Google sobre entidades y las relaciones entre ellas. Se lanzó en 2012 con la frase «things, not strings» (cosas, no cadenas de texto) — Google dejó de tratar «Apple» como una cadena de cinco letras y empezó a tratarla como una entidad que podía ser la fruta, la empresa o el sello discográfico, cada una con sus propios hechos y conexiones. El Knowledge Graph impulsa el Knowledge Panel (el recuadro a la derecha de un resultado de búsqueda) y alimenta la comprensión de entidades en todos los productos de Google. Está informado por Wikipedia y Wikidata, entre muchas otras fuentes — pero Google lo posee, lo controla, y usted no puede editarlo directamente.

La relación en una sola frase: Wikipedia y Wikidata son fuentes abiertas, públicas y editables que Google ingesta en su propio Knowledge Graph propietario, que luego utiliza (a su sola discreción) para mostrar Knowledge Panels e informar las respuestas de la IA.

Confundir estos tres sistemas lleva a errores predecibles. La gente intenta «editar su Knowledge Panel» directamente — no se puede; solo se puede reclamarlo y sugerir cambios. La gente asume que un elemento de Wikidata producirá un artículo de Wikipedia — no lo hará, son procesos separados con listones separados. Y la gente asume que cualquiera de todo esto garantiza un panel — no lo hace; Google siempre toma la decisión final.

Cómo los datos estructurados alimentan a Google y los LLM

Para entender por qué Wikidata tiene tanto peso, hay que entender cómo está construido — porque la estructura es exactamente lo que las máquinas quieren.

Cada elemento de Wikidata tiene un QID, un identificador único como Q95 (Google), Q312 (Apple Inc.) o Q42 (Douglas Adams). El QID es la dirección permanente de la entidad. Nunca cambia aunque cambie la etiqueta, y es independiente del idioma — Q42 es Douglas Adams tanto si la interfaz está en inglés como en japonés o árabe. Esto es lo más importante que proporciona Wikidata: un identificador estable e inequívoco para una cosa.

Sobre el QID se asientan afirmaciones (statements), construidas a partir de propiedades (properties) y valores (values). Las propiedades también están identificadas (P31 es «instancia de», P159 es «sede», P1448 es «nombre oficial», P856 es «sitio web oficial»). Así, el hecho «Apple Inc. tiene su sede en Cupertino» se almacena como Q312 → P159 → Q190080 (Cupertino). Las máquinas no tienen que analizar una oración; leen una tripleta.

Esto importa para dos consumidores:

• Google. El Knowledge Graph es en sí mismo un grafo de entidades y tripletas. El formato de Wikidata se mapea casi directamente sobre él, lo que explica por qué Google ingesta Wikidata a escala y por qué un elemento de Wikidata bien construido es una de las señales más claras que se pueden enviar sobre la identidad, el tipo y los atributos principales de una entidad. Google también se apoya en Wikidata para la desambiguación — distinguir su empresa de las otras cinco empresas con un nombre similar.
• Los modelos de lenguaje grandes (LLM, por sus siglas en inglés). Cuando un LLM (como ChatGPT o Gemini) responde «quién fundó [empresa]» o «dónde tiene la sede [empresa]», extrae patrones de sus datos de entrenamiento. Wikipedia es la fuente de texto con más peso en la mayoría de los corpus de entrenamiento, y Wikidata aparece cada vez más en los conjuntos de datos estructurados utilizados para el anclaje, la recuperación y las búsquedas en bases de conocimiento. Una entidad consistente y bien referenciada tiene muchas más probabilidades de ser representada correctamente — y mucho menos riesgo de ser confundida con una entidad de nombre similar — que una que solo existe como menciones dispersas y no estructuradas en la web abierta.

Esta es la versión honesta de la «visibilidad en IA», y es el fundamento del trabajo de SEO (optimización para motores de búsqueda) basado en entidades y Knowledge Graph: usted no inyecta contenido en ChatGPT o Gemini. Nadie puede. Lo que sí puede hacer es construir una infraestructura limpia, legible por máquinas y bien documentada que hace más probable que las máquinas describan su entidad con precisión. Hemos escrito más sobre esa distinción en nuestro trabajo de visibilidad en IA — la palanca es la calidad de las fuentes y los datos estructurados, no la manipulación de prompts.

El listón de notabilidad más bajo de Wikidata

Aquí está la parte que la mayoría de la gente no conoce, y la que amplía quién puede beneficiarse realmente.

Wikipedia exige notabilidad (Wikipedia:Notability) — el tema debe ser lo suficientemente conocido como para que fuentes independientes lo hayan cubierto en profundidad. Wikidata exige algo mucho más débil: a grandes rasgos, existencia verificable e identificabilidad, más un enlace de sitio a una página de Wikimedia existente, una referencia a una fuente externa seria, o ser estructuralmente necesario para describir otros elementos.

Léalo de nuevo, porque la diferencia es el punto central. Wikipedia pregunta «¿es este tema lo suficientemente importante como para que el mundo haya escrito sobre él?» Wikidata pregunta «¿podemos verificar que esta cosa existe y apuntar a una fuente que lo confirme?» Son umbrales completamente diferentes.

En la práctica, esto significa que una empresa mediana que sería rechazada en Wikipedia — no tiene suficiente cobertura independiente en profundidad — puede a menudo tener un elemento de Wikidata perfectamente legítimo, siempre que su existencia y sus hechos principales sean verificables a través de referencias creíbles: un registro mercantil, una presentación regulatoria, un registro de autoridad, bases de datos externas establecidas. El elemento no hará que la empresa sea famosa ni fabricará notabilidad. Pero le da a la entidad un QID, una identidad estable y un conjunto de hechos legibles por máquinas que el Knowledge Graph y los LLM pueden leer.

Algunas advertencias honestas para que nadie malinterprete esto:

• «Listón más bajo» no significa «sin listón». Wikidata sigue teniendo directrices de notabilidad (WP:NCORP — política de notabilidad de organizaciones en Wikipedia), y los elementos sobre temas no notables sin referencias serias se eliminan. No se puede crear un elemento para una consultoría unipersonal sin huella externa alguna y esperar que sobreviva.
• Wikidata no es un espacio promocional. Es una base de datos factual. No hay lugar para el lenguaje de marketing, y así debe ser.
• Un elemento de Wikidata por sí solo es una señal más débil que un artículo de Wikipedia. Es un cimiento, no la línea de meta.

Pero para una amplia franja de empresas e individuos que son reales y verificables pero aún no notables para Wikipedia, Wikidata es el paso de la capa de entidades que es realmente alcanzable hoy. Por eso lo recomendamos tan a menudo como primer paso.

Anatomía de un Google Knowledge Panel

Cuando aparece un Knowledge Panel, sus campos se ensamblan a partir de múltiples fuentes. Ninguna fuente única «posee» el panel. Entender qué campo tiende a venir de dónde ayuda a entender qué vale la pena corregir — y dónde Wikidata tiene realmente influencia.

La tabla a continuación es una guía general, no un contrato. Google mezcla fuentes, las anula y cambia su comportamiento con el tiempo. Trátela como «de dónde suele venir este campo», no «de dónde viene siempre».

Dos conclusiones. Primera, el panel es un compuesto — mejorar una fuente mejora una franja. Si su descripción es incorrecta, eso suele ser un problema con la introducción de Wikipedia; si su dirección es incorrecta, es un problema de Google Business Profile; si su fecha de fundación o tipo de entidad es incorrecto, suele ser un problema de Wikidata. Segunda, si aparece un panel o no es decisión de Google, impulsada principalmente por si Google confía en que la entidad es real, distinta y lo suficientemente notable como para merecer uno. Wikidata y Wikipedia aumentan esa confianza. No obligan al resultado.

Fundamentos del SEO de entidades: sameAs, schema y registros de autoridad

Wikidata no opera de forma aislada. Se asienta dentro de una red más amplia de señales de identidad, y cuantas más de ellas coincidan entre sí, con más confianza puede un motor de búsqueda resolver su entidad. La idea central es la corroboración: los mismos hechos, los mismos identificadores, apuntando a lo mismo desde múltiples lugares independientes.

Los bloques de construcción prácticos:

• Datos estructurados de schema.org en su propio sitio. Marcar su página de inicio o página «sobre nosotros» con schema Organization o Person (en JSON-LD) le dice a Google directamente qué entidad representa el sitio — su nombre, logotipo, fecha de fundación y personas clave. Esta es la única parte de la capa de entidades que usted controla completamente, en infraestructura que posee.
• La propiedad sameAs. Dentro de ese marcado schema, sameAs es un array de URLs que apuntan a otras representaciones autorizadas de la misma entidad — su artículo de Wikipedia, su elemento de Wikidata, sus perfiles sociales verificados, su entrada en Crunchbase o en una base de datos del sector. sameAs es, en efecto, usted diciéndole a Google «todos estos hacen referencia a lo mismo». Es el tejido conectivo entre su sitio propio y el grafo de entidades abierto.
• Registros de autoridad. Son identificadores formales e institucionales mantenidos por bibliotecas, organismos de normalización y registros. Son prueba externa de que una institución reconocida ha catalogado su entidad. Los más comunes:

Wikidata es donde muchos de estos confluyen: un elemento bien construido enlaza con VIAF, ISNI, ORCID, LEI, GRID/ROR y otros a través de propiedades dedicadas. Eso convierte el elemento de Wikidata en un hub — un único lugar donde una máquina puede confirmar que «este QID» equivale a «este LEI» equivale a «este ORCID» equivale a «este artículo de Wikipedia». Cada identificador coincidente es un voto más de que la entidad es real y singular.

No necesita todos ellos. Un instituto de investigación debería tener GRID/ROR; una empresa que cotiza en bolsa debería tener un LEI; un académico individual debería tener ORCID. La cuestión no es coleccionar insignias — sino que los identificadores para los que legítimamente califica estén presentes y sean consistentes, para que todo el grafo coincida consigo mismo.

Modos de fallo comunes

La mayoría de los elementos de Wikidata que no hacen nada útil fallan por un pequeño número de razones recurrentes. Vemos el mismo puñado constantemente.

• Elementos huérfanos. El elemento existe pero nada apunta a él y él no apunta a nada. Es un registro flotante sin relaciones. El Knowledge Graph es un grafo — las entidades derivan su significado de sus conexiones. Un elemento sin enlaces entrantes ni salientes hacia otras entidades es casi invisible para los sistemas que consumen Wikidata.
• Referencias faltantes. Las afirmaciones sin fuentes son débiles y propensas a ser eliminadas. «Sede: Berlín» sin referencia es una aserción; «Sede: Berlín» citado en un registro mercantil es un hecho. Los elementos sin referencias se marcan, y las afirmaciones sin referencias son eliminadas o ignoradas por los consumidores cautelosos aguas abajo.
• Sin enlace de sitio en inglés (o sin enlace de sitio alguno). Un enlace de sitio conecta el elemento de Wikidata con un artículo de Wikipedia en un idioma dado. Muchas integraciones de alto valor y gran parte de la confianza de Google se apoyan en la conexión en lengua inglesa. Un elemento sin enlace de sitio a ninguna edición de Wikipedia es más delgado y más difícil de que los sistemas confíen en él. (Por esto un elemento de Wikidata no es un sustituto de un artículo de Wikipedia cuando uno es alcanzable.)
• Entidades ambiguas o duplicadas. Dos elementos para la misma empresa. Un fundador confundido con un deportista del mismo nombre. Un producto fusionado en el elemento de la empresa, o dividido cuando no debería estarlo. Los duplicados y la ambigüedad son veneno para la resolución de entidades — precisamente el problema que el sistema QID existe para prevenir. Fusionar duplicados y desambiguar entidades en conflicto suele ser el trabajo de limpieza de mayor valor en un elemento existente.

Nada de esto es exótico. Es la diferencia entre un elemento que existe y un elemento que funciona — y detectarlos es la mayor parte de en qué consiste el trabajo cuidadoso con Wikidata.

Cronograma realista, y qué puede y no puede desencadenar un elemento limpio

Gestionemos las expectativas con honestidad, porque aquí es de donde proviene la mayor parte de la decepción.

Crear un elemento de Wikidata bien construido no es lento en sí mismo — el elemento puede estar activo en un día. Lo que lleva tiempo es la propagación aguas abajo, y ese cronograma no está bajo el control de nadie salvo de Google.

• Creación del elemento: horas o un día para un elemento correctamente estructurado y referenciado.
• Indexación e ingestión por Google: normalmente semanas. Google reingestiona Wikidata en su propio calendario.
• Efecto visible en un Knowledge Panel (si aparece alguno): semanas o meses, y solo si Google decide que la entidad merece uno.

Lo que un elemento de Wikidata limpio puede hacer:

• Establecer un QID estable y una identidad legible por máquinas para la entidad.
• Mejorar la desambiguación — reduciendo la posibilidad de ser confundido con una entidad de nombre similar.
• Contribuir hechos estructurados precisos (tipo de entidad, fundadores, sede, sitio oficial, identificadores) que Google y los LLM pueden leer.
• Fortalecer la red sameAs vinculando el schema de su sitio propio a un hub externo autorizado.
• Hacer que el andamiaje de datos de un futuro artículo de Wikipedia sea más limpio.

Lo que un elemento de Wikidata limpio no puede hacer:

• Garantizar un Knowledge Panel. Google siempre toma la decisión final, y muchas entidades perfectamente válidas nunca obtienen uno.
• Crear notabilidad. Registra hechos verificables; no le hace importante, y no sustituirá a la cobertura independiente que requiere un artículo de Wikipedia.
• Inyectar o controlar el resultado de la IA. Mejora las probabilidades de una representación precisa. No le permite dictar lo que dice un modelo.
• Anular los datos de Google Business Profile. Su dirección, horario y reseñas provienen de otro lugar.
• Sobrevivir si es promocional o no está referenciado. Wikidata es una base de datos factual con editores y bots activos; un elemento de baja calidad se limpia.

Si una agencia le dice que un elemento de Wikidata garantizará un Knowledge Panel o controlará cómo ChatGPT le describe, eso es la misma palabrería vacía contra la que advertimos en todas partes. El argumento honesto es probabilístico: una infraestructura de entidades limpia aumenta la probabilidad de una representación precisa y elegible. No es un interruptor que se acciona.

Cuándo Wikidata es el primer paso correcto

Wikidata es el primer movimiento correcto — antes de intentar un artículo completo de Wikipedia — en un conjunto reconocible de situaciones:

• El tema es real y verificable pero aún no es notable para Wikipedia. El caso más común. Hay una inscripción en el registro mercantil, una huella regulatoria, quizás algo de cobertura sectorial, pero no los 3–5 artículos independientes en profundidad que necesita un artículo de Wikipedia. Wikidata le da a la entidad una identidad legible por máquinas y legítima ahora, mientras construye la base de fuentes para Wikipedia más tarde.
• Hay un problema de confusión de entidades. Google o un LLM le está confundiendo con una empresa, persona o producto de nombre similar. Un elemento limpio y desambiguado con los identificadores correctos es a menudo el correctivo más directo.
• Quiere tener el cimiento del SEO de entidades en su lugar antes de un esfuerzo mayor. El marcado schema, sameAs y un hub de Wikidata limpio son el trabajo de base sobre el que debería asentarse un artículo de Wikipedia — no un sustituto, sino la capa que hace todo lo demás más coherente.
• No está seguro de si califica para Wikipedia en absoluto. Esto es exactamente para lo que sirve una auditoría de notabilidad de Wikipedia (Wikipedia:Notability). Si la auditoría dice que las fuentes apoyan un artículo, genial — pursue la creación de página de Wikipedia (AfC — Articles for Creation, proceso de revisión de borradores), con Wikidata como parte del mismo flujo de trabajo. Si dice que las fuentes se quedan cortas, Wikidata es el paso alcanzable que aun así hace avanzar la capa de entidades mientras se cierra la brecha de cobertura.

La lógica de secuenciación es sencilla. Wikidata tiene el listón más bajo y el camino más rápido hacia un resultado legítimo, por lo que es donde deben empezar los temas verificables pero aún no famosos. Wikipedia tiene el listón más alto y la señal más fuerte, por lo que es adonde se va cuando las fuentes realmente están ahí. Intentar Wikipedia primero cuando no se califica desperdicia semanas y arriesga una eliminación (AfD — Articles for Deletion, proceso de eliminación de artículos en Wikipedia) que hace más difícil el siguiente intento. Construir Wikidata primero cuesta poco, ayuda de todas formas y nunca perjudica el caso para Wikipedia.

Lo que no es, es un truco, un atajo hacia la fama o un panel garantizado. Es la capa de entidades — el cimiento sin glamour, estructurado y bien referenciado que hace que las máquinas le describan con precisión. Para muchas empresas e individuos, poner en orden esa capa es a la vez el paso más alcanzable y el más ignorado de toda la conversación sobre visibilidad en IA.

¿No está seguro de si su entidad debería empezar con Wikidata o ir directamente a por un artículo de Wikipedia? Escríbanos a team@wikibusines.com y le enviaremos una lectura honesta sobre qué paso se adapta realmente a su situación.