All posts by : Carlos González Pizarro

mainEntityOfPage es la propiedad de Schema.org con la que declaras cuál es la entidad principal de una página web. Responde a una pregunta que la IA se hace sobre cada URL: de qué entidad trata realmente este documento. Cuando la declaras con un Q-ID de Wikidata verificado, dejas de depender de que el motor adivine y le entregas una identidad resoluble sin ambigüedad.

El problema es que la mayoría de los sitios marcan datos, pero no declaran la entidad protagonista. Publican un Organization aquí, un Article allá y un Service suelto, todos como islas desconectadas. Sin mainEntityOfPage, el grafo no tiene un punto de entrada claro, y los motores generativos quedan sin una respuesta directa a la pregunta más básica: qué es esta página.

En este artículo te explico qué es mainEntityOfPage, en qué se distingue de mainEntity, about y mentions, y por qué es la pieza que cose tu página a una entidad verificable. Al final verás cómo SemanticGEO la emite automáticamente desde tu grafo de conocimiento, sin que escribas una línea de JSON-LD a mano.

Qué es mainEntityOfPage y en qué se distingue de mainEntity, about y mentions

mainEntityOfPage vive en el nodo WebPage y apunta a la entidad principal que describe esa página. Es una referencia, no una descripción: no guarda texto, guarda un puntero con @id hacia otra entidad del grafo. Schema.org la define como la entidad principal descrita por la página, y su valor práctico es enorme porque le dice al motor cuál es el sujeto central del documento.

mainEntityOfPage apunta desde la página; mainEntity apunta desde la entidad

Son dos caras de la misma relación. La propiedad mainEntity se usa dentro de un nodo para señalar su entidad principal, por ejemplo en una FAQPage donde mainEntity apunta a la Question. mainEntityOfPage se usa en sentido inverso: desde el WebPage hacia la entidad que lo protagoniza. Cuando ambos extremos se referencian por el mismo @id, el grafo queda cosido y sin ambigüedad.

about, mentions y mainEntityOfPage: tres señales con propósitos distintos

about declara de qué trata el contenido, como tema general. mentions señala entidades que se mencionan de paso. mainEntityOfPage nombra a la entidad protagonista, la que responde a la pregunta de qué es esta página. Un artículo sobre la evolución del SEO puede tener about apuntando a search engine optimization, mentions apuntando a Google, y mainEntityOfPage apuntando al propio Article.

Por qué el schema tradicional falla sin una entidad principal declarada

La mayoría de los plugins de datos estructurados emiten bloques JSON-LD válidos pero desconectados. Cumplen con el validador de Schema.org, y aun así dejan la página sin un mainEntityOfPage que la ancle a una entidad. El resultado es el escenario que viven miles de sitios: el código valida, pero la IA no sabe quién es el protagonista, así que no tiene una entidad limpia que citar.

Sin esa referencia, un WebPage es un documento suelto, no una página que habla de una entidad. Y como los motores generativos no leen keywords sino que resuelven entidades, una página sin entidad principal es una página que la IA no puede resolver con precisión.

Cómo declarar la entidad principal con un Q-ID verificable

Declarar mainEntityOfPage bien tiene tres requisitos. Primero, la entidad apuntada debe existir en tu grafo con un @id propio, no como texto suelto. Segundo, debe estar anclada a Wikidata mediante sameAs con un Q-ID real. Tercero, el @id debe ser canónico y estable, normalizado en HTTPS, para que no se parta en dos entidades.

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "WebPage",
      "@id": "https://ejemplo.cl/servicios/seo/#webpage",
      "url": "https://ejemplo.cl/servicios/seo/",
      "mainEntityOfPage": { "@id": "https://ejemplo.cl/#service-seo" }
    },
    {
      "@type": "Service",
      "@id": "https://ejemplo.cl/#service-seo",
      "name": "Consultoría SEO B2B",
      "provider": { "@id": "https://ejemplo.cl/#organization" }
    }
  ]
}

Fíjate en el detalle: el WebPage no repite la descripción del servicio, solo lo referencia por @id. Esa es la diferencia entre coser un grafo y emitir islas. La entidad se define una sola vez y se referencia desde todas las páginas que la protagonizan.

La solución tecnológica: SemanticGEO

SemanticGEO emite mainEntityOfPage automáticamente como parte de su Graph Stitching sobre el grafo de Yoast SEO. Cuando creas un nodo Service o SoftwareApplication para una página, el plugin cose ese nodo al WebPage correspondiente con la referencia correcta, sin que escribas una línea de JSON-LD a mano. La entidad vive en tu biblioteca central, con su Q-ID validado en tiempo real contra la API de Wikidata, y se reutiliza en todo el sitio con el mismo @id.

El flujo es este: defines la entidad una vez, eliges el Q-ID con el buscador de Wikidata integrado, y el plugin se encarga del resto. Los 13 packs de nicho importables traen las entidades base de tu vertical ya verificadas, y el llms.txt se genera desde el mismo grafo, así que la entidad principal de cada página viaja también al resumen que leen los crawlers de IA. Cero tipeo manual, cero islas, cero @id partidos.

Preguntas frecuentes

¿mainEntityOfPage es lo mismo que la URL canónica?

No. La URL canónica resuelve cuál de varias versiones de una misma página es la oficial. mainEntityOfPage resuelve qué entidad es el sujeto principal del contenido. Operan en planos distintos: el canonical evita contenido duplicado, la entidad principal le dice a la IA de qué trata el documento.

¿Qué pasa si no declaro mainEntityOfPage?

El validador no te lo marca como error, porque es una propiedad opcional. Pero dejas que el motor adivine el sujeto de la página a partir del texto. En un sitio con varias páginas similares, esa ambigüedad es justo lo que hace que la IA no sepa a quién citar.

¿mainEntityOfPage va en todas las páginas o solo en las de servicio?

En todas. Cada página tiene un protagonista: un artículo, un servicio, un producto, una persona. Lo que cambia es el tipo de entidad apuntada. En una entrada es el Article, en una página de servicio es el Service, en un producto de WooCommerce es el Product.

¿Puedo declarar la entidad principal sin tener una entrada propia en Wikidata?

Sí. No necesitas que tu empresa tenga una entrada propia en Wikidata para declarar mainEntityOfPage. Puedes apuntar a un nodo interno de tu grafo anclado a entidades verificables mediante sameAs. Lo importante es que la entidad esté desambiguada y referenciada de forma estable.

¿mainEntityOfPage garantiza que la IA me cite?

No, y ningún marcado puede garantizarlo. Los motores generativos no confirman oficialmente qué señales consumen ni cómo ponderan cada una. mainEntityOfPage es la implementación técnica más rigurosa de un factor que estos motores demuestran consumir: la resolución de entidades. Es rigor, no magia.

Conclusión

mainEntityOfPage es una de esas propiedades pequeñas que separan a un sitio “con schema” de un sitio que la IA puede resolver. Sin ella, tu página es un documento suelto; con ella, es una página que habla de una entidad verificable. En un mundo donde los motores generativos resuelven entidades y no keywords, declarar el protagonista de cada página es el primer paso para que te entiendan, te verifiquen y te consideren una fuente.

Schema.org define knowsAbout como la propiedad que indica, sobre una persona y con menos frecuencia sobre una organización, un tema que esa entidad conoce, sugiriendo posible experiencia sin llegar a certificarla. Su valor puede ser texto, una entidad (Thing) o una URL, y se usa sobre los nodos Person y Organization. En términos de SEO semántico y GEO, es la forma estructurada de responder la pregunta que los motores generativos se hacen antes de citarte: ¿de qué puede hablar esta empresa con autoridad?

Cuando ChatGPT, Perplexity o Google AI Mode deciden a quién citar sobre un tema, no cuentan palabras clave: resuelven entidades y comparan grafos de conocimiento. Una organización que declara knowsAbout apuntando a una entidad verificada en Wikidata emite una señal de expertise legible por máquina. Una que solo escribe «somos expertos en SEO» dentro de un párrafo deja esa expertise invisible para el grafo.

