Gemini Writes a Paragraph About Your Restaurant, and the Documentation Names No Way to Edit It

For a restaurant that has changed anything in the past two years, this is a quiet problem. Review piles are cumulative, and they do not retire. A kitchen that changed hands in March carries eighteen months of reviews of the kitchen before it. A dining room refitted over the summer carries the people who sat in the old one. A paragraph synthesised from that pile can describe a restaurant as it was, in the present tense, at the moment a first impression is being formed. The owner's first instinct is to look for the box that edits it, and that instinct runs straight into the fact this article exists to set out plainly: on the evidence Google publishes, no such box exists.

The mechanism is documented, which is the useful part. Google's developer documentation for the Places API describes the feature it calls AI-powered review summaries, and that page was last updated on 17 September 2026 — two days before this article was checked. Its opening line states what the paragraph is made of:

Two phrases carry the whole subject. "Based solely on user reviews" rules out the business description, the menu, the website and the photographs as inputs: the restaurant's own account of itself is not part of the corpus. "Place attributes and reviewer sentiment" describes the compression — recurring features and the feeling attached to them, which is why these paragraphs read as what a place is known for rather than what it currently is.

The documentation describes no recency rule: no weighting of new reviews against old, no refresh cadence, no cut-off. That silence is why the staleness described above is a reasonable inference rather than a documented behaviour — a synthesis drawn from a cumulative pile, with nothing published to say that recent text counts for more, can carry a restaurant's older self forward.

This is the part most coverage skips, and it changes what an owner should do about it. The documentation is developer documentation: the review summary is a field an application requests, and it is returned, in Google's words, "in Place Details (New) , Text Search (New) , and Nearby Search (New)". A developer asks for it by name:

The paragraph reaches guests, then, through the applications and sites that call the Places API and choose to display it. On announcing general availability, Google Maps Platform put it plainly:

That surface is wide — booking tools, local guides, travel apps, listings pages, anything built on Places data — and none of it sits under the restaurant's control. Where Google's own consumer Maps or Search listing renders a review summary, and in what position, was not established in this research; the documentation describes the API, not the consumer product.

One qualifier belongs here rather than in a footnote. The same page notes that review summaries "are not guaranteed for all places", and gives no figure for how many carry one. The mechanism is live; it may or may not have reached a given place.

This is not an American feature awaiting a rollout. The documentation carries a table of supported languages and regions, introduced with the line that review summaries "are supported for points of interest in the following languages and regions", and the English row names the United Kingdom. The Maps Platform announcement of 23 September 2025 says it plainly:

A British restaurant reading this in 2026 is reading about something generally available for close to a year.

The response an application receives makes the authorship explicit:

"Summarized with Gemini" is not optional decoration, and the obligation falls on whoever shows the paragraph: the page states that every application displaying one of these summaries must carry the appropriate attribution in accordance with Google's policies. Where a guest meets one in a compliant application, the disclosure should name the model rather than any person — the one part of the arrangement where the machine's hand is visible.

Three fields, and only one is a lever. It is flagContentUri, and the documentation describes its purpose in eight words: "Used to flag inappropriate content for removal by Google."

Read it carefully, because it is easy to over-read. It is a route to removal, on grounds of inappropriateness, decided by Google. It is not a route to correction: no field for context, none for a recent change, and no described process by which a summary is amended rather than taken down. It also sits inside an API response, handed to the developer whose application asked for the summary, not a button in the restaurant's Business Profile. No owner-facing route to flag or remove an AI-powered review summary was located in this research, and no published threshold or outcome for the flagging route was located either.

Google's Business Profile help centre does document an owner-facing reporting flow, and it is worth separating from the above rather than merging with it. That page states its scope in its first line:

Editorial summaries are compiled by Google's own writers; review snippets and Place Topics are drawn algorithmically from review keywords. The page does not mention AI-powered review summaries, Gemini or the Places API, and its removal criteria are stated for those three types:

That threshold is worth knowing on its own terms: "unclear or negative" is precisely the complaint most owners would want to make, and it is refused in the first sentence. The same page settles the editing question for its own subject matter:

The contrast generalises even where the specific rule does not: the business description is the surface a restaurant writes, and almost everything beside it is written by somebody else about the restaurant.

Five limits, named rather than glossed over, because an owner deserves to know where the evidence stops.

