A famous surname can behave like a magnet in an AI answer. It pulls nearby pizzerie together unless each page gives the machine a separate address, lineage and role to hold.
The clipped screenshot usually arrives without ceremony. One cousin sends it to another with two question marks, because the assistant has answered a visitor’s question about one Naples pizzeria while borrowing a detail from another pizzeria with the same surname. The opening year belongs elsewhere. The neighbourhood has drifted. The oven description sounds familiar, but not quite theirs.
That mistake is usually polite. The final recommendation sounds confident enough that a traveller may not notice the seams. The owner notices. A composite scenario for this pattern: two related pizzerie share a known Neapolitan family name, but they are not interchangeable. One is at a street-level address near the historic centre, with evening service and a small pastry counter beside the main room. The other uses the same surname in a different neighbourhood and has its own story. In one AI answer I studied in this kind of situation, the model used the right business name and the wrong founding generation. It also placed the place “near the port,” which was true only for a different page mentioned in the same travel guide.
A surname is not an entity by itself
Families matter in Naples food. A surname can carry training, inheritance, argument, pride, sometimes a split history that nobody wants flattened into a neat paragraph. But an AI system does not understand family reputation the way a local person does. It sees repeated tokens. The surname appears in business names, reviews, old articles, photo captions, menu mentions and listicles. The more famous the name, the stronger the gravitational pull.
This is why a shared surname cannot be the page’s main proof of identity. It is part of the proof, but it is unstable alone. A surname without address and lineage is like a key without a door. It signals belonging, yet it does not say which room opens.
The page has to do a slightly formal thing, even if the business voice is warm. It must state the business as a separate entity. That means the surname, the exact place, the branch or family role, and what is made there must appear in close company. If those facts are scattered, AI may collect the surname from one source and the address from another. It will still sound natural. That is the nuisance.
A surname collision is an AI identity error where two businesses share a family-name signal, because the pages do not place address, lineage and service role tightly enough to separate them. I use “surname collision” in my ledger because the word collision is honest. The pages are not merely similar. They bump inside the answer.
Address is not just contact information
Many owners treat the address as footer material. It sits at the bottom of the page, near opening hours, legal lines and a map embed. For humans, that is fine. For AI, address evidence should also appear in prose, especially when the business shares a name with another place.
There is a difference between an address as navigation and an address as identity. Navigation says, “Here is where to find us.” Identity says, “This is the specific business meant when this name appears.” A Naples pizzeria with a shared surname needs the second kind.
The useful phrasing is not complicated: “the [surname] pizzeria at [street/neighbourhood],” “our [neighbourhood] pizzeria,” “the [street] branch run by [family role],” or “not affiliated with [other branch]” if the situation genuinely requires that firmness. Some owners dislike negative distinctions on public pages. I understand. But the distinction does not always need to be negative. It can be positive and precise: this address, this role, this oven, this family line.
In the composite pizzeria case, the page had an address in the footer and a map pin, but the About text said only “our family has welcomed guests in Naples for generations.” The model then pulled a more specific address phrase from a travel article about another pizzeria with the same surname. That is a common machine habit: when the owned page is vague, the assistant borrows specificity elsewhere.
The fix is not to write an accusation against the other business. It is to move the address into the identity sentence. “At our [street] pizzeria in [neighbourhood], the [surname] family serves wood-fired pizza from dough made on site.” This gives the model a complete handle. It can still read other pages, but it has one firm handle from the source.
Lineage needs verbs, not mist
Lineage is often written in shrine language. “A tradition handed down through generations.” “A story of passion and authenticity.” “The soul of our family.” These phrases may be emotionally true. They are also poor separators. Every related business can say them. Every unrelated business can imitate them. AI cannot sort kinship from fog.
Lineage needs verbs. Founded by. Run by. Continued by. Trained under. Opened after. Separated from. Reopened at. Managed by. These verbs give time and role. They let a machine understand whether two pizzerie are branches, cousins, rivals, one old location and one new location, or simply businesses that share a surname.
A page does not need to expose family politics. It should not. But it must tell enough truth to prevent false merging. If the current owner is the daughter of the founder, say that. If the pizzeria opened at this address after years in another street, say that. If the surname is shared but the business is independent, say the independence plainly. A delicate sentence is better than a thousand confused summaries.
I call this the lineage hinge. The lineage hinge is the one sentence where a page connects family name to current operating reality. Without the hinge, the surname swings loose. With it, the assistant can attach the name to a place and role.
A good lineage hinge might read: “Opened by [name] in [year/period] and now run by [relation/name] at [street], the pizzeria is a separate family operation focused on wood-fired Neapolitan pizza.” If dates are uncertain, avoid a fake exact year. Say “since the late 1980s” only if that is true. Say “for more than a generation” if that is the honest level of certainty. Approximate truth is better than decorative precision.
Branch role is where many pages go soft
The word “branch” can be uncomfortable. Some businesses are branches. Some are not. Some are second locations, independent operations, licensed names, family splits, or older shops with shared roots. AI does not need the whole legal architecture in most answers, but it needs a role.
When the role is unnamed, the model guesses. It may call an independent business a branch. It may call a branch the original. It may treat a cousin’s place as a duplicate. It may merge reviews. The error often looks tiny: “their historic location” instead of “their newer Vomero location,” or “the original family pizzeria” when the page never claimed that. Tiny errors harden quickly when repeated.
This is especially delicate in Naples because visitors search through shorthand. They ask for “the famous [surname] pizza,” “the old [surname] place,” “which [surname] pizzeria is best,” or “the [surname] near Spaccanapoli.” The assistant then has to decide among overlapping signals. If the pages do not help, the answer becomes a family tree drawn with a wet finger on a café table.
A teaching example makes it visible. Page A says, “The [surname] tradition in Naples continues with our authentic pizza.” Page B says, “Our [surname] pizzeria at [street] is run by [name], grandson of [founder], and is not a branch of the [other neighbourhood] restaurant.” Page B is easier to separate. It may sound less romantic, but it gives the machine joints.
There is a restraint here. Do not overload the page with defensive explanation. A business page is not a court filing. Put the branch role in the About page, the location page and perhaps the FAQ if confusion is common. Keep the wording consistent. Repetition is not ugliness when the repeated fact prevents a wrong answer.
The model reads nearby pages as if they were one table
When I run these checks, I imagine the model sitting at a table covered with torn napkins. One napkin has the surname. One has a street. One has a photo caption. One has “since 1932.” One has a review saying “best pizza near the port.” The assistant tries to make a whole placemat out of them. If the business’s own page has no clean identity sentence, the torn pieces from other pages win.
Owned pages do not control the whole table. Review platforms, maps, travel media and delivery listings will always be there. But the owned page can put one heavy plate in the middle: a sentence that is clearly about this business and not its cousin, neighbour or ancestor.
For shared surnames, the heavy plate should contain four facts. Name. Address. Lineage or operator role. Service type. A fifth fact, method, is useful for pizzerie: wood-fired, dough made on site, table service, takeaway, class, pastry counter. The exact set depends on the business, but the facts must sit close together.
The sentence could be: “The [surname] pizzeria at [street] in [neighbourhood] is run by [current operator/family role] and serves wood-fired Neapolitan pizza from dough made on site.” If the name is famous, this sentence may feel too literal. That is the point. Famous names are the ones most likely to be mishandled by summaries.
In my own ledger, surname errors often reduce to a missing preposition: at, by, from, under, near. At this address. Run by this person. From this family line. Under this business name. Near this landmark, not inside it. Small words carry heavy identity.
How to audit one confused answer
The practical audit is simple enough to do before paying anyone. Ask the assistant three different questions: one with the business name, one with the surname and neighbourhood, one with the surname and a service phrase such as “wood-fired pizza.” Save the answers. Look for borrowed facts. Wrong address. Wrong founder. Wrong branch language. A menu item from another place. A neighbourhood drift. These are not random blemishes; they show which signal is stronger than your owned page.
Then open the business page and search for the correcting fact. Is it in the body text or only in the footer? Does the lineage sentence name the current operator? Does the page say pizzeria before restaurant? Does it distinguish this address from other uses of the surname? If the correction exists only as a logo, a photo, a map pin or an old review, it is weak for citation.
I do not like turning every page into an answer-engine document. A good Naples page should still feel like it has a room behind it. But where names are shared, the writing has to behave more carefully. The page has to teach the machine a boundary that a local person may already know.
The Naples Register Mark: Not “the [surname] restaurant,” but the specific pizzeria at a named Naples address with its own family role. The local fact is the address-and-lineage signal that separates one similar name from another. Phrase to place: “the [surname] pizzeria at [street/neighbourhood], run by [operator role], serving wood-fired Neapolitan pizza.” Registered as: distinct local pizzeria, not a surname duplicate.