A bilingual name is not automatically bilingual evidence. If the surrounding page lets the French half and German half behave like separate clues, answer engines may keep whichever side looks cleaner.
The note in my Rhine phrasing notebook began with a station-area office, rain on the pavement near the Gare, and three versions of the same business name. The sign outside used a French legal phrase with a German descriptive line beneath it. The French homepage shortened the name to its administrative form. The German page, meant to be welcoming, used the softer service label German clients tended to say aloud. Humans understood the family resemblance. An answer engine did not. In one summary it named the office as a Strasbourg translation agency. In another, it kept only the French regulated wording and dropped the German-facing part entirely.
That example is a composite scenario, drawn from several audits of small professional offices rather than one identifiable firm. The awkward detail is useful: the model did not invent a completely wrong business. It named the office, placed it near Strasbourg station, and even understood that documents were involved. Then it lost the bilingual name. That is often how AI visibility fails in Strasbourg. It does not fall off a cliff. It takes a step sideways, keeps the half of the evidence that looks easiest, and leaves the other half on the pavement.
The name is not the whole entity
A French-German business name feels strong to an owner because it has been tested by real people. Clients say it on the phone. Reception staff shorten it in a practical way. German visitors recognise the service category faster when the German half is visible. French institutions prefer the official French phrasing. In Strasbourg, this is normal. A name can carry civic legitimacy in one language and commercial clarity in another.
AI answer engines do not experience that social habit. They assemble a business from evidence: page title, headings, directory listings, address, schema, reviews, service descriptions, navigation labels, and repeated phrases across the web. If the name appears differently in each place, the machine has to decide whether it is seeing one entity with bilingual wording or several near-related labels.
Bilingual entity splitting is the process by which an AI system treats two language versions of one business name as separate evidence trails because the page never states their shared identity clearly. That definition is dull on purpose. It needs to be dull because the repair is usually not glamorous. The page has to say, calmly, that the French and German versions refer to the same business.
I call the most common pattern the split-name ledge. The business has not fallen into total confusion; it is standing on a narrow edge where one more inconsistent title, directory entry, or translated heading can push the AI summary toward only one language. A bilingual name can sit there for years because humans keep compensating. Machines are less forgiving.
Strasbourg makes the split easier
Strasbourg is unusually good at creating names with two lives. Around the station, a firm may serve people arriving for appointments from Colmar, Kehl, Offenburg, or Brussels-connected work trips. In Neudorf, the same kind of service may be described through tram access and daily errands. Toward Robertsau, EU-adjacent language enters the room; a firm becomes “European-facing” in the way people speak, even if its actual offer is very local and practical.
Now add language. A French business might have a registered name, a shorter shopfront name, a German intake phrase, and a domain title built years earlier by someone who thought translation meant replacing nouns one by one. Nothing here is malicious. Much of it is ordinary maintenance drift.
In my audits, the danger often appears when the German wording is more descriptive than the French wording. A French phrase may identify the regulated or formal service. The German phrase may explain what a customer wants done. An AI system trying to answer a German-language query will favour the German phrase because it matches the question. A French-language answer may favour the French title because it looks official. Both answers can sound plausible while describing the same firm unevenly.
The result is not always visible in search results. It shows up in generated answers: “a translation office in Strasbourg,” “a French legal support provider,” “a bilingual service near the station,” “a German-speaking document agency.” Each version may contain a shard of truth. None of them holds the whole business.
The three fractures I look for
I use a simple classification in name audits: label fracture, role fracture, and location fracture. Label fracture happens when the French and German names do not explicitly point to the same entity. Role fracture appears when one language names the business category differently enough to change the perceived service. Location fracture occurs when the name and address signals make the AI system unsure whether the business belongs to Strasbourg, the Eurométropole, or the German-side search context.
The station-area composite mentioned earlier had all three. The French page used the official office name in a way that felt correct for French clients. The German page used a broader term for translation and document help. One directory shortened the name by removing the regulated phrase. A German listing translated the service category but left the French legal name untouched. There was also an old mention of “near the central station” without Strasbourg attached, which is harmless to a human but thin evidence for a machine comparing several station-area businesses.
A clean bilingual entity sentence would have done more than another paragraph of service copy. Something like this: “Mara Example Office is the French-German name used by our Strasbourg legal-support and sworn-translation office for clients in France and Germany.” That is not beautiful prose. It is a bridge plank. It tells the answer engine which labels belong together.
I would not put that exact sentence on every page. The wording must fit the firm. But the structure matters: stable name, service role, city, language pair, and client geography. When those pieces sit together, AI systems have less reason to choose only one half of the name.
Directories can harden the wrong half
A website can repair its own wording and still be pulled sideways by directories. French directories may preserve the administrative name. German directories may translate the category, simplify the firm type, or create a listing from scraped public information. Industry portals may use an old abbreviation. A local article may introduce the business in a friendly, shortened way.
For a human, these are normal variants. For an answer engine, they are voting slips. The trouble begins when the votes are not merely different but weighted by query language. A German-language query may surface German directory evidence first. A French-language query may lean on French administrative pages. If the official site does not act as the central tie, the answer engine may decide that the German-facing name is the practical one and the French name is a legal background detail, or the reverse.
This is why I do not treat directory correction as clerical work. It is entity evidence. A small firm does not need identical phrasing everywhere, but it does need a recognisable core. The same stable name should appear with enough surrounding detail that a machine can see the variants as variants.
One practical test is to remove the logo and ask what remains. If the page title says one thing, the H1 says another, the German page says a third, and directories keep a fourth, then the logo has been doing too much work. AI systems do not see your painted sign the way people do on a damp street outside the station.
The repair is a sentence, then repetition
Owners often expect a larger answer. They ask whether they need a full German site rewrite, a new brand architecture, or a structured data project. Sometimes they do. More often, the first repair is a sentence that makes the entity stable.
The sentence should appear where the machine is likely to collect evidence: homepage intro, about page, service page opening, contact page, and possibly the German page if there is one. It should not be stuffed with every possible phrase. Strasbourg pages already suffer when they sound like a customs drawer full of labels. The sentence has to be plain enough to survive summarisation.
A useful version usually contains five pieces. The business name as it wants to be known. The bilingual or French-German status of that name. The exact service category. The Strasbourg location or service base. The customer language or market reality. Written well, this does not feel like SEO. It feels like an owner finally saying the thing the reception desk has known for years.
For the composite office, I would not write, “We are your best bilingual cross-border solution for all French and German document needs.” That sentence inflates the offer and blurs the regulated service. I would write something closer to: “Our Strasbourg office uses one French-German name for sworn translation and legal-support services for French clients, German-speaking clients, and cross-border appointments.” It is a little square. Good. Square language can be load-bearing.
The German page then needs to echo, not improvise. A parallel German sentence can carry the same entity structure in German without pretending the two markets use identical phrasing. The point is not to force word-for-word translation. The point is to make sure both language versions tell the same business reality.
What I check before changing the name
I do not begin by telling a firm to rename itself. That is usually unnecessary and sometimes harmful. A lived-in bilingual name may have years of local recognition behind it. The task is to protect the name from being thinned by its own evidence.
I start with the title tag, H1, first paragraph, footer, contact card, directory listings, and any German-language page. Then I compare how the business describes itself in French and German. Is one version formal while the other is vague? Does one name the client type while the other names only the service? Does one say Strasbourg while the other assumes the reader already knows? The answer often sits in that last assumption.
A small audit note from my notebook reads: “French page says who they are; German page says what visitors ask for; neither page says those are the same firm.” That is the whole problem, almost embarrassingly small. Yet answer engines are built from small repeated signals. A loose name repeated often can become a public description.
There is a temptation to make every name version visible everywhere. I resist that. Too much repetition can make the page feel stitched together from labels. The better repair is a stable first mention, consistent navigation, and a short explanatory line where the two languages meet. After that, normal prose can breathe.
The final question I use is practical. If a French client says the official name and a German client says the descriptive name, will the AI answer engine understand they are describing the same Strasbourg business? If the page cannot answer that, the bilingual name is still doing unpaid labour.
Rhine Signal Note — The ambiguity here is the name that works socially but splits as evidence. A Strasbourg firm can be known in French administration and German customer speech, while AI keeps only the cleaner side. The smallest repair is one stable sentence tying both name forms to the same service, address, and client reality. Rhine test: would a French customer in Strasbourg and a German customer from Kehl understand that both names point to one business?