Identity: Tu hotel no es una URL. Es una entidad

Identity y la nueva arquitectura del descubrimiento hotelero en la era de la IA

La industria hotelera está entrando en una transición que va bastante más allá de la aparición de ChatGPT, Gemini, Perplexity o AI Overviews como nuevos canales de descubrimiento. Durante más de dos décadas, gran parte del marketing digital se ha construido alrededor de una arquitectura relativamente estable: una consulta genera resultados, el usuario selecciona una URL, accede a una web y continúa allí su proceso de investigación o conversión. La página era la unidad básica de descubrimiento y el clic, el mecanismo que conectaba la demanda con la información.

Ese modelo no desaparece, pero empieza a convivir con otro sustancialmente diferente. Los sistemas generativos pueden recuperar información de múltiples fuentes, relacionarla, sintetizarla y construir una respuesta antes de que el usuario visite ninguna de ellas. Un viajero puede preguntar qué hotel de Tenerife encaja mejor con una pareja que busca tranquilidad, gastronomía local y acceso a senderos evitando las zonas masificadas, y recibir directamente una selección razonada de establecimientos.

La transformación importante, por tanto, no consiste simplemente en que aparezca otro buscador. Consiste en que la unidad de descubrimiento empieza a desplazarse de la página hacia la entidad. Un hotel ya no compite únicamente por conseguir que una URL aparezca para una determinada consulta; necesita conseguir que los sistemas puedan reconocer qué establecimiento es, comprender sus atributos, relacionarlos entre sí y recuperar esa información cuando el contexto la haga relevante.

La URL continúa siendo fundamental como soporte de información, indexación y conversión. Pero deja de representar todo el activo digital.

La URL es el soporte. La entidad es el activo de conocimiento.

Ese es el punto de partida del primer pilar del Hotel Knowledge Graph Framework: Identity.

1. De posicionar páginas a resolver entidades

En un entorno generativo, entre la consulta y la respuesta pueden intervenir procesos de recuperación de información, identificación de entidades, evaluación de relevancia, selección de evidencias, reranking y síntesis. Antes de decidir si un hotel es adecuado para una consulta, el sistema necesita saber de qué hotel estamos hablando.

Aquí entra un concepto fundamental: entity resolution. Nombre, dominio, dirección, coordenadas, teléfono, perfiles oficiales, fichas de Google, presencia en OTAs, restaurantes asociados y otras señales deberían poder converger razonablemente sobre una misma entidad. Si esas señales son contradictorias, incompletas o están desactualizadas, la representación que los sistemas construyen sobre el hotel se vuelve menos precisa.

Identity, por tanto, no significa simplemente «lo que dice nuestra web». Significa la capacidad de una máquina para reconocer que múltiples datos, páginas y relaciones describen al mismo establecimiento.

Desde una perspectiva de ingeniería de conocimiento, un hotel puede entenderse como un nodo conectado a múltiples atributos y entidades:

Hotel → habitaciones → características → ofertas
Hotel → restaurante → chef → propuesta gastronómica
Hotel → spa → tratamientos → horarios
Hotel → ubicación → destino → puntos de interés
Hotel → organización → marca

Una web puede distribuir toda esa información entre decenas de URLs. El reto consiste en que los sistemas puedan reconstruir las relaciones existentes entre ellas.

2. Cómo construyen las máquinas esa representación

Conviene evitar algunas simplificaciones habituales alrededor de los modelos de lenguaje. No existe un único mecanismo mediante el que «las IA leen Internet». Dependiendo del sistema pueden intervenir índices tradicionales, Knowledge Graphs, búsqueda léxica, embeddings, recuperación semántica, sistemas híbridos, APIs y arquitecturas de Retrieval-Augmented Generation (RAG).

Una cadena simplificada ayuda a entenderlo. Mediante Named Entity Recognition (NER) un sistema puede detectar que un término corresponde a un hotel, una ciudad, un restaurante o una persona. Posteriormente, mediante procesos de entity linking, esa mención puede relacionarse con una entidad concreta. Los sistemas de recuperación seleccionan después documentos o fragmentos potencialmente relevantes y procesos de reranking priorizan las evidencias que mejor responden a la consulta antes de que el modelo genere una respuesta.

Los embeddings permiten además representar conceptos y textos en espacios matemáticos donde la proximidad refleja similitud semántica. Esto facilita, por ejemplo, relacionar un hotel con una intención como «escapada tranquila en la naturaleza» aunque esa expresión exacta no aparezca en su web, siempre que existan suficientes señales relacionadas con privacidad, entorno, senderismo, baja densidad o determinadas características de estancia.

Pero el objetivo de un hotel no debería ser «optimizar sus vectores». No controlamos directamente esas representaciones. Lo que sí podemos hacer es construir información precisa, consistente, estructurada, recuperable y suficientemente explícita para facilitar que diferentes sistemas interpreten correctamente la entidad.

3. La consistencia de entidad es el verdadero problema

Un establecimiento puede tener una excelente web y, sin embargo, una identidad digital fragmentada. El nombre puede aparecer de distintas maneras, una OTA puede conservar datos antiguos, Google puede mostrar un horario diferente, determinadas fotografías pueden corresponder a una etapa anterior o las políticas sobre mascotas, familias o accesibilidad pueden variar entre plataformas.

