AI Hotel Memory 2026:Models remember the hotel, then invent the website

People increasingly ask chatbots for hotels. Usually the model searches the web first — so its answer reflects what’s online, not what it knows. We removed that crutch. With tools disabled, an LLM can only answer from the patterns baked into its weights during training: its parametric memory. So we asked, repeatedly: name hotels you know — in JSON, with each hotel’s website and address. Because a website is checkable, we can do something a pure recall test can’t: measure whether the memory is correct, not just present.

The result is a clean gradient. Chains live in every model’s memory perfectly. Famous palace hotels mostly do too. But the long tail of real, individual hotels is where models start to confabulate — and they do it with total confidence, returning a tidy JSON record for a hotel whose website doesn’t exist.

The design borrows from Dejan Marketing’s AI Brand Authority Index, which ranks brands by how often a model names them unprompted. We adapt it to hotels and add one twist that fixes Dejan’s biggest limitation — he could only normalise raw name strings, never verify them.

• Web search OFF. No tools, no retrieval. Pure memory. (In normal use, ChatGPT searches the web — we deliberately don’t.)
• Three low-cost models: GPT-5.4-nano, GPT-5.4-mini, and Google’s Gemini 3.1 Flash-Lite.
• Two cuts: “name 40 hotel chains or brands” (global), and “name 30 hotels in {city}” for Paris, Dubai, London and New York.
• JSON output: each run returns {name, website, address}. The website becomes the hotel’s identity — no fuzzy matching against a database needed.
• Verification: we check whether each returned domain resolves (DNS). A dead domain is strong evidence of confabulation; a live one is only a lower-bound signal — it may still be a generic chain homepage, a parent-collection domain, or the wrong property.
• ~150 runs per model for chains, ~80 per model per city; temperature 1.0 — intentional, since the goal isn’t one safe answer but to sample the distribution of hotels that surface from memory across repeated generations.

The base layer of hotel memory is rock-solid. Asked for hotel chains or brands, every model returns the majors — and their correct websites — essentially every time. GPT-5.4-mini hit a 99% live-website rate on chains; even nano managed 88%. Chains appear in training data on a single, predictable domain millions of times, so the association is overlearned.

Drop to the individual-hotel level and a city’s “memory leaderboard” emerges — the properties a model names again and again, unprompted. These are the hotels with the strongest grip on the model’s mind. Tables below are GPT-5.4-mini; “Recalled” is the share of 80 runs that named the hotel.

Here is the headline. For each model and place, what share of the hotels it named came with a website that actually resolves? Chains: near-perfect. Individual hotels: a different story — and it gets worse the weaker the model and the more independent the city.

The failure mode is the interesting part. The model usually knows the hotel exists — it just fabricates the web address, often a clean, plausible guess that happens to be dead:

One nuance the live-domain test deliberately flattens: for a hotel, “correct” isn’t a single canonical domain. A property can live on its own domain (ritzparis.com), on a correct parent-collection domain (oetkercollection.com), or on an invented-but-plausible one (bristolparis.com). We score only the first two as live; a future pass should separate exact-property recall from brand-level recall, because naming marriott.com for a specific St. Regis is a weaker kind of memory than naming the property’s own site.

Pulling those apart, the misses fall into four distinct failure modes — only the first is a clean dead domain, but the middle two are “live yet weak” recall the resolving-domain test cannot tell from the real thing:

Paris is the worst-remembered of the four cities for every model (down to 47% live-website rate on nano), and it also produces the longest tail of invented names — nano emitted 469 distinct “Paris hotels” across 80 runs, versus a tight 177 for Gemini. The reason is structural: Paris’s famous hotels are often independent palaces, collection-owned properties, or historically branded names with non-obvious domains. The model knows “Le Bristol Paris” but its site lives under Oetker Collection (oetkercollection.com); it knows “Plaza Athénée” but the domain sits under Dorchester Collection (dorchestercollection.com). A chain trains the model on one obvious domain; an independent or collection-owned palace does not, so the model guesses — and misses.

A tighter set with more live websites (Gemini) signals a sharper, more reliable memory; a sprawling set with dead domains (nano) signals a model padding its answer with invention.

The counterintuitive finding: the cheapest model had the best hotel memory. Google’s Gemini flash-lite returned the highest share of working websites in cities — 97% in Dubai, 96% in London— beating the pricier GPT-5.4-mini and far ahead of GPT-5.4-nano. It’s not about price; it’s about how much specific, rare detail a model retains. This is also why Dejan’s original brand index could run on low-cost Gemini at all: that family punches above its cost on real-world entity recall. Two low-cost models, two very different memories.

• If you’re a chain or a famous palace, the model knows you — name and website. You’re in the memory layer, not just the search layer.
• If you’re an independent or boutique hotel, the model may know your name but invent your web address. When a model answers from memory (or a user copies its output), that’s a wrong link pointing away from you.
• Memory ≠ retrieval. With web search on, models ground their answers and this mostly disappears. But the memory layer still shapes which hotels a model reaches for first, and what it “believes” before it searches.
• The fix: make the association Hotel Name → canonical domain boringly obvious everywhere — one canonical URL across your Google Business Profile, schema (Hotel with url + sameAs), OTAs, press and Wikidata; no abandoned domains; keep redirects alive. The risk isn’t that the model has never heard of you — it’s that it has heard of you imprecisely.

Retrieval can correct memory — but memory still decides what a model reaches for before it checks. For chains, that memory is crisp. For an independent hotel it can be a foggy postcard: the name is right, the address looks plausible, and the website is invented. That is the part worth fixing.