A restaurant listed on OpenTable now has a second description of itself in circulation, and nobody at the restaurant wrote it. AI-generated restaurant profiles arrived on 26 August as part of OpenTable's largest product release to date, and the announcement is direct about the raw material: the profiles are built "using information from restaurant websites and details operators provide".
That is a supply chain worth tracing, because the far end of it is no longer OpenTable's own app.
Five assistants read the profile, not the site
OpenTable named its distribution partners in the same release: Google Search, Maps and Gemini; ChatGPT; Microsoft's Copilot; Perplexity; and Amazon's Alexa+. A diner asking any of those for somewhere to eat is, on that path, asking OpenTable. The assistant queries a reservation platform's index and gets back a record. The restaurant's own site sits upstream of that record, but it isn't the thing being read at the moment the answer is assembled.
Which makes the quality of the record a function of what a scraper could find on the website when it looked. A page carrying a PDF menu, a hero photograph and an address gives the generator very little to work with. A page carrying dish names, prices, sections and dietary tags in the HTML gives it a lot. The generator writes from what it can read.
The channel has a published figure now
AI discovery has been an article of faith in restaurant marketing, asserted far more often than it has been sized. OpenTable put a number in the release: "LLM integrations drove 17x more seated diners year-over-year", and those diners "spent on average 20% more compared to other channels". Its AI Concierge, a natural-language discovery tool inside OpenTable, reports more than 500,000 monthly active users globally.
Treat the multiple carefully. Seventeen times a small base is still a small base, OpenTable has an obvious interest in the figure being large, and no absolute number sits alongside it. The 20% is the more useful half, because it says diners arriving through an assistant aren't a cheaper class of booking — which is the question an operator would actually ask before caring about any of this.
A reservation record is not a menu
What the profile covers is what a reservation platform knows: the room, the event space, the availability. OpenTable describes the profiles as bringing "dining rooms and event spaces to life". Nothing in that sentence is about food.
A booking record has no field for whether the ragù is made with beef, whether the set lunch is on today, or what the vegan main costs. When an assistant is asked about a dietary requirement and a budget, the reservation index answers the availability half of the question and something else has to answer the rest. On a page marked up with Menu and MenuItem, that something else is the restaurant. Where the markup is missing, the model fills the gap from reviews, from aggregators, or not at all.
Two indexes now describe the same restaurant
The position after 26 August is that a restaurant on OpenTable is described in two places at once. One description is generated, lives in a platform index, and reaches five assistants through partnerships the restaurant had no part in negotiating. The other is whatever that restaurant published on its own domain in a form a machine can parse.
The second feeds the first. It also reaches the crawlers that never touch OpenTable at all: the model answering a question about allergens rather than a table for four, the voice assistant asked what's on the lunch menu, the aggregator building a dish-level index of a city.
OpenTable's generator can only describe what it found. Menu detail that nobody has written down in a machine-readable form doesn't go missing from one answer. It goes missing from all of them.