¿Qué es el Knowledge Graph?

Conviene separar tres cosas que en el trabajo diario se mezclan. La entidad es el objeto del mundo real: una empresa, un municipio, un fármaco. El Knowledge Graph es el almacén donde Google guarda esas entidades con sus atributos y sus vínculos. El panel de conocimiento es solo una de las superficies donde ese almacén se muestra, y su ausencia no demuestra que la entidad falte en el grafo.

Tampoco es lo mismo que el índice de búsqueda. El índice guarda documentos: URL, texto, señales de rastreo. El grafo guarda hechos sobre cosas y las conexiones entre ellas, con un identificador propio para cada nodo. Una empresa puede tener cien URL indexadas y ningún nodo reconocido, y también ocurre lo contrario: una persona sin web propia figura en el grafo porque otras fuentes la describen.

Los datos estructurados son un canal de entrada al grafo, no el grafo. Marcar Organization en la página principal ayuda a Google a entender los datos administrativos de la organización y a distinguirla de otras con nombre parecido, según la documentación de Search Central actualizada el 15 de abril de 2026. Esa misma página advierte de que Google no garantiza que las funciones que consumen datos estructurados aparezcan en los resultados.

El grafo se construye a partir de fuentes que recopilan información factual. Google describe su base como miles de millones de hechos sobre personas, lugares y cosas, y reconoce que además licencia datos de terceros para bloques como resultados deportivos, cotizaciones bursátiles o previsiones meteorológicas. El resto procede del rastreo de la web abierta y de repositorios públicos.

Cada entidad recibe un identificador estable. La API de búsqueda del Knowledge Graph lo devuelve con el prefijo kg:, por ejemplo kg:/m/0dl567, junto a tipos alineados con schema.org (Person, Place, Organization, Movie, Book, Event, entre otros). Ese identificador es lo que permite resolver «Springfield» en un texto sobre Illinois y «Springfield» en un texto sobre Massachusetts como dos nodos distintos.

El mecanismo tiene tres pasos. Google extrae candidatos a hecho del texto y del marcado, resuelve a qué nodo pertenece cada candidato (desambiguación) y consolida el valor cuando varias fuentes independientes coinciden. La propiedad sameAs es la señal habitual para declarar que tu web, tu ficha en un directorio y tu perfil social describen la misma entidad. Propiedades menos visibles como iso6523 o naics trabajan en segundo plano con el mismo fin: separarte de organizaciones homónimas.

Sobre la herramienta de consulta hay una limitación que conviene conocer. Google indica que la API heredada se está migrando a Cloud Enterprise Knowledge Graph, recomienda el producto nuevo a quien empieza ahora y advierte de que el endpoint antiguo no es apto como servicio crítico en producción. Sirve como sonda de auditoría, no como fuente operativa permanente.

La decisión concreta que depende de esto es dónde inviertes cuando tu marca no aparece reconocida. Si el problema está en los documentos, se corrige con contenido y enlaces. Si el problema está en la entidad, ninguna cantidad de artículos lo resuelve: lo que falta es que Google pueda identificar quién eres, bajo qué nombre canónico y con qué fuentes que lo corroboren.

Esa diferencia se ha encarecido desde que los sistemas de respuesta generativa citan marcas. Un modelo que resume una consulta comercial trabaja sobre entidades recuperadas, no sobre tu meta description. Si tu empresa no está resuelta como nodo, aparece descrita de forma genérica, confundida con un homónimo o directamente fuera del conjunto de candidatas.

También cambia la gestión de los datos básicos y de las crisis. Un domicilio antiguo, un fundador que ya no está o una razón social obsoleta se propagan por muchas superficies a la vez cuando viven en el grafo. Corregir la web sin tocar las fuentes que alimentan el nodo deja el dato viejo circulando. Google señala que los paneles se generan de forma automática y que los representantes verificados pueden reclamar la ficha y sugerir correcciones.

• Designa una sola página de entidad para la marca (la portada o un «quiénes somos» estable) y márcala con Organization en JSON-LD, con name, url, logo y legalName coherentes con el registro mercantil.
• Declara sameAs hacia los perfiles que ya te describen: Wikidata si existe, LinkedIn, la ficha de Google Business Profile y los directorios de tu sector. Usa la URL canónica de cada perfil, sin parámetros de campaña.
• Fija un nombre canónico único y úsalo en la web, en la facturación y en los perfiles. Si conviven «Nordia», «Nordia Group» y «Nordia Consulting SL», elige uno y relega los demás a alternateName.
• Corrobora los datos duros (domicilio, año de fundación, personas clave) en al menos dos fuentes externas legibles por un rastreador. Un hecho que solo aparece en tu propia web es un hecho sin confirmar.
• Comprueba si ya existe nodo antes de planificar: una consulta a la API de búsqueda del Knowledge Graph con el nombre exacto de la marca te devuelve el identificador y el tipo asignado, o nada.
• Reclama el panel de conocimiento como representante verificado y usa el flujo de sugerencia de cambios para los errores factuales, en lugar de reescribir la web una y otra vez.

• Tomar el panel de conocimiento como prueba de existencia. El panel se genera de forma automática cuando hay suficiente información en la web abierta, así que su ausencia apunta a falta de corroboración, no a que el nodo no exista.
• Insertar el marcado Organization en todas las plantillas del sitio. La entidad se declara en una página; repetir el bloque en miles de URL multiplica versiones que se contradicen entre sí.
• Esperar un efecto garantizado del marcado. Google afirma de forma expresa que no garantiza que las funciones que consumen datos estructurados se muestren en los resultados.
• Apuntar sameAs a cualquier página que mencione la marca. Esa propiedad declara identidad, no mención: un artículo que habla de ti no es un perfil tuyo.
• Montar la auditoría sobre la API heredada. Google la está migrando a Cloud Enterprise Knowledge Graph y advierte de que no es apta como servicio crítico, de modo que una respuesta vacía puede ser un límite del endpoint y no la ausencia de la entidad.