Wielojęzyczny WordPress w 2026: WPML, Polylang, MultilingualPress i headless

#Wielojęzyczny WordPress w 2026: WPML, Polylang, MultilingualPress i headless

Wielojęzyczny WordPress to jedno z tych pytań, na które odpowiedź “to zależy” jest uczciwa i przydatna. W 2026 roku działają obok siebie cztery sprawdzone strategie, a każda inaczej rozkłada akcenty między wygodą redakcji, SEO, wydajnością i kosztami utrzymania. Ten przewodnik dobiera właściwą strategię do najczęstszych profili zamawiających i pokazuje, co się psuje, gdy wybór jest zły.

Artykuł łączy się z filarem usług headless WordPress dla sytuacji, w których o wyborze decydują SEO i Core Web Vitals.

#Wielojęzyczny WordPress w 2026 w skrócie

• Polylang Pro: bezpieczny wybór domyślny dla redakcyjnego WordPressa na jednej instalacji, z małym lub średnim zespołem.
• WPML: standard dla sklepów WooCommerce ze złożonym procesem tłumaczeń.
• MultilingualPress: pasuje do sieci Multisite, w których każdy język jest osobną witryną.
• Headless na Astro 5+ lub Next.js 15: najlepszy, gdy kontrola nad SEO i wydajność liczą się bardziej niż wygoda redakcji.
• Wszystkie cztery wymagają poprawnego hreflang, osobnych map witryny dla języków i czystej struktury adresów.

#Co WordPress robi z wieloma językami bez wtyczki

Rdzeń WordPressa tłumaczy interfejs, a nie treść. Świeża instalacja działa w jednym języku witryny, wybranym w ustawieniach ogólnych, a rdzeń pobiera pasujące paczki językowe z translate.wordpress.org dla siebie oraz dla wtyczek i motywów z katalogu WordPress.org.

Od WordPressa 4.7 każdy użytkownik może wybrać w profilu własny język kokpitu. Rdzeń zapisuje go w metadanych użytkownika pod kluczem locale, a gdy pole jest puste, używa języka witryny (make.wordpress.org/core, 2016). To samo wydanie dodało switch_to_locale() i restore_previous_locale(), z których wtyczki korzystają, żeby wysłać e-mail w języku odbiorcy, a nie w języku żądania, które go wywołało.

WordPress 6.5 wymienił mechanizm wczytywania tłumaczeń. Paczki językowe z WordPress.org zawierają teraz pliki .l10n.php obok .mo i .po, a gdy istnieją oba, rdzeń wczytuje plik PHP, który OPcache może trzymać w pamięci. Witryny z samymi plikami .mo działają dalej, a filtr translation_file_format zwracający 'mo' wyłącza pliki PHP (make.wordpress.org/core, 2024). Komercyjne wtyczki spoza WordPress.org muszą wygenerować pliki PHP same, na przykład poleceniem wp i18n make-php z WP-CLI 2.10.

Rdzeń nie ma za to powiązania między dwoma wpisami, które mówią to samo w dwóch językach. Roadmapa WordPressa wymienia witryny wielojęzyczne jako 4. fazę projektu Gutenberg, po edycji, personalizacji i współpracy, bez daty wydania (roadmapa WordPressa). Dopóki ta faza nie wejdzie do rdzenia, każda z poniższych strategii dodaje tłumaczenie treści przez wtyczkę, sieć Multisite albo osobny front end.

#Jakie są cztery strategie wielojęzycznego WordPressa

#1. Polylang (Pro) na pojedynczej witrynie WordPress

Jak to działa: każdy wpis, strona, taksonomia i pozycja menu istnieje raz na każdy język w ramach jednej instalacji WordPressa. Wtyczka łączy ze sobą odpowiadające sobie wpisy. Edytor blokowy pokazuje przełącznik języka, a redaktorzy tłumaczą w tym samym kokpicie.

Kiedy wybrać:

• Zespół jest mały lub średni, a proces redakcyjny prosty.
• Witryna ma do kilkunastu języków o wspólnej strukturze.
• Budżet na hosting jest skromny: jedna instalacja WordPressa jest wyraźnie tańsza niż Multisite.
• WooCommerce nie ma albo odgrywa niewielką rolę.

