Multilingual Website Development: How to Build One and What It Costs

A multilingual website is one site that publishes the same content in two or more languages, with a URL structure and a set of hreflang annotations that tell search engines which version belongs to which audience. The languages share a codebase. They rarely share a URL.

That last sentence is where most projects go wrong. A second language sounds like a content task, so it gets handed to a translator and a plugin. Six months later the German pages rank for nothing and the French version has fallen out of the index.

Every decision that matters is made before the first word is translated: where the languages live in the URL, how the versions point at each other, whether the slugs get translated, and who keeps it in step afterwards. Vezert runs its own site in five languages, so what follows comes from a setup you can inspect from outside.

A multilingual website serves content in several languages. A multi-regional website targets several countries, which is a different problem: one language can serve many markets, and one country can need several languages. Belgium wants Dutch and French. Austria, Germany and Switzerland all read German. Confuse the two in a planning meeting and you scope twelve versions where four would have done.

Three more terms get used as if they meant the same thing. Translation converts the words. Localization adapts everything around them: currency, dates, addresses, examples, legal pages, images with text baked in. Internationalization is the engineering work that makes localization possible, which mostly means separating text from code first.

Our own site runs five active locales: English, German, Spanish, French and Dutch. English sits at the root, the other four behind a language prefix. One codebase, five content sets.

Language moves buying behaviour more than most teams expect. According to a 2020 report from CSA Research, which surveyed 8,709 consumers across 29 countries, 76% of online shoppers prefer to buy products with information in their own language, and 40% will never buy from a website in another language. The second figure decides budgets.

Four signals say go. You already field enquiries from a country you do not publish in. Your search data shows the same questions arriving in another language. You sell something a buyer has to read carefully before paying. Or your competitors there publish locally and you do not.

Three signals say wait. Your product is bought by people who work in English all day, which covers most developer tooling. Nobody on your team can answer a support email in the new language. Or the site is not converting in English yet, and translation multiplies the problem.

The blunt version: a second language is a commitment to run two sites forever, not a one-off translation invoice.

Three URL structures are in common use, and the choice is close to permanent. Subfolders put every language on one domain, at /de/ or /fr/. Subdomains give each language its own host, de.example.com. Country domains give each market its own registration, example.de. Changing your mind two years later means redirecting every URL on the site.

According to Google's guidance on multi-regional and multilingual sites, subdirectories on a single generic domain are easy to set up and low maintenance, country-specific domains give the clearest geotargeting signal but cost more to run, and URL parameters such as ?lang=de are listed as not recommended.

Google names no winner. The trade-off that usually settles it is authority: every link your German pages earn on a subfolder feeds the same domain as your English pages, while on example.de it feeds a separate site starting from nothing. We picked subfolders for vezert.com and would pick them again for any company under fifty people. Country domains earn their keep when the markets really are separate businesses.

An hreflang annotation tells search engines that two URLs are the same page in different languages, so the right version reaches the right searcher. It is a mapping, not a redirect, and not a ranking factor. Google's documentation is blunt about the requirement people skip: if two pages do not both point at each other, the annotations get ignored.

The rules are short. According to Google's documentation on localized versions, every version lists itself as well as all the others, so a five-language set carries five entries on every page. Language codes come from ISO 639-1 and region codes from ISO 3166-1 Alpha 2, and a region code alone does nothing: be will not target Belgium, nl-BE and fr-BE will. The W3C advises keeping each tag short, so plain de beats de-DE when there is one German version.

Where it breaks, in the order we meet it. One-way tags, where the English page lists the German page and the German page lists nothing back. Tags pointing at a URL that redirects, which happens the first time somebody renames a slug. And tags that disagree with the canonical, so the two signals cancel out.

Our own set is generated from a stable identifier rather than from matching URLs. Every article carries an id equal to its English slug in all five locales, and the alternates are built from it. The URLs look nothing alike, and they are allowed not to.

