Multilingual Website Search Without Translating Every Page

A visitor can understand enough of an English website to become interested and still struggle when the question becomes specific.

They may want to ask in French whether a product fits an older model. A Hebrew-speaking researcher may need one fact from an English PDF. An Arabic-speaking customer may know the product name but not the wording used in the returns policy.

Translating the whole website could help all three people. It is also a separate editorial, legal and operational project. Cross-language search offers a narrower option: let the visitor ask in one language, retrieve evidence from content written in another and return a short answer with links to the original sources.

That can make a single-language site more usable. It does not turn the whole site into a fully localised experience.

Four language layers that should not be confused

“Multilingual search” can describe several different capabilities. A responsible product page or article should state which one it means.

1. Source language

This is the language of the indexed page, document or PDF. A site may contain only English sources, or it may mix several languages.

2. Query language

This is the language the visitor uses in the search box. It may differ from the source language and may include misspellings, transliterated words or untranslated product names.

3. Answer language

This is the language of the generated response. A system may retrieve an English passage and explain it in Spanish, for example.

4. Interface language

This is the fixed chrome around the answer: the placeholder, button labels, loading message, error message and “Sources” heading.

These layers can have different levels of support. An answer can be in Arabic while the surrounding widget controls remain in English. A website can offer eight interface locales while the underlying search system supports a broader set of query languages. Saying “the product works in any language” hides distinctions that matter to users.

How cross-language answer search works

A typical cross-language pipeline has several stages.

Understand the question

The system detects or infers the query language, fixes obvious spelling issues and identifies the user’s intent. Product names, scientific terms and acronyms may need to remain unchanged.

Bridge the vocabulary

The query can be translated or normalised into a form that matches the indexed content. This is not always literal translation. “Send it back” may need to match “returns,” while an everyday medical phrase may need to match a technical term.

Retrieve evidence

Search runs against the site’s indexed pages and documents. The goal is to find relevant passages, not to translate and republish the entire source collection.

Generate the answer

A model writes a concise answer from the retrieved evidence and is instructed to use the visitor’s language. Source links remain visible so the visitor can inspect the original page.

Preserve a failure mode

If the evidence does not answer the question, the system should not use fluent translation to manufacture certainty. It should decline or show related material.

Google Cloud’s current Agent Search language table lists support for search and generated answers across many languages, including Arabic and Hebrew. The level of support varies by feature, which is exactly why each production language should be tested rather than covered by one universal promise.

What cross-language search solves

Cross-language search is useful when the source content already contains the answer but the visitor cannot express the question in the same vocabulary.

It can help with:

• English documentation used by an international developer community;
• research websites with reports and papers in one main language;
• product sites serving customers across several countries;
• tourism, education and nonprofit sites with limited translation budgets;
• technical catalogues where model numbers stay constant but descriptive words vary;
• help centres where visitors prefer to ask in their first language.

The value is focused. The visitor gets a shorter path to an answer and an original source to inspect.

What it does not solve

It does not translate the whole journey

Navigation, checkout, forms, account pages and legal notices remain in their original interface language unless the site translates them separately. Search can help someone reach information; it cannot make an untranslated purchase or support process fully accessible.

It does not certify translation quality

A generated answer can mistranslate a qualification, choose the wrong sense of a word or handle a specialised term poorly. Product names, measurements and legal wording deserve explicit tests.

It does not improve missing content

If the English page never states whether a service is available in France, a French question does not create that fact.

It does not replace the authoritative source

For legal, medical, financial, scientific or safety-critical material, the original document and a qualified reviewer remain authoritative. A translated AI answer is an aid to discovery and comprehension.

It does not guarantee every feature in every language

Retrieval, answer generation, ranking, speech input and interface translation can have different language matrices. Check the exact feature, not only a vendor’s headline language count.

How Achla AI currently handles language

Achla AI’s answer pipeline prepares a visitor’s query before retrieval. It can correct spelling, normalise forms, translate the query for matching and expand it with site-relevant terms. The answer request includes an instruction to reply in the original query language.

The indexed website remains the evidence boundary. A visitor asking in Spanish can receive a Spanish explanation grounded in an English source, with a link back to that English page.

For right-to-left content, the current widget applies automatic text direction to user messages and answers so Hebrew and Arabic text can align according to their content.

The boundary is important: the embedded widget’s current chrome strings are English-only. The answer itself may be multilingual, but labels such as the placeholder, loading state and source heading are not yet a complete multilingual interface. Site owners should evaluate that experience with representative users before describing it as fully localised.

Achla’s public marketing and account interface currently has eight locales—English, Russian, Hebrew, Arabic, French, German, Italian and Spanish—but that is a separate capability from answer-language handling.

A practical multilingual test plan

Do not test only by translating the same easy question eight times. Build a small evaluation set for each important audience.

Include plain-language questions

Use the words a customer or visitor would naturally choose, not terms copied from the source page.

Keep domain terms intact

Test product names, model numbers, acronyms and scientific terminology. Check whether the system translates words that should remain unchanged.

Add ambiguous phrases

A word such as “charge,” “return” or “cell” can have several meanings. Verify that site context guides the right interpretation.

Test unsupported questions

Ask for a fact that is not present. A multilingual system should be able to say that the evidence is missing in the query language.

Review citations

Open every source. Confirm that the cited passage supports the translated answer and that important qualifications were preserved.

Test the complete interface

Use keyboard navigation, screen readers and mobile devices. For Hebrew and Arabic, inspect punctuation, numbers, source markers and mixed-direction strings—not only paragraph alignment.

Use a fluent reviewer

Machine translation back into English is not an adequate quality review. A fluent domain-aware reviewer should inspect high-value and high-risk questions.

Record the questions and expected behaviour so the same set can be rerun after content, model or pipeline changes.

When to translate the site anyway

Cross-language search is a useful bridge, not an argument against localisation.

Translate the full journey when a market is strategically important, when local law requires specific notices, when visitors must complete forms or transactions, or when brand trust depends on a consistently local experience. Search data can help prioritise that work: repeated questions in one language may reveal where a translated landing page or help article would have the most value.

The two approaches can reinforce each other. Full localisation serves the whole journey. Cross-language search helps visitors ask unanticipated questions across the content that remains.

Make the promise precise

A credible multilingual-search promise sounds like this:

That is less dramatic than “your website now speaks every language.” It is also accurate enough to build on.

Explore the multilingual search definition, review AI search for documentation-heavy sites, and test real questions from the audiences you actually serve.

Play video

The YouTube player is not loaded until you press play.

Watch on YouTube (Video: Multilingual Website Search Without Translating Every Page)