Kompromisy: WPML ma nieco bardziej dopracowany interfejs dla redaktorów, którzy często przełączają języki. Polylang Pro sprawia mniej problemów ze zgodnością motywów i wtyczek poza ekosystemem WooCommerce.

Co obejmuje wersja darmowa, a co Pro, według karty Polylang w katalogu WordPress.org: wersja darmowa tłumaczy wpisy, strony, media, kategorie, tagi, własne typy treści i taksonomie, a język odczytuje z kodu w adresie URL, z subdomeny albo z osobnej domeny. Pro dodaje duplikowanie i synchronizację treści między tłumaczeniami, tłumaczone slugi w adresach URL, tłumaczenie maszynowe przez DeepL oraz eksport i import XLIFF dla zewnętrznych tłumaczy. WooCommerce wymaga osobnego dodatku Polylang for WooCommerce, który tłumaczy stronę sklepu, koszyk, zamówienie i konto klienta oraz wysyła e-maile WooCommerce w języku klienta.

#2. WPML na pojedynczej witrynie WordPress

Jak to działa: model architektury podobny do Polylanga (jedna witryna, wiele wersji językowych), ale z rozbudowaną warstwą zarządzania tłumaczeniami: pamięcią tłumaczeniową, integracją z profesjonalnymi tłumaczami i głębszą integracją z WooCommerce.

Kiedy wybrać:

• Witryna to sklep WooCommerce z tłumaczonymi produktami, kategoriami, atrybutami i tekstami w procesie zamówienia.
• Zespół korzysta z zewnętrznych biur tłumaczeń przez system zarządzania tłumaczeniami (TMS).
• Wtyczki, od których zależy witryna, wymieniają WPML jako oficjalnie wspieranego partnera.

Kompromisy: licencja WPML jest płatna, a progi zależą od liczby witryn. Niektóre wydania WordPressa i WooCommerce w przeszłości powodowały tarcia; opóźnienia WPML w dostosowaniu się do nich są realne, ale zwykle krótkie.

#3. MultilingualPress na WordPress Multisite

Jak to działa: każdy język to osobna witryna w sieci Multisite. MultilingualPress łączy wpisy między witrynami i daje redakcji przełącznik. Architektura to “jedna sieć, wiele witryn”, a nie “jedna witryna, wiele języków”.

Kiedy wybrać:

• Wersje językowe działają operacyjnie osobno: oddzielne zespoły redakcyjne, oddzielne harmonogramy publikacji, oddzielne zestawy wtyczek.
• Powody marki lub prawne wymagają widocznego rozdzielenia witryn językowych (różne domeny, różny branding).
• Wydajność każdej wersji językowej ma znaczenie i odizolowanie wtyczek jednego języka od pozostałych pomaga.

Kompromisy: Multisite to cięższy model utrzymania. Zgodnych wtyczek jest mniej. Wyszukiwanie i raportowanie między witrynami wymaga dodatkowej pracy.

#4. Headless WordPress z Astro 5+ lub Next.js 15

Jak to działa: WordPress (z Polylangiem lub WPML do tworzenia treści) staje się zapleczem. Publiczną witrynę renderuje Astro lub Next.js, pobierając treści w danym języku przez WordPress REST API lub WPGraphQL. Za hreflang, mapę witryny, dane strukturalne i cache na brzegu odpowiada front end.

Kiedy wybrać:

• SEO i Core Web Vitals bezpośrednio wpływają na przychód (e-commerce, pozyskiwanie leadów, branże regulowane).
• Treść trafia nie tylko na stronę WWW (aplikacja mobilna, powierzchnie agentów AI, syndykacja).
• Zamawiający chce mieć pełną kontrolę nad strukturą adresów dla każdego języka, cache na brzegu i dokładnością hreflang.
• Jurysdykcja UE nie podlega negocjacjom; standardowy wzorzec to Cloudflare Workers + źródłowy WordPress hostowany w UE.

Kompromisy: redakcja pracuje z lekkim pośrednictwem (podgląd działa przez osobną domenę). Trzeba utrzymywać dwa stosy. Przewagi architektoniczne narastają przez kolejne pięć lat, a koszt widać w pierwszych sześciu miesiącach.

Tę ścieżkę szczegółowo opisuje filar usług headless WordPress.

