How we handle multi-language sites for European clients

European clients frequently need a site that genuinely serves multiple languages, not just a translated copy of an English site bolted on as an afterthought. The translation itself is usually the easiest part of the project; the technical and structural decisions around it are where most of the real complexity actually lives.

Separate country-code domains, subdomains, or subdirectories for each language each have real SEO and maintenance tradeoffs. For most clients we recommend subdirectories, like /fr/ or /de/, over subdomains, since it consolidates domain authority in one place rather than splitting it across what search engines treat as semi-separate sites with their own independent authority.

hreflang tags tell search engines which language version to show to which searcher, and they're commonly implemented incorrectly, missing the required self-referencing tag, or with mismatched language codes between pages. We validate this explicitly, since a broken hreflang implementation can actively hurt visibility rather than helping it, sending searchers to the wrong language version entirely.

German text is routinely 20 to 30 percent longer than the equivalent English copy. A layout designed and tested only in English frequently breaks, awkward wrapping, overflowing buttons, once real German or Finnish copy is dropped in. We test layouts with actual translated content, not placeholder text, specifically to catch this before launch rather than after.

The harder ongoing problem is keeping languages in sync as content changes. We set up a defined workflow, usually flagging untranslated or outdated content in the CMS, so a content update doesn't quietly leave four other language versions stale, which is the most common way multi-language sites degrade after launch once the initial project momentum fades.

Beyond language, EU markets carry different legal disclosure requirements, cookie consent specifics, VAT display rules, that vary by country. We flag these to clients early, since they're easy to overlook when a team is focused on translation and can create real compliance exposure if missed at launch.

One client's existing multi-language site had hreflang tags pointing to French content for the German-language tag, a simple copy-paste error in the original implementation that had gone unnoticed for over a year, quietly sending some German searchers to the wrong language version and hurting both markets' visibility.

Rather than waiting for final translated copy, we request early sample translations for the longest-running languages specifically, German and Finnish tend to expand the most, and stress-test key layout components against that longer text well before the full translation project is complete.

Automated translation can be a reasonable starting draft for internal review, but we never publish it directly for client-facing content, since subtle errors in tone or accuracy are hard for anyone but a native speaker to catch, and they can meaningfully damage credibility with that specific market's audience.

Beyond translating text, European markets often expect prices, dates, and measurements displayed in locally conventional formats, not just a language swap. We build this as a distinct localization layer from translation itself, since the two are related but require different attention to detail.

Some languages have real regional variation in vocabulary and convention across the countries that share them. For clients targeting multiple countries within one language, we clarify upfront whether one translated version serves all regions adequately or whether region-specific variants are worth the additional investment, based on how much the target markets actually differ.

We give clients a realistic estimate of translation cost per content update across their full set of languages, since this recurring cost is easy to underestimate when a project is scoped around the initial build alone rather than the years of ongoing multilingual content maintenance that follow launch.

Some European clients eventually expand into markets requiring right-to-left text support, Arabic or Hebrew, even if their initial launch covers only left-to-right European languages. We flag this early during information architecture planning if there's any realistic chance of future expansion in that direction, since retrofitting genuine right-to-left support onto a site's layout system built without any consideration of it is a substantially larger project than planning for the possibility from the start.

We also build a simple internal glossary of brand-specific and product-specific terminology, agreed with the client and shared with translators, before any translation work begins. Without this, the same product feature can end up described with two or three different translated terms across a site, which reads as inconsistent and slightly unprofessional to a native speaker even though each individual translation might be technically accurate. A shared glossary, maintained as the product evolves, is a small upfront investment that noticeably improves how polished a multi-language site feels once it's actually live and being used by real visitors in each market.

Launching all target languages simultaneously delays the whole project until every translation is complete, while launching with a smaller initial set and adding languages progressively gets the site live sooner in its primary markets. We help clients weigh this tradeoff based on which markets carry the most immediate business priority, rather than assuming a simultaneous full launch is automatically the right approach for every situation.

Some clients prefer using their own in-house bilingual staff or regional offices for translation rather than an external translation agency, which we fully support, but it changes how we structure the CMS workflow, since an in-house translator usually needs simpler, more guided tools than a professional translation agency's own pipeline would require.

We set clear expectations upfront about turnaround time in this model too, since an in-house translator juggling translation alongside their primary role typically can't match a dedicated agency's turnaround speed, which affects how far in advance content needs to be drafted before a planned multi-language publish date.