GEO for Hotels, Restaurants and Cafes: Show Up in AI

The sentence a guest now types into their phone looks like this: "Can you recommend somewhere still open at 8 pm, within walking distance of the hotel we are staying at, that has a gluten-free option and works with a three-year-old?" That is not a search query. It is a request carrying five separate constraints inside it. The old habit was to type "Kadıköy restaurant" into a search box, and the difference between the two is not only length. The old query was a category name. The new one is a set of filters.

Look at enough of these requests and three features repeat. The first is context: the user puts where they are, who they are with and what time it is into the sentence itself. The second is constraint: a feature is required, stated not as a preference but as an elimination criterion. The third is multiplicity: the constraints are not raised one at a time, they are listed to be satisfied all at once. A page written with keyword logic answers none of the three, because the page was built around a topic rather than around conditions.

For hospitality businesses the practical consequence of this shift is clear: the user no longer looks at a list of ten links and does the filtering themselves. The assistant does the filtering, and two or three names are left. Being one of those names has little to do with how good your site looks. It is a question of whether the constraint information about your business can be read by a machine.

Which constraints an AI matches before recommending a venue

A multi-constraint request is not processed in one piece on the model side. It breaks apart into conditions that each have to be verified separately, and every condition is an elimination step of its own. For hotels, restaurants and cafes those conditions gather under six headings in practice.

Location and distance. "Within walking distance" works against the reference point the user is standing at, not against the name of a district. A business whose site mentions only the district does not land in the same bracket as one that states its position by street, neighbourhood, nearest stop and a recognisable landmark.

Hours. Two different pieces of information get mixed up here: the closing time of the venue and the last order time of the kitchen. The answer to "is it open at 8 pm" usually depends on the second one, but most sites publish only the first. Public holiday and weekly closing day exceptions are left out in the same way.

Price range. An average per person, a starting nightly rate for a room, or at the very least a band. A page that never states a price drops out of consideration on any query that carries a price constraint.

Diet and cuisine. Gluten-free, vegan, vegetarian, lactose-free, halal. There is a large gap between leaving this at the level of "ask us" and writing down which item on the menu suits which diet.

Accessibility. Wheelchair entrance, lift, accessible toilet, whether there are tables on the ground floor. This constraint turns up in queries more and more often, and it is the information found least often on sites.

Children and pets. High chair, children's menu, play area, pet policy, whether pets are accepted in the garden. In queries from families and pet owners these can be decisive on their own.

All six do not have to be satisfied at the same time. But an answer about each of them has to be findable, because what the model does is not to rank businesses, it is to match conditions.

If the constraint is missing, an AI can neither rule you out nor pick you

The asymmetry here goes unnoticed. A human visitor who lands on your site and sees no gluten-free option picks up the phone and closes the gap themselves. A language model does not make that call. Producing a claim it holds no evidence for — "there is a gluten-free menu here" — runs against its most basic accuracy constraint. So when the information is absent, the model does not give a positive answer.

The result is this: missing information ends up in the same place as negative information. You may well accept pets; unless it is written on your page, you are not in the answer to the query "cafe where I can bring my dog". The reverse holds too, and that is in fact the good news: most of your competitors are not writing this information down either. A business that states its constraints openly gains a clear advantage out of the sector's general omission.

If you want a closer look at the difference between local search habits and this new behaviour, the piece where we cover the difference between local SEO and GEO is a good place to start. In short: local SEO aims to get you onto a list, GEO aims to get you inside the answer itself.

Making menu, room and amenity information machine-readable

Three common patterns make information invisible in the hospitality sector.

The first is the PDF menu. Attached to the page exactly as it came from the designer, a PDF is readable for a human but is not reliably processed as part of the site's content. The second is text embedded in an image: a photo of the menu, a poster graphic describing room features, a screenshot of the price list. The third is content that only opens on a click: room descriptions living inside the booking engine, tabs loaded with JavaScript. All three end the same way — the information exists on the site, but not in the text of the page.

In hotels the most expensive version of this pattern shows up in room types. Room names are listed on the page, but square metres, bed layout, view, balcony, bath or shower, the option of an extra bed and similar details stay inside the booking engine. On a query such as "a room suitable for a family with two children", that is exactly the information that makes an assessment possible.

The first step of the fix is boring but effective: write the menu, the room types and the amenity list onto the page as plain HTML text. The images and the PDF can stay; make sure a text equivalent exists alongside them.

The second step is structured data. Restaurant for restaurants, Hotel or BedAndBreakfast for hotels, and over those types servesCuisine, priceRange, a Menu / MenuSection / MenuItem set connected through hasMenu, suitableForDiet at item level, amenityFeature for facilities, openingHoursSpecification for opening hours, plus acceptsReservations, petsAllowed, and checkinTime and checkoutTime for hotels. These fields do not stand in for the visible text on the page, they confirm it. We looked in more detail at which signals the markup strengthens in our article on schema markup and E-E-A-T.

When booking platforms represent you

