Multilingual website and what adds to the cost

A second language on a website rarely costs what the client expects. In a quote it looks like translating copy. In practice it turns out to be a separate URL structure, a separate set of fields in the database, a separate content owner and a separate search strategy.

Start with the language model

Draw up a matrix of languages and markets before anyone sketches a first screen. A language describes how you communicate; a market can change the offer, the contacts, the documents, the currencies, the form rules and the sales team. One language does not always mean identical content across regions, and one country can require several language versions.

That matrix decides four things at once, and none of them can be settled after the mockups are done.

• The address structure. Subfolders, subdomains or separate domains, and that choice is rarely reversed later.
• The fields in the content system. Which blocks are shared across every language and which belong to one language only.
• Editor roles. Who may publish a given version and who signs off on the content.
• The set of templates. How many pages exist in each version and what to show when a counterpart is missing.

Language, country and market

For each version write down the audience, the goal, the owner and the differences. If only the text changes, a translated version is enough. If services, legal material, contacts and the route an inquiry takes all differ, you need a regional layer of its own. It can live on the same platform but carries its own rules.

Do not decide the market from browser settings alone. Someone may be working abroad, using a shared device or deliberately reading the international version. An automatic hint is fine; the final choice stays with the visitor and gets remembered.

Full and partial versions

A full version has a counterpart for every public page. A partial one may carry only the key services, the contacts and material for a single market. Both work, as long as the boundary is visible. What is dangerous is the illusion of completeness, where half the links quietly return the visitor to another language.

For a partial version, decide in advance what a missing page does. Showing an explanation and a link to the available material in another language is fine. Do not redirect every missing counterpart to the home page: the person loses their context, and a search engine does not see an equivalent page.

URL structure

This choice governs how simple administration is, what certificates cost, how workable the analytics are and what search history each version starts with. There are three options and they are not equivalent.

• Subfolders. The balanced option for most companies: a new version needs no separate domain, certificate or configuration, and every version is managed from one admin. The format itself gives no indexing advantage. Google says plainly that it has no preference between subfolders and subdomains. That does not carry over to separate country domains, which also act as a location signal.
• Subdomains. They make sense when versions differ substantially in structure, live on different servers or sit closer to their region. Search engines treat them as separate properties.
• Separate national domains. Maximum trust in a specific country and the sharpest targeting, but each domain has to be promoted as a new project with no history behind it.

Hreflang markup and sitemaps

A crawler has to know unambiguously which version to show a visitor. Pages point at each other with dedicated tags, and the governing rule here is reciprocity.

If a page in one language points at its counterpart in another, the return reference is mandatory. Each page also points at itself. Broken reciprocity on even one address means the crawler ignores the markup for the whole pair. In practice it breaks in three places.

• The page does not reference itself. This self-reference is the one most often skipped, and without it the set is incomplete.
• One side was updated, the other was not. An address changed on one side and the cluster fell apart silently, with no error anywhere in the reports.
• The set contains a page that no longer exists. A tag points at a deleted address and the crawler ignores that particular link. The remaining reciprocal pairs keep working, but the language the broken tag pointed at is left without a counterpart.

A fallback version sits alongside: a tag saying where to send someone whose language settings match none of your versions. Usually that is the international English one. Every address in the tags is absolute, with the protocol included, and leads straight to the final page that returns 200 rather than to a redirect. Language codes follow the ISO standard, so Ukrainian is “uk”, not “ua”. The code “ua” stands for the country, and search engines ignore a tag that uses it.

Sitemaps are easier to keep as one file per language with a shared index. That way the indexing of each branch can be watched separately.

What increases the amount of work

The common client assumption is that going multilingual means copying text into new rows in a database. In reality each extra language complicates the architecture, the interface and the support routine, and that is what shapes the final website development cost.

The same sentence at different lengths

The same idea takes different widths in different languages. German and French terms run noticeably longer than their English equivalents, and that breaks layouts built for a single language.

• Buttons. The label overflows or wraps onto two lines, pushing everything below it down.
• Navigation. Menu items stop fitting on one row and jump to a second on mid-size screens.
• Cards and tables. Element heights in a row stop matching and the grid looks ragged.
• Data formats. Dates, currencies, decimal separators and phone masks differ from market to market.

Scripts written right to left need the layout mirrored: logo placement, icon direction, list order. That is a separate stage of styling work rather than a setting.

Data architecture

Every dynamic element gets tied to a locale identifier: headings, text blocks, metadata, image attributes, form messages, category names, legal documents. As the number of languages grows so does the number of database queries, so translations are stored modularly and frequent queries are cached.

A site designed modularly from the start can take a third and a fourth language without a rewrite. A site where the second language was bolted on after launch usually has to be reworked at template level.

Who owns the content

A translation without an owner goes stale quickly. Each language needs a person or a role that signs off on content, terminology, contacts and local exceptions. A translator is responsible for linguistic quality but cannot decide whether a service is available in a market or which department receives an inquiry.

