Multilingual Website Development
Several languages on a site is a question of structure, not of translation: each language needs its own URL, its own meta tags and correct hreflang links. Done carelessly, it costs you rankings in every language at once.
Updated
What this gives you
Three things that separate a genuinely multilingual site from a site with a translate button.
Every language has its own URL
A path per language, so search engines can index each version separately and a person can send a link in the language they were actually reading.
Hreflang that ties the versions together
A search engine needs to be told that these are versions of one another, not duplicate content. That is what hreflang and x-default are for — and the links have to be reciprocal, or they are ignored.
The visitor picks the language
No automatic redirect based on browser settings: those often do not match what a person wants to read, and an unexpected redirect annoys more than one extra click.
Where it usually goes wrong
A multilingual site looks like a translation task, but the mistakes are almost always technical rather than linguistic.
- A translate widget instead of separate URLs. If every language lives at the same address and only what is on screen changes, then as far as a search engine is concerned there is one version. The others will simply not be found.
- One-way hreflang. The links have to be reciprocal: if the English version points to the Lithuanian one, the Lithuanian one must point back. Otherwise the whole markup is ignored.
- No x-default. You need a version to send people to when their language is not covered by the site.
- A switcher that leads to the home page. You are reading a service page, you click another language, and you end up at the start. It is the most annoying and the most common small defect there is.
- A half-translated page. Headings in one language, buttons and form errors in another. It is the system strings that get forgotten most often.
How it is done
The URL structure is directories on one domain: example.com/en/, example.com/lt/. One language can also live at the root if it is the main language of the site. That keeps the whole domain reputation in one place instead of splitting it across separate domains.
With Astro.js the multilingual setup lives in the project itself: each language has its own content set, while the shared part of the site — header, menu, forms — stays single. This site is built exactly that way: four languages, one shared frame, hreflang with x-default.
With WordPress a dedicated plugin is used, for example Polylang or WPML. Which one fits depends on the number of languages, the volume of content, and who will be editing it day to day.
What I check before launch
Whether each language has its own title, description and canonical URL. Whether the hreflang links are reciprocal and whether x-default is there. Whether the language switcher leads to the same page rather than to the home page. Whether the sitemap covers every version. Whether the system strings — buttons, form errors, search field — were translated along with the content.
Only after that is the site submitted to Google Search Console.
How the work goes
Languages and scope
Which languages, whether all of them get every page, or whether some versions stay shorter. That decides both the URL structure and how much content has to be prepared.
Structure and URLs
I lay out the URL scheme and the language switcher so that from any page you land on the same page in the other language, not on the home page.
Implementation
With Astro.js the multilingual setup lives in the project itself; with WordPress it is a dedicated plugin such as Polylang or WPML, chosen by the number of languages and the volume of content.
Checks and indexing
I go through whether the hreflang links are reciprocal, whether each version has its own meta tags, and whether the sitemap covers every language. Then the site is submitted to Google Search Console.
FAQ
Questions that come up before we start.
Do you translate the text?
No — the translation comes from you or your translator. What I take responsibility for is that every language has its own URL, its own meta tags and the right place in the structure. Machine translation is not offered: bad language costs trust, and Google does not reward it either.
How much does a multilingual site cost?
The multilingual setup is part of the business plan from €200. The final price depends on the number of languages and the number of pages — every extra language is another set of content to load and check.
Can a language be added to an existing site?
Usually yes. The first step is to look at how the site is put together, because that decides whether a language can be added cleanly or whether it would mean rebuilding the URL structure with redirects.
Will the site show the visitor their own language automatically?
No, and that is deliberate. Browser language settings often do not match what a person wants to read, and an automatic redirect also makes indexing harder. The visitor picks the language with the switcher.
Does each language need its own domain?
Almost never. Separate domains make sense when it is not the language that differs but the business in that country. Normally the languages live on one domain in separate directories, which keeps the whole reputation of the site in one place.
How will search work in each language?
Every version gets its own headings, meta tags and schema.org markup — that is the technical base. Whether a version finds its audience also depends on the content: a word-for-word translation rarely matches what that market actually searches for.
What is next
How many languages do you need?
Write which languages you need and whether the site already exists — I will tell you what scope of work that takes.
Get in touch