What Makes a Website Genuinely Multilingual?

A website does not become genuinely multilingual because a language switcher appears in the header.

The real test begins after someone clicks it.

Does the menu change? Do the opening hours remain understandable? Does the contact form use the selected language? What happens when the visitor reaches the reservation tool, checkout, confirmation email or downloadable PDF?

Many websites translate the visible first layer and leave the rest of the customer journey behind.

The homepage changes language. The service pages do not.

The navigation changes. The form error messages do not.

The product page is translated. The delivery information and checkout return to the original language.

Technically, the website offers several languages.

Practically, the visitor is still expected to work around the gaps.

A genuinely multilingual website does not need every historical page translated into every language immediately. It does need to let the intended audience complete the important journey without repeatedly falling out of the language they selected.

Translation is not the same as a multilingual experience

Translation concerns the words.

A multilingual experience includes the entire path around those words:

finding the correct page;
recognising the available language options;
understanding the offer;
checking prices, opening hours or delivery conditions;
completing a form;
booking or purchasing;
receiving confirmation;
finding help when something goes wrong.

A business can have accurate translations and still provide a poor multilingual experience.

The translated text may be buried behind an unclear language menu. A reservation tool may open in another language. The selected language may disappear when the visitor follows an internal link. Search engines may send people to the wrong version. A customer-service email may arrive in the site’s default language.

The words are translated.

The journey is not.

The selected language should survive the complete task

The simplest practical test is this:

Can a person choose a language and complete the main task without being forced back into another one?

For a restaurant, that task may be:

understand the concept;
view the menu;
confirm the location and opening hours;
reserve a table;
receive a useful confirmation.

For a local service business:

understand the service;
decide whether it fits;
review pricing or conditions;
send an enquiry;
understand what happens next.

For a webshop:

find a product;
understand the details;
select a size or variation;
review delivery and returns;
complete checkout;
receive order information.

When the chosen language disappears halfway through, the website has not completed its job.

The visitor may still manage.

That does not make the experience good.

A language selector is a promise

A visible language option creates an expectation.

When a website offers English, Dutch or French, the visitor reasonably expects the relevant information and actions to be available in that language.

That does not require perfection.

A small business may not have the time or budget to translate every old article, press release or rarely visited page.

But the central customer journey should be honest.

If only part of the site is translated, the business should decide deliberately which part is complete and which part is not. A language option that changes the homepage but leaves the menu, form and booking process untouched can create more frustration than offering fewer languages clearly.

A partial translation is not automatically useless.

An accidental partial translation is the problem.

Translate the pages that help somebody act

The first translation priority should not necessarily be the page with the most words.

It should be the page that supports the most important decision.

For many small businesses, the priority order is closer to this:

1. The offer

What does the business provide? Who is it for? What does it cost, or what affects the price?

2. Practical information

Where is the business? When is it open? Which location, delivery region or service area applies?

3. The next action

How can someone book, buy, call, visit or request information?

4. Conditions and reassurance

What are the delivery terms, cancellation rules, return conditions, payment methods or important limitations?

5. Confirmation and follow-up

What happens after the visitor submits the form, places the order or makes the reservation?

A translated blog archive may support search visibility and trust.

A translated confirmation email may prevent an immediate customer problem.

Priority should follow the customer journey, not the convenience of the content system.

The hidden parts matter most when something goes wrong

The easiest pages to translate are usually the pages a business sees every day.

The forgotten parts often appear only after an action or error:

required-field messages;
payment errors;
unavailable booking times;
out-of-stock notices;
cookie and consent settings;
password-reset emails;
order confirmations;
cancellation messages;
automated support replies;
legal or delivery conditions.

These moments matter because the visitor is already trying to solve something.

A beautiful translated homepage offers little comfort when the payment error is incomprehensible.

A multilingual review should therefore test success paths and failure paths.

Do not only ask whether the form can be submitted.

Ask whether a person understands what to correct when it cannot.

Menus, PDFs and external tools still count

Businesses often treat external tools as somebody else’s responsibility.

The visitor does not.

A restaurant site may be translated while the menu is available only as a French PDF. A multilingual hotel site may send the visitor to an English-only booking engine. A webshop may present products in Dutch but use an untranslated returns portal.

From the visitor’s point of view, the journey belongs to one business.

The fact that a different supplier operates the final step does not remove the friction.

External systems should be included in the multilingual review:

booking and reservation platforms;
payment and checkout tools;
delivery trackers;
help centres;
embedded maps and widgets;
downloadable menus and brochures;
account portals;
automated emails and messages.

Sometimes the business cannot fully control the external system.

That limitation should still be recognised and, where possible, explained before the visitor reaches it.

The website should remember the visitor’s choice

Selecting a language repeatedly is unnecessary work.

When someone chooses a language, the site should normally preserve that choice while they move between pages. Internal links should lead to the equivalent language version where one exists.

Common failures include:

the logo returns to the default-language homepage;
a call-to-action links to the original-language page;
blog links cross into another language;
the language switcher always returns to the homepage instead of the equivalent page;
checkout ignores the storefront language;
changing language clears the current task.

