How a hotel appears in AI assistants: The three layers of visibility

How do I appear in ChatGPT? In Gemini? In Claude?

This is the question that more and more hotels are asking themselves. And it’s logical that they would. The truth is, the answer does not fit into a quick formula: there are several layers of visibility in AI assistants, and they do not all work the same way.

For years, digital visibility was complex, but it had a recognizable framework: Google published SEO guides, advertising worked with bidding rules, and metasearch engines operated with their own connection and competition rules. Complex, but known. With AI assistants, the landscape is shifting again. And the temptation is to treat them like a new Google with a new set of rules to decode.

It does not work that way.

A hotel can appear in an answer through three different layers. Each one has different rules, tools, and levels of control for the hotel, and its weight changes depending on the phase of the funnel.

Before moving on, a quick clarification: we are talking about organic positioning. The emerging paid layer within assistants, with ChatGPT testing Ads in beta and Google advancing in AI Mode with formats like direct offers, is another dynamic.

An assistant does not always answer from the same source

When a user asks an assistant a question, the key is not just what it answers, but where the information it uses to build that answer comes from.

To understand this, it is worth clearing up a common misconception first: an LLM (large language model) is not the same as an AI assistant.

• An LLM is the engine that reasons and generates language. We are talking about models like GPT (OpenAI), Claude Opus (Anthropic), or Gemini (Google), developed by a small group of companies capable of taking on the investment, infrastructure, and technical complexity they require.

• An assistant is the product layer with which the user interacts. It uses one or more LLMs, but it also decides what to do with the question: answer with the model’s knowledge, search the web, consult a connected source, or combine several options. The best-known assistants are ChatGPT (OpenAI), Claude (Anthropic), or Gemini (Google).

In reality, the assistant does not always answer from the same place. First, it understands what the user is asking for: inspiration, validation, price, conditions, or an action. Then it decides which sources to use: model memory, web search, a connected source, or a combination of several. With that context, the model builds the answer.

These three layers are not mutually exclusive. The assistant can combine them depending on the question, the available tools, and the level of certainty required.

Three layers of visibility. Three very different levels of control for the hotel.

Layer 1: the LLM, what the model remembers

Where does the information come from?

The first layer is the knowledge of the model itself.

LLMs are trained on huge amounts of public information, from content about destinations, brands, and hotels to guides, media, reviews, OTAs, or blogs. This is where associations come from that an assistant can retrieve without having to search for anything, such as romantic hotels in Mallorca, family resorts in the Canary Islands, or iconic accommodations in Paris. If the model “knows you”, you appear here. If not, you don’t.

There is a key detail: an LLM does not retrain in real time. It is updated in versions. If a hotel changed its name last month, opened a new spa, or renewed its website two weeks ago, the model does not necessarily know it until a subsequent update. And months can pass between versions.

What can the hotel control?

That is why, even though it is the layer that many imagine when they think of “appearing in ChatGPT”, it is also the slowest, most opaque, and least actionable. What you do today does not change the current model, and there is no direct, measurable, and controllable way to influence future versions either.

Faced with this opacity, a discipline called GEO (Generative Engine Optimization) has emerged. There is also talk of AEO or LLMO, depending on who is telling it. Its objective is to increase the probability of a brand being mentioned or used by generative answers. The acronyms are not standardized and their real effectiveness remains difficult to prove.

GEO has grown through trial and error. As large models do not publish how they are trained or how they select references, the industry works with hypotheses: structured data, schema.org, brand consistency, accumulated authority, mentions in reliable media, and specific content. These are reasonable practices and, in many cases, coincide with good SEO. On the other hand, techniques that promise specific effects in ChatGPT, Claude, or Gemini still lack robust evidence. Google itself is moving in that direction: it dismantles many of these pseudo-hacks and treats attempts to manipulate generative answers as spam.

What can the hotel do today?

