Wielojęzyczność to problem techniczny, nie językowy

Większość firm podchodzi do strony wielojęzycznej jak do zadania tłumaczeniowego: wziąć treści, przetłumaczyć, opublikować pod przełącznikiem języków. Sama część tłumaczeniowa zwykle wychodzi dobrze. Strona i tak nie dowozi, a powód prawie nigdy nie leży w słowach.

O wyniku decyduje to, jak wyszukiwarkom komunikuje się, która wersja należy do której grupy odbiorców. To konfiguracja hreflang i adresów kanonicznych, i łatwo zrobić ją subtelnie źle — wersje zostają odczytane jako duplikaty, sygnał rankingowy się rozprasza, a każda wersja radzi sobie gorzej, niż poradziłaby sobie strona jednojęzyczna. To najczęstszy scenariusz porażki i jest niewidoczny: nic nie wygląda na zepsute, ruch po prostu nie przychodzi.

Druga decyzja jest strukturalna. Rynki nie formułują rzeczy identycznie, a dosłowne tłumaczenie celuje we frazy, których w danym kraju nikt nie wpisuje w wyszukiwarkę. Analizę słów kluczowych trzeba zrobić osobno dla każdego języka, a struktura podstron musi za nią pójść. Czasem oznacza to, że dany rynek potrzebuje podstrony, której w języku oryginału w ogóle nie ma.

Trzecia to kruchość. Routing wersji łatwo psuje się przy przebudowach i migracjach — wersje zamieniają się miejscami, przekierowania znikają, hreflang wskazuje na stare adresy. Naprawiałem dokładnie taki przypadek u klienta, któremu wersje językowe zamieniły się przy redesignie generowanym przez AI: ruch spadł w dwa dni i wracał ponad miesiąc po poprawkach.

Zrobione porządnie, daje prosty efekt. Katalog nieruchomości, który zbudowałem, działa w czterech językach, przynosi ponad 1500 wizyt z organiku miesięcznie bez budżetu reklamowego, a jego klienci pochodzą z ponad dwudziestu krajów — bo każda wersja została zbudowana, żeby działać na swoim rynku, a nie odbijać oryginał.