TLDR: The AI-search visibility your restaurant group has already earned does not travel with you to a new address. It is tied to each location's own facts, listings and review history, and opening another site is exactly the moment those can start to disagree with each other. Run a short before, launch-day and after routine at every opening, and the group keeps what it has already built.
This is a different problem to the one a brand-new restaurant faces. Our guide to opening a restaurant in a new city covers that cold start: no history, no listings, nothing for an engine to recognise yet. If your group is already named in AI answers somewhere, the real question is how to keep that true while you add a fourth, fifth or tenth site.
Why doesn't visibility earned at one location travel to the next?
An AI engine answering a diner's question about one of your venues draws on facts tied to that specific address: its business profile, its reviews, its menu and its booking link. Growth multiplies the number of these records that have to agree with each other. The quiet failure is not usually a wrong answer about the new site. It is a degraded answer about a location you already had working correctly.
This is not a hypothetical risk. An independent, census-based audit of two international dining markets found that whether a venue was recommended at all correlated more with documentation signals, review volume, having its own website and listed price information, than with star rating alone, and the result varied sharply between adjacent, otherwise similar venues. The facts behind a listing, not the reputation alone, decide whether an engine can use it.
Your facts stop matching once one location changes and the others don't
A group rename, a menu refresh or a change of booking platform at head-office level often reaches every live location except the newest one, or reaches the newest site but not the group directory that is meant to list it. Google's own guidelines for representing your business are specific here: locations within the same country should carry the same business name and share the category that best represents the business, with limited named exceptions for genuine sub-brands. A new opening is the moment that rule gets tested, because it is when someone is most likely to type the name slightly differently on a new form.
A new site launches with an incomplete profile, so engines borrow from elsewhere
A business profile published with a placeholder address or a "menu coming soon" note does not stay empty in an AI answer. When a reader's question names your group, an engine that cannot find a confident answer for the new address has an obvious second source: the group's existing, better-populated listings. That can mean an answer about your new location quietly describes the kitchen, hours or booking route of a different branch. Google's own Local Business structured data documentation is clear that the markup on a location page should describe what guests can actually see; a template that copies one branch's address or hours into another's structured data creates exactly this kind of mismatch, and the mismatch is what an engine ends up repeating.
Review and listing platforms start the new location at zero, not at the group's level
Google only moves reviews automatically when a business relocates and the owner updates its existing profile in place. Opening an additional, genuinely new site is a different case: it creates its own profile and does not inherit the group's accumulated reviews. None of the platforms a group typically relies on move at the same speed as the opening itself. Google's own review of a submitted verification can take up to five business days once the steps are completed, and a postcard code commonly takes around 14 days to arrive and expires after 30. A newly claimed Yelp location is usually reviewed within two days or fewer, and claiming an additional location happens directly in your Yelp for Business account settings. TripAdvisor behaves the same way: a new address starts life as an unclaimed listing, and claiming it is free but gated behind its own identity-verification step before management access opens up. OpenTable only activates group-level features for a new site once a named approver has signed it into the group account; until then it stays pending. Until each of those steps clears, the new venue has less third-party evidence behind it than the rest of the group, through no fault of the operator.
A zero-review new site is also where a group is most tempted to incentivise early reviews to catch up quickly. In the UK, that is now a specific legal risk rather than a grey area: fake and concealed-incentive reviews became a banned practice under the Digital Markets, Competition and Consumers Act 2024 from 6 April 2025, and the CMA's published guidance expects a trader that publishes reviews to take reasonable, proportionate steps to prevent them. Leave the new site's reviews to arrive at their own pace and treat the gap as a known, temporary state to disclose internally, not a target to close by incentive.
What should a restaurant group check before, during and after every opening?
Run this at every opening, not only the first one. It is written as three stages so each has a clear owner and a clear point at which it is done.
- Before you open: audit the existing locations first. Pull every live location's name, address, phone number, hours, menu link and booking destination from its own page, not from memory or a head-office spreadsheet. Confirm the group directory and homepage still point to the correct venue for each one, not just the ones opened most recently.
- Set the new site's identity before any listing goes live. Decide the exact name variant and category for the new location now, matching the group's existing name and category per Google's guidance, and write it down so whoever creates the listings does not improvise one on the day. If the venue genuinely isn't trading yet, use Google's own future-opening-date option on the profile rather than leaving it ambiguous or marking it open early to look further along than it is.
- Launch day: publish a complete page, not a holding page. The new location's page needs its address, opening status, menu and booking link together from the day it goes live. A logo and a "coming soon" banner leave the job unfinished and give an engine nothing reliable to cite.
- Launch day: claim the listings and check parity in both directions. Create, rather than duplicate, the new site's Business Profile and claim it on every review or listing platform the group already uses. Then check the group directory the same day: does it now link to the new venue correctly, and does every older venue's entry still point to itself rather than to the newcomer?
- Re-check the sibling locations, not just the new one. A rollout is also the moment someone is most likely to copy a template and fat-finger an older page while they are in there. Spot-check two existing locations' pages and profiles on launch day for exactly this reason.
| Day | What to check | Why it is the point most groups skip |
|---|---|---|
| 30 | Is verification complete on every platform, with no review or listing still pending approval? | Pending approvals are easy to lose track of once the opening-week attention moves on. |
| 60 | Run the same set of local AI-search questions against the new site and two existing sites, on the same engines and settings used before the opening. | Groups usually only test the new location. A drop at an older site is the one that actually costs visibility. |
| 90 | Confirm the new site has its own, genuine review history building, and that no older location's listing was altered during the rollout. | This is when a mismatched template edit from launch week has had time to actually surface in an answer. |
How do you know whether the safeguard worked?
Compare like with like. Run the same set of local questions, on the same engines and with the same settings, before the opening and again at each recheck point, and keep branded questions in a separate group from the questions that do not name you at all. A single screenshot proves nothing either way; a repeated pattern across several checks does.
Treat an "unknown" result as unknown, not as zero. If a platform's answer history is incomplete, a source is blocked, or a sample is too small to read, say so and note it for the next check, rather than recording a drop that may just be a measurement gap. Keep location-page visits, booking clicks and confirmed reservations as a separate set of numbers from AI-mention counts. A mention is evidence about one answer at one time; it is not a booking, and crediting every change in covers to AI visibility will hide the actual cause when something else moves at the same time, a seasonal menu, a local event, a staffing change.
How this differs from launching in a brand-new city
Our restaurant opening checklist for a new city is the right guide when a venue has no prior AI visibility to protect: the job there is building facts an engine has never seen. If your real problem is that AI answers already send guests to the wrong branch of a group that is established in several cities, our guide to helping guests find the right branch covers that ongoing diagnosis, independent of any particular opening. Between the two sits a narrower case: visibility you already have, and the routine to run specifically at the moment you add to it.
Where does Schmitdy fit into this decision?
Schmitdy's free AI Search audit is the practical way to check nothing slipped, run once before an opening and again after the 60-day mark. It records how your group currently shows up across ChatGPT, Claude and Google AI, what is shaping those answers, and a prioritised 30-day plan, and for a group with more than one location it separates the branches, checks each location's facts individually, and assigns the resulting actions to the team responsible for each one rather than to the group as a whole. Marco reviews every accepted request personally.
| Approach | Who does the checking | What you actually get | Who owns the fix |
|---|---|---|---|
| No formal check, rely on the opening-week punch list | The opening team, as one task among many | Confidence the new page exists, not evidence about the group's AI answers | Nobody specifically, until a guest reports a problem |
| A general AI-visibility monitoring tool alone | An automated crawl against prompts you configure | A dashboard of mentions, without a branch-level breakdown or a plan | The person who bought the tool, usually without a route to a fix |
| The checklist above, run in-house, with no outside check | Your own team, with no outside check | A documented routine, but no independent read on whether it worked | Your team, which also wrote the audit it is marking |
| Schmitdy's free audit, before and after the opening | An independent review of your actual AI answers, branch by branch | A dated record of what changed, with named next actions by location | The team each action is assigned to, with a plan to check against |
Do this before committing to any paid work: it tells you whether the new location needs a different remedy from an older one that has quietly drifted.
Choose one upcoming or recent opening and check its public journey from "does this location exist in AI answers" to "does the group directory point to it correctly." If you want an independent read on where that stands, request a free AI Search audit and bring your location list so the branches are checked individually, not as one average.
Sources
- Google Business Profile Help: Verify your business, for verification timelines.
- Google Business Profile Help: Guidelines for representing your business, for the same-name, same-category rule across locations.
- Google Business Profile Help: Add a future opening date.
- Google Business Profile Help: Manage reviews across Business Profiles, for how reviews do and do not move between profiles.
- Google Search Central: Local Business structured data.
- Yelp for Business: How do I add another location of my business?
- Yelp for Business: How do I claim additional locations of a business?
- OpenTable Support: Connect and manage your restaurant group in OpenTable
- TripAdvisor: Claim your business, for how a new, unclaimed listing is verified.
- legislation.gov.uk: Digital Markets, Competition and Consumers Act 2024, Schedule 20, fake-review prohibitions in force from 6 April 2025.
- CMA208: Fake reviews guidance (PDF).
- arXiv 2608.07069: "Invisible to the Machine" (Pitenin), an independent audit of AI restaurant recommendations against a complete local venue census.
Squarespace
Webflow
Sanity
Shopify
HubSpot