When Travellers Ask AI Where to Stay, Is Your Hotel in the Answer?

The answer arrives before the comparison starts

A traveller used to be handed a page of links and left to do the comparing themselves. Ten blue results, three ads, a map. The work of narrowing was theirs, and every hotel in the market got a chance to be considered because every hotel was, in principle, on a page they might scroll.

Increasingly, part of that narrowing is done before the traveller sees anything. They ask a question in ordinary language — somewhere in the old town for an anniversary, quiet rather than showy, walkable to dinner — and receive a paragraph naming three or four properties, with reasons attached.

The hotel that is not in that paragraph was not rejected. It was never considered. There is no page two.

This is not the death of search, and it has emphatically not killed the OTA. It sits in front of both, at the moment the shortlist forms. Which happens to be the moment hotels have always had the least visibility into and the least control over.

What this article does not say

A great deal of what is currently written on this subject leans on a statistic: some percentage of travellers who now "start with AI." We looked for a primary, traceable source for a figure like that and did not find one we would be willing to put our name to. So this piece contains none.

That is not false modesty. It is the whole methodological point. If a number cannot be traced to a source you can open, it is not evidence, and building a commercial case on it means building on someone else's marketing. What follows is narrower and, we think, more useful: for a defined set of questions, on named surfaces, on recorded dates, here is what can actually be measured about a property.

Why the same question gives different answers

Ask the same question twice and you may get two different sets of hotels. This unsettles people who expect search-engine behaviour, and it is the single most important thing to understand before spending money on the problem.

These systems are non-deterministic. The answer depends on how the question was worded, which surface answered it, what date it is, where the device is, whether the account has history, and — critically — which sources happened to be retrievable at that moment.

Three consequences follow, and each one has cost someone money already.

One appearance is not visibility. A hotel director shows a screenshot in a meeting: we're in ChatGPT. They are in one answer, on one day, for one phrasing. That is an observation. It is not a position.

One absence is not invisibility. The mirror-image error, and the one agencies use to sell. A single miss proves nothing except that the miss happened.

There is no rank to hold. Most answers are prose. There is no ordinal position to read, nothing to average, and nothing to defend. When a numbered list genuinely appears, the order is worth recording as an observation — but the moment you call it a rank you have started measuring something that does not exist.

A useful discipline, and the one we work to: one answer is an observation; a repeated, documented pattern is evidence.

The Recommendation-to-Revenue Chain

Visibility is not an event. It is a chain, and revenue leaves at whichever link breaks first:

Guest question → AI or search answer → cited sources → hotel shortlist → official or OTA path → booking journey → commercial outcome

Most AI-visibility products examine the first three links. The last four are where the commercial damage happens, and they are where a hotel commercial function already knows how to think.

The failure modes are distinct and demand different responses:

| Failure | What it looks like | What it actually is | | --- | --- | --- | | Absent | The property is never named for questions its guests ask | A content and source-authority problem | | Inaccurate | Named, described wrongly | A source problem, usually not a website problem | | Out-competed | A competitor is consistently preferred | A positioning and evidence problem | | OTA-cited | Right answer, every source belongs to a channel that charges you | A distribution problem | | No direct path | Recommended, with no official route visible | A distribution problem | | Journey loses it | Official path taken, confidence lost | A conversion problem | | Conflicting data | Sources disagree about rates, policies, amenities | An entity-management problem |

Notice how few of these are content problems. The category sells content.

The most expensive outcome is not absence

It is worth sitting with this, because it inverts the usual pitch.

The worst realistic result is not that AI has never heard of your hotel. It is that AI describes your hotel accurately, warmly, at the top of the answer — and every source it leans on belongs to someone who takes fifteen to twenty per cent of the booking.

You have paid for that recommendation. You paid for it in the product, the service and the reviews that made the property worth recommending. And then the answer handed the traveller a link you do not own.

Absence is a marketing problem, and it is slow to fix. Being cited exclusively through channels that charge you is a distribution problem, and it is often fixable in weeks.

Entity accuracy: the answer, not the website

Here is the trap that catches good hotels with good websites.

The answer is not reading your website. It is synthesising from whatever it retrieved — your site if it can reach it, but also the OTA listing, the Business Profile, the tourism board page, a review platform, a restaurant guide, a three-year-old magazine piece.

So a property can have an immaculate site and a wrong answer.

We see this in the sample audit we publish: an answer states that a hotel does not accept pets. The website says small dogs are welcome in garden rooms. The answer is not wrong about what it read — it read a stale policy field on an OTA record that nobody has updated since 2023. The website is irrelevant to that answer, because the website was not the source.

The list of facts worth checking is unglamorous and specific: name, property type, location and district, room count and room types, amenities that actually differentiate, restaurants and bars, policies covering pets, children, accessibility and check-in, and which guest segments and occasions the property suits.

Every one of those can be wrong in an answer while being right on your site. Fixing your site does nothing. Fixing the source does.

Official site versus OTA citation

This is the metric almost nobody reports, and the one a commercial director understands immediately.

Of the answers that cited anything at all, how many cited your own domain? How many cited an OTA?

It converts directly into a question about channel cost, which is a conversation hotels have been having for twenty years. It needs no new vocabulary and no education. And unlike "AI visibility," it points at a specific, ownable action.

Two things drive the answer. Source authority — whether your own pages are substantial and citable enough to be worth quoting. And crawler access — whether the surfaces can reach your site at all.