Este artículo explica qué es knowsAbout, en qué se diferencia de about y mentions, por qué es la señal de expertise que la IA puede verificar y cómo declararla con Q-ID para que tu WordPress deje de ser texto y se vuelva dato.

Qué es knowsAbout y qué la distingue de about y mentions

Para ubicar knowsAbout hay que entender la tríada de propiedades que describen «de qué trata» algo en Schema.org. Las tres cumplen funciones distintas y confundirlas degrada el grafo:

• about: el tema central del contenido de una página (CreativeWork). Responde a «¿de qué trata esta página?».
• mentions: una referencia que aparece en el contenido pero no es su tema central. Responde a «¿qué se menciona de pasada?».
• knowsAbout: el tema que una Person u Organization conoce, sugiriendo posible expertise. Responde a «¿de qué puede hablar esta entidad con autoridad?».

La definición oficial de Schema.org es precisa y vale la pena leerla completa: «Of a Person, and less typically of an Organization, to indicate a topic that is known about, suggesting possible expertise but not implying it». La última parte importa: sugiriendo posible expertise, sin implicarla. knowsAbout no certifica que seas experto; declara un área de conocimiento para que el motor pueda razonar sobre ella. Esa sobriedad es exactamente la que conviene respetar: ningún marcado convierte a nadie en autoridad por sí solo.

Por qué knowsAbout es la señal de expertise que la IA puede verificar

La diferencia entre expertise invisible y expertise verificable está en el anclaje. Un párrafo que dice «nuestra agencia domina el SEO técnico» es texto libre: un modelo de lenguaje puede leerlo, pero no tiene una identidad de entidad a la que atar esa afirmación. No hay nada que desambiguar, verificar ni comparar contra otras fuentes.

knowsAbout con Q-ID cambia la naturaleza del dato. En lugar de una frase, emites una referencia a una entidad real del Google Knowledge Graph, con su identificador único y su sameAs a Wikipedia y Wikidata. El motor ya no interpreta una opinión: consulta un hecho estructurado.

Este es el núcleo del SEO de entidades: los motores generativos no leen keywords, resuelven entidades. knowsAbout es el mecanismo por el que tu organización le entrega al grafo la lista de entidades sobre las que reclama autoridad, en un formato que no necesita ser adivinado. La expertise deja de ser una afirmación retórica y se vuelve un dato consultable.

Del texto libre al dato estructurado: el rol del Q-ID

{
  "@type": "Organization",
  "name": "Agencia Ejemplo",
  "knowsAbout": {
    "@type": "Thing",
    "name": "search engine optimization",
    "sameAs": "https://www.wikidata.org/wiki/Q180711"
  }
}

Dónde declararlo: Organization, Person o ambos

knowsAbout se usa sobre dos tipos, Person y Organization, y el dónde importa tanto como el qué.

En el nodo Organization, knowsAbout declara las áreas en las que la empresa opera o asesora. Es la señal institucional de expertise: «esta organización conoce sobre X, Y y Z». En el nodo Person, knowsAbout declara lo que una persona concreta conoce. Es la señal E-E-A-T de autor individual: el fundador o el autor del blog firma sus artículos y, además, declara sus áreas de conocimiento con entidades ancladas. El motor puede conectar worksFor (trabaja en), author (escribe en) y knowsAbout (sabe de) en una sola persona verificable.

La práctica recomendada para un sitio B2B es declarar ambos niveles: la organización como entidad matriz y la persona como fuente de expertise verificable, conectadas por @id. Esa estructura de dos capas es la que los grafos incompletos no logran, porque se limitan a un nodo Organization con nombre y logo y dejan el resto como texto libre. Yoast SEO, por ejemplo, genera un grafo base correcto, pero sin esta profundidad de entidades.

La solución tecnológica: SemanticGEO

Declarar knowsAbout a mano, con Q-IDs verificados, en cada página y cada autor, es inviable en un WordPress real. SemanticGEO lo automatiza sobre el grafo que Yoast SEO ya genera, mediante Graph Stitching.

El plugin extiende el nodo Organization de Yoast y le añade knowsAbout con entidades de su Biblioteca Central: cada entidad se define una sola vez, con nombre canónico, Wikipedia y Q-ID de Wikidata, y se reutiliza en todo el sitio sin inconsistencias. El Q-ID se valida en tiempo real contra la API de Wikidata en el momento de importar, así que un dígito equivocado nunca conecta tu marca a una entidad ajena. Los 13 packs de nicho importables te entregan una base de entidades coherente por vertical, sin tipeo manual.

El nodo Person E-E-A-T se conecta a la organización por @id y hereda la misma biblioteca, de modo que el knowsAbout del autor y el de la empresa apuntan a las mismas entidades. Y como el grafo completo se renderiza en llms.txt, los motores generativos reciben un resumen técnico sin ambigüedades: quién eres, qué sabes y dónde operas, todo anclado a fuentes verificables.

Preguntas frecuentes

¿Qué es knowsAbout en Schema.org?

Es la propiedad que indica, sobre una Person y con menos frecuencia sobre una Organization, un tema que esa entidad conoce, sugiriendo posible expertise sin implicarla. Acepta texto, Thing o URL como valor.

¿Cuál es la diferencia entre knowsAbout, about y mentions?

about describe el tema central del contenido de una página; mentions señala una referencia secundaria dentro del contenido; knowsAbout declara el área de conocimiento de una persona u organización, independiente de una página concreta. Son tres señales distintas que no deben confundirse.

¿knowsAbout garantiza que la IA me cite como experto?

No. Schema.org lo dice en su propia definición: sugiere posible expertise, no la implica. knowsAbout es la implementación técnica más rigurosa de uno de los factores que los motores generativos declaran y demuestran consumir, pero ningún marcado puede garantizar citación.

¿Dónde debo declarar knowsAbout: en la organización o en la persona?

En ambos, si es posible. La organización declara sus áreas de expertise institucional y la persona firma su expertise individual, conectadas por @id. Esa estructura de dos capas es la que refuerza la señal E-E-A-T de autoridad.

¿Qué valor es mejor en knowsAbout: texto o un Q-ID?

Una entidad con Q-ID. El texto libre es ambiguo y no se puede desambiguar; una referencia a Wikidata con sameAs doble entrega un identificador único que el Knowledge Graph puede verificar contra fuentes externas.

Conclusión

knowsAbout es la propiedad que convierte la afirmación «somos expertos» en un dato que el Knowledge Graph puede leer. En un entorno donde los motores generativos resuelven entidades y no keywords, declarar qué sabe tu empresa, anclado a un Q-ID verificable, es la diferencia entre ser texto que un modelo hojea y ser una entidad que un motor resuelve. No garantiza citación, pero es la implementación más rigurosa de uno de los factores que estos sistemas declaran consumir.

En Schema.org, about y mentions son dos propiedades distintas que responden a preguntas distintas. about declara el tema central de la página: de qué trata el contenido en su esencia. mentions declara las entidades que el contenido menciona de paso, pero que no constituyen su asunto principal. La diferencia no es cosmética: es la señal con la que un motor decide si tu página es sobre “consultoría SEO B2B” o si solo habla de ella tangencialmente.

El problema es que casi ningún sitio distingue entre ambas. Los plugins de SEO tradicionales dejan about vacío o lo rellenan con texto libre, y mentions ni siquiera aparece. El resultado es una página ambigua: el Knowledge Graph de Google y los motores generativos no pueden determinar con precisión de qué trata tu contenido, así que eligen citar a otro que sí lo dejó claro.

En la era de la búsqueda generativa, declarar de qué trata una página con una entidad verificable, no con una frase, es la diferencia entre ser resuelto y ser ignorado. Los motores generativos no leen keywords, resuelven entidades. Y para resolver una entidad necesitan saber exactamente cuál es el tema central y cuáles son las menciones accesorias.

Qué es la propiedad about: el tema central de la página

La propiedad about define el sujeto principal del recurso. En el vocabulario de Schema.org, about es el vínculo semántico entre un WebPage, un Article o un CreativeWork y la entidad que constituye su asunto. Si escribes un artículo sobre el entity linking, el nodo about debería apuntar a la entidad “entity linking”, no a un texto que diga “entity linking”.

