Which data a hotel needs for accurate AI answers

Key takeaways

• Start with the property's master data and a separate markup for each room category, then add the individual features, not the other way round.
• Anything that can appear in an AI answer must be in the page's HTML and accessible to Googlebot.
• To check, view the page without JavaScript, run the testing tools and compare a chatbot's answer with your own price list.
• llms.txt is a proposal, not a standard: cheap to create, but no substitute for markup in the page source.
• The most expensive mistake is contradictory information across your website, portal profile and directory listings.

Google and chatbots need three things in machine-readable form to represent your property correctly: the property's master data, each room category individually, and the rules of the stay: arrival time, parking, pets, breakfast, cancellation. Everything else, from well-written copy to the llms.txt file, only works once these details are present and free of contradictions.

The reason is simple. A language model has no knowledge of your property; it only has text. If it finds no clear details on your site, it takes what is available elsewhere: the portal profile, a directory listing, a press release from two days ago. The answer then sounds confident anyway, just with the arrival time from 2019. The same master data and room details also form the basis for the booking flow of a direct booking website that shows availability and prices live from the same system.

Which markup a property should add first

Structured data is a fixed format for labelling content in the page source so that machines can assign it. Google describes its purpose and structure in its introduction [Q1]. For an accommodation business, the order is clear.

First the property itself: name, address, geo-coordinates, phone, languages, check-in and check-out times, payment methods. The schema.org vocabulary has a Hotel type for this. Then, for each room category, a separate HotelRoom block with size, occupancy, bed type and price range. Not one collective page for all rooms, but one unit per category that a system can cite individually. Only then the features as individual attributes: lift, parking, charging station, dogs allowed, kitchen, washing machine.

For holiday apartments, Google has its own data format for vacation rentals, which is tied to a partner programme and cannot be used freely [Q2]. If you rent out several apartments, describe the properties as above first and check separately whether joining the programme makes sense for your property.

Two mistakes come up regularly. The first is duplicate markup: a theme and a plugin each generate their own details, which contradict each other, for example two different phone numbers on the same page. The second is marking up details that are not visible on the page at all. Structured data describes what a page contains. What exists only in the source code and nowhere in the text is not a gain, but a source of errors at the next check.

What appears about your property in an AI answer

The same details appear in answers almost every time: location and nearest town, category, price range, whether breakfast is included, whether dogs are allowed, whether there is parking, when you can check in and how cancellation works. These are the questions a guest also asks on the phone.

For its AI features, Google describes the same basic rules as for classic search: what the bot is not allowed to retrieve, or what is excluded from the preview, cannot appear in generated answers either [Q3]. In practice, if your price range appears only in a booking widget that loads later via an iframe from a third-party system, it is not available for the answer. The sentence "from 140 euros for a double room, breakfast included" belongs as text on the page, and additionally in the markup.

The second point is consistency. A system that finds a check-in time of 15:00 on your site, 14:00 in your business profile and 16:00 in your portal profile will choose one of the three, and you have no influence over which. Contradictions do more damage than gaps: a missing detail leads to a follow-up question, a wrong one to an annoyed guest standing at a locked door.

An aparthotel with twelve units: how many details add up

Let us work through this with a real-world example. Suppose you run twelve units in three categories: studio, two-room apartment and maisonette. For the property itself you maintain around twelve master fields. Each category adds about eight details: size, occupancy, beds, kitchen, balcony, price range, cleaning fee, minimum stay. That is 3 times 8, i.e. 24 details, plus twelve for the property: 36 details in total.

These 36 details are probably held in four places today: your own website, the Booking.com profile, the Airbnb listing and the Google business profile. That makes 144 maintained fields that are meant to say the same thing. If you change the check-in time from 15:00 to 16:00, the change has to reach four places, and there are three opportunities to forget one.

The assumption here is deliberately simple: the same number of features per category and no seasonal variations. With two seasonal prices per category, the price block doubles. The number itself matters less than the insight: without a single source from which the website draws its details, you maintain the same information several times, and contradictions arise not from carelessness but from arithmetic.

How to check what is actually being read

Three checks are enough to start. First, open your room page and look at the source code. Is the price there as text, or does it appear only once the widget has loaded? Second, run your pages through Google's structured data testing tool; errors and warnings are named there, and the introduction explains the formats [Q1]. Third, ask a chatbot three questions a guest would ask, such as "Does the property have parking?", "Are dogs allowed?" and "What does a double room cost in June?", and compare the answer with your price list.

The third check is the most uncomfortable and the most useful. It does not show whether your markup is technically correct, but what a guest ultimately hears. Note the discrepancies and work through them, rather than polishing the wording on the home page.

Record the result in writing: date, pages checked, discrepancies found, corrections made. Half a page is enough. At the next round you will see whether an error recurs, and recurring errors almost always have a cause in the system, not in the text.

What llms.txt does and does not do

llms.txt is a text file in the root directory of the website that lists the most important pages in Markdown and briefly describes them. It is published as a proposal and is explicitly labelled as such [Q4]. No search provider has committed to evaluating it.

The sober assessment follows: the file takes half an hour to set up, costs nothing to run and does no harm. But it does not replace markup in the source code, and it does not lift any page in a ranking. Anyone who creates it should fill it with the same facts as the pages themselves. A third version of the house rules is worse than none.

What you need to handle yourself

The technology can be handed over, the facts cannot. Someone in the property has to determine what applies: arrival from when, dogs against which fee, breakfast until when, free cancellation until when. The same person must report changes as soon as they are decided: at the seasonal switch, after a renovation, when the parking space is lost.

A fixed date, say twice a year, makes sense: go through the master data, repeat the three checks above, and correct discrepancies between the website and portal profiles. Also not outsourceable is the decision about which details should be public. If you only quote prices on request, you will appear with concrete values less often in AI answers. That is a legitimate decision, but it should be a deliberate one. A first overview of the current state comes from a technical look at the existing hotel website. How visibility in AI answers arises overall is covered in the article on visibility in AI search. If you also want to use the maintained data for guest questions, the link is the AI concierge for recurring questions.

Your next step: open the source code of a room page today and check whether price, occupancy and arrival time are there as text. How the markup is then structured is covered under structured data for AI search, and for implementation you can book an appointment.

Sources and further reading

[Q1] Google Search Central: Introduction to structured data

[Q2] Google Search Central: Structured data for vacation rentals

[Q3] Google Search Central: AI features and your website

[Q4] llms.txt: proposal and specification