A multilingual website makes sense when your company is ready to serve visitors in several languages. First identify the audiences, the offer available to each and the people who can respond to enquiries. Then plan the pages, translations and implementation.
An additional language lets you present an offer to another audience. It does not guarantee a particular number of impressions, enquiries or a payback period. Results depend on demand, the offer, content and continuing work.
Define the scope of each version
Different markets may need different pages. Check service availability, working arrangements, contacts, examples and supporting documents before deciding what to translate.
In a hypothetical project, a supplier sells equipment in two countries but provides maintenance in only one. Translating the maintenance page without checking the offer would leave visitors with the wrong expectation.
For project scoping, list the following separately:
- Main pages and catalog content.
- Navigation, labels and buttons.
- Forms, errors and confirmations.
- Follow-up emails and messages.
- Images containing text and attached documents.
- Page metadata and addresses.
Plan URLs and language switching
Each language version needs an accessible address. CoreWeb's English home page uses /, while its Russian version uses /ru. For each new page, define the addresses of the versions that actually exist and check the links between them.
A language switch should lead to the corresponding material when a translation is available. If it is missing, choose an understandable alternative: explain that the translation is unavailable or offer an appropriate section. Do not disguise another language's content as a completed translation.
Changing menu labels is not enough. Check the page title, body, form and error messages as well.
Connect versions for search
The hreflang attribute helps identify corresponding language versions for search engines. It does not translate content or guarantee indexing. Referenced versions must exist and match the actual pages. Google's guidance on language versions.
Keep a list of URLs, languages, canonical addresses and alternatives. Do not put missing translations in the sitemap. Every published version should have meaningful content and navigation.
Make translation a repeatable workflow
Assign responsibilities for the source text, terminology review, offer approval and publication. Machine translation can assist the process, but the result needs review in the context of the product and interface.
Text length affects buttons, cards and navigation. Review translations in the actual layout. Agree on dates, number formats, currencies and contact options. Translating a price does not automatically convert it or establish identical terms across markets.
In the CMS, check whether editors can save a draft, preview the translation and notice when the source page has changed. Adding a language to a settings list does not settle these editorial questions.
A launch readiness matrix
Copy this table and replace the hypothetical rows with your website's scope. Keep “not checked” separate from a successful result.
| Material | Source version | Translation | Interface check | Action check |
|---|---|---|---|---|
| Home page | Approved | Review needed | Navigation and first screen | Open the relevant service |
| Service page | Terms being clarified | Not started | Not checked | Enquire about the service |
| Product page | Data ready | Terminology under review | Specifications and documents | Request product selection |
| Form | Fields agreed | Errors being translated | Mobile layout | Confirmed receipt |
Add a URL, responsible role and verification date to your working version. Do not include real customer contacts or enquiries in a public readiness document.
Second-language launch checklist
Run these checks for every page type, and test forms and key actions in every language. Record the URL, device, date, reviewing role, expected result and actual result. Use “passed”, “failed”, “not checked” and “not applicable”, with an explanation.
- Completeness. Compare published content with the matrix: body copy, navigation, labels, documents, images containing text and metadata. Expected result: visitors can understand the offer without changing to the source language; required materials are available and unfinished translations are not presented as complete.
- Language switching. Open an internal page directly, change languages and switch back. Also test a page without a translation. Expected result: the corresponding page opens, and a missing translation follows the agreed fallback; there is no empty page or unexpected redirect loop.
- Forms. Test missing required fields, invalid formats, successful submission and the designed delivery-error scenario in an approved test environment. Expected result: labels and messages are translated, correcting an error preserves entered data, and the responsible recipient actually receives the marked test. A thank-you screen alone is insufficient.
- Formats and layout. Check dates, numbers, currencies, phone numbers, long headings and buttons on mobile and desktop. Expected result: values match the agreed market terms, text remains readable and does not obscure actions. Language selection alone does not automatically convert a currency.
- Search connections. Compare URL availability, canonical addresses, language alternatives and the sitemap with the actual versions. Expected result: references lead to existing corresponding pages; a missing translation is not listed as an available alternative. Indexing is monitored separately after launch and is not guaranteed by this check.
- Editor workflow. Change the source in a test item, prepare its translation, open the preview and check the publishing sequence. Expected result: responsibilities and outdated-translation status are clear, drafts do not become public accidentally, and the process for maintaining both versions is agreed.
Hold the release if the main offer is inaccessible, enquiries are lost or a required check is incomplete. For a non-critical issue, record its impact, responsible role, deadline and the release decision. After a fix, repeat the affected scenario and retain the retest result rather than just a “fixed” label.
What affects cost and timing
The estimate depends on the amount of content, its readiness, the CMS, integrations, differences between markets and the required checks. Some versions can share their structure; others need different sections or processes.
Avoid applying a universal percentage for a second language. Prepare a page matrix, language list, translation status and launch constraints instead. Also agree on who maintains the versions when services or catalog data change.
Test the complete visitor journey
Before launch, use each version on mobile and desktop. Open a direct link, switch languages, find the offer and send a marked test enquiry in an approved environment. Check errors and confirmations, then verify receipt and processing of the enquiry.
After publication, observe search discovery and enquiries separately by language. Missing data is not evidence of either success or failure.
CoreWeb performs its development work in-house. We can discuss language architecture as part of a complete website project. You may also find our guide to technology and editorial workflows useful when preparing the brief.