Multilingual site: a technical checklist

A multilingual site is not a "translate" button bolted onto the homepage. It is a separate engineering and content discipline with its own failure modes, and most of them are invisible until traffic has already scattered. Done carelessly, internationalization quietly suppresses the very growth it was meant to unlock.

What you cannot afford to miss

The fundamentals of a correct multilingual build are well understood, yet constantly skipped by teams that treat translation as the whole job. Each item below is a place where a small oversight becomes a large SEO or UX problem once two or more languages are live.

• Correct hreflang for every language and regional version, including the fallback.
• Clean URL structure that keeps languages in the path, not buried in session parameters.
• Full content translation, not just the menu and the hero.
• Canonical links and a per-version sitemap so crawlers map the set.
• Fonts and layout tested for accented and non-Latin scripts.

hreflang is where most sites break

Hreflang tells search engines which language and region each page targets, and it must be reciprocal: if page A points to page B as its Spanish version, page B must point back. A broken or one-directional cluster is worse than none, because it actively misleads the crawler about which page to serve. We audit the return tags on every deploy, because a single missing link can drop a whole market from the index.

Regional variants add a second axis. Spanish for Spain and Spanish for Mexico are not the same page, and tagging both as generic "es" sends the wrong users to the wrong prices and currency. The markup has to express both language and region, and the content has to actually differ where the market differs. Copy-paste localization is the fastest route to a penalty for duplicate content across regions.

URL structure decides your fate

There are three common patterns: subdomains, subfolders, and country-code top-level domains. Subfolders under one domain consolidate authority and are simplest to maintain, which is why we default to them for most clients. Subdomains isolate signals and need more link-building effort per language. ccTLDs signal strongest local intent but multiply hosting, legal, and maintenance overhead. The choice is strategic, not cosmetic, and it should be made before the first page ships, because changing it later means migrating every URL.

Translation is the easy part

Machine translation has made turning text from one language to another almost free. That is precisely why it is no longer the hard problem. The hard problem is intent: the same product described for a German procurement manager reads nothing like the version for a Brazilian consumer, and a literal translation that ignores local units, payment habits, and legal wording will convert poorly no matter how grammatically perfect it is.

• Localize measurements, currency, date formats, and address fields.
• Adapt imagery and examples to the local context rather than reusing stock.
• Rewrite calls to action for local buying behavior, not word-for-word translation.
• Have a native speaker review, because rhythm and trust live in the details.

The SEO traps of internationalization

Internationalization mistakes hit SEO hardest because search cannot tell which version to show, and traffic fractures across near-duplicate pages. Canonical tags must point within the same language set, never across languages, or you instruct Google to ignore your translations. Each language needs its own sitemap and its own internal linking, so a French visitor is guided through French pages and never lands on an orphaned English one by accident.

Another trap is serving content by IP detection. It feels helpful but breaks caching, confuses crawlers, and frustrates travelers and VPN users. We prefer an explicit, persistent language selector that respects the user's choice and keeps the URL authoritative. The crawler and the customer should never disagree about what page they are on.

Performance and rendering across languages

Adding languages multiplies the asset and font load if you are not careful. Non-Latin scripts need larger font files, and loading every language's font on every page is a silent performance tax. We subset fonts per language and lazy-load them, so a Russian visitor never downloads the Arabic font. The same Lighthouse discipline that governs a single-language site applies twice as hard when the page must stay fast in ten locales.

A rollout checklist

We launch multilingual projects behind a strict checklist so none of the above surfaces in production. The order matters: structure first, content second, signals third, and validation continuously.

• Decide the URL strategy and reserve every locale's path or domain up front.
• Implement hreflang clusters with automated reciprocal-tag testing in CI.
• Translate and localize content with native review before any page goes live.
• Submit a per-language sitemap and verify indexing in each target region.
• Monitor crawl errors and position shifts per locale for the first eight weeks.

A real example

A client expanding from Russia to the EU launched three languages without hreflang and with language chosen by IP. Within a month, the German pages were being served to Austrian users as the generic version, rankings for the French pages vanished, and organic traffic from the new markets was a fraction of the forecast. We rebuilt the hreflang clusters, moved to subfolders with an explicit selector, and re-submitted sitemaps. Traffic recovered over the following quarter, but the lost quarter was pure cost that correct setup would have avoided.

Translating the text is easy. Making search serve the right language is the real task.

The bottom line

Treat multilingual as a first-class architecture decision, not a translation afterthought. Get the hreflang, the URLs, the canonicals, and the localization right before you scale to the next market, and each new language becomes a predictable channel. Get them wrong, and you pay for the mistake in lost visibility every single month. The engineering is mundane. The consequences of skipping it are not.