La diferencia práctica es enorme. Cuando about apunta a una entidad con un identificador verificable, el motor puede triangular: qué es esta página, a qué entidad se refiere, cómo se relaciona esa entidad con el resto del grafo de tu sitio. Cuando about es un string de texto libre, el motor solo tiene una cadena de caracteres sin identidad, sin Q-ID, sin conexión con Wikidata.

Qué es la propiedad mentions: lo que aparece de paso

La propiedad mentions declara entidades que el contenido nombra, pero que no son su tema. Un artículo sobre “cómo estructurar un cotizador web” puede mencionar a WordPress, a un plugin de SEO o a una región geográfica. Ninguna de esas entidades es el tema del artículo, pero todas aportan contexto que el motor debería poder conectar.

Cuando mentions se emite como referencia a entidades verificadas, el grafo de la página gana riqueza contextual sin diluir el tema central. El motor entiende: “este contenido trata de cotizadores, y en el camino menciona estas tecnologías y estas localidades”. Eso es exactamente el tipo de precisión que los motores generativos necesitan para decidir a quién citar cuando responden una pregunta con matices.

La diferencia que importa para los motores generativos

Los motores generativos comparan grafos de conocimiento, no páginas sueltas. Cuando un usuario pregunta a una IA “¿qué agencia de SEO B2B opera en la Región Metropolitana?”, el sistema resuelve entidades: necesita identificar qué organización es una agencia, qué servicios ofrece, qué cobertura territorial declara y quién la respalda. Las propiedades about y mentions son parte de esa resolución.

Una página con about bien anclado a una entidad verificable le dice al motor de forma inequívoca de qué trata. Una página con mentions bien referenciado le entrega el contexto accesorio sin contaminar el tema. Una página que deja ambas propiedades en texto libre le entrega ruido. El motor, ante el ruido, elige la página que le dio señal.

Por qué el texto libre ya no alcanza

El SEO de keywords entrenó a una generación entera a pensar que repetir una frase es suficiente. “Consultoría SEO B2B”, escrito veinte veces, no es una entidad: es una cadena de caracteres. Sin un identificador, sin un sameAs, sin una conexión con una fuente verificable, ese texto es indistinguible de cien mil páginas que repiten lo mismo. La extracción de entidades (NER) de los motores modernos distingue entre el string y la entidad, y premia a quien declara la entidad.

Nota de entidad: cómo un Q-ID transforma texto en dato

La solución tecnológica: SemanticGEO

SemanticGEO resuelve el problema de about y mentions en la raíz: lo hace sobre el grafo que Yoast SEO ya emite en tu WordPress, extendiéndolo mediante Graph Stitching. En lugar de escribir strings, defines cada entidad una sola vez en una biblioteca central con su Q-ID de Wikidata validado en tiempo real contra la API, y el plugin la referencia por @id en todo el sitio.

• Validación en tiempo real contra la API de Wikidata: cada Q-ID se comprueba al importar; un dígito equivocado no se instala jamás.
• Graph Stitching sobre Yoast: extiende el grafo existente en lugar de competir con él, cosiendo los nodos about, mentions y sameAs sobre el grafo que Google ya conoce.
• 13 packs de nicho importables: despliegas una base de entidades coherente para tu vertical en minutos, con Q-IDs verificados en vivo.
• llms.txt automático: un render en Markdown del grafo, generado desde las mismas entidades, para que los crawlers de IA lean la versión sin ambigüedades.
• Cero tipeo manual: el buscador de Wikidata integrado rellena el Q-ID y la URL de Wikipedia verificados al seleccionar.

Los Términos Semánticos del plugin aplican esta lógica por página: si un término coincide con una entidad de tu biblioteca, se emite en keywords y se auto-ancla a mentions con su sameAs verificado. Texto libre para el editor, entidad comprobable para el grafo.

Preguntas frecuentes

¿Qué diferencia hay entre about y mentions en Schema.org?

about declara el tema central del recurso, la entidad que constituye su asunto principal. mentions declara entidades que el contenido nombra de forma accesoria, sin que sean su tema. La primera responde “de qué trata esta página”; la segunda, “qué aparece de paso en ella”.

¿Por qué no basta con escribir el tema en texto plano?

Un texto libre es una cadena de caracteres sin identidad. Para que un motor lo convierta en dato, necesita un identificador verificable: un Q-ID de Wikidata, un enlace sameAs, una entidad resoluble. Sin eso, tu página es indistinguible de miles que repiten la misma frase.

¿Cómo afecta esto a que una IA cite mi empresa?

Los motores generativos comparan grafos de conocimiento y eligen la entidad más completa y verificable. Declarar de qué trata cada página con entidades ancladas, y separar menciones de tema, entrega la señal precisa que estos sistemas consumen. Ningún plugin puede garantizar la citación, pero sí puede entregar la implementación técnica más rigurosa de los factores que declaran consumir.

¿Puedo declarar about y mentions en WordPress sin escribir JSON-LD a mano?

Sí. SemanticGEO lo hace por ti: define cada entidad una vez en la biblioteca central, y el plugin referencia about, mentions y sameAs por @id sobre el grafo que Yoast SEO ya emite. El buscador de Wikidata integrado rellena el Q-ID y la URL de Wikipedia verificados, sin tipeo manual.

¿La propiedad mentions sustituye a las frases clave relacionadas?

En el enfoque de SemanticGEO sí: los Términos Semánticos se emiten en keywords y, si coinciden con una entidad de la biblioteca, se promocionan a mentions con sameAs verificado. Es la alternativa a las frases clave relacionadas de Yoast Premium, funcionando sobre la versión gratuita y saliendo al marcado.

Conclusión

Distinguir entre about y mentions no es un detalle de vocabulario: es la diferencia entre una página que declara su tema con precisión verificable y una que solo acumula texto. En la búsqueda generativa, esa precisión decide si el motor te resuelve o te ignora. SemanticGEO automatiza la parte difícil: entidades ancladas a Wikidata, referencias por @id y un grafo coherente que los motores generativos pueden leer sin ambigüedad.

Los word embeddings son la técnica de procesamiento del lenguaje natural (NLP) que convierte cada palabra en un vector, es decir, una lista de números que la posiciona en un espacio de significado continuo. En ese espacio, “abogado” y “jurista” quedan cerca, mientras que “abogado” y “zanahoria” quedan lejos. Respuesta directa: no son palabras clave ni etiquetas, son coordenadas.

Para el SEO esto lo cambia todo. Un motor que busca por embeddings no compara cadenas de texto, compara posiciones en el espacio vectorial. Por eso “cómo arreglar un computador” y “reparar un PC” le parecen la misma consulta aunque no compartan ni una palabra. Y por eso tu página ya no compite por keywords: compite por cuán resuelta está su entidad dentro de ese espacio.

Esta es la capa matemática que sostiene el Knowledge Graph, la búsqueda semántica y el GEO. Entenderla es entender, de una vez, por qué los motores generativos resuelven entidades y no leen palabras.

Del texto a las coordenadas: qué es exactamente un embedding

Una palabra, para una máquina, es solo una secuencia de caracteres. El problema es que dos palabras con el mismo significado pueden escribirse distinto, y dos palabras idénticas pueden significar cosas distintas según el contexto. Los embeddings resuelven esto representando cada palabra como un punto en un espacio de cientos de dimensiones, donde la distancia entre dos puntos mide su relación de significado.

La idea central es la hipótesis distribucional: una palabra se define por las palabras que la rodean. “Banco” aparece junto a “crédito”, “depósito” o “sucursal”, y también junto a “plaza”, “sentarse” o “parque”. El embedding captura esas dos regiones del espacio como vecindarios distintos, de modo que el mismo token “banco” puede quedar cerca de “finanzas” o de “mobiliario urbano” según el contexto de la frase. Esa es la diferencia clave frente a una keyword: la keyword es una cadena fija, el embedding es una posición que se ajusta al contexto.

De Word2vec a los transformers: cómo se aprende el significado

