8 September 2026 · The AI Web Factory team

Translating your website: when it pays off and how to do it so it is worth something

Translating without changing the addresses is throwing money away: Google does not index what has no URL of its own. What we learned moving our websites to three languages.

Translating a website looks like a marketing decision but it is above all a technical one. It can be done well and multiply your visits. It can be done badly and bring in not a single one, however flawless the translation is.

The difference comes down to one thing: whether each language has its own address.

The mistake you pay for in full

There are websites where you change the language with a button, the content changes and the address in the browser stays the same. The language is stored in a cookie.

For the person browsing, it works. For Google, the translated versions do not exist. There is no address to index, so that translation never appears in any search. You have paid for work that will not bring in a single visit.

And there is a second effect you notice sooner: if you share a link on WhatsApp with a Catalan client, it opens in whatever language they have stored in their cookie, not in the one you sent.

One of our websites, Gest Peritia, was like this until September 2026. That is exactly why we migrated it.

What the addresses have to look like

The rule we follow across the whole group is this: the main language lives at the root with no prefix and the others carry their own.

/precios          → español
/ca/precios       → catalán
/en/precios       → inglés

Spanish without a prefix is not a whim. Its addresses are the ones that have been ranking for years. Moving them to /es/precios would throw that ranking down the drain for nothing.

The three tags that make it work

With separate addresses the three versions can now be indexed. What is left is telling Google they are the same page in different languages. That is done with three things in the <head>.

The hreflang tags for all three languages, on every version. Each page declares where its siblings are.

The x-default, which points to the version served to anyone who does not match any of the languages. In our case, always the Spanish one.

And each version’s canonical pointing to itself. This is the most expensive mistake and the easiest to make: pointing the Catalan canonical to the Spanish page tells Google not to index the Catalan one. It is exactly the opposite of what you want: the translation stays just as invisible as before.

There is one more condition hardly anyone checks: hreflang tags have to be reciprocal. If the Spanish page says the Catalan one is its Catalan version, the Catalan page has to say the same thing back. When they do not match, Google discards the whole group. A single wrong page leaves its three versions unlinked.

The sitemap has to say it too

Besides the tags on each page, the sitemap should announce the three versions of each address with their xhtml:link tags. It is redundant on purpose: that way Google discovers the translations even if it has not yet got round to crawling every page.

We checked our own websites and found that one had it and another did not. The one without it had spent months listing the addresses separately, with no relationship between them. It takes three lines of configuration.

And what about the visitor

Two rules we always apply.

Automatic detection only kicks in on the first visit. If someone picks a language by hand, that choice rules from then on. It is not overwritten every time they come back.

Search engines are never redirected. If you redirect Google based on the language of its request, it cannot request each version separately and all the hreflang work comes to nothing.

A common-sense detail we missed at first: a visitor whose system is set to Basque or Galician should be served Spanish, not English. They are a speaker from Spain. It seems obvious written down here. It is not when you are coding the detection by looking at a list of language codes.

When it is not worth it

If you sell in-person services in one local area and your customers speak Spanish and Catalan, translating into English will not bring you work. It will bring you visits that do not buy, which makes your numbers worse without improving your turnover.

Translating makes sense when there is real demand in that language, when you can serve customers in it and when you are going to keep the translations up to date. An English version frozen as the website was two years ago is worse than not having one.

And there is a cost nobody calculates at the start: every new page is three pages. Every price correction, three corrections. If there is no one to keep it going, the versions drift out of sync within six months.

How we keep an eye on it

With an automatic check that runs before publishing. It verifies that the three versions have the same pages, that each one declares its language, that the hreflang and x-default tags are there, that the canonicals point to themselves, that there is reciprocity and that the sitemap announces all three.

It takes two seconds. It prevents the kind of failure that, without it, you discover six months later while wondering why the Catalan version gets no visits.

If you are thinking of translating your website and want to know whether it is worth it, write to us and we will look at it together. Sometimes the answer is no.

#languages#seo#web#hreflang

← Back to the blog