Running a multilingual answer hub in Europe
Publish in the language your buyer asks the question in, which in much of Europe is not the language they work in. Translate the answers people search for rather than the whole site, and connect the versions properly so neither is read as a duplicate of the other.
In most European markets a professional buyer reads English fluently, works partly in English, and still types the question in their own language when they are looking for a supplier nearby. Both behaviours are real, and a hub that serves only one of them is invisible to half its market.
Which languages actually earn a version
The market where you can deliver, invoice and answer the phone. This is the version that gets the specifics, the prices and the local conditions.
It is the working language of cross-border research and the language much of the assistant behaviour was tuned on. It is also what a buyer in a country you do not have a version for will ask in.
Two current languages beat four stale ones. A translated page that no longer matches the original is worse than no translation, because it is confidently wrong in a market you are not watching.
Translate the answers, not the site
The costly error is deciding to localise everything and therefore localising nothing for eighteen months. Take the questions being asked in that language, in the volumes that language actually produces, and do those. The corporate pages can wait or stay in English; nobody searches for an about page.
Two languages you maintain beat four you translated once.
Translation is the wrong word for it
A question is not translated; it is re-asked. The Dutch phrasing of a question is frequently not the literal rendering of the English one, and the English rendering of a German compound noun is usually three words that nobody types. Start from how the question is asked in that language, then write the answer, then check it says the same thing as the original.
The specifics change too. Prices in the local currency with the local tax convention. Regulation as it applies there. Examples from companies a reader recognises. A page about a European regulation that uses only American examples reads as imported, and it is.
The hreflang mistakes that cost most
- Annotations that are not reciprocal. If A points at B, B must point back at A, or the pair is disregarded.
- Pointing at a URL that redirects, or at one that is canonicalised elsewhere. Point at the final, canonical address.
- Using a language code where you meant a region, or inventing combinations. Language first, region only where the content genuinely differs by country.
- No x-default. Somebody in a country you have no version for has to land somewhere sensible.
- Annotations injected by a script. Put them in the HTML head or the sitemap.
A structure that holds up
| Decision | Recommended | Why |
|---|---|---|
| Path | A language prefix on one domain | One estate to maintain, one set of signals |
| Naming | Slugs in the language of the page | The slug is read by people and machines in that language |
| Switcher | A real link between the equivalent pages | Not a redirect to the other home page |
| Detection | Offer, never force | Automatic redirection by location traps readers and confuses crawlers |
| Markup | Author, dates and organisation on every version | The same entity, stated in each language |
Questions this settles
Generally yes, and they will draw on sources in other languages to do it. A page in one language can inform an answer given in another, which is an argument for publishing the substance somewhere rather than waiting for full localisation.
It reaches the cross-border research behaviour and misses the local supplier search. For a company selling in a specific market, the local language carries the higher-intent questions.
One hub with language versions of each answer. Separate hubs drift apart, and the drift shows up as contradictions a machine will notice.