Para un usuario humano muchas de esas diferencias son fáciles de interpretar. Para un sistema que agrega información automáticamente representan señales contradictorias que debe resolver. La consistencia, por tanto, debe superar el tradicional control del NAP —Name, Address, Phone— del SEO local y evolucionar hacia una verdadera consistencia semántica de entidad: nombre, ubicación, marca, categoría, habitaciones, servicios, políticas, público objetivo, relaciones con otras entidades y vigencia temporal de los datos.

La temporalidad es especialmente importante. Un dato puede haber sido correcto hace tres años y ser incorrecto ahora. Un cambio de chef, una reforma, el cierre de un restaurante o una modificación de la política de cancelaciones alteran la entidad. Identity implica también controlar el freshness de la información y evitar que contenido históricamente válido termine describiendo una realidad que ya no existe.

Podemos resumirlo mediante una pregunta de auditoría mucho más interesante que «¿tenemos Schema?»:

¿Cuántas fuentes relevantes describen nuestro hotel de manera coherente y cuántas están introduciendo contradicciones?

4. Schema.org como capa de conocimiento estructurado

Schema.org adquiere especial importancia porque permite expresar algunas de estas relaciones de forma explícitamente interpretable por máquinas. En hospitality podemos identificar el establecimiento, describir dirección y geolocalización, horarios de entrada y salida, características, clasificación, políticas, amenidades, unidades de alojamiento y ofertas.

Su valor no debería reducirse a obtener resultados enriquecidos en Google. Dentro de Identity, los datos estructurados funcionan como una capa de modelado semántico.

Una implementación madura debería ir más allá de «poner Schema Hotel en la home». El objetivo es construir un pequeño grafo coherente dentro del propio dominio mediante identificadores persistentes y relaciones explícitas entre hotel, habitaciones, restaurantes, servicios y ofertas. Propiedades como sameAs, geo, address, amenityFeature, checkinTime, checkoutTime, petsAllowed o starRating deberían reflejar datos reales y mantenerse sincronizadas con el contenido visible.

Y aquí aparece una regla básica: los datos estructurados nunca deberían crear una realidad paralela a la web. Si Schema.org afirma una cosa y la página visible otra, simplemente habremos añadido una nueva inconsistencia al sistema que pretendíamos ordenar.

5. Profundidad semántica no significa escribir más

Este cambio también obliga a revisar la estrategia de contenidos. Durante años hemos organizado buena parte del SEO alrededor de palabras clave, volúmenes de búsqueda y URLs. Esa lógica sigue siendo válida, pero ahora debemos añadir una segunda pregunta:

¿Qué información necesita una máquina para comprender correctamente nuestro hotel?

Una página de habitación debería especificar superficie, capacidad, camas, vistas, equipamiento y restricciones relevantes. Una página de spa debería aclarar servicios, horarios y condiciones. Una página de ubicación debería conectar el establecimiento con destinos, puntos de interés, movilidad y experiencias concretas.

Podemos hablar aquí de densidad informativa de entidad: cuántos hechos, atributos y relaciones útiles contiene realmente una pieza de contenido. Esto no supone escribir de manera robótica ni eliminar la narrativa de marca, sino evitar que la información importante desaparezca detrás de expresiones intercambiables como «una experiencia inolvidable», «un oasis de tranquilidad» o «un enclave único».

Para una IA que intenta responder si un hotel dispone de habitaciones comunicadas, piscina climatizada, cargadores eléctricos o acceso directo a senderos, diez párrafos aspiracionales no sustituyen una afirmación factual clara.

La profundidad de entidad no consiste en producir más contenido. Consiste en describir mejor.

6. La web sigue siendo fundamental, pero cambia su función

Hablar del «fin de las URLs» no significa afirmar que la web haya dejado de importar. Todo lo contrario. El sitio oficial debería funcionar como fuente canónica de primer nivel para la información que el hotel controla: identidad corporativa, inventario, servicios, políticas, habitaciones, restauración, experiencias e información práctica.

SEO continúa siendo parte esencial de esta infraestructura.Un análisis de Ahrefs realizado sobre aproximadamente 1,9 millones de citas de AI Overviews, encontró que el 86% de las páginas citadas podía encontrarse dentro del Top 100 de Google y el 76,1% dentro del Top 10. La lectura prudente de estos datos no es que Google determine automáticamente qué recomendará una IA, sino que existe una continuidad significativa entre las actuales infraestructuras de búsqueda y las nuevas capas generativas.

GEO no sustituye al SEO. Lo integra dentro de un sistema de descubrimiento más amplio.

También cambia la forma en que debemos evaluar determinados contenidos. Una página sobre accesibilidad, mascotas, parking o políticas puede tener muy poco tráfico y, sin embargo, resultar crítica para responder correctamente a una consulta específica. Parte del contenido deberá seguir optimizándose para generar clic y conversión; otra parte deberá evaluarse también por su capacidad para aportar conocimiento a la entidad.

7. Infraestructura no es estrategia

