When a guest asks about one restaurant in a group, the answer needs to lead to that restaurant. A familiar brand name is not enough if the suggested menu belongs to another branch or the booking button opens a venue across the city.
The practical response is one useful page per location, supported by a clear group directory and consistent venue facts. We describe the problem as location confusion rather than assuming your branches are competing inside a hidden AI scoring system. You can observe wrong-branch answers and fix the information behind them. You cannot infer how an engine distributes “authority” merely because a venue was absent from one answer.
What to check first
- Each venue has its own address, hours, menu details and booking destination.
- The group directory explains where each location is and what makes it different.
- Business profiles and important third-party listings point to the right branch.
- Shared menus are clearly shared; local differences are stated explicitly.
- Reporting separates brand mentions, correct-venue mentions and completed enquiries.
Why does an AI answer sometimes recommend the wrong branch?
The first task is to establish what actually happened. Did the answer name the wrong location? Did it name the right one but attach a different address? Did the restaurant's own booking link send the guest elsewhere? These are different defects and require different fixes.
Save the question, answer, date, location settings and linked sources. Then compare the public information. A stale publisher listing may still describe a closed venue. The group homepage may present one restaurant's photograph beside another restaurant's booking button. A venue page may inherit the head office's address in its structured data.
These are testable possibilities, not a claim that all mistakes originate on your website. Generated answers can be wrong even when your pages are accurate. Establishing where the wrong fact appears lets you act on what you control and request corrections where appropriate.
Start with a question a guest would genuinely ask. “Where can I book dinner near the station?” is a better location test than a highly engineered question that names your brand, exact menu and every selling point. Run branded questions too, but keep the two groups separate in reporting.
What belongs on each restaurant's location page?
Treat the page as a compact visit planner. Someone arriving from a search answer should be able to decide whether this is the right venue without returning to a group homepage and starting again.
| Page element | Group-wide information | Location-specific information |
|---|---|---|
| Introduction | Brand and cuisine | Neighbourhood and setting |
| Menu | Shared food philosophy | Actual menu, service and local exceptions |
| Reservations | General booking policy | Correct venue link, group route and walk-ins |
| Hours | Brand contact if useful | Service hours and exceptional closures |
| Access | Group accessibility contact | Entrance and facilities verified at this venue |
| Events | Shared programme | Dates, availability and local capacity |
Write the location-specific parts from facts approved by the venue team. A quiet room suitable for a business lunch at one site does not establish that every branch offers the same experience. Equally, avoid dressing identical facts in different prose just to make pages appear unique. Useful differences come from the restaurants themselves.
Give guests a visible way to switch locations. If a date is unavailable at one venue, an alternative can be helpful, but it should be clearly named before the guest moves to another booking journey.
Should every branch have a different website?
Usually the first question is whether the existing group website can support distinct, usable location pages. Separate domains create extra maintenance and are not a prerequisite for explaining multiple venues.
A group directory can link directly to each location. Each location can link back to the directory and, where helpful, to nearby alternatives. Use page titles and headings that make the branch clear while preserving the actual brand name.
Google's business-profile guidelines address consistency across chains and individual locations. Do not rename each profile with extra keywords in an attempt to force a distinction. Put useful area information in the appropriate fields and in the page content.
An independently branded concept may justify a different site for commercial reasons. That is a branding and operating decision, not a shortcut to AI recommendations. Before restructuring domains, compare the cost with simply fixing the directory, pages and booking links you already have.
How do you handle shared menus and branch exceptions?
Create a single maintained source for genuinely shared information and make the exceptions obvious where guests choose a venue. A group may share its core menu while offering different lunch services, wine lists or private-dining arrangements.
For example, imagine a fictional three-site group. Its central restaurant serves lunch and dinner, its neighbourhood site serves dinner only, and its third location has a private room. A generic “open for lunch and private dining” claim on every page misrepresents two venues. The fix is not more promotional writing; it is accurate local information.
A shared menu link can work if the page clearly lists the locations it applies to. If a venue offers a materially different menu, publish that menu at a distinct, stable address and link to it from the location page. Give seasonal documents a review date and remove outdated links from navigation when a menu changes.
Check bookings with the same discipline. Open each branch's reservation link on a phone, confirm the selected venue and inspect the route for large groups. A central enquiry form should ask which location the guest wants rather than leaving the reservations team to guess.
What should your developer check?
Ask for a small, specific review rather than an undefined “AI optimisation” project. Each venue page should be reachable through normal links, available to search engines and readable without access to an internal account. Important facts should not live only in an image or a staff-only reservations dashboard.
The page's structured data should match the visible venue. Google's Local Business documentation describes fields for addresses, hours and menu links. A shared template is useful, but test the output on every branch: copying the template must not copy the first restaurant's address into all the others.
Check that old venue URLs have a sensible destination when a restaurant moves or closes. Do not silently present a closed location as open or send every historic link to the homepage. The right treatment depends on whether the business relocated, closed permanently or changed concept.
Keep this work proportionate. Google's guidance for generative AI search does not require a special AI file or new kind of markup. Clear, accurate location pages serve guests regardless of how a search result was generated.
Who should own the facts when several teams make changes?
A useful division is for the group team to own the template and each venue to approve its facts. Marketing can maintain the directory and reporting; operations can confirm service details; reservations can verify the booking destination.
Give each location a short change record. Record the fact that changed, its effective date, the person who approved it and the public places needing an update. A change to kitchen hours might affect the website, Google Business Profile, booking platform and a major directory. A new photograph probably requires a smaller update.
Set a regular review rhythm and an event-based one. A monthly check catches drift, but an unexpected closure or changed service must be corrected when it happens. Avoid creating a process that waits for the next marketing meeting to fix information a guest needs today.
How can you measure whether the right venue is being found?
Build a small question set for each branch using its actual catchment and occasions. Include the neighbourhood, relevant transport stop and genuine reasons to visit. Keep a separate set for the group brand so a strong brand result does not hide a weak branch result.
For each sampled answer, record whether the group appears, whether the correct venue appears, whether the address and service facts are accurate, and whether any link lands on the correct page. A brand mention with the wrong booking destination should not count as an unqualified success.
Keep the questions, services and settings consistent enough to compare periods. If you add a new city or a new question category, label the change instead of treating the new set as directly equivalent to the old one. AI answers vary, so look for repeated patterns rather than celebrating or diagnosing from a single screenshot.
Alongside those observations, review location-page visits, booking starts and verified reservations where your systems support them. Report unavailable attribution as unavailable. A growth in mentions can be encouraging without proving additional covers.
What is the smallest useful first project?
Choose the venue with the clearest commercial need: an opening, a recurring wrong-branch problem or a location with capacity to fill. Audit its page, profile, menu and booking route together. Fix the gaps, then use that checked example as the pattern for the rest of the group.
For a new city, use the restaurant opening checklist. If you need help choosing the first venue and question set, request an AI-search audit with your location list and priority occasions.
Squarespace
Webflow
Sanity
Shopify
HubSpot