Building a Multilingual Website: Lessons From Serving Eight Markets at Once
A client once came to us with a spreadsheet: eight languages, one website, a launch date already promised to their board. Their first question was "how long does the translation take?", as if that was the whole project. It never is. By the time a site serves more than one language properly, translation is maybe a third of the work. The rest is architecture: how URLs are structured, how search engines know which version to show whom, what happens when a page exists in Swedish but not yet in Polish, and how a language switcher avoids sending a Copenhagen visitor to a German homepage because their browser happened to be set that way.
Most of the pain in a multilingual website project shows up in exactly these decisions, not in the wordsmithing. Get the structure wrong early and you end up re-platforming eighteen months later, once Google has indexed the mess and you have to untangle it without losing rankings. Get it right from the start and adding a ninth market later is a configuration change, not a rebuild.
Why "just translate the text" isn't the job
Swapping English copy for Swedish copy on the same URLs, with no other changes, technically produces a multilingual page. It does not produce a multilingual website. Search engines need a way to know that /products/shoes and /produkter/skor are the same content in two languages, not two competing pages about shoes. Users need a way to land on the right version without guessing. And the content itself needs to read as if it were written for them, not translated at them: currency symbols, date formats, phone number formats, and cultural reference points all have to shift, not just the vocabulary.
None of this is exotic. It's well-understood, well-documented territory. But it's also exactly the kind of detail that gets skipped when "multilingual" gets treated as a checkbox rather than a piece of information architecture.
Choosing a URL structure: subdirectories, subdomains, or separate domains
This is the first decision, and it's harder to undo than it looks. There are three common patterns, and each has real SEO and operational tradeoffs.
| Structure | Example | Pros | Cons |
|---|---|---|---|
| Subdirectories | neuraweb.se/en/, neuraweb.se/sv/ | Consolidates domain authority in one place; cheapest to run; easiest to maintain as one codebase | Requires disciplined routing and consistent slug conventions per language |
| Subdomains | en.example.com, sv.example.com | Can be hosted or deployed somewhat independently; useful if regional teams manage their own content | Search engines can treat subdomains as semi-separate entities, sometimes diluting authority; more infrastructure to maintain |
| Separate ccTLDs | example.se, example.de | Strongest signal of local relevance; can register per-country trust | Most expensive and slowest to scale; authority doesn't transfer between domains; separate SEO campaigns effectively |
For most small and mid-sized businesses expanding into a handful of markets, subdirectories are the pragmatic default. They keep all your backlinks and domain authority working for every language version instead of splitting it across separate properties, and they let a single content team manage everything from one admin panel. Separate ccTLDs make sense mainly for large enterprises with the budget to run what are essentially independent marketing operations per country, or in genuinely regulated markets where a local domain carries trust that a subdirectory can't replicate.
Whatever structure you pick, consistency matters more than the specific choice. Mixing subdirectories for some languages and subdomains for others, because a decision got made piecemeal over a few years, is a common source of the technical debt we get called in to untangle.
hreflang tags: telling search engines who gets what
Even a perfect subdirectory structure doesn't automatically tell Google that /en/pricing and /sv/priser are language-alternates of the same page. That's the job of the hreflang attribute, a tag in the page's <head> (or in the XML sitemap) that explicitly maps every language version of a URL to every other one, plus an x-default fallback for visitors whose language doesn't match any version you offer.
Without it, search engines are left guessing, and they often guess wrong: showing a German user the English page because it has more backlinks, or worse, treating near-duplicate content across languages as low-quality duplication and suppressing pages that should be ranking fine. With it, each language version competes in its own market's search results instead of cannibalizing the others.
The technical requirement that trips people up most is reciprocity: every page in the hreflang set has to reference every other page in the set, including itself. If the Swedish page links to the English and Norwegian versions but the English page forgets to link back to Swedish, the whole annotation becomes unreliable and search engines may ignore it. This is exactly the kind of thing that's trivial to get right in a templated system and easy to get subtly wrong when pages are managed by hand or added inconsistently over time.
Translation is not localization
Translation converts words from one language to another. Localization adapts the whole experience (currency, date formats, units of measurement, address formats, imagery, idioms, and cultural reference points) so the page reads as if it were built natively for that market, not repurposed for it.
A few concrete examples: 1,000.50 in English becomes 1.000,50 in Swedish. Dates written month/day/year in the US read as day/month/year almost everywhere else, and a form field that doesn't account for that will silently misread 03/04 as March 4th when a Swedish visitor meant April 3rd. Prices need to show in the local currency, not just be translated as a number with a different symbol appended. Idioms and figures of speech that translate literally often read as strange, or unintentionally funny, to a native speaker. "Hit the ground running" doesn't mean anything word-for-word in most other languages, and a literal rendering signals immediately that the site wasn't built with the local audience in mind. Even color and imagery choices carry different associations across cultures, though that's a subtler layer than most projects need to worry about on a first pass.
Machine translation has genuinely improved, and it's a reasonable starting point for high-volume content like product catalogs. But it should never be the last step for anything customer-facing: landing pages, service descriptions, calls to action, anything where tone and precision matter. A native speaker reviewing and adjusting the output, not just checking it's grammatically correct, is what separates a site that reads naturally from one that reads translated.
What happens when a page doesn't exist yet in every language
No site launches with every page fully translated into every language on day one, and most never reach 100% parity; a niche blog post or a seasonal landing page may simply not be worth translating into all eight markets. The question is what happens when a user in one locale requests a page that only exists in another.
There are a few defensible fallback strategies, and the wrong choice here creates broken navigation or thin, confusing pages:
- Show the page in the site's default language, clearly labeled, rather than a 404. This keeps the user on the site and gives them something useful, even if it's not in their preferred language.
- Hide untranslated pages from that locale's navigation and sitemap entirely, so users only ever see content that genuinely exists for their language, and search engines aren't sent to thin or duplicate-feeling pages.
- Avoid partial translation of a single page: a page that's half in the target language and half in the fallback language, because only some fields were translated, looks broken rather than intentional. It's better to not show the page at all in that language than to show it half-finished.
This is also where content architecture decisions made early, like keeping a clean, language-independent mapping, of "this page in language A corresponds to this page in language B" pay off. Retrofitting that structure after a few hundred pages have been created ad hoc is a much bigger job than building it in from the start.
Language switchers and detection that doesn't annoy anyone
Automatically redirecting visitors based on browser language or IP geolocation feels helpful in theory and is a common source of frustration in practice. A Swedish speaker traveling in Spain doesn't want to be redirected to a Spanish version because of their IP address. A user who deliberately typed in the English URL doesn't want to be bounced back to their browser's default language on every visit. And aggressive auto-redirects can actively hurt SEO, because search engine crawlers can get redirected too, preventing them from indexing language versions they're trying to reach.
A more reliable pattern: use browser language or geolocation as a soft suggestion, not a forced redirect. Show a small, dismissible banner ("It looks like you're in Sweden. View this site in Swedish?") rather than an automatic bounce, respect the user's choice once they've made it (via a cookie or URL), and always make the language switcher itself easy to find, typically in the header, listing languages by their native names ("Svenska," not "Swedish," when shown to a Swedish speaker) rather than relying on flag icons alone, since flags represent countries, not languages, and the mapping between the two isn't as clean as it looks (Spanish, for instance, spans many countries and flags).
Common mistakes that are easy to avoid
A few patterns show up repeatedly in multilingual projects that weren't planned as multilingual from the start:
- Machine-translating everything with no human review. Fast and cheap up front, but it shows, especially in anything persuasive: headlines, CTAs, service descriptions, where tone matters as much as accuracy.
- Translating the visible content but forgetting metadata. Page titles, meta descriptions, image alt text, and URL slugs often get left in the original language because they're not visible on the page itself. Search engines index all of it, and an English meta description on a Swedish page undermines exactly the local search visibility the translation was meant to earn.
- Inconsistent URL slugs across languages. If the English version of a page lives at
/en/services/web-designand the Swedish equivalent is generated inconsistently (sometimes translated, sometimes left in English, sometimes restructured entirely), internal links break, hreflang mapping gets harder to maintain, and navigation between language versions of the same page stops working cleanly. - Treating the language switcher as an afterthought. Bolting it onto the header late in a project, after the URL structure and templates are already built, usually means it doesn't actually preserve the current page when switching, sending users back to the homepage instead of the translated equivalent of the page they were reading.
Every one of these is avoidable with planning, but expensive to fix retroactively once a few hundred pages and a year of search engine indexing are involved.
Planning for this from the start
None of this needs to be built for every market on day one. A sensible approach is to design the architecture (URL structure, hreflang setup, content model, fallback rules) for the number of languages you expect to eventually support, then launch with fewer and add markets over time without restructuring. The expensive mistake isn't launching with two languages instead of eight; it's building a system that can only ever cleanly support one, then trying to bolt more onto it later. If you're evaluating a web agency for a project like this, it's worth asking directly how they've handled multilingual architecture before, rather than taking "yes, we do that" at face value. Our article on how to choose the right web agency goes into the specific questions worth asking to separate genuine technical experience from a claim on a services page.
If you're planning a website that needs to serve more than one language or market, it's worth getting the architecture right before the first page is built rather than after. Our custom web design work includes exactly this kind of multilingual planning: URL structure, hreflang, localization workflow, and a content model that scales as new markets get added. Get in touch if you'd like to talk through what your project needs.
