Translating a website: method and pitfalls to avoid

Take a site translated into German in a few days. The pages are there, and so is the menu. Then a visitor fills in the contact form and receives their confirmation in French, mistypes a URL and lands on an error page that does not speak their language; in Google’s results, the page title has stayed in French. None of these mistakes shows up when you review the pages: translating a website means translating everything the visitor reads, at URLs specific to each language.

This guide brings together the decisions to make, from the URL to the review; the website translation section covers each one in a separate article.

A word on where we stand: we run Palmora Property for a client, a property listings site with more than 3,000 URLs published in six languages (English, French, Thai, Russian, Chinese and German). We also publish this site, in French and English. The mistakes cited below were found on the former.

What should you decide before translating the first word?

Three decisions are made before opening a single translation file, because they are expensive to undo later.

The languages, in order. A language is opened for a market where demand exists, not to lengthen the list. Before translating the whole site, test demand on a few pages: we explain how to choose your markets, and between a domain per country, a subdomain or a subdirectory.

The shape of the URLs. It is decided before the catalogue grows: that is the subject of the next section.

Who reads each language. A language nobody reads in-house is published reviewed, by someone outside if need be. Otherwise, its mistakes stay online until a visitor reports them.

Why give each language its own URL?

Because that is what Google recommends, and what allows each version to be found:

The same page adds three recommendations. Do not automatically redirect a visitor from one language version to another. Stick to one language per page, with no side-by-side translations: Google determines a page’s language from its visible content. And offer links on every page to its other versions, so that everyone can choose their own.

Two tags then describe each version. First, the lang attribute: the W3C puts it bluntly, “Always use a language attribute on the html tag to declare the default language of the text in the page.” The declared language is used for speech synthesis and braille, font selection and spell checkers, according to the W3C.

Then hreflang tags link the versions together: each language version references itself and lists all the others, in the page code, in HTTP headers or in the sitemap, three methods Google treats as equivalent. The x-default value designates the page to show when no language matches. We cover them in detail in our guide to hreflang tags and their mistakes.

That leaves the shape of the URLs. Google’s page on multilingual sites accepts localised terms in the URL: /de/zu-verkaufen/ rather than /de/for-sale/. The choice is made early. On Palmora Property, some English articles kept French URLs: changing them would require one redirect per page, and a check of each, for a gain that does not justify it.

What needs translating beyond the pages?

Everything the visitor reads, including what they do not see while browsing the site:

Templates need the same attention as pages. A title assembled from pieces translated one by one comes out wrong in the target language: that is how a Palmora Property listing page ended up titled “Villas Zu verkaufen” in German. You need a complete template per language, with singular, plural and agreement with the number, which takes three forms in Russian.

How do you keep the same vocabulary in every language?

The vocabulary is set before the first pass, not during review:

Keywords go in too, but they are not translated: you research them in each language, among the terms people in that country actually type, then the chosen term applies to every page, titles and descriptions included.

Next, a translation memory stores each approved sentence, segment by segment: at each update, only what has changed goes back for translation. On Palmora Property, after the first pass, 95% of segments are reused from the memory without a new call to the model; on a site whose text changes more, the reused share is lower. How it works and how to set it up are in our article on translation memory in business.

Who reviews what?

Reviewing takes someone who reads the language, and their time is limited: it goes first where a mistake costs the most. Offers, prices, terms and the pages that sell are reviewed in full, at every change. A repetitive product or listing page is approved via its template, reviewed in full in each language, then on a sample of pages.

This split has its limits: Google considers it essential to check any AI-generated content before publishing it, metadata included. A sample works for hundreds of similar pages, never for an offer or terms and conditions. The detail, page type by page type, is in our comparison between machine translation and reviewed translation.

Which checks should you run before publishing a language?

A language goes live when it passes six checks:

1. 01Every text exists in every language.

   A parity check verifies that no key is missing, like the one that runs before every build of Palmora Property.

2. 02The language is declared in every list in the code that enumerates languages.

   On Palmora Property, German was served on all its URLs, but missing from several of these lists: some pages displayed empty while returning 200, until they were fixed.

3. 03hreflang tags only point to pages that exist.

   A noindex page emits none.

4. 04The sitemap lists every version.

   Only those that exist: a version announced but missing is an error.

5. 05A wrong URL answers in the requested language.

   On Palmora Property, the 404 page displayed in English whatever the language of the URL, until it was fixed.

6. 06Forms and emails work end to end.

   In every language, from the click to the confirmation received.

The checklist for the tags themselves, in seven points, is in the hreflang guide cited above.

What does a site maintained in several languages cost?

The first pass is only part of the bill. An open language needs maintaining for as long as the site lives:

Two levers bring down the second column. The translation memory, seen above. And the choice of model, language by language: on Palmora Property, switching from DeepL to Gemini cut the translation cost by a factor of 60, a ratio specific to that site and its six languages. Before opening a language, count the second column as much as the first.

Where to start?

With a single language, and first the pages that sell: the home page, the offers, the contact form and its emails. Set the URLs and the glossary, pass the six checks, then open the language. Product pages and articles follow, once the template holds.

To find out which pages to translate first, and into which language, send us your site’s URL and the languages you are targeting: we start from what already sells in your language.

Frequently asked questions

Sources

1. The W3C puts it bluntly (new tab)w3.org
2. According to the W3C (new tab)w3.org
3. Each language version references itself and lists all the others (new tab)developers.google.com
4. Google considers it essential (new tab)developers.google.com