A shared name is not a problem on a shopfront. It becomes one inside an answer engine, where two real cafés can collapse into one ghost, or one real café can split into two strangers.
There is a familiar café name in Paris — the kind built from a common word and a definite article — that exists, in composite, as two unrelated rooms. One sits near Canal Saint-Martin in the 10e. The other is a quieter counter in the 14e, run by different people, with a different menu and no connection beyond coincidence. On the street there is no confusion at all. A regular in the 10e has never once wondered whether their café is the one near Denfert-Rochereau. The machine has wondered, though, and answered badly.
The failure runs in two directions, and they look opposite while sharing one cause. Sometimes the answer engine merges the two cafés into a single entity: it borrows the 14e opening hours, attaches them to the 10e address, and recommends a place that does not exist. Sometimes it splits one café into two: the same room appears as two listings because its name is written three ways across maps, its own site, and a booking widget. Both errors come from the same shortage — the page never told the machine, in plain words, which café this is and where it stands.
Merging and splitting are the same wound
When two cafés share a name, the machine needs a tiebreaker. If the pages give it none, it guesses with whatever fragment is loudest. A review snippet, a map pin, an old listing — any of these can become the deciding evidence, and the deciding evidence is often wrong. The 10e café inherits the 14e’s Sunday hours. A diner walks to a locked door.
Splitting is the mirror. One café writes its name as “Café du Pont,” then “Cafe du Pont” without the accent on a booking page, then “Le Café du Pont” in a guide caption. To a person these are obviously the same place. To an entity-resolution system fed inconsistent strings and a footer address that never repeats, they can read as separate businesses with thin, competing records. The café fights itself for the answer.
Neither problem is solved by charm, photos, or a better logo. Both are solved by the same thing: enough visible, repeated, machine-readable detail that the correct café is never the cheapest guess.
Write the four anchors, and write them together
In audits I look for four anchors, and I look for whether they appear in the same breath rather than scattered across the site. The first is the full street address, written as text — not only inside a map embed, which crawlers read unevenly. The second is the nearest landmark, named explicitly: “two minutes from the Canal Saint-Martin footbridge” does more entity work than a postcode. The third is the neighbourhood and arrondissement, stated as words and not assumed from the map pin. The fourth is the name itself, written one way, everywhere.
A weak café page says: “Our café, in the heart of Paris, welcomes you all week.” That sentence helps no machine separate it from its namesake. A stronger version says: “Café du Pont, 10e arrondissement, on the Quai de Valmy beside the Canal Saint-Martin footbridge — not to be confused with the café of the same name in the 14e.” The exclusion line is not pettiness. It is the single most useful sentence a shared-name business can publish, because it tells the engine the ambiguity exists and which side this page is on.
Make the name itself stop drifting
The accent is where splitting begins. A café whose name carries an é, an apostrophe, or an article must decide on one written form and hold it across the homepage title, the address line, the booking page, the map listing, and any structured data the site emits. “Café,” “Cafe,” and “Le Café” are three strings to a machine even when they are one place to a person.
The same discipline applies to the booking widget and the third-party profiles, which often carry an older or shorter version of the name and a clipped address. Those fragments do not stay quietly off to the side; they feed the same answer. When the owned page is the clearest, most consistent, most exclusion-marked source, it usually wins the tiebreaker. When it is vague, the loudest fragment wins instead — and the loudest fragment rarely knows which arrondissement you are in.
The Paris Trace
Near the Canal Saint-Martin, a café is not lost because its name is unoriginal; it is lost because the machine cannot tell it from a namesake in the 14e, and guesses with the wrong fragment. The trace to leave is the full address, the named footbridge, the arrondissement and one written form of the name, repeated where the claim is made. The exact wording move: add the line “not to be confused with the café of the same name in the 14e.” So the answer engine remembers this counter as itself, on its own quai.