When AI Confuses Properties Within a Hotel Brand

In a 35-answer test of Google AI Mode, the answers named the right hotel brand every time, yet three answers attached a fact to the wrong property or the wrong place. One answer gave a town-centre resort an address in the village where its sister resort sits. Another offered a sister property's signature villa type at a resort that does not sell it. A third put two neighbouring resorts more than two kilometres apart, although the brand's own map pins put them about 140 metres apart.

The overall error rate was low. Three of 123 checkable claims were wrong, which is 2.4 percent. The errors clustered where a guest is most likely to act on them, in questions about location, room types and which sibling property fits a need. This article shows how we checked the properties, what went wrong, where the public record diverged, and how a hotel group can correct and retest its property facts.

The failure beyond brand visibility

Most AI visibility reports stop at one question, which is whether the brand appeared. For a hotel group with several properties in one destination, that question is too coarse. A guest who asks for a pool villa with a valley view needs the right property, the right room type and a working booking path.

The clearest case in our sample came from a direct question about one property's address, rooms, restaurant, spa and check-in time. Google AI Mode answered the rooms, restaurant, spa and check-in correctly. It placed the property in the wrong village, naming the village that belongs to a sibling resort about six kilometres north. The answer cited an online travel agency's questions page as its first source.

When we ran the same question a second time, the answer gave the correct address. A guest who saw only the first answer would have no way to know which version was right without opening the hotel's own contact page.

The study looks at one surface. Every answer came from Google AI Mode, collected through a third-party API (SearchAPI) with the location set to Jakarta, Indonesia. That is a single-surface study of an API collection method. It does not show what the consumer interface showed any individual traveller on those days.

How the properties were checked

We picked one hotel brand with five boutique resorts on one Indonesian island. Four sit in or near the same inland town and one sits on the coast. Two of the town properties stand on the same road, about 140 metres apart. The brand is not a Search Agency client, and we are not naming it or its properties until the property teams have reviewed the findings and had a chance to reply.

The dated truth register

Before collecting any answers, we built a truth register from the brand's official website only. It records each property's official name and aliases, address, telephone, map coordinates from the official location pages, room-type names and sizes, restaurant and spa names, experiences, and policies. Brand-level policies such as check-in time, shuttle service, payment rules and connecting rooms were recorded once, because the official questions page states them once for the whole group.

The pages were fetched on 2 and 3 November 2026 and saved with their fetch times. Accessibility information was not published on the pages we fetched, so we did not assess it. That topic needs sign-off from the properties before anyone publishes claims about it.

The prompts and the sample

We wrote six English prompt types for each property, following the brief's design. They covered an explicit property question, an ambiguous name, an amenity-constrained recommendation, a location-constrained recommendation, a sibling comparison and a booking instruction. That gave 30 prompts.

The plan allowed up to three repetitions per prompt, or 90 answers. We completed 35. Every prompt ran once, and the five explicit property questions ran a second time. We stopped there to stay within the study's collection budget. All 35 calls returned a valid answer, with no failures, refusals or empty answers. Repetitions of the same prompt are not independent travellers, so we read the results at the prompt level and treat the second runs as a check on stability.

How claims were coded

From each answer we extracted the factual claims about a property, such as an address, a room type, a restaurant name, a distance, an amenity or a booking step. Opinions about vibe or value were left out. That produced 151 claims.

Coding ran in two passes. In the first pass each claim got a code from the brief's taxonomy. In the second pass every coded problem was checked again against the truth register, and the reason for any change was written down. Eighteen first-pass codes changed in the second pass. Two rules mattered most. An omitted amenity is not an error, and a brand-level answer is not automatically property confusion.

The errors that appeared

Of the 151 claims, 28 could not be checked against any official source, mostly walking distances and travel times. That leaves 123 adjudicated, checkable claims. Three were verifiably wrong under the taxonomy, and two more had no support in the official record.

The factual error rate was 3 of 123 checkable claims, or 2.4 percent. Adding the two unsupported claims gives 5 of 123, or 4.1 percent. At the answer level, 3 of 35 answers contained at least one taxonomy error, and 5 of 35 contained an error or an unsupported claim. The unverifiable claim rate was 28 of 151, or 18.5 percent.

Ten of the eleven first-pass "parent policy" codes concerned the 2 pm check-in time. The brand's questions page states one default for every property, so applying it to a single property matches the official record. We recoded these as correct and listed check-in as a fact each property should confirm. The eleventh, a remark that the coastal resort lacks a quick shuttle, was recoded as ambiguous because the brand offers an area shuttle at every property.

Where errors sat by prompt type

The explicit property questions were the most accurate. Across ten answers they made 50 checkable claims and got one wrong. The booking instructions were also clean, with 10 checkable claims and no errors. All five pointed to the brand's own website and its Book Now form, and none sent the guest to a reseller.

The location-constrained prompts were the weakest. They produced 19 claims, and 11 of those were distances or walking times with no official figure to check against. Of the 8 checkable claims, one was wrong. Sibling comparisons produced the most unverifiable colour, with 10 of 34 claims that no official page could confirm.