#Jak wybrać strategię wielojęzycznego WordPressa

#Jak Polylang i WPML przechowują tłumaczenia w bazie danych

Model zapisu decyduje o tym, jak trudna będzie późniejsza migracja, własne zapytanie albo eksport do headless.

Polylang korzysta z taksonomii rdzenia WordPressa. Kod wtyczki rejestruje cztery: language i term_language przechowują język wpisu albo terminu, a post_translations i term_translations grupują elementy, które są swoimi tłumaczeniami. Wpis po niemiecku to zwykły wpis z przypiętym terminem language, więc WP_Query, eksporty i kopie zapasowe widzą standardowe dane WordPressa.

WPML trzyma dane we własnych tabelach. Języki i powiązania tłumaczeń są w icl_translations: element_id to ID wpisu albo term_taxonomy_id, element_type określa rodzaj obiektu, trid grupuje elementy będące swoimi tłumaczeniami, language_code to język elementu, a source_language_code jest pusty dla oryginału (tabele bazy danych WPML). Teksty spoza wpisów, takie jak opis witryny, trafiają do icl_strings i icl_string_translations, a zlecenia tłumaczeń do icl_translate_job i powiązanych tabel. Własne zapytanie albo skrypt migracyjny musi łączyć te tabele, bo sama tabela wpisów nie mówi, w jakim języku jest dany wpis.

#Jak przenieść witrynę z WPML na Polylang

W tę stronę istnieje dedykowane narzędzie. WPML to Polylang, utrzymywane przez twórców Polylang, importuje języki, języki i tłumaczenia wpisów oraz terminów (także własnych typów treści i taksonomii), wielojęzyczne menu, tłumaczenia tekstów i ustawienia tłumaczenia pól ACF. Nie usuwa danych WPML. Kolejność z dokumentacji: kopia zapasowa bazy, dezaktywacja WPML, aktywacja Polylang i importera bez tworzenia żadnego języka w Polylang, uruchomienie importu z ekranu importera w menu narzędzi, a na końcu dodanie przełącznika języków. Importer nie ma własnej obsługi błędów, a jego autorzy podają udany test na witrynie z około 9000 wpisów i plików mediów. Linki, przekierowania i integracje wtyczek trzeba potem sprawdzić ręcznie, dlatego zmianę wtyczki planuje się przed startem, a nie po nim.

#Jak skonfigurować WordPress Multisite dla sieci witryn językowych

MultilingualPress działa na sieci Multisite, więc najpierw zapadają decyzje dotyczące sieci. Multisite włącza się wpisem define( 'WP_ALLOW_MULTISITE', true ); w wp-config.php, który odblokowuje ekran konfiguracji sieci. Ten ekran pyta o subdomeny albo podkatalogi. Dokumentacja WordPressa mówi, że po instalacji można przestawić sieć na drugi wariant, ale może to nie być łatwe (tworzenie sieci). Strukturę zgodną z planem adresów URL dla języków wybiera się przed utworzeniem pierwszej podwitryny.

Osobne domeny dla języków nie wymagają wtyczki. Mapowanie domen jest wbudowane od WordPressa 4.5: administrator sieci edytuje podwitrynę i wpisuje pełną domenę, razem ze schematem, jako jej adres. Każda dodatkowa domena musi w DNS wskazywać na sieć, każda potrzebuje certyfikatu SSL (SNI obsługuje kilka domen na jednym serwerze), a logowanie, które po cichu nie działa na zmapowanej podwitrynie, zwykle naprawia define( 'COOKIE_DOMAIN', $_SERVER['HTTP_HOST'] ); w wp-config.php (mapowanie domen w Multisite).

#Jak pobierać przetłumaczone treści w headless WordPressie

Front end headless musi pobrać z WordPressa treść w jednym języku i ID jej tłumaczeń, bo sam buduje zestaw hreflang i przełącznik języków.

Z Polylang działa to przez REST API, ale tylko w Polylang Pro. GET /wp/v2/posts?lang=fr zwraca wpisy po francusku, a wpisy i terminy dostają dwa dodatkowe pola: lang z kodem języka i translations, obiekt, który przypisuje kodom języków ID przetłumaczonych elementów (REST API Polylang).

