Adding a language is easy to put in a brief, but it involves copy, navigation, forms and later changes. Start with the customers the business actually serves and the team’s ability to maintain those versions, rather than wanting more switches.
Here we choose initial languages and check readiness. General search preparation and the website commissioning process remain separate topics. More languages do not guarantee enquiries or entry into a new market.
Start with customers and reply arrangements
For each language, record which customers will use the website and which service you offer them. Use real enquiries, an agreed market or a concrete working plan. Country and language are different attributes: do not assume a customer’s language from geography alone.
Check who will respond after an enquiry. If the website offers discussion in a language, the team needs a way to provide it. Choose the main version with the project’s requirements in mind, and additional versions for audience tasks rather than a universal number.
Choose a complete first-release scope
The table helps discuss readiness. These are planning options, not requirements for every business or an assessment of search demand.
| Situation | First-release decision | What to agree |
|---|---|---|
| Main audience is defined | Prepare a complete journey | Service, contact and necessary terms |
| Second audience and materials exist | Plan an additional language version | Translation, review and customer response |
| Second market is only being discussed | Record a future stage | Reason to launch and materials needed |
| Translation is partly ready | Complete the necessary scope before publication | Version contents and no empty links |
Translate the whole journey, not one page
- Navigation, service names and links between necessary pages.
- Service content, important terms, examples and FAQ.
- Contact explanations, field labels and instructions.
- Errors, confirmations and the next step after submission.
- Page titles, descriptions and accessible image labels.
- Messages after an enquiry where the process includes them.
Do not show a menu item that leads to an empty translation. If version scopes differ, make this clear in the structure and agree it with the business. Visitors should not discover only at the form that the service or a reply in their language is unavailable.
The service page copy guide helps prepare content; the enquiry form guide covers fields and states.
Assign an editor and translation review
Choose someone to check terminology, facts and meaning in the version. Automated drafts also need review: are scope, exclusions, reply arrangements and service names preserved? Approve alignment with the actual offer as well as natural wording.
Review real copy in the interface. Translation can change button, line and hint lengths. Check necessary font characters, visible headings and the form with the keyboard open. Short placeholder text does not prove readiness across languages.
W3C explains identifying page language for assistive technologies to work correctly. Ask the developer to verify its declaration, not just the visible switch. This is one check, not a full accessibility audit.
Agree how all versions will change
Assign an owner for facts, translation and publication. For a new service condition, record the affected pages and languages. Natural wording may differ, but versions should not accidentally contradict each other.
Educational example: a business adds a travel condition. Before updating, it finds mentions on the service page, FAQ and contacts, approves translations and checks links. This is a hypothetical scenario, not an XEVOR case study. If a new language is not ready, do not present old terms as a current translation.
Use the CMS planning guide to discuss editing. Several languages alone do not determine who should manage the website or how.
Search checks before adding a language
Google’s localized version guidance describes reciprocal hreflang links between corresponding URLs, including the current version. Ask for a page-pair map and checks of final URLs; a switch alone does not confirm this.
Google also explains multilingual websites: use separate language URLs and accessible links. Do not rely solely on automatic changes based on browser settings.
- Translated pages open at their own URLs.
- Canonicals, language relationships and sitemap match the actual structure.
- Titles and descriptions reflect the particular version’s content.
- Test indexing restrictions have not reached the intended release.
These checks provide a technical basis, not proof of indexing or rankings. Ask for the actual result during acceptance and observe search performance after launch.
Agree language acceptance criteria
- Audience, main version and each additional version’s scope.
- Materials, translator, editor and fact owner.
- Pages and messages within the enquiry journey.
- URL and language-pair maps with technical checks.
- The same test scenario for every version.
- How terms are updated and another language added.
Follow the service-to-contact journey, switch language and check where you arrive. Agree any actual test enquiry with the recipient; without one, record that only the interface was checked. Opening a form is not receiving a request.
Check the journey on a phone · Discuss business website language versions · Send a task description
Website language FAQ
Do I need three languages at launch?
There is no universal number. Scope follows project requirements, audiences and the ability to prepare and maintain complete versions.
Can I add a language after launch?
Yes, with a separate plan for content, URLs, links and checks. Record a future stage rather than assuming a hidden completed feature.
Is automated translation enough?
Do not treat a draft as an accepted deliverable. Have a responsible person check facts, terms, conditions and the interface.
Must the whole blog be translated at once?
Agree each version’s scope and available links. Do not leave empty pages or links promising an unfinished translation.