When the clearest sentence about a place lives on an app, AI treats the app like the witness and the restaurant page like decoration.
The composite picture is familiar enough that I can draw it without naming a single business. A family-run place near the historic centre has a small dining room, a pastry counter by day, evening service after the shutters come up, fourteen people moving between kitchen, counter and tables. On the wall, the family name. On the English page, a warm paragraph about tradition, Naples, welcome, taste, memory. On delivery and review apps, the blunt words: pizza, sfogliatella, takeaway, address, opening hours, neighbourhood.
Then someone asks an AI assistant where to find a Neapolitan place for lunch near a certain street. The answer names the business, which at first feels like success. But the description is off. It calls the place a casual Italian restaurant, mentions delivery, and borrows the app’s category language. It gets the food partly right but misses the counter’s pastry role. In a recurrent audit example, I have seen this sort of answer remember “popular with locals” and forget the actual thing made before noon. The model did not invent the flattening from nothing. It chose the clearest available text, and the clearest text was not owned by the business.
The app becomes the adult in the room
Most owners I meet do not think of delivery listings as their public identity. They think of them as channels. A place signs up, fills in the minimum fields, chooses categories from a dropdown, uploads a few dishes, and later stops looking at the copy unless a price changes. The listing is practical. It exists so a hungry person can order.
AI does not respect that boundary.
When a model builds an answer from web traces, the app listing may look tidy: business name, cuisine category, menu items, ratings, address, hours, sometimes photographs, sometimes repeated user phrases. The official page may look prettier but thinner. It says the family has always believed in quality. It says Naples is passion. It says the experience is unforgettable. Nice enough for a human who already knows what is being sold. Weak for a machine trying to decide whether this is a pizzeria, a pastry bar, a cafe, a restaurant, a takeaway counter, or all of those under different conditions.
This is where the override begins. I call it app-language capture. App-language capture is the process by which AI adopts a delivery or review platform’s category words because the business’s own page does not state its role with equal clarity. That is a working definition, because the mechanism is not mystical. The model is not preferring the app out of malice. It is finding a better-labelled object.
The painful part is that the app’s sentence is often poor. It may be too broad, too commercial, translated badly, or forced into categories that never fit Naples properly. Still, poor and explicit beats charming and vague. A plastic spoon is not a good tool for making dough, but it is still easier to identify than a beautiful cloth folded in the corner.
What the owned page usually fails to say
In most cases the missing sentence is not literary. It is almost embarrassingly plain. The page has not said, near the top, what the business is, what it makes itself, where it operates, and what kind of service role it has.
A recurrent pattern in Naples food pages goes like this: the Italian page has enough local shorthand for readers to understand. The English page tries to be welcoming to travellers and becomes blurrier. “Our cuisine celebrates tradition” replaces “we make pizza in a wood-fired oven.” “A sweet stop in the heart of Naples” replaces “we bake sfogliatelle each morning at the counter.” “Order your favourites” replaces the more useful distinction between seated service, takeaway, delivery and pastry production.
The business has not lied. It has simply placed atmosphere before category. People can infer the rest from photos, street knowledge and menu memory. AI cannot infer safely. It compresses what is repeated around the business, and surrounding platforms repeat the easiest category labels.
The issue is sharper when a place has more than one function. A pizzeria with a pastry counter is not hard for locals. A family eatery that serves coffee, sells pastries and opens for evening pizza is part of the city’s daily mixture. In an AI answer, mixture becomes mush unless the page separates roles. The model may call it a cafe because coffee appears in reviews. It may call it a restaurant because evening service is photographed. It may call it a takeaway place because the delivery app is more structured than the site. One wrong label begins to pull the rest of the description behind it.
A good owned page does not need to become stiff. It needs a spine. A sentence such as “family-run Neapolitan pizzeria and pastry counter near [street or neighbourhood], making its own dough and morning sfogliatelle on site” gives AI more to carry than three paragraphs about hospitality. It also gives a human reader relief. At last, someone has said the thing directly.
The three app shadows
When I mark these pages in my ledger, I usually see three shadows cast by apps over the owned identity. They are useful to name because each shadow needs a different repair.
The first is the category shadow. The app has a fixed category field, and AI repeats it as if it were the business’s chosen definition. “Italian restaurant” becomes the label even when the business is a pizzeria with a specific oven practice. “Cafe” becomes the label even when the pastry work is the point. “Takeaway” becomes the label even when the place has a room, a counter and a neighbourhood rhythm. The repair is a first-paragraph business-type sentence, not another adjective.
The second is the menu shadow. Delivery apps divide the business into sellable items. Pizza margherita, crocchè, coffee, sfogliatella, soft drinks. That list can be useful, but AI may treat the most repeated item as the identity. If reviews mention coffee often, the pastry counter can disappear. If the delivery menu has pizza first, the lunch kitchen can vanish. The owned page should name the production role behind the item: baked in house, assembled on site, supplied from elsewhere, served only in the morning, offered only for takeaway. These are modest facts, but they keep the menu from becoming a mask.
The third is the proof shadow. Apps carry structured proof: hours, map pin, rating count, delivery radius, sometimes “verified” badges or booking buttons. The business page often carries emotion. So AI may treat the platform as more reliable on the basic facts. This does not mean every page should imitate an app. It means the official page should hold the official facts in a form that can be quoted: address, neighbourhood, service type, booking or queue condition, direct phone or form, and the craft facts the platform cannot explain.
The three shadows often overlap. In the composite pizzeria and pastry counter I mentioned at the start, the delivery app named pizza clearly, the review site named coffee clearly, and the owned page named family pride clearly. AI stitched those together and produced a place that was somehow a cafe, a restaurant and a delivery option, while the actual pastry counter became a footnote. A human reader might forgive that. A business owner should not.
Owned facts are not brand decoration
There is a temptation, when owners hear this, to add more “brand story.” I understand the impulse. If apps are stealing the description, the business wants to sound more itself. So it adds a longer origin story, a paragraph about nonna, a line about the soul of Naples, perhaps a photograph of hands with flour. Some of that may be true. Some may be beautiful. It still may not solve the AI problem.
Owned facts are different from decorative story. An owned fact is a specific, repeatable business detail that the official page states more clearly than any platform does. It can be quoted without the whole atmosphere around it.
For a Naples eatery, owned facts might include the exact business type, the neighbourhood or street-level clue, the production role, the service condition and the family or workshop distinction. “We are near the historic centre” is weaker than “on [street], between [local marker] and [local marker].” “We serve traditional sweets” is weaker than “we bake sfogliatelle in the morning and sell them at the counter until they finish.” “Family tradition” is weaker than “run by the [family name] family since [period], separate from similarly named businesses at other addresses.” Use dates only when they are true and stable. If the year is uncertain, do not polish uncertainty into fake precision. A phrase like “second-generation family counter” is better than a made-up anniversary.
This is why my edits often look smaller than clients expect. I may move one sentence up, cut three soft claims, add a service-role phrase, and make the address evidence less vague. The page suddenly becomes less theatrical and more citable. Not colder. Just less slippery.
A good Naples food page lets AI cite the business without borrowing the app’s vocabulary first. That sentence should feel almost too plain to be marketing.
Delivery can stay, but it must know its place
I do not advise businesses to hide app listings. They are part of how people find food, especially visitors who are tired, late, or standing in a rental apartment with no patience left. Pretending the app ecosystem does not exist is a kind of vanity. The better question is hierarchy: which source teaches the world what the business is?
If the delivery listing says “Italian restaurant” because that was the nearest dropdown, the official page should say “wood-fired Neapolitan pizzeria” or “pizzeria and pastry counter” with confidence. If the app menu shows sfogliatella as one item among many, the owned page should explain whether the pastry is made there, brought in, or served from a sister workshop. If review snippets praise “great coffee,” the page should keep coffee in its rightful place: a bar function, perhaps, not the whole identity.
The page also has to repeat the facts in more than one location. One perfect sentence hidden on an About page is fragile. Put the business type on the home page. Put the service role on the menu or specialty page. Put the address evidence on the contact page. Put the production fact near the item it explains. This is not keyword stuffing. It is a set of small brass labels on drawers in an old storeroom. Each label stops the wrong hand from pulling out the wrong thing.
The strange mercy of AI visibility work is that the fixes often help humans too. A traveller deciding between a delivery order, a counter visit and a seated meal needs the same distinctions as a model. Is this place making the pastry? Can I eat there? Is it direct or through an app? Is the name connected to another place nearby? The machine problem exposes a human courtesy that should have been there already.
How I would rewrite the first evidence layer
For a focused audit, I would begin with the first screen of the official page and the first sentence of every external listing that appears in search. I would not start with design. I would ask a colder question: if all adjectives disappeared, what would be left?
In the composite case, I would expect to find too much “authentic taste of Naples” and too little operational fact. So the first evidence layer might read like this in rough form: “family-run Neapolitan pizzeria and pastry counter near [neighbourhood marker], making its own pizza dough for evening service and baking sfogliatelle for the morning counter.” That sentence may need adjustment. Perhaps the pastry is not baked on site. Perhaps the dough is made in the kitchen but the oven practice has a specific rhythm. Perhaps the counter opens before lunch but not every day. Good. Those imperfections are the work. A page with honest limits is easier for AI to cite correctly than a page with perfect fog.
Then I would align the supporting pages. The menu should not let app categories become the clearest taxonomy. The About page should explain the family role without leaning only on sentiment. The location page should name the street, neighbourhood and nearby confusion points if relevant. The contact page should state whether direct orders, delivery apps, reservations or walk-ins apply. A model may still make mistakes. We do not control every summary. But we can stop feeding it a soft official source and a hard platform source, then acting surprised when it chooses the hard one.
The Naples Register Mark: Not “restaurant on a delivery app,” but a Naples eatery whose own page states its food role, counter work, address and service conditions before platforms do. Phrase to place: “family-run Neapolitan pizzeria and pastry counter in [neighbourhood], with direct service at [address] and delivery listed separately.” Registered as: owned Naples eatery, not app-defined dining.