Wielojęzyczność WordPress - jak stwórzyć stronę w wielu językach

Do obsługi wielu języków na WordPress masz trzy drogi, ale w praktyce realnie wybiera się między dwiema. Multisite (osobna instalacja na każdy język) daje maksymalną separację, lecz mnoży nakład pracy – aktualizujesz każdą witrynę osobno, a treści nie łączą się ze sobą automatycznie. Dziś używa się go rzadko, głównie w dużych korporacyjnych strukturach z osobnymi zespołami na każdy kraj.

Standardem są wtyczki wielojęzyczne: jedna instalacja, wiele wersji językowych powiązanych ze sobą, automatyczny przełącznik języka. Trzecia opcja – tłumaczenie maszynowe doklejone przez JavaScript (typu widżet Google Translate) – nie tworzy realnych, indeksowalnych wersji językowych i dla pozycjonowania jest bezwartościowa.

Dla większości firm pierwszy rząd tej tabeli to właściwy wybór. Resztę artykułu poświęcamy więc wtyczkom i temu, co naprawdę decyduje o sukcesie wdrożenia.

Struktura adresów to decyzja, którą podejmujesz raz i trudno ją później cofnąć bez przekierowań, dlatego warto ją przemyśleć przed instalacją wtyczki. Masz trzy warianty i każdy inaczej rozkłada autorytet domeny oraz koszty utrzymania.

W naszych wdrożeniach domyślnie rekomendujemy podkatalogi (example.com/en/). Cały zgromadzony autorytet domeny pracuje wtedy na wszystkie wersje językowe, konfiguracja jest najprostsza, a wtyczki takie jak WPML i Polylang używają tego modelu domyślnie. Osobne domeny krajowe (.de, .fr) mają sens dopiero, gdy budujesz osobne marki na różnych rynkach albo masz zespół i budżet, by pozycjonować każdą domenę niezależnie.

Nie ma jednej najlepszej wtyczki – jest najlepsza do konkretnego projektu. Różnią się modelem cenowym, sposobem tłumaczenia i tym, jak głęboko sięgają w strukturę witryny.

WPML to weteran rynku i najbardziej kompletne narzędzie. Tłumaczy wszystko: treści, wtyczki, motywy, widżety, a String Translation łapie nawet teksty zaszyte w kodzie. Ma Translation Management do zlecania pracy tłumaczom oraz integracje z większością wtyczek premium. Cena (orientacyjnie od kilkudziesięciu do ok. 159 € rocznie za pełny pakiet CMS) i pewien narzut wydajnościowy to koszt tej kompletności.

Polylang ma sensowną wersję darmową – tłumaczy posty, strony, kategorie, tagi i dodaje hreflang. Wersja Pro odblokowuje tłumaczenie menu, widżetów i lepsze SEO. To dobry wybór na mniejsze witryny i start bez budżetu. Uwaga: pełna obsługa WooCommerce wymaga osobnej płatnej wtyczki Polylang for WooCommerce.

TranslatePress stawia na prostotę – tłumaczysz wizualnie, klikając elementy bezpośrednio na podglądzie strony, bez tabel i paneli. Idealne, gdy klient ma tłumaczyć treści samodzielnie. Wersja darmowa obsługuje dwa języki; Pro znosi limit i dodaje tłumaczenie maszynowe oraz WooCommerce.

Perspektywa KC Mobile: w naszych wdrożeniach widzimy, że najwięcej problemów nie bierze się z wyboru wtyczki, lecz ze zmiany wtyczki w trakcie życia strony. Migracja tłumaczeń między WPML a Polylang to żmudna, ręczna robota i częste źródło utraty treści. Dlatego decyzję o wtyczce traktujemy jak decyzję architektoniczną – podejmujemy ją na starcie projektu strony internetowej, nie po fakcie, gdy strona ma już setki podstron w jednym języku.

SEO to miejsce, w którym wielojęzyczne wdrożenia najczęściej się sypią – i to nie z powodu treści, tylko źle ustawionych sygnałów technicznych. Filar to atrybut hreflang, który mówi Google, że dana podstrona ma odpowiedniki w innych językach (np. wersja polska wskazuje na angielską i odwrotnie). Wtyczki dodają go automatycznie, ale obowiązkowo zweryfikuj poprawność – w Screaming Frog lub Ahrefs sprawdź, czy linki hreflang są wzajemne (jeśli A wskazuje na B, B musi wskazywać na A) i czy używają poprawnych kodów języka.

Drugi częsty błąd to canonical. Każda wersja językowa musi mieć własny tag canonical wskazujący na samą siebie – nigdy na wersję traktowaną jako główna. Ustawienie canonicala wszystkich wersji na stronę polską wyrzuca pozostałe języki z indeksu, co jest jednym z najczęstszych powodów, dla których przetłumaczona strona nie pozyskuje ruchu z zagranicy.

Do tego dochodzą szczegóły, które robią różnicę:
- Przetłumacz meta title i meta description – to one decydują o klikalności w obcojęzycznym SERP.
- Przetłumacz slug URL na czytelny w danym języku (zamiast /pl/o-nas/ daj /en/about-us/), ale bez polskich znaków diakrytycznych w adresie.
- Nie mieszaj dwóch języków na jednej podstronie – Google nie wie wtedy, dla jakiego rynku ją wyświetlić.
- Dodaj wszystkie wersje językowe do Google Search Console i prześlij sitemapę obejmującą każdą z nich.