The source of truth

Decide which version triggers a change: one base edition or separate market ones. When an editor changes the source, the linked pages move to a “needs review” state. The system should not silently copy text into the other fields or treat them as current.

Not every change needs a new translation. Fixing a stray space should not block publication; a new service condition should. With a short note on the change and a marker showing which blocks it affects, nobody has to reread the whole page.

Translation states

A working cycle runs through draft, ready for translation, translated, edited, checked in layout and published. A page does not become publishable merely because none of its fields are empty.

You need a gap report: an untranslated menu item, button, form message, image description, metadata field or document. A manual pass complements the automatic one, because a field can be technically filled with an old or wrong version of the text.

Local exceptions

Localization changes more than words. Examples, date formats, contacts, legal notices, field order in a form and the list of available services can all differ. Those fields are kept apart from the shared ones so a general update does not overwrite an agreed exception.

Keep a register of exceptions with a reason and an owner against each. Without it the team cannot tell whether a difference is deliberate or the page was simply never updated. During a redesign that register is what stops local decisions disappearing by accident.

Machine translation and editing

For a first pass over large sections, machine translation saves time. Leaving it unedited is unwise, particularly where the reader is deciding whether to work with you.

• A machine draft. The module produces a first copy of the page in the target language.
• A native pass. The translator corrects industry terminology and register, not only grammar.
• A technical check. An editor looks at formatting, internal links and whether the media is present.
• Publication. The content manager opens the page and enables the switcher for visitors.

That order is faster than translating from scratch and leaves none of the machine phrasing a foreign reader spots in the first paragraph.

Optimizing each language version

Automatic translation on its own brings no organic traffic from other countries. Each branch is optimized as a project in its own right.

People in different regions search for the same services using different words. A literal translation of a keyword list often returns nothing, simply because the target audience phrases the question differently.

• Its own keyword set per branch. Collected separately from local data rather than translated from an existing list.
• Unique titles and descriptions. Built on local queries rather than on translations of what you already have.
• Addresses in the audience’s language. For non-Latin scripts that usually means transliteration, which Google explicitly allows, while non-Latin characters in an address turn into a long encoded string when the link is copied.
• Translated structured data. Organization, service and breadcrumb names belong in the language of the page.

Which sections a corporate website needs in the first place is covered in our article on corporate website structure.

The usual mistakes

Forcing a redirect by location

Automatically redirecting a visitor to a version based on their IP address harms both sides. The person may be traveling or deliberately reading the international version. Most Google crawling comes from the US, so a hard redirect can hide the other versions from the crawler and keep them out of the index.

The better practice is an unobtrusive bar offering to switch, while the switcher still lets visitors choose any version.

Mixed content

A visitor opens the English version and the form labels, button text and error messages are still in another language. To a foreign client that reads as a defect and a reason to close the tab.

Before releasing a new version, walk the whole chain.

• Menus and buttons. Including the ones that appear only after an action: “show more”, “collapse”, “send”.
• Form fields and hints. Placeholders and helper text get forgotten more often than the labels themselves.
• Error messages. Fill the form in wrongly on purpose and see which language it answers in.
• The email after submission. It comes from a template that is frequently not tied to the language versions at all.

A switcher nobody can hit

On a phone the switcher sometimes hides in a submenu or is small enough to miss with a finger. It belongs somewhere visible in the header, next to the menu button. Label the languages with letter codes rather than flags, because one language is spoken in dozens of countries and a flag can mislead.

The checklist before opening a new version

• Tags are reciprocal. Cross references exist on every page of the pair, including the self-reference.
• Paths are absolute. Every tag carries the full address with no intermediate redirects.
• Forms work. A test inquiry from each language version arrived and the error texts are translated.
• Required pages are translated. Contacts, company details, the error page and the privacy policy.
• Indexing is open. The new paths are not blocked in robots.txt and the sitemaps carry canonical addresses only.
• Analytics are separated. Visitors and goals are segmented by branch, otherwise there is no way to judge the return.

Conclusions

A multilingual website costs more not because of translation but because of everything around it: the address structure, the fields in the database, the editor roles, a separate keyword set and a separate update process.

The decision that sets the budget happens before the prototypes. It is the matrix of languages and markets, which shows whether only the text changes or the services, the contacts and the inquiry route change with it. The first costs what a translated version costs; the second costs what a second site on a shared platform costs.

If you are planning to enter a new market, send us the list of languages and describe what will differ in each version besides the words. We will build the matrix, show where the line falls between a translated version and a regional layer, and quote both separately. Often it turns out that a partial version with a handful of key pages is enough to start with, and then we price only that. We take on full multilingual builds as part of corporate website development. The tier with a custom design and a structure shaped around your services costs from $2,000 to $3,000, and a second language version is included in that price. If your company is based outside Ukraine, the way we handle the process, payments and access is set out in our article on working with a Ukrainian web studio.