That second one is worth dwelling on, because it is binary, common, and invisible from the inside.

Google's own guidance on its AI features names CDN and hosting infrastructure alongside robots.txt as places where crawling must be permitted. That phrasing exists for a reason. The realistic failure is not a deliberate block; it is a firewall rule, a bot-protection toggle or an aggressive rate limit — often switched on by an IT team or an agency with good intentions — quietly returning 403 while robots.txt says Allow.

And these crawlers are not one thing. OpenAI runs OAI-SearchBot for ChatGPT's search-and-cite behaviour, GPTBot for training, and ChatGPT-User for user-triggered fetches. Allowing one does not allow the others. A hotel that blocked "AI crawlers" two years ago to protect its content from training may have removed itself from the answers as a side effect, and nobody will have told it.

Hotel Center and being bookable

Discovery and bookability are separate projects that people insist on treating as one.

Google's free booking links exist to put a hotel's official site alongside OTA options in its booking modules, with no cost per click. Eligibility runs through Hotel Center participation with rates available and a working landing page, and the rate feed generally arrives through a connectivity partner.

The commercially interesting part: a great many hotels are already connected through their booking engine or reservation provider and do not know it. Others are eligible and simply absent. Either way, if the official rate is not present in the module, the traveller is offered channels — and no amount of content work changes that, because it is not a content problem.

On agentic booking — travellers completing reservations inside an assistant — the honest position is that it is early. Google's Universal Commerce Protocol has been extended to lodging, the hotel remains merchant of record, and Google's own FAQ states plainly that participating does not influence ranking. Anyone selling protocol readiness as a visibility lever is contradicting the documentation they are citing.

Assess readiness. Claim nothing about eligibility you have not confirmed on the property's own account.

What hotels should actually measure

Not a score. A score hides the one thing you need — which link in the chain is broken — and invites comparison with figures that were never calculated the same way.

Measure counts over stated denominators, on recorded dates:

• Shortlist rate — answers naming the property, over answers observed
• Citation rate — answers displaying any source
• Official-source citation rate — over answers that cited anything
• OTA-source dependence — same denominator, opposite reading
• Answer accuracy — verified assertions, over assertions with a decided verdict
• Direct-path visibility — where an official route was observable
• Competitor share — of a stated observation pool, not of the market
• Entity consistency, technical readiness, distribution readiness — as pass/fail checklists, not scored

Every one carries its sample size. A percentage without a denominator is decoration.

A note on first-party data, because it comes up: Google's Search Console now has a generative-AI performance report. It reports impressions without clicks, click-through rate or query data, it began with limited history, and it has been rolled out selectively by region. For a property outside the initial rollout it should be assumed unavailable until checked. And because there is no query dimension, no first-party tool can currently tell you which traveller question produced an impression. That gap is precisely what a documented prompt panel fills, and it is the honest justification for this kind of work existing at all.

A twelve-question self-audit

No tool required. An afternoon, and a note of the date.

1. Ask three questions a guest would genuinely ask about your market — destination, segment, occasion — in a fresh private window. Is your property named?
2. Ask the same three again tomorrow. Did the answer change?
3. When your property is named, is the description factually correct?
4. Which sources are cited? Is your own domain among them?
5. How many of the cited sources are OTAs?
6. Is there any visible route to book directly in the answer?
7. Search your property by name. Is the official rate present in Google's hotel module, or only OTA options?
8. Open your robots.txt. Does it address OAI-SearchBot explicitly, separately from GPTBot?
9. Ask your IT or hosting provider whether any CDN, WAF or bot-protection rule challenges declared search crawlers.
10. Open your most important amenity, accessibility and policy facts. Are they in crawlable HTML, or in a PDF, an image or a client-rendered widget?
11. Check your pet, child, accessibility and check-in policies on the three largest OTA listings. Do they match your website?
12. Ask directly: is it cheaper to book [your property] directly? Does anything on your site answer that question in crawlable text?

If questions 4 through 7 produce uncomfortable answers, the problem is distribution, not content — and it is likely the cheapest thing on this list to fix.

What this does not prove

Being named in an answer has not been shown to cause bookings, and this article does not claim it does. Establishing that link needs a measured before-and-after against a stated baseline, and even then it is correlation reported as correlation.

What can be said with confidence is narrower and still commercially serious: if an answer describes your property inaccurately, that is a cost. If every source behind it is a channel that charges you commission, that is a cost. If the official path does not exist at the moment the traveller decides, that is a cost.

Those are measurable today, without a single claim about the future.

Sources and limitations

Primary sources used:

• Google Search Central, AI features and your website and the generative-AI optimization guide — the statements that no special schema and no AI-specific optimization are required, and that crawling must be permitted by CDN and hosting infrastructure as well as robots.txt.
• Google Search Console Help, Generative AI performance report — dimensions available and rollout limitations.
• Google Hotel Center Help, About hotel free booking links — eligibility and cost.
• Google for Developers, Universal Commerce Protocol for Lodging FAQ — merchant-of-record model and the statement that participation does not influence ranking.
• OpenAI crawler documentation — the separation of OAI-SearchBot, GPTBot and ChatGPT-User, and published IP ranges for verification.

Limitations, stated plainly: platform documentation changes, and dates should be re-checked before any of it is relied on commercially. The illustrative figures referenced here come from a fictional sample property and are not a Katalyst client result — we have none for this capability, and we will not manufacture one. Nothing here predicts or guarantees placement in any surface.