En 2013, el modelo Word2vec (Q22673982) popularizó la idea: entrenar una red neuronal para predecir una palabra a partir de sus vecinas, y quedarse con los pesos internos de esa red como el vector de cada palabra. El resultado fue una propiedad sorprendente, la llamada aritmética semántica: rey - hombre + mujer ≈ reina. El significado dejó de ser un diccionario y se volvió una geometría.

Los transformers, la arquitectura detrás de los modelos actuales, llevaron esto un paso más allá con los embeddings contextuales. Ya no hay un único vector para “banco”: hay un vector distinto para “banco” en “retiré dinero del banco” y en “me senté en el banco”. La palabra se resuelve en función de toda la oración. Cuando un LLM decide si tu empresa es relevante para una consulta, no está comparando palabras: está midiendo la distancia entre el vector de la consulta y el vector de tu contenido dentro de ese espacio de significado.

Similitud semántica: por qué “auto” y “coche” son el mismo punto

La similitud semántica (Q2268914) es la métrica que cuantifica qué tan cerca están dos significados. En el espacio de embeddings se calcula típicamente con la similitud coseno, un número entre 0 y 1 que mide el ángulo entre dos vectores, no su longitud. Dos palabras con el mismo significado apuntan casi en la misma dirección, aunque su frecuencia de aparición sea distinta.

Esto explica por qué la estrategia de “sinónimos exactos” que usábamos en el SEO de keywords quedó obsoleta. Ya no necesitas repetir “auto”, “coche”, “vehículo” y “automóvil” por separado para cubrir variantes: un motor basado en embeddings las resuelve como la misma región del espacio. El trabajo del SEO semántico ya no es amontonar cadenas, es asegurarse de que la entidad que representas tenga una posición clara, densa y sin ambigüedad.

Nota de Entidad: de texto libre a dato estructurado

De los embeddings al Knowledge Graph: el puente que falta en tu web

Hay una confusión frecuente: se cree que basta con “escribir semánticamente” para que la IA te entienda. No es así. Los embeddings son la representación interna del modelo, un espacio que vive dentro del sistema y que tú no controlas. El Knowledge Graph de Google (Q648625) y los grafos que alimentan a los LLMs son la representación externa y verificable, la que tú sí puedes construir con datos estructurados.

La pieza que conecta ambos mundos es la entidad desambiguada. Un embedding te dice que “empresa de SEO en Santiago” y “consultora semántica en Chile” apuntan a la misma región de significado, pero no te dice de cuál empresa hablas. Solo un grafo con sameAs verificable y Q-ID de Wikidata le permite al modelo resolver que ese significado corresponde exactamente a tu organización y no a tu competidor. Por eso el Entity SEO y la Topical Authority no son modas: son la forma de asegurar que tu posición en el espacio vectorial esté ocupada por tu entidad, y no por una ambigua.

La solución tecnológica: SemanticGEO

SemanticGEO aborda exactamente este puente. Es un plugin de GEO para WordPress que extiende el grafo de Yoast SEO mediante Graph Stitching: cose nodos de entidad sobre el grafo que Google ya conoce, en lugar de emitir bloques JSON-LD aislados. Cada entidad de tu biblioteca central queda anclada a Wikipedia y Wikidata con sameAs doble y Q-ID verificado en tiempo real contra la API de Wikidata. No escribes identificadores a mano: el buscador integrado valida cada Q-ID antes de instalarlo, y los 13 packs de nicho importan una base de entidades coherente en minutos, con sus identificadores comprobados durante la importación.

El resultado es una web que deja de depender del texto libre para posicionarse en el espacio de significado. Tu organización, tus servicios, tu cobertura territorial y tu autor de contenido se publican como nodos resueltos y referenciados por @id, y el archivo llms.txt se genera automáticamente desde ese grafo para que los crawlers de IA lean un resumen técnico sin ambigüedad. No prometemos citación: entregamos la implementación técnica más rigurosa de los factores que estos sistemas declaran y demuestran consumir.

Preguntas frecuentes

¿Qué es un word embedding?

Es la representación de una palabra como un vector de números en un espacio de significado continuo, donde palabras con sentido similar quedan cerca entre sí. Es la base matemática que permite a los motores y modelos de lenguaje comparar significado en lugar de comparar cadenas de texto.

¿Por qué los word embeddings hacen obsoletas las palabras clave?

Porque una keyword es una cadena fija y un embedding es una posición ajustable al contexto. Dos consultas sin palabras en común, como “reparar PC” y “arreglar computador”, se resuelven como la misma región del espacio vectorial, algo que el emparejamiento exacto de keywords no podía detectar.

¿En qué se diferencian los embeddings del Knowledge Graph?

Los embeddings son la representación interna del modelo, que tú no controlas. El Knowledge Graph es la representación externa y verificable, que sí construyes con datos estructurados. El puente entre ambos es la entidad desambiguada, anclada con Q-ID de Wikidata y sameAs verificable.

¿Basta con escribir semánticamente para que la IA me entienda?

No. El texto semántico ayuda, pero el modelo necesita datos estructurados para resolver a qué entidad concreta se refiere tu contenido. Sin un grafo con identificadores verificables, tu posición en el espacio de significado puede quedar ocupada por un competidor o por una entidad ambigua.

¿Cómo anclo mi empresa al espacio de significado de forma verificable?

Publicando un grafo de conocimiento coherente con nodos de entidad anclados a Wikidata mediante Q-ID validado y sameAs doble. Es justo lo que SemanticGEO automatiza sobre WordPress, extendiendo el grafo de Yoast SEO en lugar de reemplazarlo.

Conclusión

Los word embeddings son la razón de fondo por la que la búsqueda dejó de ser un emparejamiento de cadenas y se volvió una resolución de significado. Entender el espacio vectorial es entender por qué las keywords ya no protegen tu tráfico, por qué la similitud semántica reemplazó a los sinónimos exactos y por qué solo una entidad desambiguada y verificable ocupa su lugar en ese espacio. El SEO que sobrevive no escribe más palabras: publica una entidad que la IA pueda resolver.

Google Knowledge Vault es el sistema de aprendizaje automático que Google presentó en 2014 para construir bases de conocimiento a escala web, de forma automática y sin depender de la edición humana. Extrae entidades y hechos desde texto, tablas, estructura de páginas y anotaciones de Schema.org, los fusiona de forma probabilística y asigna a cada hecho una confianza y una procedencia. Es la prueba técnica más clara de que Google dejó de leer keywords y pasó a construir grafos de entidades.

Para el consultor SEO y el director de marketing B2B, Knowledge Vault importa por una razón concreta: confirma que Google extrae entidades de la web de forma automática y les asigna una probabilidad de ser correctas. Si tu negocio no está anclado a fuentes verificables y no emite datos estructurados consistentes, el sistema no puede resolverte con confianza. Los motores generativos no leen keywords, resuelven entidades, y Knowledge Vault es el motor que las construye.

En este artículo explico qué es Knowledge Vault, cómo fusiona cuatro fuentes de extracción en un único grafo, por qué cada hecho nace con una probabilidad de certeza, y qué implica esto para una estrategia de Entity SEO y GEO que pretenda ser resuelta por la búsqueda generativa.

Del Knowledge Graph curado a la extracción automática

Para entender qué es Knowledge Vault hay que entender qué es lo que intenta ampliar. El Knowledge Graph que Google lanzó en 2012 se construyó, en buena medida, desde fuentes curadas como Freebase y Wikipedia: bases de conocimiento editadas por humanos, con alta precisión pero crecimiento limitado. El problema era de escala: el mundo de las entidades crece más rápido de lo que un equipo humano puede catalogar.

Knowledge Vault fue la respuesta. En lugar de depender de editores, propuso extraer hechos directamente de la web a gran escala, aceptando que la extracción automática introduce incertidumbre. La solución a esa incertidumbre no fue evitarla, sino medirla: cada hecho extraído lleva asociada una confianza y una procedencia, y la fusión final se hace con aprendizaje supervisado que calibra la probabilidad de que cada tripleta sea correcta.

Las cuatro fuentes de extracción que lo alimentan

El paper original de Dong et al. (KDD 2014) describe un sistema que combina cuatro extractores, cada uno con sus propias fortalezas:

• Extracción de texto (NL text): procesamiento de lenguaje natural sobre el contenido de las páginas, el extractor más ruidoso por sí solo.
• Estructura de página (DOM): lectura de los árboles de documento para identificar pares de entidades y clasificar la relación que los conecta.
• Tablas (TBL): extracción de datos tabulares, una fuente de hechos estructurados de alta densidad.
• Anotaciones de webmaster (ANO): lectura directa del marcado Schema.org que ya publica cerca del 20% de las páginas web.

El dato decisivo para el SEO es el último: Google mapea automáticamente el marcado Schema.org hacia su esquema interno y lo convierte en hechos de su grafo. Tu dato estructurado no es un adorno para un validador: es una fuente de extracción que el sistema de Google consume para construir conocimiento.

Por qué cada hecho nace con una probabilidad de certeza

Knowledge Vault es una base de conocimiento probabilística. A diferencia de un grafo curado, donde cada tripleta es una afirmación binaria de verdad, aquí cada hecho es una distribución de confianza. El sistema reportó en 2014 una escala de 2.500 millones de tripletas extraídas automáticamente, fusionadas desde las cuatro fuentes mediante aprendizaje supervisado que calibra la probabilidad de corrección de cada una.

Esto tiene una implicación directa para cualquier negocio. Google no necesita estar seguro de todo: necesita poder estimar qué tan seguro está. Y esa estimación mejora cuando la misma entidad aparece de forma consistente en múltiples fuentes. Si tu marca está anclada a Wikidata con sameAs verificado, emite schema coherente en todo el sitio y se referencia a sí misma por @id, le das al sistema señales convergentes que suben la confianza de la extracción. Si la escribes distinto en cada página, le das ruido que baja la probabilidad.

La consistencia como señal de confianza

El proceso de fusión probabilística (knowledge fusion) pondera las fuentes según su fiabilidad y converge cuando varias de ellas apuntan al mismo hecho. Por eso una entidad con nombre canónico único, Q-ID verificado y cobertura territorial anclada es más fácil de resolver que una entidad ambigua escrita de tres formas distintas. La Topical Authority y el Entity SEO no son técnicas decorativas: son la forma de maximizar la convergencia que un sistema como Knowledge Vault premia.

Qué significa esto para tu estrategia GEO

Si Google extrae entidades de forma automática desde tu schema, tu WordPress debe dejar de ser una colección de páginas con keywords y convertirse en una entidad única, verificable y consistente. Eso se logra con tres movimientos concretos:

• Anclar tu marca a fuentes verificables: Wikipedia y Wikidata mediante sameAs doble con Q-ID validado contra la API. Sin esto, tu negocio es una entidad ambigua para el extractor.
• Coser tu schema en un grafo coherente: dejar de emitir bloques JSON-LD aislados y referenciar cada nodo por @id, con la organización definida una sola vez.
• Exponer tu grafo a los crawlers de IA: un llms.txt generado desde el grafo, con los hechos de tu entidad, servicios, productos y preguntas frecuentes listos para extracción.

La solución tecnológica: SemanticGEO

SemanticGEO convierte tu WordPress en una entidad que Google y las IAs pueden entender, verificar y citar. Extiende el grafo de conocimiento que Yoast SEO ya genera mediante Graph Stitching: costura nodos nuevos (Person E-E-A-T, Service, SoftwareApplication, cobertura territorial) sobre el grafo existente, referenciados por @id, con cada entidad anclada a Wikipedia y Wikidata mediante sameAs doble con Q-ID verificado en tiempo real contra la API.

La biblioteca central de entidades incluye 13 packs de nicho importables (SEO, Salud, Legal, Logística, Inmobiliario, Educación y más), con los Q-ID validados en vivo durante la importación: cero tipeo manual, cero identificadores sin verificar. El llms.txt se genera automáticamente desde el grafo y nunca se desincroniza del schema. Es la implementación técnica más rigurosa de los factores que los motores generativos declaran consumir, sin promesas de magia.

Preguntas frecuentes sobre Knowledge Vault y SEO

¿Qué es Google Knowledge Vault y para qué sirve?

Knowledge Vault es el sistema de aprendizaje automático que Google presentó en 2014 para construir bases de conocimiento a escala web. Extrae entidades y hechos desde texto, tablas, estructura de páginas y anotaciones de Schema.org, los fusiona de forma probabilística y asigna a cada hecho una confianza y una procedencia.

¿Qué diferencia a Knowledge Vault del Knowledge Graph de Google?

El Knowledge Graph lanzado en 2012 se construyó principalmente desde fuentes curadas como Freebase y Wikipedia, con alta precisión pero crecimiento limitado. Knowledge Vault amplía ese grafo extrayendo hechos automáticamente de la web a gran escala, aceptando incertidumbre y midiéndola con probabilidades calibradas de corrección.

¿Google realmente extrae entidades de mi marcado Schema.org?

Sí. El extractor ANO (annotations) del paper de Knowledge Vault mapea automáticamente el marcado Schema.org hacia el esquema interno de Google y lo convierte en hechos de su grafo. Por eso un schema coherente, verificado y consistente en todo el sitio mejora la probabilidad de que tu entidad sea extraída con confianza.

¿Cómo preparo mi sitio para que Google y las IAs me resuelvan como entidad?

Anclando tu marca a Wikidata mediante Q-ID verificado y sameAs, cosiendo tu schema en un grafo coherente referenciado por @id, y exponiendo tu grafo a los crawlers de IA con un llms.txt generado desde los datos estructurados. Es exactamente lo que SemanticGEO automatiza sobre WordPress y Yoast SEO.

¿Un plugin puede garantizar que Google o un LLM me cite?

No. Ningún identificador, plugin o archivo llms.txt puede garantizar citación en motores generativos. Knowledge Vault y los LLMs son sistemas probabilísticos, y llms.txt es un estándar emergente aún no confirmado por los proveedores. Lo que sí se puede hacer es implementar de forma rigurosa los factores que estos sistemas declaran consumir: entidades ancladas, grafo coherente y contenido extraíble.

Conclusión

Knowledge Vault es la prueba de que Google dejó de curar entidades a mano y pasó a extraerlas automáticamente de la web, midiendo la confianza de cada hecho. Tu marcado Schema.org no es un requisito formal: es una fuente de extracción que alimenta el grafo del que la búsqueda generativa resuelve respuestas. La diferencia entre ser resuelto y ser ignorado no está en las keywords, sino en la consistencia y verificabilidad de tu entidad.

Si tu WordPress todavía está optimizado para keywords sueltas, estás dejando que el extractor te lea con baja confianza. La búsqueda de la era de los grafos y de los motores generativos recompensa a la entidad más completa, verificable y consistente del vertical. Esa es la apuesta de SemanticGEO: no magia, sino la implementación técnica más rigurosa de los factores que Google y las IAs demuestran consumir.

Google MUM (Multitask Unified Model) es el modelo multimodal de inteligencia artificial que Google presentó en mayo de 2021 y que, para efectos prácticos del SEO, sentencia el fin definitivo del posicionamiento basado en palabras clave. MUM entiende información de forma simultánea en texto, imagen, video y audio, y es mil veces más potente que su antecesor BERT. No busca palabras: resuelve tareas complejas comparando entidades y significado a través de formatos.

Para el consultor SEO y el director de marketing B2B, MUM importa por una razón concreta: confirma que la evolución algorítmica de Google dejó de premiar la repetición de términos y pasó a recompensar la resolución de entidades. Si tu sitio está optimizado para keywords sueltas y no para ser entendido como una entidad verificable, la búsqueda de la era MUM sencillamente no puede resolverte con confianza. Los motores generativos no leen keywords, resuelven entidades.

En este artículo explico la línea evolutiva que va de Hummingbird a MUM, por qué cada salto fue alejando a Google del texto literal y acercándolo al significado, y qué implica esto para una estrategia de Entity SEO y GEO que pretenda sobrevivir a la búsqueda generativa.

De Hummingbird a MUM: la línea evolutiva que enterró las keywords

