Módulo 5 — Datos estructurados y entidades

🏷Este módulo convierte tu sitio en algo que la IA entiende "con nombres propios". Es un salto sutil pero

Por qué la IA necesita nombres propios

Hay una diferencia enorme entre que un sistema entienda de qué tema hablas y que entienda de qué entidad concreta hablas. Un modelo puede captar perfectamente que tu página trata de "planes de precios" —eso es tema— y a la vez ser incapaz de distinguir tu "Plan Pro" de tu "Plan Team" o de mezclar las características de uno con las del otro —eso es entidad—. El GEO de los primeros módulos te hace visible y legible; el GEO de este módulo te hace inconfundible.

Un agente funciona muchísimo mejor cuando cada cosa importante de tu negocio tiene tres atributos estables: un nombre canónico único, una URL canónica donde vive, y una definición estable que no cambia de una página a otra. Cuando faltan esos tres anclajes, empiezan los problemas clásicos: el sistema confunde el plan A con el plan B, atribuye la característica X al producto equivocado, o funde dos términos que "suenan" parecidos en una sola cosa que no existe. Estas "respuestas mezcladas" son de los errores más dañinos porque son sutiles: la respuesta parece coherente y confiada, pero es falsa, y el usuario no tiene forma de saberlo.

El coste invisible de la inconsistencia

Merece la pena entender por qué la inconsistencia de nombres hace tanto daño, porque es un problema que casi nadie ve hasta que lo busca. Imagina que en tu web llamas a lo mismo de tres formas según la página: en la home es "Plan Profesional", en precios es "Pro", y en un post de blog antiguo era "Plan Business". Para ti son obviamente la misma cosa, porque tienes el contexto completo en la cabeza. Para un modelo de lenguaje, en cambio, son tres cadenas de texto distintas, y no tiene ninguna garantía de que se refieran a la misma entidad. En el mejor caso, las trata como sinónimos con cierta duda; en el peor, las trata como tres productos diferentes y construye una respuesta que inventa un catálogo que no tienes.

Esto se agrava con el mecanismo de recuperación por fragmentos que ya conoces: si tres chunks distintos usan tres nombres distintos para la misma entidad, ninguno refuerza a los otros, y la señal de "esta entidad existe y es importante" se reparte y se diluye en lugar de sumarse. La consistencia de nombres no es una manía de estilo; es lo que permite que todas tus menciones de una entidad se acumulen en una sola señal fuerte en lugar de dispersarse en varias señales débiles.

Dónde encaja BotPass: empieza por las entidades que la IA ya toca

Como en cada módulo, BotPass te evita trabajar a ciegas. No todas tus entidades merecen el mismo esfuerzo de canonización; las prioritarias son las que los bots ya están consumiendo. Usa BotPass para encontrar qué páginas sobre planes, políticas y características clave se están leyendo, porque esas páginas definen las entidades que más necesitan nombres y URLs canónicos para evitar respuestas mezcladas. Empezar por ahí es empezar por donde el riesgo de confusión es real y actual.

Hay además una señal concreta a la que prestar atención: si BotPass muestra que los bots consumen varias páginas distintas sobre la misma entidad, tratálo como un problema de consistencia que hay que resolver ya. Significa que la IA está recibiendo múltiples versiones de la misma verdad, probablemente con nombres o datos ligeramente divergentes, que es la receta exacta de la respuesta mezclada. La solución es la de siempre: consolidar en una fuente canónica y orientar hacia ella, en la línea de lo que trabajaste en el Módulo 3.

La Hoja de Entidades: el diccionario de tu negocio

Si solo hicieras una cosa después de leer este módulo, debería ser construir tu Hoja de Entidades. Es, literalmente, el diccionario de tu negocio: el documento maestro donde defines, de una vez y para siempre, cómo se llama cada cosa, dónde vive y qué significa. Y su poder está en que es la fuente de la que beben todas las demás tareas de GEO: alimenta un copy consistente, un schema consistente, unas vistas limpias consistentes y un llms.txt consistente. Sin ella, cada una de esas piezas se construye por separado y acaban contradiciéndose; con ella, todas cantan la misma canción.

La Hoja de Entidades tiene, además, un beneficio organizativo que va más allá del GEO: obliga a tu equipo a ponerse de acuerdo sobre cómo se llaman las cosas. Muchas veces el ejercicio de rellenarla destapa que ni siquiera internamente había consenso — marketing lo llamaba de una forma, producto de otra, ventas de una tercera—, y ese consenso, una vez fijado, mejora muchísimo más que solo la visibilidad ante la IA. Esta es la tabla que la vertebra:

Qué es el schema y por qué ayuda de verdad

Si la Hoja de Entidades es el diccionario que vive en tu cabeza y en tu documentación, el schema es la forma de decirle ese diccionario a las máquinas en su propio idioma. El schema —datos estructurados, habitualmente en formato JSON-LD— es un bloque de información legible por máquinas que declara explícitamente "qué es qué": esto es una organización, esto es un producto, esto es una pregunta frecuente con su respuesta, esto es una guía con estos pasos. En lugar de obligar al sistema a inferir la estructura a partir del texto visible, se la sirves ya digerida.

El schema es especialmente útil en situaciones concretas: cuando tienes FAQs reales, un FAQPage las hace inequívocas; cuando tienes pasos claros, un HowTo los ordena; cuando quieres reforzar quién eres, un Organization fija tu identidad; y cuando describes servicios o planes, Service o Product los delimitan. Pero hay una regla de oro que no puedes saltarte, y que si la ignoras te hará más mal que bien: el schema debe coincidir con el contenido visible. Si tu schema dice una cosa y tu página dice otra, no solo no ayuda, sino que baja la confianza, porque el sistema detecta la incoherencia y aprende a desconfiar de tus señales. El schema es un espejo del contenido, nunca un decorado independiente.

Implementar schema sin romper nada

El schema asusta a mucha gente por su aspecto técnico, pero con un procedimiento ordenado es abordable sin ser desarrollador, sobre todo apoyándote en el generador de BotPass. La secuencia es sencilla.

Primero, elige tres páginas para empezar, sin intentar cubrir todo el sitio de golpe: una fuente de verdad como precios, política o documentación; una landing de producto; y una guía. Este trio cubre los tipos de schema más útiles y te enseña el patrón. Segundo, decide qué schema aplica a cada una: en la de precios suele encajar un FAQPage combinado con un BreadcrumbList; en la landing, un Organization a nivel de sitio junto con Service o Product; y en la guía, un HowTo o un Article, con FAQPage si procede. Tercero, y esto es obligatorio, haz QA: comprueba que los nombres coinciden con tu Hoja de Entidades, que las URLs son las canónicas, y que las condiciones —moneda, región, fechas— están bien. Ese control de calidad es lo que garantiza que el schema sea un espejo fiel y no una fuente nueva de contradicciones.

Cómo se ve una entidad bien definida

Para aterrizarlo, mira cómo queda una entidad cuando le aplicas todo lo anterior. Toma el "Plan Pro". Su tipo es Plan; su nombre canónico es "BotPass Pro", y ese nombre se usa en todas partes sin excepción; su URL canónica es /pricing#pro; su definición en una frase es "Plan para equipos que necesitan X, incluye Y, con límite Z"; sus atributos críticos son el precio en euros al mes, la facturación anual opcional, el número de dominios incluidos y el nivel de soporte; y su fuente de verdad es /pricing. Cuando una entidad está así de definida, ocurre algo casi mágico: tu copy, tu schema y tus vistas limpias dejan de contradecirse, porque todos beben de la misma definición única. La IA ya no tiene que elegir entre versiones; solo hay una versión.