• Keep the official website technically healthy: crawlable, fast, well-structured. It is the basis of SEO and also a condition for search engines, assistants, and retrieval tools to interpret it better.

• Ensure brand consistency between the official website, OTAs, Google Business Profile, and directories. The fewer contradictions there are between sources, the easier it will be for search engines and assistants to build a coherent answer.

• Work on authority, presence on social media, and mentions in recognized media and guides.

This is, of the three layers, the least controllable, the most opaque, and the slowest. The honest approach is to work on the practices that already benefit the hotel brand and its SEO, and not to chase techniques that promise effects that are impossible to verify.

Layer 2: Search, what the assistant finds

Where does the information come from?

The second layer appears when what the LLM remembers is not enough. If the assistant needs more current, specific, or verified information, it can launch a search tool on the internet. That is where pages, sources, citations, and snippets come into play.

The parallel with Google is clear, though not exact. The assistant can find official websites, OTAs, metasearch engines, media, guides, or reviews. It does not read the entire internet. It retrieves potential results, selects sources, extracts snippets, and builds an answer from them. Not everything it finds ends up in the final answer.

What can the hotel control?

This is the layer where classic SEO still works. Brand SEO and technical SEO are the foundation: that the official website dominates searches for the hotel name and that it is crawlable, fast, well-structured, and understandable. It is not new, but it remains essential.

What is new is that appearing as a source no longer guarantees traffic. The user can solve their query within the assistant itself, without visiting any page. The official website stops competing only for clicks and starts competing to be the raw material of an answer as well.

That changes slightly how it should be written. Saying “live an unforgettable experience” is not the same as explaining “adults-only hotel in Deià, with terrace suites, private spa, and dinners for couples”. The first phrase sounds good, but provides little signal. The second helps an AI understand which queries it can fit into.

The content of the website is no longer written just to convince the user. It must also help an assistant understand when and why that hotel fits a query.

What can the hotel do today?

• Protect brand SEO: that the official website dominates when someone searches for the hotel name.

• Prioritize technical SEO: crawlability, speed, clean architecture, and basic structured data.

• Write specific content, with words that the user would use and that an assistant can transform into an answer.

This is the layer where an individual hotel has more margin, especially when the intent narrows down: it no longer searches for “hotel in Mallorca”, but rather “adults only hotel with spa in Deià”. Classic SEO, well done, still works here.

But it has a ceiling. When the user needs certainties to decide or book, such as availability, conditions, or price for their dates, Search is no longer sufficient, because real-time data does not reside on an indexed website.

Layer 3: dynamic sources, what the assistant consults

Where does the information come from?

The third layer appears when neither the model’s memory nor a web search is enough. The assistant no longer needs to read pages, but to ask a live, official, and connected source directly. These connected sources are known as AI connectors.

Here the answer is no longer supported only by inferences or snippets, but by structured and updated data. This is usually called grounding: a website is read; a dynamic source is consulted.

When an AI consults a dynamic source, it does not just get information, it gets structured, real-time information linked to the possibility of executing actions. Not just “this hotel has a pool” extracted from a page, but “there is availability for August 12th, at this price and with these conditions.” The difference is moving from interpreting a page to consulting a system.

The technology may change, but the objective is the same:

• MCP is currently the most useful reference to explain this connection layer between assistants and external systems.

• MCP will not be the only way. It will coexist with APIs, proprietary models, and emerging agentic commerce protocols, such as UCP driven by Google or ACP driven by OpenAI.

What is relevant is not the winning acronym, but the underlying logic: exposing official, structured, and verifiable information to assistants without depending on a web page.

What can the hotel control?

This is the layer of the lower part of the funnel: deep consideration, transaction, and post-booking. Here the AI needs certainties, not approximations.

When the user asks if a room with a terrace is available for their dates, if they can cancel for free, if the price includes breakfast, or if it accepts children, the LLM does not know it and Search can only get close. To answer with guarantees, a source connected to the hotel’s authorized systems is needed.