Para entender qué es MUM hay que mirar la secuencia de actualizaciones que lo precedieron. Cada una fue quitándole peso al texto literal y sumándole peso al significado. Quien vea la secuencia completa entiende por qué el SEO de densidad de keywords quedó obsoleto de forma irreversible.

Hummingbird (2013): el primer golpe al texto literal

En 2013, Google Hummingbird reescribió el algoritmo de búsqueda para interpretar la intención detrás de una consulta en lugar de casar palabras exactas. Fue la primera señal pública de que Google comenzaba a construir un Knowledge Graph semántico y a tratar las consultas como preguntas sobre entidades, no como cadenas de texto a emparejar.

RankBrain (2015): el significado entra por la puerta

En 2015, RankBrain introdujo el aprendizaje automático en el núcleo del ranking. Su función era interpretar consultas nunca antes vistas, incluso con errores de escritura o sintaxis ambigua, proyectándolas sobre vectores de significado. Por primera vez, Google ya no dependía de que el usuario escribiera la keyword exacta: entendía a qué se refería.

BERT (2019): el contexto bidireccional

En 2019, BERT (Bidirectional Encoder Representations from Transformers) permitió a Google leer cada palabra en relación con todas las demás de la frase, en ambas direcciones. Esto destrozó el mito de la palabra clave aislada: el significado de un término depende de su contexto, y Google empezó a modelarlo así en una décima parte de las consultas en inglés desde su lanzamiento.

MUM (2021): multimodal y mil veces más potente

MUM lleva esa lógica al extremo. Es un modelo basado en la arquitectura transformer, igual que BERT, pero entrenado para ser multimodal: procesa texto, imagen, video y audio de forma simultánea. Puede recibir una foto y devolver una respuesta textual, o cruzar información en 75 idiomas distintos. Google lo describe como mil veces más potente que BERT. Su nombre lo dice todo: Multitask Unified Model, un modelo unificado que resuelve varias tareas a la vez.

La implicación para el SEO es directa: si un modelo puede entender una imagen y su contexto textual a la vez, el contenido que solo existe como palabras sueltas pierde la mitad de su señal. Solo las entidades, definidas y ancladas de forma consistente, sobreviven como unidad estable de significado a través de formatos.

Por qué MUM es la sentencia final del SEO de keywords

MUM no indexa páginas: resuelve tareas complejas

El caso que Google usó para presentar MUM lo aclara todo. El modelo recibió la pregunta de si un usuario que ya escaló el monte Adams podría escalar el Fuji en otoño, y fue capaz de descomponerla en subtareas: comparar altitudes, evaluar la dificultad, cruzar condiciones climáticas y recomendar un plan. Ninguna de esas respuestas vive en una sola página web. MUM sintetiza información desde múltiples fuentes y formatos.

Esto es exactamente lo que hoy hacen los motores generativos como Google AI Overviews, ChatGPT Search o Perplexity. Ya no clasifican páginas: responden preguntas citando entidades. La keyword era la unidad de una búsqueda que listaba documentos. La entidad es la unidad de una búsqueda que compone respuestas.

Multimodalidad: el texto ya no es suficiente

MUM puede responder con una combinación de texto e imagen, y puede recibir una imagen como consulta. Para un negocio, esto significa que su identidad debe estar modelada de forma coherente en todos los formatos: el nombre canónico, la cobertura territorial, los servicios y las personas que lo respaldan. Un grafo de conocimiento bien construido es la única representación que se mantiene estable cuando el modelo cruza texto, imagen y video.

La entidad como única unidad estable de significado

Frente a un modelo multimodal y multilingüe, el texto libre es ambiguo y frágil. Una entidad anclada a Wikidata mediante sameAs con Q-ID verificado, en cambio, es un nodo identificado que el modelo puede resolver igual en español, inglés o frente a una imagen de tu logo. El Entity SEO no es una moda: es la consecuencia inevitable de una infraestructura de búsqueda que dejó de leer keywords y empezó a resolver entidades.

Qué significa esto para tu estrategia GEO

Si MUM y los motores generativos resuelven entidades, tu WordPress debe dejar de ser una colección de páginas con keywords y convertirse en una entidad única, verificable y consistente. Eso se logra con tres movimientos concretos:

• Anclar tu marca a fuentes verificables: Wikipedia y Wikidata mediante sameAs doble con Q-ID validado contra la API. Sin esto, tu negocio es una entidad ambigua para el modelo.
• Coser tu schema en un grafo coherente: dejar de emitir bloques JSON-LD aislados y referenciar cada nodo por @id, con la organización definida una sola vez.
• Exponer tu grafo a los crawlers de IA: un llms.txt generado desde el grafo, con los hechos de tu entidad, servicios, productos y preguntas frecuentes listos para extracción.

La solución tecnológica: SemanticGEO

SemanticGEO convierte tu WordPress en una entidad que Google y las IAs pueden entender, verificar y citar. Extiende el grafo de conocimiento que Yoast SEO ya genera mediante Graph Stitching: costura nodos nuevos (Person E-E-A-T, Service, SoftwareApplication, cobertura territorial) sobre el grafo existente, referenciados por @id, con cada entidad anclada a Wikipedia y Wikidata mediante sameAs doble con Q-ID verificado en tiempo real contra la API.

La biblioteca central de entidades incluye 13 packs de nicho importables (SEO, Salud, Legal, Logística, Inmobiliario, Educación y más), con los Q-ID validados en vivo durante la importación: cero tipeo manual, cero identificadores sin verificar. El llms.txt se genera automáticamente desde el grafo y nunca se desincroniza del schema. Es la implementación técnica más rigurosa de los factores que los motores generativos declaran consumir, sin promesas de magia.

Preguntas frecuentes sobre Google MUM y SEO

¿Qué es Google MUM y para qué sirve?

MUM (Multitask Unified Model) es el modelo multimodal de Google presentado en 2021 que entiende texto, imagen, video y audio de forma simultánea, mil veces más potente que BERT. Sirve para resolver tareas de búsqueda complejas que requieren sintetizar información de múltiples fuentes y formatos en una sola respuesta.

¿MUM eliminó definitivamente el SEO de palabras clave?

No eliminó la optimización, pero sí dejó obsoleto el enfoque basado en repetir keywords. MUM confirma que Google resuelve significado y entidades, no cadenas de texto. La optimización que sobrevive es la que estructura el contenido como una entidad verificable, no la que persigue densidad de términos.

¿Cómo preparo mi sitio para la búsqueda multimodal y generativa?

Anclando tu marca a Wikidata mediante Q-ID verificado y sameAs, cosiendo tu schema en un grafo coherente referenciado por @id, y exponiendo tu grafo a los crawlers de IA con un llms.txt generado desde los datos estructurados. Es exactamente lo que SemanticGEO automatiza sobre WordPress y Yoast SEO.

¿Un plugin puede garantizar que MUM o ChatGPT me citen?

No. Ningún identificador, plugin o archivo llms.txt puede garantizar citación en motores generativos. MUM y los LLMs son sistemas probabilísticos y llms.txt es un estándar emergente aún no confirmado por los proveedores. Lo que sí se puede hacer es implementar de forma rigurosa los factores que estos motores declaran consumir: entidades ancladas, grafo coherente y contenido extraíble.

¿Qué diferencia a SemanticGEO de otros plugins de schema?

SemanticGEO no emite bloques JSON-LD aislados como los plugins de schema tradicionales. Extiende el grafo de Yoast SEO mediante Graph Stitching, define cada entidad una sola vez con Q-ID verificado contra la API de Wikidata, y genera un llms.txt sincronizado con el grafo. Es un grafo coherente para todo el sitio, no islas de datos por página.

Conclusión

MUM es el punto de no retorno. La línea Hummingbird → RankBrain → BERT → MUM describe un solo movimiento: Google dejó de emparejar palabras y empezó a resolver entidades a través de formatos e idiomas. Frente a un modelo multimodal, el texto libre es ambiguo y frágil; una entidad anclada a Wikidata con Q-ID verificado es un nodo estable que la máquina puede resolver con confianza.