A sample answer comparison

Where the record diverged

Each error traces to a gap between the brand's own pages and the other sources the answer drew on. The official site was cited often. Thirty-two of 35 answers cited at least one page on the brand's domain, and every answer cited at least one source. Official citation did not prevent errors, because answers mixed official pages with travel agencies, review forums, map listings and a tour operator's PDF.

The wrong village

The Property B address error matched the wording on a travel agency questions page that the answer cited first. The official contact page lists Property B on the main road in the town and lists the other village only for Property D. We could not prove that the village name moved from the sibling, so the second pass coded it as a wrong location.

The borrowed room type

An ambiguous prompt about a valley pool villa produced an answer saying the room type was at Property D "and select options at" Property C. Property C sells six room types on its official site and none of them is called a valley pool villa. Both properties sit above river valleys, which makes the transfer easy to understand. It would still send a guest to the wrong booking page.

The impossible distance

A location prompt about a ridge walk listed Property B at 1.23 km and Property A at 3.4 km. On the brand's own map pins, A and B are about 140 metres apart, so both figures cannot be right. The answer cited travel agency pages for each property, and each agency appears to compute distances its own way.

Signals outside the answer text

Two problems appeared in the sources and map results without reaching the written answer. In one run, the answer about Property A cited a lookalike site whose domain contains the brand and property name. That site describes itself as an independent guide and completes bookings on a large travel agency. In another run, the map results for Property E included a different hotel elsewhere on the island whose name differs by one letter. We did not count either as a claim error, because the answer text was correct.

Not every first-pass flag held up. A recommendation of Property A for a query about Property B looked like confusion. The second pass treated it as a fair reading of a genuinely ambiguous query, since both properties stand on the same road. A claim that Property B ran a cooking class looked unsupported until we found it in the property's own guest directory PDF.

The operational consequences

We had no access to the hotel's guest messages or support records, so we cannot report any incident caused by these answers. Everything in this section is a potential consequence, inferred from the error type. None of it was observed.

• A wrong village in an address could send a guest's driver to the wrong area, with a delayed arrival and a support call.
• A room type attributed to the wrong property could lead a guest to book one resort expecting a villa that only its sibling sells.
• Wrong distances could steer a guest who wants to walk everywhere toward a property that suits them less.
• A lookalike site in the sources could pull a guest who wanted to book direct onto an indirect channel, with a different cancellation route and no direct relationship.

The more practical risk is the cost of handling these moments at the front desk and in reservations. A property team can test that cheaply by tagging pre-arrival questions that mention an AI tool for a few weeks.

What the group can correct

The fixes split by owner. Each one starts from the truth register, because a correction is only as good as the record it points to.

Property facts owned by each property

Each property team should confirm its address line, map pin, room-type names and the experiences it really runs. Property C's experience page lists no cooking class, while a third-party PDF still advertises one. Either the page is incomplete or the PDF is out of date, and only the property can say which.

Central templates owned by the brand

The brand's questions page states check-in, shuttle and payment rules once for all five properties. That is efficient, and it means every property inherits the same answer. If any property differs, the template needs a property-level line. The brand can also publish one consistent address block per property, in the same format on every page, with the village or district named explicitly.

Listings and third-party pages

The Property B village error matched a travel agency questions page, and the distance errors came from agency pages. These need correction requests through each partner's extranet or support route. The lookalike site needs a separate decision about trademark or partner policy. That decision belongs with the brand's legal or commercial lead, outside the SEO team.

For ownership across teams, the brand entity consistency audit explains how to compare how a brand is described across its own pages and outside profiles. The hotel local SEO guide covers map listings, which carry the pins and addresses that AI answers lean on.

How to retest

A correction is finished only when a later round of answers is checked against the same truth register. Retesting cannot guarantee that an error disappears, because the answer engine decides what to show. It can show whether the error rate moves after the record is fixed.

Use the same prompts, the same surface, the same location setting and the same coding rules as the first round. Run each prompt more than once, since our two runs of the Property B question gave different addresses. Record the date of every run and of every correction, so a change can be lined up against the fix that preceded it.

Keep the baseline rows. Without them a retest only shows the latest answer, and a single answer can look fixed by chance.

What remains outside control

The hotel controls its own pages and can request changes from partners. It does not control which sources an answer engine selects, how it blends them, or when it refreshes them. The second Property B run shows the same question can produce a right and a wrong address on consecutive days.

The sample has clear limits. It covers one brand, five properties, 30 prompts and 35 answers from one surface, collected through a third-party API in English with a Jakarta location. It does not estimate error rates for hotels in general or for any other AI assistant. Nearly one claim in five could not be checked at all, which is a finding in itself. Distances, travel times and star ratings are things guests ask about, and the official pages do not publish them.

The narrower point holds within those limits. Brand recognition was perfect in this sample, and the property-level details still slipped in the places that matter for a stay. For the wider hospitality context, see the hospitality GEO guide and Search Agency's travel industry page. If your group runs several properties under one brand, check AI accuracy across your property portfolio with a dated truth register and a coded sample before deciding what to fix first.