Translation converts sentences. Localization adapts everything a sentence sits next to, and that is where the hours actually go. A translated page carrying a dollar price, an American date format and a screenshot full of English interface text reads as a foreign page somebody ran through a tool. Buyers spot it in seconds.

What changes is longer than most briefs allow for, and the table below is the short version: currency and tax display, number and date formats, address and phone fields, legal pages that differ by jurisdiction, and images with text baked into the pixels.

Layout is the quiet one. German compounds and French phrasing run longer than the English they came from, so a button designed to fit Get Started splits onto two lines and takes a grid with it. Design for the longest language, and check the templates before the copy is signed off.

Machine translation has a place, and it is narrower than the vendors suggest. It works as a first pass on long-tail content a human then edits, and not on the twenty pages that carry your revenue.

A localized URL translates the slug as well as the page: /de/blog/website-erstellen-kosten rather than /de/blog/website-cost-guide. It is optional, and it is one of the few optional things on this page we would argue for. The URL shows up in the search result, in the browser bar and in every link somebody pastes into a chat.

Two arguments hold up. A German buyer reading a German result should not run into an English string halfway through. And the keyword match, smaller than SEO folklore claims but real, comes free once you are writing in that language anyway.

On our site every locale carries its own slugs. The budget article is /de/blog/website-erstellen-kosten in German and /es/blog/presupuesto-pagina-web in Spanish, while the structure guide is /fr/blog/arborescence-site-web in French. Section paths are translated too: /de/preise, /fr/tarifs, /nl/prijzen. It all maps back through the same identifier, which is why the hreflang set survives slugs that share no characters.

Here is the cost nobody mentions up front. Every slug renamed after publication owes a permanent redirect, forever. Our redirect file holds more than 320 of them, nearly all from slug renames during localization, and the number only goes up.

One question separates the systems that survive a second language from the ones that fight you: does the platform treat a locale as a first-class field on the content, or as a copy of the site with a flag on it? The first group can tell you what changed in English since the German version was approved. The second cannot.

WordPress reaches multilingual through plugins, mainly WPML, Polylang and TranslatePress. It is the cheapest path when the team already knows WordPress, and the cost arrives later, on every plugin update and every theme never tested with a second language. Drupal handles multilingual in core, which is why it still turns up in public-sector tenders. Contentful, Storyblok and Sanity model locales as fields on the content, which suits sites past three languages with real editors. Webflow offers localization as a paid tier, and Shopify Markets covers per-market pricing for catalogues.

Our own site runs on Next.js with i18n routing and content stored as JSON per locale rather than a database. That suits a small team that writes and ships, and would suit thirty editors much less. Our comparison of Next.js, WordPress and Webflow works through the trade-offs.

Whatever you pick, check three things before signing: what happens when a translation is missing, whether URLs can be translated per locale, and whether hreflang is generated automatically.

The same content in five languages is not duplicate content, and Google says so clearly enough that the worry can be retired. The real duplication risk sits between versions of the same language: an English page for the UK and another for the US, chasing one query with nearly the same words. That is where canonical tags and hreflang have to agree.

Google's advice is to pick a preferred version and use rel=canonical together with hreflang so the correct regional URL gets served. What the documentation warns about separately is translating only the boilerplate, menu and footer while the body stays in one language, which leaves several near-identical results in the index.

Demand is the part that catches people out. It is not proportional to population, and it is not a translation of your English keyword list. When we researched the French version of this site in July 2026, agence web design, our English term translated literally, returned around 600 monthly searches. Agence web, the phrase French buyers actually type, returned about 7,500. Same service, ten times the demand.

So the sequence runs: research keywords per locale, write the page in that language, then translate what is left. Reverse it and you rank for phrases nobody types. The structural half is covered in our guides to planning a website structure and website architecture and search visibility, which apply per locale rather than once.