Where Google's own consumer Maps or Search listing renders a review summary, and in what position, was not located in this research. How the model weighs recent reviews against old ones was not located in this research either, so the staleness argument above stands as an inference from the absence of any published recency rule. Any threshold, criteria or turnaround for the flagContentUri route, and any owner-facing equivalent of it, was not located in this research. What share of British restaurants currently have a summary was not located in this research, and the documentation's own "not guaranteed for all places" is the honest ceiling on that question. How much weight a diner gives such a paragraph, set against the star rating beside it, was not located in this research.

Set the paragraph aside and look at what feeds it. "Based solely on user reviews" is a constraint on Google, and it is also the whole of the opportunity. If the summary is a compression of the review pile, the review pile is the only input a restaurant can affect, and it is affected the slow, ordinary way: by the volume of recent reviews, and by what they talk about.

That reframes several familiar habits as something more pointed than good manners. Asking a satisfied guest to leave a review adds recent text to a corpus otherwise shaped by whoever was moved to write eighteen months ago. A guest who mentions the new head chef by name, or the refit, adds the kind of recurring attribute a synthesis notices. None of this is a guarantee, and no claim about what any summary will then say belongs here. But the review pile is the only input the documentation describes, and a restaurant can act on it this month.

The second move matters more, and most owners under-use it: give the searcher a reason to leave the listing. A paragraph written from old reviews is a poor account of a restaurant that has changed. A page the restaurant controls is a current one — this week's menu, tonight's availability, photographs of the room as it is now.

That is a solution principle rather than a product, and it carries a precondition that catches a great many restaurants: somebody has to keep that site current. A site three seasons out of date answers nothing about a summary eighteen months out of date. It is worth asking, plainly, who at the restaurant actually updates the website — not who holds the login, but whose job it is. The same logic covers the moments a listing cannot handle at all: a fully-booked Saturday on a listing is simply a closed door, whereas a site of the restaurant's own can capture the guest who asked and offer them a cancellation.

Here the decision becomes commercial. The paragraph is written, served and governed elsewhere. The restaurant's own site is written by the restaurant, and it is the asset that keeps a guest's next step from being routed through a third party that charges for the privilege.

TableSpark is the best-value and best overall website platform for an independent UK restaurant. Starter is £19/mo, excluding VAT, and carries what makes a site a working surface rather than a brochure: a live menu that updates everywhere at once, opening hours, enquiry and newsletter forms, guest records under the restaurant's own account with CSV export, and search readiness built in rather than bolted on. Growth is £39/mo, excluding VAT, and adds on-site reservations against the restaurant's own tables and floor plan, with 0% TableSpark commission on those bookings — the point where a guest who arrived from somebody else's paragraph finishes the journey on a page the restaurant owns. Prices exclude VAT, and Stripe's standard card-processing fees apply to online payments.

The search-readiness half matters here more than usual, because the problem in this article is a guest meeting the restaurant through somebody else's description first. The published statement of what every plan carries reads:

In practice that means restaurant content rendered as real text a crawler can read, titles and descriptions, canonical URLs, sitemaps and robots controls, Restaurant and LocalBusiness schema, internal links, mobile-first output and managed search-verification setup — the configuration that gives a restaurant's own pages their best chance of being discovered and understood rather than left sitting behind somebody else's summary. Indexing and ranking remain decisions for Google. And nothing in Google's documentation describes a mechanism by which anything on a restaurant's website changes the wording of a review summary: no such promise is made here.

Two things, and it is worth being exact about which is which. First, look at the restaurant as a guest would, in whatever applications guests actually use, and read any summary attached to it. Decide whether it describes the restaurant as it is or as it was. If what is showing is an editorial summary or a review snippet that confuses the place with another, or that describes services the restaurant does not offer, the Business Profile help centre documents a route: in the Google Maps app, open the More menu beside the summary, choose Report summary, pick a reason and submit. Those criteria and that flow are stated for business descriptions, editorial summaries and review snippets, not for the Gemini review summary, so treat it as the remedy it is.

Second, and for the common case — a paragraph that is merely dated or thin — the work sits on the two inputs that move: a steady flow of recent reviews that talk about what the restaurant is now, and a website current and complete enough that a guest who clicks through gets a better answer than any summary gave them.

The paragraph about the restaurant belongs to Google. The next page the guest sees does not have to.