Restaurants
The guest asks an assistant where to eat tonight. An answer can use your menu only if it can read it.
Someone asks ChatGPT for a quiet Italian place nearby with a gluten-free pasta that takes reservations for 7:30 and has parking. The assistant reads restaurant websites and listings and answers with three names. A PDF menu, or hours that differ between your site and your profile, takes you out of that answer.
A restaurant's pages should answer what a guest asks: the menu as text a machine can read, hours that agree on every page that carries them, and the things guests ask about (dietary options, reservations, noise, kids, parking) stated in sentences. An answer can repeat that a dish is 'gluten-free' only if the dish and the label exist as words on the page. An image of the menu is a picture of words.
How your customers ask
How guests ask before they book
The guest's question is about tonight
The question carries a cuisine or a dish, a constraint, a time and a place: Thai, gluten-free, tonight, near here. A restaurant that fails a constraint has no place in that answer, and one whose pages never mention the constraint gives the AI assistant nothing to confirm it with.
A guest's question turns on four things: what is on the menu, whether you are open now, whether the guest can book, and whether the room suits them. The first is a document you already print. The last is a sentence nobody writes, because nobody at the restaurant has ever been asked by a page whether it is quiet.
Hours are the fact most likely to live in four places: your site, your profile, the reservation platform, the delivery listing. When two disagree, an assistant has to pick one, or say the hours vary. 'Hours vary' is the answer that sends the guest somewhere else.
What has to be on a restaurant's site as text
The middle column is what your host says on the phone. The right-hand column is the form a machine can read, and a PDF fails every row that depends on the menu.
| The guest asks | What your site states | Form |
|---|---|---|
| What do you serve | The full menu as text: every dish, a description, the price and the section it belongs to | HTML on a menu page; Menu, MenuSection and MenuItem with an Offer and a price in JSON-LD |
| Can I eat there | Dietary labels beside each dish: vegetarian, vegan, gluten-free, nut-free; what the kitchen can adapt and what it cannot | A label in text next to the dish, not an icon alone |
| Are you open tonight | Hours by day, kitchen close where it differs from door close, holiday exceptions | Text plus OpeningHoursSpecification; the same hours on your profile and every platform |
| Can I book | Whether you take reservations, for which party sizes, the walk-in policy, how to book | Text; acceptsReservations in the Restaurant markup |
| Will it suit us | The room in a sentence: noise, seating, bar versus dining room, high chairs, parking, step-free access | Plain sentences on the visit page |
| Who and where | One name, one address, one number, the cuisine and the price range | Restaurant in JSON-LD with servesCuisine and priceRange |
| Is it good | Guest reviews quoted as text, with the dish they mention | Quoted text, with the dish and the platform |
Restaurant is one of schema.org's LocalBusiness subtypes, and schema.org's Menu vocabulary (Menu, MenuSection, MenuItem, each item with an Offer and a price) is how a menu becomes structured data; hours go in OpeningHoursSpecification. Google's local business documentation lists what it reads, and its structured data introduction asks that markup describe only what a visitor can see: a dish in the markup is a dish on the page, at the same price.
A menu in a PDF is a file, not a page. A fetcher may or may not open it, and when it does, the sections, prices and labels arrive as a stream of words with no structure. A menu in an image arrives as nothing. If you can print it, you can post it; it is the same document.
What the crawl found: the menu in a file, the hours in four places
In our audit of 9,483 small business websites (40 trades, 90 metros across the US, Canada, Europe and the UAE, late August to early September 2026), 2.1% of the sites kept their real content, the price list or the service menu, in a PDF, and 3.0% rendered their content only in JavaScript. The audit's crawler ran no scripts, as the assistants' own crawler documentation gives no reason to expect a rendering step either.
43.1% were inconsistent about who and where they are across their own three main pages, 36.9% published more than one phone number, and 34.1% had no postal address a machine could parse. For a restaurant, the address is the answer to 'near me' and the hours are the answer to 'tonight'.
On 64.7% of the sites a crawler found no review it could read, and 8.9% carried rating schema. 61.5% had no question-and-answer content of any kind: nothing that says whether there is parking, whether children are welcome, whether a table for twelve is possible.
When we put one buyer question per business to Claude, with web retrieval on, 14.9% of 9,240 businesses were named; of every name it gave, 99.4% were actual businesses and 0.6% were directories or aggregators. One question, one assistant, one day: a direction, not a rate.
What to fix first, starting with the menu
- The menu as HTML: every dish, its price, its section and its diet labels, with the date it was last changed. Keep the PDF as a download beside the text if you like; the text is what gets read.
- Menu markup: Menu, MenuSection and MenuItem with Offer and price, matching the page.
- Hours in one place of truth, copied the same day to the site, the profile, the reservation platform and the delivery listing; kitchen close stated where it differs.
- One name, one address, one number on every page, and Restaurant markup with servesCuisine, priceRange, acceptsReservations and OpeningHoursSpecification.
- The room in sentences: noise, seating, children, parking, step-free access, the largest table.
- Guest reviews on the page as text, with the dish they mention and where they were posted; a platform's ratings stay out of your review schema, as Google's review snippet rules ask.
- Check what a crawler receives with the crawler access check, then measure the same guest questions before and after, as our methodology describes.
Go deeper
Articles for restaurants
Fundamentals
AI visibility for restaurants: named for tonight, with the right hours
Technical & Structure
Making a restaurant menu readable for AI: every dish, its labels and its price, in text
Local & Industries
Restaurant data across portals: one set of hours, one menu, one price range, everywhere a guest looks
Local & Industries
What travelers ask an assistant before they book a hotel
What owners ask
Our menu changes every week. How can a web page keep up?
If you can print it, you can post it; the page is the same document as the printout. A dated menu page that is right most weeks is worth more to an assistant than a PDF that is always right and never read. Put the date on the page, and when a dish is gone, take it off the same day you take it off the board.
We are full every night with regulars. Why does this matter?
It may not, for the regulars. It matters for the guest who is new in town, the visitor with an evening free, and the person with a diet who asks before they go anywhere. Whether those people are being sent to you today is a question the numbers answer; the free check fetches your site the way our audit did and reports what an assistant can read on it.
Our reservation platform shows our hours and menu. Isn't that enough?
The assistant may read the platform's page and may read yours, and when they disagree it has a contradiction to resolve. The platform's page is the platform's; your site is the one place where every word is yours. And the answer a guest gets is mostly restaurants by name, not platforms: in our probe, 99.4% of the names Claude gave were actual businesses.
Do we have to publish prices?
The menu is the price list, and a guest asking for 'somewhere not too expensive' gets an answer built from the prices assistants could read. Prices on the menu page and a priceRange in the markup let the assistant place you; a menu without prices leaves it to guess or to skip you. Change them when they change; the page can move as fast as the board.
Sources: our audit of 9,483 small-business sites, with its method · schema.org, Menu, MenuSection and MenuItem · schema.org, OpeningHoursSpecification · schema.org, LocalBusiness and its subtypes · Google, local business structured data · Google, introduction to structured data · Google, review snippet