Most multilingual projects land in one of three shapes, and naming yours early settles half the scope argument. A translated entry set, a full mirror, or a market-aware store. They differ in how much of the site gets translated, and in how independent the language versions are allowed to become.

Shape one: a translated entry set. The English site stays the main site. Four or five pages get a proper local version: home, one service page, pricing, contact. Everything else stays in English. Cheap, quick, and a fair market test.

Shape two: a full mirror. Every page exists in every language, one codebase, one design, a content set per locale. That is what our own site does across five locales, blog included, and it needs governance more than technology. The failure mode is drift: English gets updated, the other four fall behind, and within a year you run five sites that share a logo.

Shape three: a market-aware store. A multilingual ecommerce website adds problems the first two never meet. Currency and tax per market, shipping rules, payment methods that exist in one country only, and a checkout translated down to the last validation error. Ecommerce website localization is mostly not a text project, which is why it gets underestimated.

The build happens once. Languages get added to it, and they add content work and quality assurance rather than a second build. On our published pricing, a landing page starts at €1,500, a corporate website at €4,500 and a web portal at €9,000, and each figure covers the first language.

What every additional locale costs depends on four things: how many words the site genuinely contains rather than how many pages it lists, how many templates need a layout check in the longer language, how many locales launch at once, and whether content is written per locale or translated. Vendors quote per word and agencies per page, so agree on the unit first.

Timelines follow the same logic. Our published windows run two to five days for a landing page, two to four weeks for a corporate website and six to twelve weeks for a portal. A second language adds a translation pass and a review pass, not a second project. Where the calendar slips is review: waiting for somebody in the market to approve copy is the longest step, and the one nobody plans for.

Then there is the part that never ends. Every locale needs updating when the source changes, which is why our maintenance plans run €500, €2,500 and €5,000 a month depending on the amount of change and monitoring. Our website budget breakdown covers the wider picture.

Six failures account for most of the multilingual sites we get asked to repair. All six are cheap to avoid during planning and expensive to fix afterwards, because each one touches every URL on the site at once. They run roughly in the order we meet them.

1. Automatic redirection by IP address with no way out. A German speaker sitting in Spain gets the Spanish site and cannot escape. Detect, suggest, let the visitor decide. Crawlers usually visit from one country, so a hard redirect can also hide four of your five versions.

2. A language switcher that dumps everyone on the home page. Switching language on a pricing page should land on the pricing page in the new language. Label each option in its own language, Deutsch rather than German, and skip the flags.

3. Half-translated pages. Menu and footer in German, body copy in English. Google warns about this pattern by name, and to a visitor it reads as abandonment.

4. hreflang bolted on at the end. Added after launch, when nobody remembers which URL maps to which, so one-way tags follow within the week.

5. Everything else left untranslated. Transactional emails, form validation messages, the 404 page, image alt text and meta descriptions. The first two cost trust; the last two cost rankings.

6. No owner per locale. The most common of the six, and not technical at all. If nobody is named as responsible for the Dutch version, it is out of date inside six months.

Maintenance is where multilingual sites are won or lost. A launch is a project with a date on it. Keeping five locales in step runs forever, and it needs three things: one source of truth, a visible queue of pending changes per locale, and a named owner for each language who can approve copy without a meeting.

Pick a source locale and write there first. Ours is English. Every change starts there and propagates outward, which means at any moment we can answer the only question that matters: which pages in which language are behind the source, and by how much.

Automate the checks a human will not run five times over. We generate a markdown mirror of every article in every locale, so AI crawlers get clean text instead of a rendered application, and the same pass rebuilds the llms.txt index per language. Our SEO audits run per locale, because a score that passes in English says nothing about the Dutch version.

If you take one thing from this guide, take this: settle the URL structure and the slug policy before the first translation is ordered. Everything else here can be changed later at a reasonable price. Those two cannot. When you are ready to build, our corporate website service and the maintenance plans are shaped around this problem.