Si tu WordPress todavía está optimizado para keywords sueltas, estás compitiendo en un juego que ya no se juega. La búsqueda de la era MUM y de los motores generativos recompensa al grafo más completo, verificable y consistente del vertical. Esa es la apuesta de SemanticGEO: no magia, sino la implementación técnica más rigurosa de los factores que Google y las IAs demuestran consumir.

Antes de que existiera ChatGPT, antes de que Google lanzara los AI Overviews, hubo una decisión técnica que cambió el destino del SEO: Google dejó de indexar solo páginas y empezó a construir una base de conocimiento formada por entidades. Ese proyecto se llamó Knowledge Graph y se presentó en mayo de 2012. Hoy, cada motor generativo que responde preguntas citando empresas es heredero directo de esa infraestructura.

Lo que casi nadie explica es que el Knowledge Graph no nació de la nada. Se construyó cosiendo tres fuentes: Freebase (la base de conocimiento abierta que Google compró y absorbió), Wikidata (el grafo libre que la reemplazó) y Schema.org (el vocabulario que estandarizó cómo se marca el dato estructurado en la web). Entender ese backbone es entender por qué un Q-ID de Wikidata, un sameAs y un nodo Schema bien conectado son hoy la diferencia entre ser citado por la IA o ser invisible para ella.

En este artículo desarmamos ese esqueleto pieza por pieza y te mostramos por qué tu WordPress necesita alimentarlo con entidades verificables, no con keywords.

De Freebase a Wikidata: la base de conocimiento que Google ya tenía

En 2010, Google compró una empresa llamada Metaweb, creadora de Freebase, una base de datos abierta y colaborativa que almacenaba millones de entidades y las relaciones entre ellas. Freebase no guardaba palabras: guardaba nodos (personas, organizaciones, lugares, conceptos) y aristas (relaciones del tipo “trabaja en”, “nació en”, “fundó”). Ese es el corazón de un grafo de conocimiento: datos conectados, no documentos apilados.

Freebase se convirtió en la semilla del Knowledge Graph. Google la fusionó con otras fuentes y luego lanzó un proyecto interno aún más ambicioso, el Knowledge Vault, que extraía hechos probabilísticos de forma automática desde la web. El problema: mantener Freebase era caro y su comunidad migró en masa hacia Wikidata, el proyecto de la Fundación Wikimedia que hoy es el grafo de conocimiento abierto y multilingüe más grande del mundo.

En 2016, Google apagó Freebase y declaró oficialmente que Wikidata era su sucesor natural. Ahí está la clave que la mayoría de los SEO no conecta: el Knowledge Graph que Google usa para resolver entidades, y las bases que los modelos generativos consultan para decidir a quién citar, comparten el mismo anclaje: Wikidata y sus Q-IDs.

Schema.org: el vocabulario que estandarizó el marcado

En paralelo, Google, Microsoft, Yahoo y Yandex se unieron en 2011 para crear Schema.org, un vocabulario común que define cómo se declaran las entidades dentro de una página. Si Freebase y Wikidata son la base de conocimiento, Schema.org es el lenguaje con el que tu web le dice al motor “yo soy una organización, este es mi fundador, aquí opero y esto es lo que sé hacer”.

La pieza que une ambos mundos es la propiedad sameAs. Cuando un nodo Organization lleva un sameAs apuntando a la URL de su Q-ID en Wikidata, estás declarando explícitamente: “esta entidad de mi web y esa entidad del grafo de conocimiento son la misma”. Sin ese enlace, tu sitio es una isla de datos; con él, te conviertes en un nodo resoluble dentro de una red mucho mayor.

Por qué ese backbone es el que leen los motores generativos

Los motores generativos no inventaron una forma nueva de entender el mundo: heredaron la infraestructura que Google construyó durante una década. Cuando ChatGPT, Perplexity o Gemini responden “¿qué consultora SEO B2B me recomiendas en Chile?”, no buscan una página que repita la palabra “consultora SEO B2B Chile”. Resuelven entidades: identifican qué organizaciones existen, qué saben hacer, dónde operan y quién las respalda, cruzando su propia base de conocimiento contra lo que tu web declara.

Por eso el SEO de entidades no es una moda: es la consecuencia lógica de que el backbone de la búsqueda dejó de ser un índice de documentos y pasó a ser un grafo de entidades. Si tu sitio no alimenta ese grafo con identificadores verificables, el motor no tiene forma de distinguirte de cientos de competidores con un nombre parecido.

La solución tecnológica: SemanticGEO

La mayoría de los plugins de SEO emiten bloques JSON-LD aislados y desconectados, con entidades escritas distinto en cada página y sin anclaje a fuentes verificables. Eso es exactamente lo contrario de lo que el backbone del Knowledge Graph espera. SemanticGEO lo resuelve aplicando Graph Stitching sobre el grafo que Yoast SEO ya genera en tu WordPress: cose nodos Person E-E-A-T, Service y cobertura territorial referenciados por @id, y ancla cada entidad a Wikipedia y Wikidata mediante sameAs doble con Q-ID validado en tiempo real contra la API.

La biblioteca central de entidades es el corazón del producto: defines cada entidad una sola vez, con su nombre canónico, su Q-ID verificado y su URL de Wikipedia, y la reutilizas en todo el sitio sin inconsistencias. Incluye 13 packs de nicho importables (SEO, salud, legal, fintech, inmobiliario, educación y más), cuyos Q-IDs se validan en vivo durante la importación, con cero tipeo manual. Y para que los motores generativos lean tu grafo sin ambigüedades, SemanticGEO genera automáticamente un llms.txt renderizado desde el grafo, nunca desincronizado del schema.

Preguntas frecuentes

¿Qué es el backbone del Knowledge Graph?

Es la infraestructura de entidades sobre la que Google construyó su búsqueda semántica: Freebase, que luego se fusionó y migró a Wikidata, más el vocabulario Schema.org que estandariza el marcado de datos en la web. Esa misma base es la que los motores generativos consultan hoy para resolver y citar entidades.

¿Por qué Freebase fue reemplazado por Wikidata?

Mantener Freebase era costoso y su comunidad migró en masa a Wikidata, el grafo abierto y multilingüe de la Fundación Wikimedia. En 2016, Google apagó Freebase y declaró a Wikidata su sucesor natural, lo que convirtió a los Q-IDs en el anclaje de referencia para el SEO de entidades.

¿Cómo conecta Schema.org con el Knowledge Graph?

Schema.org define el vocabulario para declarar entidades dentro de una página, y la propiedad sameAs es el puente: apunta desde el nodo de tu web hacia la URL de su Q-ID en Wikidata, declarando que ambas entidades son la misma. Sin ese enlace, tu sitio es una isla de datos desconectada del grafo.

¿Un Q-ID garantiza que la IA me cite?

No. Ningún identificador ni plugin puede garantizar citación en motores generativos. Un Q-ID verificado es la implementación técnica más rigurosa de los factores que estos motores declaran y demuestran consumir: hace tu entidad verificable y resoluble, pero la decisión final de citarte siempre depende del motor.

Conclusión

El Knowledge Graph no es un extra del SEO: es el esqueleto sobre el que se levantó la búsqueda moderna y el que los motores generativos heredaron sin cambios. Freebase aportó la idea de grafo, Wikidata aportó los Q-IDs abiertos y Schema.org aportó el lenguaje de marcado. Si tu WordPress sigue emitiendo texto libre y bloques schema aislados, estás hablando un idioma que el motor ya no escucha. La ventaja competitiva hoy no está en repetir keywords, sino en alimentar ese backbone con entidades verificables, conectadas y consistentes en todo el sitio.

El SEO cambió de dueño el día en que Google dejó de contar palabras para empezar a entender significado. Y el punto de quiebre técnico tiene nombre propio: BERT. En 2019, Google anunció que este modelo de lenguaje había entrado a su buscador para entender mejor las consultas, y desde entonces la unidad de trabajo del SEO dejó de ser la palabra clave y pasó a ser la entidad: quién es quién, qué relación tiene con qué, y qué fuentes verificables lo respaldan.