Information Gain, który rzadko pada w poradnikach: hreflang to podpowiedź dla rankingu, nie gwarancja indeksacji. Jeśli wersja angielska jest słabej jakości (np. surowy maszynowy przekład), Google i tak może ją zignorować mimo poprawnego hreflang. Sygnał techniczny nie naprawi słabej treści.

Tłumaczenie maszynowe i ludzkie to nie wojna, tylko podział pracy według wagi treści. Mechaniczne potraktowanie całej witryny jednym przebiegiem DeepL kończy się tekstem, który technicznie jest po angielsku, ale brzmi obco dla rodzimego odbiorcy – a to ten odbiorca ma kliknąć w przycisk zakupu.

Rozsądny podział wygląda tak:
- Treści ofertowe, opisy produktów, strona główna, hasła reklamowe – tłumaczenie ludzkie albo maszynowe z obowiązkową korektą native speakera. Tu liczy się ton i perswazja.
- Treści informacyjne, dokumentacja, FAQ, regulaminy – tłumaczenie maszynowe z lekką korektą zwykle wystarcza.
- Teksty systemowe interfejsu (przyciski, komunikaty koszyka) – gotowe pliki językowe motywu/wtyczki, nie tłumaczysz ich ręcznie.

Wśród silników maszynowych DeepL daje wyraźnie lepsze wyniki niż Google Translate dla języków europejskich – mniej kalek i naturalniejszą składnię. Najlepszy stosunek kosztu do jakości to model hybrydowy: maszyna robi pierwszy przebieg, człowiek poprawia. Sam koszt wdrożenia rośnie zresztą nieproporcjonalnie do liczby języków – drugi język to nie 50% więcej pracy, bo dochodzi konfiguracja struktury, hreflang, przełącznika i testów, którą wykonujesz raz.

Każda wersja językowa to dodatkowe zapytania do bazy i więcej danych do przetworzenia przy każdym ładowaniu strony, więc wielojęzyczność realnie obciąża wydajność – szczególnie przy ciężkich wtyczkach. WPML bywa zasobożerne na dużych serwisach, dlatego sensowny hosting i cache nie są opcją, lecz wymogiem.

Konkretne kroki, które stosujemy, by utrzymać szybkość:
- Cache stron (np. obiektowy Redis + cache pełnych stron) skonfigurowany tak, by poprawnie rozróżniał wersje językowe.
- Ograniczenie liczby aktywnych wtyczek – im więcej dodatków musi obsłużyć tłumaczenie, tym większy narzut.
- Polylang jako lżejsza alternatywa tam, gdzie nie potrzeba pełnego workflow WPML.
- Regularna kontrola Core Web Vitals osobno dla każdej wersji językowej, bo problem może dotyczyć tylko jednej z nich.

Kwestia, o której łatwo zapomnieć: wielojęzyczna strona wymaga też podwójnej dyscypliny przy utrzymaniu. Każdą aktualizację treści, każdą zmianę oferty i każdą poprawkę bezpieczeństwa wykonujesz świadomie we wszystkich językach. Strona z aktualną wersją polską i zapomnianą, nieaktualną angielską szkodzi wizerunkowi bardziej, niż gdyby angielskiej w ogóle nie było.

Wielojęzyczność to nie tylko teksty wpisów i stron. Najwięcej niedoróbek widać w elementach, które łatwo przeoczyć, bo nie widać ich w głównej kolumnie treści, a użytkownik i tak na nie trafia.

Lista elementów, które trzeba świadomie przetłumaczyć:
- Menu nawigacji – w Polylang Free menu nie tłumaczy się automatycznie, potrzebujesz wersji Pro lub osobnego menu na język.
- Widżety i stopka – dane kontaktowe, polityka prywatności, teksty newslettera.
- Teksty systemowe (String Translation w WPML) – komunikaty formularzy, etykiety przycisków, teksty wtyczki cookie.
- Przełącznik języka – musi być widoczny i czytelny; flagi bywają mylące (flaga to nie język), więc lepsze są nazwy języków lub kody (PL/EN/DE).
- Dane lokalne per rynek – adres, numer telefonu czy waluta powinny odpowiadać krajowi danej wersji, a nie być żywcem skopiowane z polskiej.
- Obrazy z tekstem – grafiki z napisami trzeba przygotować osobno dla każdego języka, bo wtyczka nie podmieni tekstu wtopionego w plik.

Pominięcie choćby jednego z tych elementów sprawia, że strona wygląda na niedokończoną – użytkownik klika angielski przełącznik, a po chwili trafia na polski formularz kontaktowy i traci zaufanie.

Wdrożenie wielojęzyczności – wybór wtyczki, struktury URL, konfiguracja hreflang i optymalizacja wydajności – wymaga doświadczenia i czasu. Jeśli wolisz, by zajęli się tym specjaliści, sprawdź naszą ofertę WordPress.

Możesz też napisać do nas bezpośrednio – umów bezpłatną konsultację, a my przeanalizujemy Twoją sytuację i zaproponujemy najlepsze rozwiązanie dla Twoich rynków.