AI recommends your restaurant. Can the guest actually book the right location?

TLDR: A restaurant recommendation only gets the guest part of the way. Check that the answer names the right location, links to current information and leads to that location's reservation page. Test the journey on a phone, keep a short record of each fault and verify the repair before calling it finished.

A guest finds your restaurant while planning dinner near the theater. The menu looks right. They tap to book and land on your other branch, half an hour away.

You may never hear about that visit. The restaurant was recommended, the website opened and the booking button worked. Yet the guest still could not reserve the place they wanted. For a restaurant group, checking those handovers is a useful companion to checking whether AI mentions the brand at all.

Updated 6 October 2026.

What should happen between an AI recommendation and a booking?

The guest should be able to identify the recommended restaurant, confirm that it fits the meal they have in mind and reach the right reservation destination. Keep the branch name and address visible as they move between pages. When a booking service needs the guest to choose a branch again, make that choice obvious.

There is no single route every guest follows. Some answers link to your website; others point to a dining guide, map or booking service. Start with the sources that appear in your own recorded answers. Google's guidance on AI features explains that its AI answers can show supporting links, while the answers and links may vary between experiences.

An answer, a website visit and a reservation are different events. Check each handover instead of treating the first as proof of the last.

How can you check the booking route without creating fake reservations?

Run a short inspection using ordinary guest questions and real public pages. Stop before submitting guest details, paying a deposit or confirming a table. If a complete booking test is necessary, agree a test slot and cancellation method with the venue and provider first.

1. Choose a specific guest request. Name an area, date or occasion, and a realistic party size. Save the question, AI service, answer and time checked.
2. Follow the answer's link. Record which site opens and whether it names the intended restaurant. A group homepage may require another clear location choice.
3. Check the facts that decide the visit. Compare address, menu, kitchen hours and group conditions with the venue's current information. Ask the restaurant to settle any disagreement.
4. Open the booking destination. Confirm the branch name and address again. Check that the date and party-size controls are usable, without completing a reservation.
5. Assign and repeat the repair. Give each fault to the person who controls that page or provider setting. After the change, start from the original link and repeat the same journey.

Use both a phone and a desktop browser. Try the normal cookie choices a guest can make. A result from a staff laptop that is already logged in does not establish that a first-time guest can use the public route.

Which guest requests should a group try first?

Start with reasons people actually choose your restaurants. A working lunch near an office, a birthday table for eight and a late dinner after a show exercise different information. Only use a question if the venue genuinely serves that occasion.

Choose one or two questions per important branch before expanding. Save the wording so the next check is comparable. Also try a direct search for the venue name: that helps separate a discovery problem from a broken booking path that affects guests who already know where they want to go.

What counts as a fault?

A wrong branch, a dead link, an unexplained change of venue or an unusable form is a fault to investigate. No tables at one particular time is not automatically a website fault. The restaurant may be fully booked, outside its booking window or operating a walk-in policy.

Record what you saw rather than guessing the cause. “The page opened Branch B after I selected Branch A” gives the team something to reproduce. “We are losing half our bookings” needs evidence the page check cannot provide.

Why do restaurant groups send guests to the wrong branch?

One common risk is a shared button copied across location pages without changing its destination. Another is an old reservation link left behind after a provider change. A booking platform may also open a general group page and expect the guest to make a second selection.

These are inspection targets, not a claim that every group has the same faults. Check the links you actually publish. Google's local business link controls let businesses manage relevant action links; some third-party links can also appear through providers. Review what the public profile shows as well as what your team entered.

A branch-specific label helps. “Book our Soho restaurant” gives more information than five identical “Book now” buttons without nearby location context. The W3C's link-purpose guidance explains why a link's text or surrounding context should make its destination understandable.

Which restaurant details should agree before guests book?

The name and address establish the location. The menu, prices, service times and booking conditions tell the guest whether it is suitable. Keep important facts on the venue page as readable text, with a dated menu where appropriate.

Google provides separate help for menu information and special hours. Updating the website does not establish that those public fields have changed. Read them after an edit.

For the developer, Google's LocalBusiness documentation and the Restaurant vocabulary describe ways to label facts such as location, hours and menu. Those labels must match the visible page. They cannot fix a booking button that opens the wrong restaurant.

What if the booking form opens but is difficult to use?

Check the controls, not just whether the page loads. Can a guest understand the date field, change party size and identify an error? Does a cookie panel cover the next button on a phone? Does moving between months keep the intended venue selected?

The W3C's guidance on labels and instructions and keyboard operation provides useful checks for your website team. Try completing the available steps with a keyboard as well as a mouse. This is a practical usability inspection, not a complete accessibility assessment.

If the fault sits inside an external booking service, send the provider the exact branch URL, device, steps and observed result. Keep your own site clear about an alternative contact route while it is being resolved. Do not advertise a phone booking option unless the restaurant can actually handle it.

How much checking does a small group need?

For a hypothetical group with four venues, two entry routes and two device sizes, the first pass contains 16 journeys: 4 × 2 × 2. One entry route might be the venue page; the other might be a source linked from a recorded AI answer.

If three journeys fail, the useful result is a list of three observed failures with owners. It is not proof that three sixteenths of guests abandon a booking. Your sample was designed to find faults, not to estimate customer behaviour or forecast revenue.

Use the count to plan the work. Use booking-system records to count reservations.

Keep a compact register: starting URL, intended branch, device, observed destination, fault, owner and retest date. Recheck after a website redesign, provider change, new venue or change to the group's booking navigation. This cadence is our operating recommendation, not a published AI ranking rule.

How do you tell whether AI discovery led to a reservation?

Keep the evidence in stages. Save the answer that named the restaurant. Use website analytics for trackable arrivals and booking clicks. Use the reservation provider's records for confirmed bookings, with an agreed way to connect the journey where the systems support it.

OpenAI's publisher FAQ describes referral tracking for clicks from ChatGPT. That helps identify some visits; it cannot reveal every guest who reads an answer, then opens a booking app separately. Google includes traffic from its AI features within its overall Search Console web-search reporting, so do not label every Google click as an AI click.

Our restaurant booking measurement guide covers that distinction in more detail. A link check can establish whether a route works. It cannot establish what caused a guest to reserve.

Where does Schmitdy fit into this?

Our multi-location booking checker helps identify public booking-path issues to investigate. The listing mismatch checker helps compare the facts on a website with supplied public listings. An inaccessible page remains unknown, and a person still needs to confirm the correct venue details.

If your only problem is a broken reservation widget, your web developer or booking provider may be the right first call. When the wider question is whether guests can discover the group and reach the right venue, ask us to review the journey.

Does a crawler need access to the booking form itself?

Keep the public venue and menu information readable. Do not expose private booking administration, guest data or payment areas for a crawler. OpenAI's crawler guidance distinguishes search crawling from other agents, and RFC 9309 makes clear that robots rules are not an access-control system. Your developer should protect private areas through proper authentication.

The public page can explain what the restaurant offers and where to reserve. The booking system should handle actual availability and confirmation. Both need to work for the guest arriving today.

Sources

1. Google Search Central, AI features and your website.
2. Google Business Profile Help, manage action links.
3. W3C, link purpose in context.
4. Google Business Profile Help, add or edit menu information.
5. Google Business Profile Help, set special hours.
6. Google Search Central, LocalBusiness structured data.
7. Schema.org, Restaurant.
8. W3C, labels or instructions.
9. W3C, keyboard accessibility.
10. OpenAI Help Center, publishers and developers FAQ.
11. Google Search Central, AI features reporting.
12. OpenAI, crawler documentation.
13. RFC 9309, Robots Exclusion Protocol.