B2B multilingual sites: why a translation widget is not the same as searchable locales

Two different meanings of a “multilingual website”

On first contact you often hear: “We need English for export.” Behind that phrase can hide two incompatible goals:

1. Convenience on the site — a foreign partner switches language and reads the catalogue.
2. Discovery abroad — people find you via queries in English, Polish, German, and so on.

An embedded translator (Google Translate and similar) mostly covers the first scenario. For the second you need indexable locales — separate URLs in the search index with their own relevance and trust signals.

What the search engine sees

A browser or JS widget usually swaps text on the fly. For the crawler you often still have one source page and one URL. The result: you do not get a full “English storefront” in results—at best a duplicate of the main locale without targeted queries for that market.

An indexable locale needs at least:

• Separate addresses — e.g. an /en/ prefix, a subdomain, or a dedicated route tree.
• Dedicated metadata — title and description matched to intent, not whatever the auto-translator produces.
• Meaningful content — not a verbatim machine duplicate, but adaptation to phrasing and market norms (units, standards, logistics).

When needed, configure hreflang and tie versions together so you do not spawn uncontrolled duplicates or bleed authority. The exact pattern depends on CMS, domains, and target countries.

A trust layer on every locale

For B2B, a “global look” is not enough. A buyer from the EU or your region checks:

• how to reach you and in which time zone to expect a reply;
• legal details, company form, delivery terms;
• case studies in a context they understand (industry, volume, geography), not vague testimonials;
• certificates and compliance where procurement depends on them.

If the English version reads like a thin auto-translation without contacts and facts, conversion drops even on paid traffic—let alone organic.

Typical mistakes

One DOM and JS translation — handy for humans today, weak as a search growth strategy.

Mixed languages on one page — confuses both people and crawlers.

Cannibalisation — several URLs with almost the same meaning in one language without a clear page role. The same logic as in SEO architecture helps: one page, one clear intent.

“We translated everything with a script and moved on” — nomenclature and unit errors remain in the catalogue; for manufacturers and suppliers that directly erodes trust.

Maturity ladder

1. Stage 1 — widget or manual switch for people already arriving from current traffic. Fast and cheap, but not the same as export in search.
2. Stage 2 — hand-built landing pages for 1–2 priority markets: key categories, contacts, delivery, differences from the “home” version.
3. Stage 3 — full locales for SEO and ads: URL tree, editorial rules, aligned legal wording.

This path is typical for EU supply, multilingual catalogues, and long sales cycles.

Technical side in brief

Implementation depends on the stack: routes and metadata are easier to design during site development; after launch, keep the locale ↔ demand link with SEO support. Agree up front who owns copy, how versions land in the sitemap, and how redirects and 404s are checked per locale. Shared acceptance criteria for speed and accessibility are in the site handoff checklist.

Why a flexible architecture on a modern framework makes growing routes easier — see Next.js vs classic CMS.

Takeaway

A translation widget ≠ export in search. If the goal is to be found in the target market’s language, plan indexable locales, meaningful metadata, and trust on each version. Otherwise you stay in “convenient for people already on the site”, not “search brings new leads”.