A traveler asks for a quiet hotel with parking; an answer can only say so of the hotels whose sites do.

The traveler's question is a list of conditions, and the assistant checks each one

Hotel questions are compound: a place, two or three conditions, and often a budget word. "Quiet", "parking", "breakfast included", "dogs", "family room", "late check-in", "walkable". The AI assistant checks each condition against the pages it read, and a property whose pages leave one unanswered has given it no way to include that property for that condition. A site that shows a parking icon but never writes the word has not answered the parking condition.

The booking platforms' pages state amenities as consistent lists, which makes them easy for a machine to read. In our audit's probe of 9,240 businesses across 40 trades (one buyer question each, put to Claude with web retrieval on, late August to early September 2026), 99.4% of the names given were actual businesses and 0.6% were directories or aggregators. The answer names properties, not portals, but it does not say which page the assistant read, and a property whose own site says less than its listing has handed that reading to the platform.

The moments differ. Planning a trip, the traveler stacks conditions. On the road at 9 p.m., the question is whether check-in is still open and where to park. Before an event, it is the distance to the venue on foot. A returning guest asks a policy question: whether the dog can come this time. Each is answered by a sentence on your site, or by nothing.

What a hotel's own site has to state for an assistant to use it

Asked about a hotel by name, an assistant with web search opens its pages the way an AI crawler does; OpenAI's crawler documentation names ChatGPT-User as the fetcher that does this for ChatGPT. It reads captions, not photographs; a gallery of the terrace tells it nothing that a sentence about the terrace would not tell it better.

Hotel and LodgingBusiness are LocalBusiness subtypes on schema.org, so the fields Google documents for local business markup apply: name, address, telephone, opening hours, geo and price range. The lodging fields map onto a traveler's conditions directly: checkinTime, checkoutTime, petsAllowed, amenityFeature. Google recommends JSON-LD and says to mark up only what a visitor can see, so the policies page and the LocalBusiness schema have to agree.

Reviews as text do a second job here. A guest review that mentions the back rooms being quiet, or the parking being easy, answers a traveler's condition in a guest's words, and quoting it on the room page with the month and the room type puts the answer where the assistant is reading. Google's review snippet rules give a hotel no review stars for reviews of itself on its own site; quoting guests is the point.

What our crawl found, and the two figures that matter most for a hotel

In the same audit, a crawler that ran no JavaScript fetched the homepage, the contact page and the about page of 9,483 small business websites in 90 metros. The audit publishes no separate cut for hotels; the figures describe the whole sample, and the method section says how it was drawn.

43.1% were inconsistent about who and where they are across their own three pages; 36.9% published more than one phone number, and 34.1% had no postal address a machine could parse. For a hotel the address is the product. A property whose footer, contact page and markup give three versions of it has left the platform's listing as the only version that agrees with itself.

64.7% showed no review signal a crawler could read, and only 8.9% carried rating schema. A hotel's reviews live on the platforms; on the property's own site, in nearly two thirds of the sample, a crawler found none.

61.5% had no question-and-answer content of any kind, and 50.7% had a question heading with no isolable answer under it. 2.1% kept their real content in a PDF, which for a hotel would be the rate card, the menu or the policies. 17.8% had no schema.org markup at all, and of the 82% that did, most described the website rather than the business.

7.2% sat behind bot protection that served the crawler a challenge page instead of the site. The free crawler access check tells you which of the nineteen AI crawler tokens your robots.txt lets in, and which it turns away.

What to fix first, in order

1. One property name, one address and one phone number, identical on every page and in the markup.
2. A policies page in plain text: check-in and check-out times, late arrival, parking (where, how many spaces, the fee or none), pets, children, cancellation terms.
3. Room pages with facts: beds, maximum occupancy, floor, what the window faces, bathtub or shower, connecting doors.
4. Hotel or LodgingBusiness in JSON-LD on every page, with address, telephone, checkinTime, checkoutTime, petsAllowed and amenityFeature filled in and matching the visible pages.
5. Reviews as text on the room pages, with a first name, a month and the room type, and a booking site's score kept out of your AggregateRating markup.
6. The questions your front desk answers by phone (quiet rooms, parking, breakfast hours, the dog), as headings with a real answer under each.
7. Check what a crawler receives: the crawler access check for robots.txt, and the source of a room page with scripts off.

No list of fixes can seat a hotel in an answer; that choice is made inside the assistant, where nobody else has access. What the list does is leave the assistant no reason to pass you over, and our measurement is how you find out whether it stopped.

Sources: our audit of 9,483 small-business sites, with its method · Google, local business structured data · Google, introduction to structured data · Google, review snippet · schema.org, LocalBusiness · schema.org, the vocabulary · OpenAI, crawler documentation