La respuesta corta a por qué esto te afecta: si sigues optimizando como si el buscador fuera un contador de frecuencias léxicas, estás compitiendo en un juego que ya no existe. Los BERT y los transformers convirtieron la búsqueda en un problema de resolución de grafos: el motor no busca tu página por las keywords que repites, sino que intenta resolver tu entidad dentro de un Knowledge Graph.

En este artículo vas a entender, sin humo y con la capa técnica correcta, qué es BERT, por qué la arquitectura transformer redefinió el procesamiento del lenguaje natural, y qué implica para ti como consultor, agencia o negocio que quiere ser citado por Google y por los motores generativos.

Qué hizo BERT: entender el contexto, no la palabra suelta

BERT (Bidirectional Encoder Representations from Transformers) fue publicado por Google Research en 2018 y es, en esencia, un modelo que lee una frase en ambas direcciones a la vez. Antes, los modelos procesaban el texto de izquierda a derecha (o al revés), palabra por palabra. BERT mira cada palabra en relación con todas las demás de la oración, lo que le permite captar el contexto y desambiguar el significado.

La consecuencia práctica fue inmediata. Una consulta como “dónde comprar un banco para sentarme” y “dónde comprar un banco para ahorrar” usan la misma palabra, “banco”, pero significan cosas distintas. El buscador tradicional, basado en coincidencia de términos, podía confundirlas. BERT no: entiende que el contexto decide la entidad a la que te refieres, y responde en consecuencia.

Esto es lo que Google anunció como “la mayor mejora en búsqueda en cinco años”. Y aunque no lo decía en estos términos, estaba diciendo algo más profundo: la búsqueda por significado reemplazó a la búsqueda por cadena de caracteres. El SEO dejó de ser un problema de texto y pasó a ser un problema de identidad.

De los vectores de palabras a los transformers: la revolución silenciosa

Para entender por qué esto es irreversible, hay que bajar una capa. Todo arranca con una idea matemática: representar cada palabra como un vector, una lista de números en un espacio multidimensional. Esa técnica se llama word embedding.

word2vec y el nacimiento de los vectores de significado

En 2013, un equipo de Google publicó word2vec, un método que aprende a representar palabras como vectores densos a partir de grandes volúmenes de texto. La intuición clave: palabras que aparecen en contextos similares tienen vectores cercanos. El resultado más famoso fue aritmético: “rey – hombre + mujer = reina”. El modelo, sin que nadie le enseñara gramática, había aprendido relaciones semánticas codificadas como geometría.

Esto ya insinuaba lo que venía: el significado no vive en la palabra, sino en la relación entre palabras. Un grafo, no una lista. La palabra clave como fetiche estadístico quedó herida de muerte ahí, aunque el mercado SEO tardó años en darse cuenta.

La atención lo cambió todo: la arquitectura transformer

El salto definitivo llegó en 2017, cuando Google Brain publicó el paper Attention Is All You Need, que presentó la arquitectura transformer. Su innovación central es el mecanismo de atención: en lugar de procesar el texto secuencialmente, el modelo pondera de forma dinámica qué partes de la entrada importan más para entender cada elemento. Puede mirar toda la frase a la vez y decidir qué relaciones pesan.

El transformer es la base de prácticamente todo lo que usas hoy: BERT, GPT, Gemini, los modelos que alimentan ChatGPT y Perplexity, y los sistemas de ranking de Google. Todos comparten el mismo principio fundacional: el significado emerge de las relaciones entre entidades, no de la ocurrencia de términos.

Qué implica para tu SEO: las keywords dejaron de ser la unidad de trabajo

Aquí está la traducción operativa para quien vive del SEO. Si el motor entiende significado y resuelve entidades, entonces tu trabajo ya no es “aparecer para la frase X”, sino hacer que tu entidad sea la respuesta correcta a la pregunta que hay detrás de esa frase. Y eso tiene tres consecuencias concretas:

• La keyword deja de ser el objetivo y pasa a ser el síntoma. Una consulta es la superficie de una intención. Si optimizas la superficie y no la entidad, rankeas para una cadena que el motor ya no lee como cadena.
• La ambigüedad te mata. Si tu marca no está desambiguada como entidad, el motor no puede saber cuál de los “bancos” eres tú. Sin identidad verificable, no hay cita posible.
• Las relaciones importan más que las palabras. Quién te fundó, qué sabes hacer, dónde operas, qué fuentes externas te validan: eso es lo que un grafo compara, no cuántas veces escribiste “consultoría SEO B2B”.

El concepto que amarra todo esto es la Topical Authority: no se construye repitiendo términos, sino emitiendo una red coherente de entidades conectadas. Y la Entity SEO es la disciplina que lo operativiza: definir tu entidad una sola vez, anclarla a fuentes verificables y referenciarla por identificadores estables en todo tu sitio.

Nota de entidad

La solución tecnológica: SemanticGEO

Si el motor ya no lee keywords sino que resuelve entidades, la pregunta operativa es cómo convertir tu WordPress en una entidad que Google y las IAs puedan resolver. Ahí entra SemanticGEO: un plugin que extiende el grafo que Yoast SEO ya emite, mediante Graph Stitching. Cose nodos nuevos (Person E-E-A-T, Service, SoftwareApplication, cobertura territorial) sobre el @graph existente, referenciados por @id, en lugar de sumar bloques de schema sueltos.

Cada entidad se ancla a Wikidata mediante sameAs doble con Q-ID verificado en tiempo real contra la API: un dígito equivocado te conectaría a una entidad ajena, y el plugin lo impide. Viene con 13 packs de nicho importables (SEO/Marketing, Salud, Legal, Logística, Tecnología, Fintech y más) para desplegar una base de entidades coherente en minutos por cliente, con cero tipeo manual. Y genera el llms.txt directamente desde el grafo, para entregar a los crawlers de IA un resumen técnico sin ambigüedades.

La lógica es la misma que convirtió a BERT en el estándar: el significado emerge de las relaciones, no de la repetición. SemanticGEO aplica ese principio a tu sitio, para que tu entidad sea la más completa, verificable y consistente de tu vertical. La implementación técnica más rigurosa de los factores que estos motores declaran y demuestran consumir.

Preguntas frecuentes

¿BERT mató las palabras clave para siempre?

No las mató, las degradó. Las keywords siguen siendo la superficie de una intención de búsqueda y conviene conocerlas, pero dejaron de ser la unidad de trabajo. El motor ya no cuenta coincidencias de términos: resuelve entidades dentro de un grafo. Optimizar solo keywords es competir en un juego que BERT y los transformers dejaron obsoleto.

¿Un Q-ID de Wikidata garantiza que Google me entienda?

Un Q-ID verificado no garantiza nada por sí solo, y ningún plugin puede garantizar citación en motores generativos. Lo que sí aporta es identidad verificable: transforma tu mención de texto libre en un nodo que el grafo puede contrastar y desambiguar. Es la implementación técnica más rigurosa de los factores que estos motores declaran consumir, no una promesa de magia.

¿Necesito entender de transformers para hacer SEO hoy?

No necesitas implementar un modelo, pero sí entender la consecuencia: el motor busca significado y relaciones. Eso cambia tu prioridad de “optimizar texto” a “definir una entidad coherente”. El consultor que entiende la diferencia entre keyword y entidad toma decisiones de arquitectura de datos, no de redacción de títulos.

¿Qué relación hay entre BERT y el Knowledge Graph?

BERT entiende la consulta; el Knowledge Graph es la base de datos de entidades contra la que se resuelve esa consulta. BERT desambigua lo que el usuario quiere decir, y el grafo decide qué entidad es la respuesta correcta. Por eso las dos piezas apuntan a lo mismo: si tu entidad no está bien anclada en el grafo, entender la consulta no te sirve de nada.

Conclusión

BERT y los transformers no fueron un cambio cosmético en el buscador: fueron la confirmación de que el significado vive en las relaciones entre entidades, no en la repetición de palabras. El SEO que sigue optimizando keywords está peleando contra la arquitectura misma del motor. El que entiende que Google y las IAs resuelven grafos, y convierte su sitio en una entidad verificable y conectada, es el que queda en posición de ser citado. La pregunta ya no es “¿para qué keyword quieres rankear?”, sino “¿qué tan resoluble es tu entidad?”.