These are not translation errors.

They are navigation and implementation errors.

They make the site feel less reliable because the visitor cannot predict what the next click will do.

Search engines also need a clear structure

People are not the only visitors that need to understand the language structure.

When separate URLs exist for different language or regional versions, Google recommends identifying those variations with hreflang annotations so that Search can connect users with a suitable version. Google also recommends clear, separate locale URLs rather than relying only on content that changes automatically according to a visitor’s perceived language or location. (Google Search Central)

A useful multilingual structure therefore needs more than translated body text.

It should consider:

stable URLs for each language version;
links between equivalent pages;
correct language and regional codes;
appropriate page titles and descriptions;
what happens when no equivalent translation exists.

The technical term matters less than the outcome:

The correct people should be able to find the correct version of the page.

The page should declare its language correctly

Web pages can declare their main language in the HTML lang attribute.

W3C guidance recommends declaring the default language of the page, and MDN notes that this helps assistive technologies such as screen readers use the appropriate pronunciation and language behaviour. (W3C Internationalisation) (MDN)

This is a small technical detail with practical effects.

A page can look correctly translated to a sighted visitor while still being announced incorrectly by a screen reader because the underlying language was never changed.

A multilingual website should therefore review both visible content and the language information built into the page.

Translation should sound like the business

Literal translation can preserve meaning and still weaken the message.

A phrase that feels natural in English may sound stiff in French. A direct Dutch translation may use words that are technically correct but commercially unusual. Formality, sentence length, humour and calls to action do not move perfectly between languages.

That is where localisation begins.

Localisation asks:

How would this audience naturally say it?
Are the currency, date and measurement formats appropriate?
Does the tone fit local expectations?
Are examples and references understandable?
Does the call to action sound normal?
Is the same level of formality used consistently?

The goal is not to make every language version identical.

The goal is to make each version equally useful.

Machine translation can help—but it still needs ownership

Modern translation tools can make multilingual publishing much faster.

They can produce a strong first draft, especially for clear source text.

They do not remove the need for decisions.

Someone still needs to verify:

names and product terms;
tone and formality;
prices and conditions;
legal or safety-sensitive information;
links;
headings and interface labels;
forms and messages;
whether the meaning survived the translation.

The more important the page is to a purchase, booking or legal commitment, the more deliberate the review should be.

Automation can reduce the work.

It cannot own the consequences.

A multilingual site needs a maintenance rule

The first translation is not the hardest long-term problem.

Keeping the versions aligned is.

A business updates its opening hours, adds a service, changes a return condition or replaces a product. The default language is corrected immediately. The other versions remain unchanged for months.

Eventually, the website contains several versions of the truth.

A practical multilingual workflow should define:

which language is the source version;
who is responsible for new translations;
which changes must be reflected immediately;
how untranslated content is flagged;
whether publication waits for every language;
how old or missing translations are reviewed;
what happens when a page is removed.

This does not need to be complicated.

A simple status—draft, translated, reviewed, published—can prevent a great deal of confusion.

A website is not genuinely multilingual only on launch day.

It must remain multilingual after the next update.

Not every business needs every language

More languages are not automatically better.

Every additional language creates work: translation, review, support, maintenance, legal consistency and quality control.

A business should choose languages according to the audience it genuinely serves or intends to serve.

Useful questions include:

Which languages do current customers use?
Which visitors abandon because information is unavailable?
Which locations or markets matter commercially?
Can the business support enquiries in that language?
Which part of the journey must be available first?
Can the language version be maintained?

For a Brussels restaurant, Dutch and English may be commercially useful even when most daily communication happens in French.

For a local service business with a narrowly defined area, one strong language version may be better than three neglected ones.

The objective is not to collect flags in the header.

It is to reduce unnecessary barriers for the right audience.

How Vayluna can help

A business owner should not need to become a multilingual website specialist to identify the practical gaps.

Vayluna can review the experience from a visitor’s point of view:

which languages are visibly offered;
which important pages are actually available;
where the selected language disappears;
whether menus, forms and external tools remain usable;
whether the next action is understandable;
which fixes appear most important.

The result should be a clear, prioritised explanation rather than a list of unexplained technical terms.

That principle also sits behind the developing Brussels Project, where multilingual access is treated as part of the customer journey rather than as a political scorecard.

The wider range of Vayluna services will continue to grow, but the standard should remain simple: identify the real problem, explain it clearly and recommend a proportionate next step.

A genuinely multilingual website feels complete

The best multilingual websites do not constantly remind the visitor that translation work happened.

They simply allow the person to continue.

The language remains selected.

The important information is present.

The buttons lead to the expected place.

Errors can be corrected.

The confirmation can be understood.

The customer does not need to wonder which parts of the business are available in their language and which parts are not.

That is the real standard.

Not a row of language options.

Not a translated homepage.

Not a plugin installed and forgotten.

A genuinely multilingual website lets the intended visitor complete the journey with confidence.