I have run pre-engagement audits on a stack of local restaurants this year, the Google Business Profile, the listings, the website, the ordering setup, the data layer, and the picture is remarkably consistent. Strong brands with loyal regulars and good food, sitting on a digital presence that leaks on every layer. Not broken in dramatic ways. Leaking in small, fixable, compounding ways nobody on the floor has had time to close.
What changed is where the leaks hurt. The decision about where to eat used to happen in a search and a map result. It now also happens inside an AI answer that never shows the customer a website at all. If your data layer is messy you are invisible in two places instead of one. This is the audit I actually run before recommending anything.
Why do restaurants lose covers before anyone walks in?
At the top of the funnel, in the few seconds where someone decides whether you are even an option. Owners think of that moment as a reservation or a walk-in. It happens earlier, and the restaurant that loses it never finds out. There is no bounced-reservation report for the person who saw a three-year-old cover photo and picked the place down the street.
What does Google actually rank restaurants on?
Relevance, distance, and prominence, as Google states plainly in its own Business Profile documentation. What has shifted is what feeds prominence.
Whitespark's 2026 Local Search Ranking Factors survey, which polls local search practitioners and ranks over 180 factors, is the most useful public read on this. Two things stand out, and one of them is a correction to advice you will find everywhere:
- Open at the time of the search is a genuine top-five factor. "Business is Open at Time of Search" ranks fifth. Wrong holiday or seasonal hours do not just annoy callers, they suppress your position during the exact hours you are trying to fill.
- Posting cadence is not the lever it is sold as. Whitespark ranks frequency of Google Posts at 148th and quantity at 168th, near the bottom of a list of 180. Anyone selling you a two-posts-a-week package on a ranking promise is selling something the evidence does not support. Post anyway, because the profile is where a hungry person actually decides and a current special in front of them at that moment converts. Just do not buy it as an SEO service.
- Photo recency sits in the middle. Whitespark has it at 89th. Worth doing, not worth panicking about, and mostly worth doing because a stale photo set is what a human reads as "this place might have closed."
- Review recency beats review volume. Forty-seven reviews with the last one from two years ago reads as a business that may not exist any more.
The fix for the whole cluster is operational rather than technical: lock the profile down once, verified phone and hours matching the front door, then hold a recurring thirty-minute weekly block to post, reply to every new review by name, and add a few fresh photos. The technical work is twenty minutes. The habit is the deliverable.
The review response cadence that reads as run by someone who cares
Thirty-seven reviews and zero owner responses reads as unmanaged. The same thirty-seven with a specific, non-templated reply on each, especially the critical ones, reads as run by a human paying attention. The reply does not need to be long. It needs to reference something real in the review, because a canned auto-response is obvious to the next reader.
Why is a PDF menu costing you AI search visibility?
First, a correction to the common version of this claim: Google does index PDFs, and lists PDF among its supported file types. The problem is narrower and more serious than "Google cannot read it."
A PDF cannot carry structured menu markup. There is no way to express Menu, MenuSection and MenuItem inside a PDF, which means the dish-level data is not available to anything that assembles an answer from structured sources. When someone asks an assistant where to get good cacio e pepe nearby, the restaurants with machine-readable menu data are the candidates. A PDF also opens slowly on a phone, which is its own tax.
Rebuild the menu as an HTML page on your own domain with proper heading structure and schema:
RESTAURANT SCHEMA TREE (JSON-LD)
-----------------------------------------
Restaurant
-> name, address, telephone (your NAP, identical
to GBP and listings)
-> servesCuisine (e.g. "Italian")
-> openingHoursSpecification (day-by-day, precise)
-> hasMenu
-> Menu
-> hasMenuSection
-> MenuSection ("Pasta")
-> hasMenuItem
-> MenuItem
-> name
-> description
-> offers (price,
priceCurrency)
-----------------------------------------
Format: JSON-LD (Google's preferred format)
Required minimum: Restaurant name + address;
MenuItem name + offers
Add FAQPage schema to the homepage and any
location page.The operational win is separate and immediate: once the menu is an HTML page, changing a price is a CMS edit rather than a call to a designer for a new PDF.
How do AI assistants decide which restaurant to recommend?
They assemble a recommendation from your listings and your reviews across the web rather than from one source, which makes cross-platform consistency a ranking input rather than hygiene. If your name, address, phone and hours disagree across Google, Apple Maps, Yelp, Bing and the data aggregators, every system reading them treats the conflict as a trust problem.
I am deliberately not going to tell you which index each assistant reads. Those arrangements are not documented by the vendors, they change, and most of the confident claims in circulation about them are repeating each other rather than a source.
What is measured is how often each surface recommends anyone at all. SOCi's 2026 Local Visibility Index, across more than 350,000 locations and 2,751 multi-location brands:
| Surface | Share of locations recommended | What feeds it |
|---|---|---|
| Google local 3-pack | ~35.9% | GBP accuracy, proximity, reviews |
| Gemini | ~11% | Google's own local data |
| Perplexity | ~7.4% | Cited web sources, directories |
| ChatGPT | ~1.2% | Structured data, third-party listings |
Note the row most articles on this subject leave out. Gemini recommends locations at nearly ten times ChatGPT's rate, and it draws on Google's local data. Which means the unglamorous Business Profile work is the AI visibility work, for the surface that actually recommends people. "How do I get into ChatGPT" is the question everyone asks and very nearly the least valuable one on this table.
On prevalence, the local-specific research is Whitespark's, across 540 queries in three cities and six industries: AI Overviews appear for 68 percent of local searches, while local packs appear for 39 percent of the same queries. The AI answer is now the more common surface, by a wide margin, and it is the one most restaurants have never looked at.
Your listings are no longer directory entries that help people find you. They are the source data an assistant uses to decide whether you are an option at all. Inconsistent data does not just lower your rank. It removes you from the answer.
What is the third-party platform actually taking from you?
A percentage you can see, and a customer relationship you cannot. The second costs more over time.
The visible cost, from each platform's own published merchant rates: DoorDash runs 15, 25 and 30 percent on delivery for Basic, Plus and Premier, with 6 percent on pickup. Uber Eats runs 20, 25 and 30 percent for Lite, Plus and Premium since its March 2026 marketplace fee change, and charges 7 percent on pickup where you can validate that in-app pricing matches in-store, or 10 percent where you cannot.
Add card processing on top. Neither platform publishes a combined all-in rate, and I am not going to invent one, but 30 percent is the ceiling on published commission and the true number sits above it rather than below.
The invisible cost compounds. The platform processes the order and hands you a ticket. It keeps the contact details, the order history and the relationship. When that customer reorders they reorder through the platform, and the platform takes its cut again. You rented the transaction. They bought the customer.
The counter-move, in order:
- Capture at the point of contact. A first-party ordering flow where you can, or at minimum a post-transaction capture: a table QR code to a short preference form, a checkout email field, a post-visit text. The goal is a contact landing in a list you control.
- Build the list deliberately. A list of people who have actually eaten there is an asset. Zero is a dependency on platforms that change their fees whenever they like. How fast it grows depends entirely on your covers and your capture rate, so measure your own rate for a month rather than trusting anyone's benchmark, including mine.
- Mark up your recurring assets. Happy hour, trivia night, seasonal specials, on a permanent page with Event schema. Most restaurants leave these completely invisible.
What is the order of operations?
Three phases in sequence: stop the bleeding, build the assets, own the data. Out of order wastes money. There is no point driving paid traffic to a site that bounces, or building a list before the profile feeding it is accurate.
- GBP accuracy and photos. These affect every impression before your site is visited, and they are fixable in an afternoon.
- Website speed and mobile experience. A slow site bleeds every traffic source. The bar is Largest Contentful Paint at 2.5 seconds or less, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift under 0.1, assessed at the 75th percentile of real visits. Test on mobile because that is what your customers use, and because Google indexes the mobile version of your site. Note that mobile-first indexing is how Google crawls, not a ranking factor in itself, whatever you have read.
- Listings consistency and on-site schema. Reconcile NAP across Google, Apple Maps, Yelp, Bing and the aggregators, then add Restaurant, Menu and FAQPage schema.
- Review cadence and list building. Habits rather than one-time fixes, so start early and let them compound.
- HTML menu and event schema. High value, lower urgency, and the move that takes you from indexed to recommended.
The work is not dramatic. It is steady infrastructure that compounds, which is exactly why most restaurants never get to it.
Common questions
Do I really need an HTML menu, or is a PDF fine if it is on my site?
Google will index a PDF, so it is not invisible. What it cannot do is carry dish-level structured data, which is what puts individual menu items in front of someone searching for a specific dish. If menu-level discovery matters to you, the PDF is the wrong container.
How do I get my restaurant recommended by ChatGPT or Perplexity?
Fix the source data every assistant reads: consistent NAP across the major platforms and aggregators, Restaurant and FAQPage schema on your site, and reviews whose text describes specific dishes and occasions. There is no ChatGPT setting. And per the table above, Gemini is the surface recommending locations at any real rate, which makes your Google Business Profile the highest-leverage thing on the list.
Is it worth leaving DoorDash and Uber Eats to avoid the fees?
Usually not entirely, since they are a discovery channel. The move is to add a first-party ordering and capture path alongside them, so repeat customers shift to the channel you own where the cost per order is a fraction of a 30 percent commission.
How fast should my restaurant website load?
Aim for Largest Contentful Paint of 2.5 seconds or less, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. On the PageSpeed Insights score, use Google's own bands rather than an invented cutoff: 0 to 49 is poor, 50 to 89 needs improvement, 90 to 100 is good.
