Multilingual website: what to decide before translating your website

You have identified interest from outside Spain or receive enquiries in another language, but translating your entire website seems like a lengthy task that will be difficult to maintain. The decision is not simply about adding a language selector: it is about deciding which audience you will serve, what information it needs and which parts of the website you will be able to update consistently.

A multilingual website makes sense when an additional language addresses a specific commercial or operational need. By the end of this article, you will be able to decide what to include in an initial version, what to prioritise and what is best left out until you have greater clarity.

The elements a multilingual website needs to address

1. A specific objective for each language

   Define what someone arriving at that version should be able to do: understand your services, request information, browse a catalogue or access documentation. A language should not be added solely because there is a potential market; it needs a purpose that helps determine the necessary pages and content.

2. A distinct audience where necessary

   Two people who speak different languages do not always look for the same things or make decisions in the same way. One version may be aimed at end customers and another at distributors, or a service may have different terms depending on the market. If the message, offer or user journey changes, a word-for-word translation will not be enough.

3. Prioritised pages, rather than an automatic copy of everything

   Start with the pages that enable the objective to be met: the homepage, relevant services, contact routes and content that clarifies an important decision. Translating outdated sections, pages with no current use or content awaiting review increases the workload and complicates maintenance without serving a clear purpose.

4. Terminology and messaging reviewed by someone who knows the business

   A service name, commercial term or technical term may need adaptation rather than a literal equivalent. Whoever approves the texts must be able to confirm that the meaning, tone and calls to action reflect what the company actually offers.

5. Navigation that keeps visitors in their chosen language

   The selector should be easy to find, and each version should link to its equivalent pages where they exist. If a page is unavailable in another language, it is best to decide what the user will see rather than directing them without notice to a different or incomplete page.

6. Consistent forms and communications

   Review what happens after an enquiry is submitted: the language of the confirmation, the person or team receiving it and their actual ability to respond. The form is part of the user journey; translating its labels alone does not resolve the subsequent experience.

7. A viable way to update content

   Every relevant change in one language may require review in the others. Before publishing, clarify who prepares updates, who validates them and what happens when one version is pending. This decision prevents the website from communicating different information due to a lack of coordination.

8. Technical rules for identifying each version

   The URL structure, links between languages and configuration of each page should be planned during development. Their purpose is to help browsers and search engines distinguish which version corresponds to each language and avoid unnecessary mixing. The specific implementation depends on your website's technology and structure.

How to prioritise the initial scope

Rank each language, page or feature according to three questions:

• Does it support a current objective? If it addresses enquiries you already receive, enables you to present a key service or resolves a known barrier, it has higher priority than a precautionary translation.
• Is the content ready? A page with approved copy and someone responsible for reviewing it can move forward before a section whose message is still changing.
• Will you be able to maintain it? Include first what you can review and update when the offer, a condition or contact information changes.

Based on these answers, divide the scope into four groups:

• Essential: the language and pages without which the defined objective cannot be met.
• Desirable: content that improves the experience but can be added later.
• Future: languages, sections or adaptations you will keep as an option without treating them as part of the initial publication.
• Out of scope: tasks that belong to another project, such as reviewing an entire offer for a new market or producing commercial materials that do not yet exist.

This classification makes it possible to discuss a specific initial version. It also prevents an apparently simple request—“translate the website”—from becoming an imprecise project involving undefined content, features and reviews.

Practical example: a reasonable initial version

Imagine, as a hypothetical example, a service company that receives enquiries in English about one specific part of its business. Its objective is for those people to understand the service and explain their needs through a form.

The initial scope could include:

• an English homepage focused on that service;
• a page explaining the service and its limitations;
• a contact page with a form and confirmation messages in English;
• navigation between Spanish and English;
• a review of who receives and responds to enquiries.

The company could leave its historical blog, services it does not offer outside Spain, documents that have not yet been reviewed and a third language for a later phase. That would not make it an incomplete website: it would be a version aligned with the available objective and its capacity for maintenance.

What is best left out until it is better defined

Do not include these elements by default in a multilingual website:

• Translation of the entire content archive. First, it is advisable to identify which pages remain useful and which need a more thorough review.
• Languages without someone responsible for validation. Publishing texts that nobody can approve or update introduces avoidable uncertainty.
• Undecided offer adaptations. If pricing, terms, delivery, coverage or the sales process vary by market, that decision must be defined before it is brought to the website.
• Features that depend on third parties without reviewing the full workflow. Bookings, payments, catalogues, customer service tools or forms may require specific adjustments for each language.
• New commercial promises. Translation is not the time to add messages the company has not confirmed.

Next step: turn the idea into a clear scope

A multilingual website is best planned around the objective, available content and the person who will maintain it. If you are unsure which languages, pages or workflows to include in your case, you can explain the project through the web development for businesses service. This will help you assess a scope that distinguishes what is essential from what can wait until a later phase.