A second website language creates work beyond translation
Before adding another website language, decide which content will be translated, who approves it and how both versions will stay current. Plan URLs, language switching, search annotations and support expectations alongside the translation. A second language creates an ongoing publishing responsibility, as well as a launch task.
Put the advice into practice
Give your next major prospect a clearer reason to choose you
Plan the content, design and enquiry pathways around the work you want to win.
Discuss your website projectDefine the service behind the translated page
A translated enquiry page can create an expectation that the organisation can respond in that language. Confirm what the team can actually provide: sales conversations, proposals, customer support, documents or only selected public information. Make the boundary clear where it affects the reader’s next step.
Also distinguish language from location. A French-language page does not necessarily describe a service delivered in France. An Australian organisation may serve people who prefer another language while retaining the same service area, currency and contract conditions.
Write down which facts vary between versions. Contact details, service availability, downloadable documents and examples may need deliberate localisation. A literal translation of the English page can leave those practical questions unresolved.
Assign translation and approval ownership
Choose an accountable owner for each language. They should be able to confirm meaning, terminology and suitability for the intended audience. For specialist services, a fluent speaker may still need subject-matter review to preserve technical distinctions.
Create a small terminology list before translating the whole website. Include service names, product names, regulated terms, button labels and words the organisation deliberately avoids. Record when a brand name remains unchanged and how abbreviations should appear.
If translation software is part of the workflow, define what must be reviewed before publication. The production method does not remove responsibility for accuracy. Check complete pages, including forms, confirmation messages, navigation, image text and attached documents.
Plan stable URLs and language relationships
Choose a URL structure that can be maintained consistently, such as language-specific folders, and map each translated page to its corresponding version. Decide what a language switcher should do when a page has no equivalent. Sending someone to an unrelated page without explanation can interrupt their task.
Google supports several ways to identify alternate language or regional pages, including hreflang annotations in HTML, HTTP headers or sitemaps. The implementation should describe the actual available versions. Have the developer validate the chosen method and the relationships between pages rather than treating a language-plugin setting as a complete check.
Keep the content accessible through ordinary links. Avoid a process that leaves a reader unable to reach their preferred version because their location or browser setting was interpreted incorrectly. Test the language selector and direct page URLs independently.
Use a two-language launch checklist
| Area | Check | Owner |
|---|---|---|
| Core pages | Scope, contact details and important conditions agree | Service lead and language reviewer |
| Navigation | Labels fit the layout and links reach the corresponding page | Designer and developer |
| Forms | Labels, errors, confirmation and recipient routing are checked | Operations and developer |
| Search setup | URL mapping and language annotations describe the real versions | Developer or SEO lead |
| Documents and images | Downloads, captions and embedded text are reviewed | Content owner |
| Support | The response language and available assistance are clear | Customer-facing team |
Test with realistic content lengths. A heading or button that fits in one language may need more room in another. Check mobile navigation, form labels and tables using the translated text, rather than placeholder strings.
Ask a reviewer to complete a task from start to finish: find a service, read the relevant conditions, submit a test enquiry and understand the confirmation. This can reveal gaps between translated pages and the systems behind them.
Build the update process before launch
When a service changes, both versions need attention. Add language-review tasks to the same content register used for the original page. Record which version is approved, which is awaiting translation and whether the old information can remain public while the update is prepared.
Prioritise material that affects a decision, such as service availability, fees where published, contact details and conditions. A translated page that no longer reflects the offer can create avoidable confusion. Give the team a way to withdraw or qualify an outdated page while it is reviewed.
Start with a scope the organisation can sustain. A smaller complete journey can be more useful than a large collection of translated introductions with untranslated forms and support documents. The launch plan should describe both the pages and the ongoing work needed to keep them dependable.
If another language is part of your next website project, include translation ownership and ongoing updates in the brief, alongside design and development.