Z WPML udokumentowaną drogą jest GraphQL. Dodatek WPML GraphQL wymaga WPGraphQL, WPML i WPML String Translation. Dodaje argument language do zapytań o listy (where: { language: "de" } albo "all" dla wszystkich języków) oraz pole translations przy wpisach i terminach, więc jedno zapytanie zwraca stronę razem z jej wersjami językowymi (WPML GraphQL). Menu i strony opcji ACF przyjmują ten sam argument.

W obu przypadkach front end przejmuje to, co wcześniej wypisywała wtyczka: hreflang zbudowany z pola translations, jeden wpis w mapie witryny na język i przetłumaczone metadane. Struktury adresów URL, zasady hreflang Google i systemy zarządzania tłumaczeniami opisuje przewodnik po globalnej strategii treści, więc ten artykuł ich nie powtarza.

#Hreflang, mapy witryny, adresy URL i metadane w wielojęzycznym WordPressie

Pięć elementów, które każda strategia wielojęzycznego WordPressa musi wdrożyć poprawnie:

Znaczniki hreflang. Każda strona musi deklarować swoje odpowiedniki w innych językach, wpis wskazujący na samą siebie i x-default. Testuj prawdziwymi narzędziami (Sitebulb, Screaming Frog albo własny crawler).

Mapa witryny dla każdego języka. Yoast, Rank Math i front endy headless obsługują generowanie map witryny dla poszczególnych języków. Sprawdź wynik ręcznie, zanim zgłosisz go w Google Search Console.

Czysta struktura adresów. Konsekwentnie używaj podkatalogów (/en/, /de/) albo subdomen (en.example.com). Parametry w adresie (?lang=en) to w 2026 roku antywzorzec, który powoduje problemy z indeksowaniem.

Przetłumaczone dane strukturalne. Bloki JSON-LD Schema.org potrzebują przetłumaczonych name, description i inLanguage na każdej stronie. Automatyczne tłumaczenie danych strukturalnych to częsta, cicha awaria.

Przetłumaczone metadane. Tytuł SEO, opis meta, tytuły Open Graph i karty Twittera tłumaczy się niezależnie od treści. Polylang i WPML to obsługują; front endy headless wymagają osobnych szablonów dla każdego języka.

#Jakich błędów unikać w wielojęzycznym WordPressie

Trzy wzorce, które psują wielojęzycznego WordPressa na produkcji:

Zmiana strategii w trakcie projektu. Start z Polylangiem i przejście na WPML (albo odwrotnie) zwykle oznacza przepisywanie linków, przekierowań i integracji z wtyczkami. Wybierz raz, po dokładnej analizie, zanim zaczniesz skalować.

Automatyczne tłumaczenie jako jedyny proces tłumaczeń. Tekst redakcyjny z maszyny czyta się jak tekst z maszyny. Tłumaczenia maszynowego używaj tylko do pierwszych wersji roboczych; wersję publiczną sprawdza native speaker.

Ignorowanie indeksu wyszukiwarki. Witryna wielojęzyczna ma N razy więcej adresów URL. Problemy z indeksowaniem się kumulują. Przeglądaj Search Console co tydzień przez pierwsze trzy miesiące po starcie i ponownie po każdej większej aktualizacji wtyczki lub motywu.

#Którą strategię wielojęzycznego WordPressa wybrać dla jakiej witryny

Dla redakcyjnego WordPressa na jednej instalacji w 2026 roku: Polylang Pro to właściwy punkt wyjścia, chyba że WooCommerce albo wymogi zgodności kierują cię gdzie indziej.

Dla sklepu WooCommerce: właściwym punktem wyjścia jest WPML.

Dla sieci wielu marek lub regionów: MultilingualPress na Multisite.

Dla witryny krytycznej wydajnościowo lub regulowanej: headless na Astro albo Next.js, z WordPressem jako zapleczem redakcyjnym. Szczegóły architektury opisują filar usług headless WordPress oraz przewodnik po Cloudflare Workers i WordPressie na brzegu sieci.

#Powiązane poradniki o wielojęzycznym WordPressie

• Filar usług headless WordPress
• Cloudflare Workers i WordPress na brzegu sieci
• Tech Radar Q4 2026: werdykty dla stosu