A restaurant can be one place to its guests and two places to a machine, when the English page promises a tourist experience and the French page describes a neighbourhood table.
A bilingual restaurant in the 5e once showed up in my ledger as two answers to the same question. Ask an English-language engine where to eat near the Panthéon and it described a “charming Parisian dining experience for visitors,” prix-fixe, evening-focused, romantic. Ask a French engine the same thing and it described a “bistrot de quartier,” lunch formule, regulars, simple. Both descriptions came from the restaurant’s own pages. Both were true. Neither was the whole truth, and together they made the engine believe in two businesses where there is one.
This is the bilingual split, and it is not caused by bad translation. It is caused by each language being written for the audience the owner imagines reading it. The English page courts visitors, so it leans on atmosphere and the Panthéon. The French page speaks to locals, so it leans on the lunch formule and the everyday. The pages drift apart on the four facts that define a restaurant, and the engine, reading each in its own language, returns whichever version the query language surfaced.
The facts that must agree, and the tone that need not
Two language pages do not need to be word-for-word translations; in fact they should not be. A French reader and an English reader arrive with different references, and flattening one language into the other reads as machine-made on both sides. What the two pages must share is not their phrasing but their facts: the same category, the same audience, the same booking logic, the same location.
Category is the first to drift. If the English page calls the place a “fine dining restaurant” and the French page calls it a “bistrot,” an engine answering in English will rank it against tasting menus and an engine answering in French will rank it against neighbourhood tables. The place cannot win either contest because it is neither extreme. Choose the true category once, and let both pages name it in their own idiom: “neighbourhood bistro” and “bistrot de quartier” point at the same thing without copying each other.
Audience and booking logic should match across the river of language
Audience is the subtlest drift. The English page that says “perfect for visitors exploring the Latin Quarter” and the French page that says “notre clientèle d’habitués” have told the engine two different stories about who eats here. The honest answer is usually both, and both pages should say so in their own register: the English page can welcome visitors and still note the lunch regulars; the French page can speak to habitués and still note that travellers are at home here. The audience fact, mixed local and visitor, must survive both translations.
Booking logic is where the split does real damage. Suppose the French page says walk-ins are welcome at lunch and the English page says “reservations recommended.” A guest reading one and a machine reading the other will disagree about whether to book, and the engine will pass on the rule it happened to read. State the same booking reality in both languages, plainly: if lunch is walk-in and dinner needs a table held, say exactly that on both pages. A booking rule is a fact, not a flourish, and it should not change with the language.
Location anchors should carry the same map
The last fact is location, and it drifts whenever one page names the arrondissement and the landmark while the other relaxes into “central Paris” or “near the famous sights.” If the French page says “dans le 5e, à deux pas du Panthéon” and the English page says only “in central Paris near the major attractions,” the French query gets a precise placement and the English query gets a blur. Both pages must carry the same map: the same arrondissement number, the same named landmark, the same nearest metro.
The test is simple and worth running monthly. Ask an answer engine about your restaurant in English, then in French, by name and by category. Read what comes back without prompting it. Does the category match across both? The audience? The booking rule? The arrondissement and landmark? Where the two answers disagree, your two pages disagree, and the fix is on the page, not in the engine. Align the four facts, keep the two voices, and the machine sees one restaurant described twice rather than two restaurants invented by accident.
The Paris Trace
A bilingual restaurant is not split because it speaks two languages; it is split because the English page sells a visitor’s evening and the French page describes a local’s lunch, and the engine believes both. The trace to leave is one shared set of facts, the same category, audience, booking rule and arrondissement, carried in each language’s own voice and never copy-pasted between them. Write “neighbourhood bistro in the 5e, near the Panthéon” and its true French twin. So the answer engine remembers one table, not two strangers.