Why does a twelve-table neighbourhood place in Portland get a full knowledge panel with photos, a description and an opening-hours card, while a regional chain with thirty locations shows nothing but a map pin?
Because those are two different Google products, and almost every article about restaurant knowledge panels confuses them. The chain has done the obvious work, which is claiming its Google Business Profile. The neighbourhood place has been written about by people Google trusts. Only one of those two things produces a knowledge panel, and it is not the one that appears in your marketing dashboard.
Getting this distinction right saves months of wasted effort, so it is worth being precise about it before touching any of the steps.
The Panel You Want Is Not the One You Have
Google shows restaurants several different boxes and they come from different systems.
The local business panel is the one most restaurants already have. It appears for searches with local intent, it carries your hours, your phone number, directions and your reviews, and it is populated largely from the Google Business Profile you control. You verify ownership, you enter data, the data appears. It is valuable and you should absolutely have it, but it is a listing rather than an entity.
A knowledge panel is generated from the Knowledge Graph, which is Google’s database of things it believes exist in the world and what it knows about them. Entries come from corroborating third-party sources, and the panel’s description text is assembled from those sources rather than from anything you submit. That is why claiming a panel lets you suggest edits but never lets you write the description.
The practical difference shows up when someone searches your restaurant by name from another city, or asks an AI assistant about it. The local panel is tied to local intent. The entity exists everywhere, which is why it is the thing worth building.
Our own figures put the stakes plainly enough: around 70% of people have searched for themselves or their business on Google, and 99% are unhappy with what they find. For a restaurant, what they find is usually a listing plus whatever a delivery aggregator decided to say.
The Three-Source Rule
Here is the model we use when planning entity work, and it holds up well for restaurants specifically.
Google appears to need corroboration before it creates an entity, which means a single excellent source does nothing. Three independent, authoritative sources saying the same structured facts about your restaurant is the practical threshold, and the sources have to be of different kinds. We call it the Three-Source Rule.
The three kinds that matter for a restaurant are editorial coverage, structured reference data, and your own marked-up website. Editorial means a publication writing about the restaurant as a subject, not listing it in a roundup of twenty places. Reference data means entries in databases Google reads, which for restaurants includes established review and guide platforms. Your own site counts only when it carries correct structured data, because that is the version Google uses to reconcile the others.
The failure case is a restaurant with twelve mentions, all of the same kind. Twelve roundup listings corroborate nothing, because they are drawing from the same aggregated source data. One review in a city paper, one entry in a recognised guide and a properly marked-up site does more than all twelve.
Apply the rule as a checklist before spending on anything. If you have zero of the three kinds, start with your own site, because it is free and it is the one Google uses to interpret everything else.
There is a fourth source type that helps and cannot be bought, which is worth mentioning because restaurants have better access to it than most businesses: a local institutional reference. A city tourism board page, a university dining guide, a chamber of commerce directory or a neighbourhood business association listing. These carry unusual weight relative to their traffic because the domains are trusted and the data is maintained by someone other than you. Most are free to be included in and most restaurants have never asked.
Step One Through Three: Build the Foundation
The first three steps are unglamorous and none of them involve press.
Fix your own site’s structured data. Add Restaurant schema with the legal name, the exact address, the phone number, the cuisine type, the opening hours, the menu URL and a logo. Use the same name string everywhere, down to punctuation. A restaurant called The Copper Hen on its site, Copper Hen on its Facebook page and The Copper Hen Kitchen on a delivery platform is three fuzzy entities rather than one clear one, and that ambiguity alone prevents panels.
Claim and complete the Business Profile properly. This does not create a knowledge panel, but it does feed Google consistent facts, and an incomplete profile with wrong hours actively undermines the reconciliation process. Fill every field, add real photos monthly, and keep the hours accurate through holidays.
Build a coherent presence on the reference platforms Google actually reads. This means the established review and guide sites in your market, with identical name, address and phone details. Consistency matters more than volume here, and an hour spent fixing a wrong suite number across six platforms is worth more than a new listing.
Do all three before anything else. They take a week and they are the difference between coverage that creates an entity and coverage that lands in a void.
What AI Assistants Do When You Have No Entity
This is the part that has changed the calculation, and it applies whether or not you care about the panel itself.
Ask an assistant for dinner recommendations in a specific neighbourhood and watch what comes back. The model names places it has read about, describes them in a sentence or two, and skips the ones it has nothing to say about. It is not querying a local listings database. It is summarizing text, and a restaurant that exists only as a listing produces no text worth summarizing.
The restaurants that get recommended are the ones with descriptive coverage, because that coverage is what the model read. A review in a city paper that says the place does Sichuan food in a converted garage with a twelve-item menu gives a model something specific to repeat. A delivery platform entry gives it a cuisine tag and a price band, which is why those restaurants get mentioned in lists and not in answers.
So the entity work pays twice. The panel is the visible outcome in search, and the recommendation is the invisible one in assistants, and both are produced by exactly the same inputs. That is unusual and worth taking advantage of, because it means one body of work serves two channels that most restaurants are treating as separate problems.
One caution: assistants also repeat errors confidently. A restaurant whose closing time is wrong in three sources will hear its wrong closing time quoted back by a model, and the fix is the same source correction described below rather than anything that can be done to the assistant.
Step Four and Five: Earn Coverage That Describes You
Now the part that costs money or time, and where most restaurants aim at the wrong target.
The coverage that builds an entity describes the restaurant as a subject. A profile of the chef, a piece about the sourcing, an opening announcement in the city paper, a feature on the renovation. What does not build an entity is inclusion in a list, because a list entry carries no descriptive content about you specifically and often draws its facts from the same aggregator everyone else used.
Aim for three to five pieces across six months rather than a burst. Google’s reconciliation works over time, and a cluster of coverage in one week followed by silence reads as a campaign rather than as an established subject. Local dailies, city magazines, regional food publications and genuine trade press all count. National coverage is nice and not necessary.
For restaurants there is a specific accelerator worth knowing: awards and competitions. A named award from a recognised body is exactly the kind of structured, dated, third-party fact that entity systems handle well, and it generates its own coverage. Local best-of lists from established publications, state restaurant association recognitions and genuine competition placements all work.
Pitch the coverage around a change rather than around the restaurant existing. Food editors get asked to write about restaurants constantly and almost never say yes to a general invitation. What they take is a new chef, a menu change with a reason behind it, a sourcing relationship with a named farm, a reopening, an anniversary with a number in it, or a response to something happening in the local food economy. Each of those is a reason for an article to exist this month rather than any other month, which is the only question an editor is actually asking.
Keep a record of every piece as it publishes, with the URL, the date and the facts it states about you. This list becomes the thing you work from when a panel shows something wrong, and assembling it afterwards from memory is much harder than keeping it as you go.
Our placement catalog runs to 1,016 publications with a median selling price of $1,500 and 174 carrying Domain Authority above 80, and the pattern across client programmes is that three well-chosen regional placements outperform a dozen cheap national ones for entity purposes. The reason is corroboration rather than authority: a local paper writing specifically about your restaurant gives Google more to work with than a national site running a syndicated paragraph.
Step Six: Claim It, Then Fix the Sources
Once the panel appears, there is a verification flow for the official representative of the entity, and it is worth completing.
Verification gets you the ability to suggest edits, add a featured image and respond to certain fields. What it does not get you is control of the description, because that text is generated. People who expect otherwise spend weeks submitting edits that revert.
When something in the panel is wrong, work backwards to the source. Find which third-party fact is producing the error, correct it there, wait for the correction to propagate, then submit the edit. A wrong cuisine type usually traces to a reference platform entry. A wrong founding year usually traces to one article everyone else copied.
Then keep going. Panels disappear, usually when the sources behind them go stale or contradict each other, and the restaurants that keep theirs are the ones still getting written about two years later. Treat the panel as a readout of your entity’s health rather than as a milestone, and the maintenance work becomes obvious: keep the name consistent, keep the site’s structured data current, and keep earning coverage that describes the place rather than listing it.