Multilingual company websites: Structure, hreflang and translation management
Your main website advertises a new service, a regional page still promises the old package, and the enquiry form sends its confirmation in the wrong language. A multilingual website needs a content structure and an update process that work together. Translation alone cannot provide either.
01Define the markets you can actually serve
Before commissioning translations, list what customers can buy in each market and who will respond to them. A company might accept English enquiries while providing on-site support in only one country. That boundary belongs in the offer. Otherwise, the sales team receives requests it cannot fulfil and prospective customers spend time completing an unsuitable journey.
Treat language and location as separate decisions. One English version can serve several markets when their offer is genuinely shared. Create regional versions when differences justify them and someone can maintain those differences. For a smaller business, a complete set of service pages, relevant references and contact information is usually a more useful starting point than a translated archive with no owner.
02Choose URLs your team can maintain
Google recommends separate URLs for different languages. Changing the content only through cookies or browser preferences can make some versions harder to discover. This is an implementation principle, not a promise of better rankings. See Google's guidance for multilingual websites.
| Structure | When to consider it | Operational responsibility |
|---|---|---|
| Directories such as /en/ and /de/ | A shared website and editorial team | Consistent routing and editing permissions |
| Subdomains | Separately managed website sections | Coherent navigation, measurement and hosting |
| Separate market domains | Long-term independent market presentations | Domain ownership and a shared page map |
Use this as a decision aid rather than a ranking formula. An elegant URL structure does not compensate for a weak offer. If your existing language already lives at the domain root, avoid moving it merely to make the directory structure symmetrical. A custom company website should accommodate established links and the people maintaining the content, as well as the visual design.
If adding languages changes existing URLs, use the checks in our guide to investigating traffic drops after a redesign.
03Connect equivalent pages with hreflang
Hreflang identifies language or regional alternatives. Each linked group should include the page itself, complete alternative URLs and reciprocal links. Use language codes such as en, adding a region when needed. The optional x-default value identifies a fallback for unmatched languages. Google's localised versions documentation defines the technical rules.
The useful business input is a page map. An English service page, its German equivalent and its French equivalent belong to one content group. A language switch should take someone to the equivalent service, not abandon their task at the homepage. When a translation is unavailable, communicate that clearly and offer a useful alternative. Do not publish empty pages simply to make every language option appear complete.
Ask the development team to generate these relationships from the content model. Editors should not have to copy technical annotations whenever a page changes. Acceptance testing should cover a translation published later than the original, a temporarily withdrawn version and a restored page. Agree which published versions belong in the group at every stage and how the visible language selector should behave.
04Keep canonical URLs and language relationships distinct
A canonical URL expresses a preference among duplicate or very similar pages. Hreflang describes language alternatives. For full translations, normally plan a canonical URL for each language version rather than pointing every version at the original language. Review the implementation and any exceptions against Google's canonical URL guidance.
Request a review sheet containing URL, language, publication status, canonical destination and related language pages. A contradiction then becomes visible: a published French service points to an English canonical, or its language selector leads to a different offer. Review the whole group together. Checking only the original page can leave an apparently finished website with an unreliable international journey.
05Give translations an owner and a review state
Use a stable content identifier with separate language fields or records. A title or slug alone is a fragile relationship because editors may change either. For every version, track whether it is in progress, awaiting review, approved or due for an update. Record who owns factual accuracy and when the content was last checked. These details are more useful than a vague global label saying that the website is translated.
Consider an illustrative workflow. A service owner changes the scope of a support package. The editor flags the affected passages; regional colleagues check whether their offer changes too; language reviewers then prepare suitable wording. Avoid silently replacing all versions. For a change that makes an existing promise inaccurate, decide whether to withdraw it temporarily, publish a limited correction or coordinate the release across markets.
The translation package should include buttons, field instructions, validation messages, page metadata, image alternatives, confirmation emails and downloads. Keep a compact glossary with examples and context. A local abbreviation may need an explanation for an international reader. Currency, support hours and service availability require a business decision, not an automatic word substitution.
Agree how feedback returns to the source. If a translator finds an ambiguous promise, the answer should improve the shared content record rather than remain in an email thread. Give reviewers a preview of the actual page, because navigation length and button space are difficult to judge in a spreadsheet. Approve the complete customer journey, not just a document containing paragraphs.
Before translation begins, use our website content checklist to make sure the source material is complete.
06Test a completed task in every language
Choose a realistic journey: find a service, inspect a relevant reference, submit an enquiry and understand the confirmation. Run it on a phone and a desktop. Longer labels must fit, and the language selector must remain discoverable. Offer an automatic language suggestion as something the visitor can change, rather than trapping them in an assumed preference.
- Open each language URL directly in a fresh session.
- Switch languages on a service page, a reference and the contact page.
- Trigger a form error and check its wording and recovery path.
- Complete a valid submission and verify the receiving team and confirmation.
- Change the source content and verify that translation review work is created.
If your website includes a portal or a complex enquiry process, maintain language throughout the web application. Test returning from an email, signing in on another device and opening attachments. Translated navigation is little help if the final step contains an unexplained condition or an error the visitor cannot understand.
07Plan maintenance beyond launch day
When existing URLs change, prepare a mapping to their replacements, implement appropriate redirects and monitor the result. Google's site migration guidance describes that process. Adding a new language does not, by itself, require moving the existing website.
Make unfinished translations, broken counterpart links, outdated attachments and unattended contact destinations part of regular editorial review. Compare enquiries by language and by whether your team can actually fulfil them. A weak English result might reflect an unclear offer or a failed handover, rather than a hreflang problem. Give each finding a specific hypothesis and an observable next check.
08Frequently asked questions
Must every archived article be translated?
No. Start with a complete journey from the offer to a usable contact route. Extend the archive when its value to a market justifies both translation and future maintenance.
Can machine translation provide a starting point?
Yes, as a draft. A responsible reviewer should check meaning, terminology and the actual offer. Important contractual or technical statements may also need specialist review.
Do we need separate British and American versions?
Only when there are meaningful differences you can maintain. An ambition to sell internationally is not enough reason to multiply every page into several regional copies.
Will hreflang improve our rankings?
It does not guarantee a ranking position. Treat it as part of coherent language relationships alongside useful content and a working enquiry journey.
09Plan your next language version
Send us your website, target markets and service list. We can map the language versions and propose a translation workflow your team can keep up to date.