For most hotels and restaurants the bulk of online visibility comes from third-party platforms: booking sites, map listings, food apps, social media profiles. While preparing an answer an assistant can look at all of these sources at once, and it sees the contradictions between them.

The contradiction turns up in three places. Name, address and phone written differently from source to source — the branch called "Kafe X Moda" in one place and "X Coffee" in another, an address format that does not match, a phone number left at the old line. Opening hours, especially in businesses with a winter and summer difference. Price, where the amount shown on the platform does not agree with the amount on your own site.

With hours in particular this picture is common: the map listing still carries summer hours, the booking platform shows the shorter hours you set for winter, and your own site has a third set of hours written two years ago. All three were technically correct at some point. All three cannot be correct today.

When it finds a contradiction the model does one of two things: it either does not use the information at all, or it prefers the source it judges to be more current. Neither works in your favour, because in both cases the control is not yours. This is why your own site has to be positioned as the primary source and the platforms aligned to it — not the other way round.

The practical method is simple: once a quarter, collect every listing where the business name appears into a single table; put name spelling, address, phone, hours and closed days into columns side by side and correct the ones that differ. This audit, together with the other groundwork on the infrastructure side, is part of the order we describe in our guide to a GEO-ready website for a small business.

Seasons, promotions and temporary changes

The hospitality sector runs on seasons. Winter menu, summer terrace, holiday programme, two weeks closed for refurbishment, booking conditions that change during wedding season. This information is published on the site and then, because it is never updated afterwards, turns over time into a source of wrong information.

Two separate things get confused here: how current the content is, and the validity window of the content. The dateModified field, which reports when the page last changed, solves the first. For the second, temporary changes to hours need specialOpeningHoursSpecification, and dated promotions need a start and end date written openly on the page. A page headed "summer promotion" that does not say which summer it belongs to misleads the user and the model alike.

Rather than deleting expired promotion pages, it is healthier to put a "this promotion has ended" note on top of them; that way links do not break and validity is stated explicitly. For fast-moving fields such as price and availability the rule is this: the amount written on the page should be the same amount met at the booking step. A gap between the two does more than cost you the user's trust — it also pulls down the reliability of your site as a source.

A realistic starting order for a small business

For a cafe run by a one-person team, all of the above may be too much at once. If the sequence is set up as follows, even the first two steps produce a measurable difference.

1. Write a single "amenities" page. Plain text, point by point: diet options, accessibility, children and pet policy, parking, wifi, outdoor space. Half an hour of work.

2. Move the menu and the room types into HTML text. Let the PDF and the images stay, and add the text equivalent underneath them.

3. Set one source of truth for the hours. Keep the hours on the site in a single place, write the exceptions there as well, then add openingHoursSpecification.

4. Run the platform audit. Make the name, address, phone and hours identical across every listing.

5. Make the booking path explicit. How many people a booking is taken for, how far in advance it can be cancelled, whether there is a channel other than the phone — write it on the page. If you are considering automating the booking and cancellation flow, our article on appointment and cancellation processes explains what that looks like on the operational side.

6. Measure. Put your own constraint queries — "somewhere in this neighbourhood I can go to with a child that has a gluten-free option" — to several different assistants and record the answers with the date. There is no other reliable way to see the change; keep a record instead of an estimate.

If you would like to talk through how these steps would land in your own business, you can take a look at the solutions we offer.

The sector page we prepared for hotels, restaurants and cafés separates these steps by business type.

Frequently Asked Questions

Does my restaurant really need its own website, or is a social media account enough?

A social media account gives you visibility but carries no structured information: menu items, diet suitability, exceptions to opening hours and accessibility details end up scattered across post captions. When an AI assistant produces a recommendation it looks for a verifiable and permanent source. A plain, even single-page site that contains this information as text makes a more reliable reference than a social profile that is constantly scrolling on.

I publish my menu as a PDF, why is that a problem?

A PDF may be readable to the human eye, but it is not reliably processed as a natural part of the page content; the item names, prices and diet notes inside it are usually left out of the assessment. The healthiest route is not to remove the PDF but to publish the same information on the page as HTML text as well. That way the print-quality menu and its machine-readable equivalent both exist at the same time.

What happens if the details on the booking site differ from the ones on my own site?

When an assistant sees contradictory information it either does not use that information at all or prefers the source it treats as more current. In both cases the control is not yours and you can be cited with the wrong hours or the wrong price. This is why your own site should be treated as the primary source and platform listings realigned to it at regular intervals, name spelling, address format and phone number included.

If I add Schema.org markup, do I still need to write the text on the page?

You do. Structured data does not stand in for the visible content on the page; it describes and confirms it. A schema field with no counterpart on the page is ignored at best, and when it is inconsistent it weakens the trust signal. The right order is to write the information as readable text first, then label the same information with schema.

How should I keep seasonal menus and promotions on the site?

Write the validity window openly on every dated piece of content: what date it started, when it ends. Instead of deleting an expired promotion page, add a note on top of it saying that it has ended, so that links do not break and the information does not misdirect. There is a separate schema field for temporary changes to hours; it serves to declare the exception without disturbing the normal opening hours.