Until now, conversation used to be an anteroom: it resolved doubts and, in the best-case scenario, took the user to the booking engine. With dynamic sources, that boundary is starting to move. The website will continue to have a central role and agentic booking will not become massive from one day to the next: there are barriers of trust, payment, commercial rules, loyalty, and integration. But for the first time it is reasonable to think that part of the decision, and even part of the booking, can happen within the assistant itself, without the user necessarily having to go through the website. And that space will not remain empty: if the direct channel does not occupy it, Booking, Expedia, or other OTAs will.

That is why this layer should not be read as another channel, but as a way to connect the assistant with the hotel’s official data.

Today, however, this layer still does not scale in a massive way. The manual installation of apps or connectors is still too much friction for the average user, although assistants are starting to move towards more natural models of suggestion and discovery.

The important thing remains to be resolved: that the assistant can find the hotel’s official source, verify its authority, and consult it without forcing the user to understand the technology behind it. Google starts with an advantage because it combines search engine, Maps, Business Profile, and Hotel Ads in the same ecosystem, but for the rest of the market this model is still under construction.

Today discovery and authority are still maturing. But if that model advances, having a dynamic source ready can make all the difference.

For the hotel, preparation begins by organizing and connecting its own data.

What can the hotel do today?

• Build a single source of truth: inventory, rates, conditions, and operational content in a structured and queryable database, not scattered in PDFs, spreadsheets, or informal knowledge.

• Prepare the engine to converse, not just to show: consulting, comparing, booking, or modifying are operable capabilities, not pages.

• Expose the hotel to open protocols, starting with MCP, to make it accessible to assistants and future applications.

Of the three layers, this is the most strategic one to prepare the direct channel: whoever arrives with official, structured, connected, and verifiable information will be better prepared to compete in the lower part of the funnel.

Visibility changes as the funnel advances

The three layers do not carry the same weight in all phases of the funnel. They change prominence as the user’s intent becomes more concrete.

In exploration, the user looks for inspiration: “romantic hotels in Mallorca”. Here the LLM dominates, supported by Search when more context is needed. The most efficient sources are usually aggregators, OTAs, guides, and media. For an individual hotel, this remains a difficult battle, as it already was in generic SEO.

In qualified discovery, the intent narrows down: “adults only hotel with spa in Deià”. The Search layer gains weight. Brand SEO, technical SEO, and clear content help the official website appear as a source. Here the hotel already has more margin.

In consideration, the user stops imagining and starts deciding. They want to know if a specific hotel has a terrace, accepts children, or has availability for a certain date. It is the hinge phase where, as we explained in the previous post, the AI funnel breaks: Search helps to validate, but live data does not live on an indexed website. Here dynamic sources start to make a difference.

In transaction, the user no longer just wants information: they need availability, price, conditions, and the ability to take action. It is the natural terrain of agentic booking, when the ecosystem matures. Something similar happens in post-booking: modifying, cancelling, or consulting a booking requires validating systems, not interpreting pages. Here dynamic sources stop being useful and become essential.

Conclusion

The initial question was how to appear in ChatGPT, Gemini, or Claude. It was a logical way to start, but too broad to understand what lies behind: it is not the same thing for the assistant to remember, find, or consult.

That is where the level of control the hotel can have changes. The closer the user gets to the decision, the more the requirement changes. Appearing helps, but it is not enough: the assistant needs a reliable source.

For the hotel, the opportunity is not in winning all generic discovery searches, a battle that was already difficult on Google and that AI is not going to simplify. It appears when the user asks about a specific hotel, a specific condition, or real availability.

In that terrain, the difference will not be made by an isolated action. It will be made by the ability to organize and expose official, structured, updated, and queryable information: an infrastructure prepared so that assistants do not have to speculate, but consult.

The core question will be another: when an assistant needs to answer about your hotel, who will be speaking on your behalf?