El auge del GEO ha traído consigo una nueva generación de soluciones que prometen convertir una web en «AI-ready» mediante pequeños ajustes técnicos. Conviene poner cada elemento en su sitio.

robots.txt permite gestionar qué agentes pueden rastrear determinados recursos, pero permitir el acceso no garantiza indexación, utilización, citación ni recomendación.

llms.txt es una propuesta destinada a facilitar a los agentes una representación simplificada de los contenidos relevantes de un sitio, pero no constituye un estándar universalmente adoptado por los principales sistemas de IA. Puede ser una capa experimental interesante, pero difícilmente debería tener prioridad sobre arquitectura web, indexabilidad, contenido factual, datos estructurados o consistencia.

Schema.org tiene una implantación mucho más consolidada, pero tampoco constituye una estrategia GEO por sí mismo.

Schema.org ≠ GEO
robots.txt ≠ GEO
llms.txt ≠ GEO

Son infraestructura. La estrategia consiste en construir una representación digital suficientemente clara, actual, coherente y recuperable para que diferentes sistemas puedan interpretar correctamente el hotel.

8. Identity como gobernanza del conocimiento

Aquí aparece probablemente la consecuencia más importante para los equipos de marketing. Identity no es solamente un problema de contenido o SEO. También es un problema de gobernanza de datos.

¿Quién decide cuál es el nombre oficial de una habitación? ¿Dónde se actualiza una política cuando cambia? ¿Qué sistema contiene el horario correcto del restaurante? ¿Quién verifica que web, Google Business Profile y OTAs muestran la misma información? ¿Qué ocurre cuando una reforma modifica las características de determinadas unidades?

En muchos hoteles esos datos están distribuidos entre marketing, operaciones, revenue management, recepción, sistemas de reservas y proveedores externos. Esa fragmentación organizativa termina convirtiéndose inevitablemente en fragmentación digital.

No todos los establecimientos necesitan desarrollar un Knowledge Graph tecnológico completo, pero sí deberían empezar a aplicar su lógica: identificadores consistentes, atributos normalizados, relaciones explícitas, fuentes canónicas y procesos claros de actualización.

Desde esta perspectiva, Identity puede auditarse mediante seis dimensiones:

Dimensión	Pregunta de auditoría clave	Objetivo de control
Identificación	¿Existe una entidad inequívoca en la red?	Evitar duplicidad o ambigüedad con otros negocios.
Consistencia	¿Coinciden las fuentes clave (OTAs, Google, web)?	Eliminar contradicciones semánticas y de datos (NAP+).
Profundidad	¿El hotel está descrito con densidad factual?	Proporcionar atributos reales frente a texto aspiracional.
Estructura	¿Sus relaciones se expresan explícitamente?	Implementar Schema.org y grafos coherentes.
Actualidad	¿Los datos reflejan el estado presente?	Controlar el freshness y retirar información obsoleta.
Verificabilidad	¿Los hechos principales pueden comprobarse?	Respaldar afirmaciones con evidencias externas/canónicas.

Podemos expresarlo mediante una formulación conceptual:

Identity = Consistencia de entidad + Profundidad informativa + Conocimiento estructurado + Actualidad

Con una condición transversal: verificabilidad factual.

No pretende ser una ecuación matemática sobre cómo funciona un LLM. Es una manera de ordenar qué debe construir un hotel antes de plantearse cómo conseguir una recomendación.

Porque Identity solo responde a la primera pregunta del Hotel Knowledge Graph Framework:

¿Quién eres?

Después habrá que responder quién valida lo que afirmas, qué experiencia cuentan quienes ya se han alojado y en qué situaciones concretas eres relevante. Ahí aparecen Authority, Experience y Context:

AI Recommendation ∝ (Identity + Authority + Experience) × Context

Antes de ser recomendado, hay que ser comprendido

Uno de los errores más habituales al hablar de GEO es empezar preguntando «¿cómo consigo que ChatGPT recomiende mi hotel?». La recomendación es el resultado final de procesos que no controlamos directamente. Lo que sí podemos trabajar es la calidad del conocimiento disponible para construir esa respuesta.

El objetivo consiste en conseguir que los sistemas puedan resolver inequívocamente la entidad, recuperar información correcta, distinguir datos actuales de información obsoleta, comprender sus servicios y características y establecer relaciones entre el establecimiento y el resto de elementos que definen su propuesta.

Esto no supone el final del SEO ni de la web. Supone un cambio en el objeto estratégico que estamos optimizando.

Durante años hemos optimizado páginas para consultas. Ahora tendremos que aprender también a gestionar entidades para sistemas que construyen respuestas.

Una URL representa un documento. Una entidad representa una red de conocimiento.

Ese es el verdadero significado de Identity dentro del Hotel Knowledge Graph Framework: conseguir que, antes siquiera de decidir si merece ser recomendado, cualquier sistema pueda responder con precisión a una pregunta mucho más elemental:

¿Quién es exactamente este hotel y qué sabemos realmente sobre él?

El siguiente problema es saber por qué debería creer todo lo que el hotel afirma sobre sí mismo.

Y ahí empieza Authority.