Wielojęzyczny sklep WooCommerce: WPML czy Polylang? Praktyczny przewodnik

Dodanie przełącznika „PL / EN / DE" nie wystarczy, aby sklep stał się wielojęzyczny. Trzeba jeszcze przetłumaczyć produkty, warianty, kategorie, filtry, koszyk, e-maile, regulaminy i komunikaty generowane przez wtyczki.

Do tego dochodzą ceny, waluty, podatki, dostawy i płatności. Niemiecka wersja sklepu może być poprawnie przetłumaczona, ale nadal nie sprzedawać, jeżeli pokazuje ceny w złotówkach, polskie metody dostawy i regulamin niedostosowany do rynku.

Najczęściej wybór sprowadza się do dwóch rozwiązań: WPML oraz Polylang. Oba pozwalają prowadzić kilka wersji językowych WooCommerce, ale różnią się sposobem obsługi tłumaczeń, automatyzacją, walutami i zakresem gotowych integracji.

W tym poradniku porównujemy je bez wskazywania jednego zwycięzcy dla wszystkich sklepów. Pokazujemy, kiedy lepiej sprawdzi się WPML, kiedy Polylang oraz co trzeba przygotować, aby wielojęzyczny WooCommerce nie stworzył problemów z SEO, produktami i zamówieniami.

W skrócie (TL;DR)

• WPML częściej sprawdza się w rozbudowanych sklepach, które potrzebują centralnego panelu tłumaczeń, automatyzacji, wielu walut i szerokich integracji.
• Polylang daje bardziej bezpośredni sposób zarządzania wersjami językowymi i może być dobrym wyborem dla prostszego procesu tłumaczeń.
• Darmowy Polylang nie zapewnia pełnej obsługi WooCommerce. Potrzebny jest dodatek Polylang for WooCommerce.
• Polylang Pro obsługuje automatyczne tłumaczenie przez DeepL, ale nie tłumaczy całego sklepu jednym kliknięciem.
• WPML ma własny moduł obsługi wielu walut. Przy Polylang trzeba dobrać osobne rozwiązanie multicurrency.
• Obie wtyczki mogą działać poprawnie pod SEO. Wynik zależy od adresów, hreflang, canonicali, jakości tłumaczeń i linkowania.
• Przed wyborem sprawdź zgodność z płatnościami, dostawami, fakturami, ERP, feedem produktowym i motywem.
• Najpierw przetestuj jeden język i małą grupę produktów. Dopiero później rozszerzaj wdrożenie.

Co naprawdę oznacza wielojęzyczny sklep WooCommerce?

Wielojęzyczny WooCommerce to kilka połączonych wersji produktów i całej ścieżki zakupowej, a nie tylko przetłumaczony opis.

Klient powinien móc w wybranym języku wejść na kategorię, użyć filtrów, otworzyć produkt, wybrać wariant, dodać produkt do koszyka, wybrać dostawę, przejść do płatności, otrzymać potwierdzenie zamówienia, przeczytać zasady zwrotu i skontaktować się z obsługą. Jeżeli karta produktu jest po niemiecku, ale komunikat błędu w kasie pojawia się po polsku, wdrożenie nie jest jeszcze zakończone.

Do przetłumaczenia mogą być: nazwy i opisy produktów, krótkie opisy, kategorie i podkategorie, tagi, atrybuty, nazwy wariantów, menu, przyciski, komunikaty WooCommerce, koszyk i checkout, e-maile transakcyjne, metody dostawy, nazwy płatności, formularze, regulaminy, polityki prywatności, bannery, stopka, meta title i meta description oraz adresy URL. Trzeba też zdecydować, które dane pozostają wspólne, a które mogą różnić się pomiędzy rynkami:

Dane	Zwykle wspólne	Mogą różnić się między rynkami
Stan magazynowy	Tak	Rzadko
SKU	Tak	Rzadko
Zdjęcia	Tak	Tak
Nazwa i opis	Nie	Tak
Cena bazowa	Często	Tak
Waluta	Nie	Tak
Podatek	Nie zawsze	Tak
Dostawa	Nie	Tak
Płatności	Nie	Tak
Dostępność produktu	Często	Tak
Regulamin	Nie	Tak
Meta dane SEO	Nie	Tak

Język, kraj i waluta to trzy różne rzeczy

Wersja językowa nie musi odpowiadać jednemu krajowi, a waluta nie powinna być wybierana wyłącznie na podstawie języka.

Rynek	Język	Waluta	Magazyn	Dostawa	Płatności
Polska	polski	PLN	PL	Paczkomaty, kurier	BLIK, karta, przelew
Niemcy	niemiecki	EUR	PL lub DE	kurier międzynarodowy	karta, PayPal
Wielka Brytania	angielski	GBP	PL lub UK	kurier międzynarodowy	karta, PayPal
Czechy	czeski	CZK lub EUR	PL	punkty odbioru, kurier	lokalne metody

WPML czy Polylang — szybkie porównanie

Decyzję trzeba oprzeć na konkretnej konfiguracji WooCommerce, nie na samej liczbie funkcji.

Kryterium	WPML	Polylang
Obsługa WooCommerce	WPML + WooCommerce Multilingual & Multicurrency	Polylang lub Pro + Polylang for WooCommerce
Produkty i warianty	Tak	Tak
Kategorie i atrybuty	Tak	Tak
Koszyk i checkout	Tak	Tak
E-maile WooCommerce	Tak	Tak
Automatyczne tłumaczenie	Centralny system i kredyty	DeepL w Polylang Pro
Tłumaczenie całej witryny	Rozbudowany workflow	Brak jednego przycisku dla całej strony
Wiele walut	Wbudowana obsługa w WCML	Osobne rozwiązanie
Tłumaczenie slugów	Tak	Polylang Pro
hreflang	Tak	Tak
Zespół tłumaczy	Rozbudowany workflow	Prostszy model, funkcje Pro
Model zarządzania	Centralny panel tłumaczeń	Powiązane treści WordPress
Typowy wybór	Duży i złożony sklep	Prostszy sklep i bezpośrednia edycja

Multicurrency oznacza obsługę kilku walut w jednym sklepie (np. PLN, EUR, GBP) wraz z ich cenami, kursami, płatnościami i zwrotami.

Ile kosztują WPML i Polylang?

Kosztów nie należy porównywać wyłącznie na podstawie jednej licencji, ponieważ WooCommerce może wymagać różnych zestawów komponentów.

Według cenników dostępnych w czerwcu 2026 roku: WPML Multilingual CMS kosztuje 99 euro rocznie; Polylang Pro od 99 euro rocznie za jedną witrynę; Polylang for WooCommerce od 99 euro rocznie za jedną witrynę; dostępny jest też pakiet łączący Polylang Pro z dodatkiem WooCommerce. Ceny i promocje mogą się zmieniać — przed zakupem sprawdź aktualny cennik producenta.

Koszty WPML. Do rozbudowanego sklepu wybiera się zwykle WPML Multilingual CMS — pakiet obejmuje główną wtyczkę, panel zarządzania tłumaczeniami, tłumaczenie tekstów motywu i wtyczek, integrację z WooCommerce, automatyczne tłumaczenia, aktualizacje i wsparcie. Automatyczne tłumaczenia działają w systemie kredytów: licencja zawiera określoną pulę, ale duży katalog może wymagać dodatkowych opłat.

Koszty Polylang. Polylang for WooCommerce może działać z darmowym Polylang albo Polylang Pro. Sam dodatek WooCommerce obsługuje najważniejsze elementy sklepu; Polylang Pro jest potrzebny, gdy zależy Ci m.in. na tłumaczeniu slugów, integracji z DeepL, eksporcie i imporcie XLIFF, zaawansowanym kopiowaniu treści, uprawnieniach dla języków i rozbudowanym procesie redakcyjnym. XLIFF to format wymiany treści między WordPressem a narzędziami profesjonalnych tłumaczy.

Które rozwiązanie jest tańsze? Nie da się odpowiedzieć bez poznania zakresu. Polylang z darmowym rdzeniem i dodatkiem WooCommerce może mieć niższy koszt wejścia; jeśli jednak potrzebujesz też Polylang Pro, DeepL oraz osobnej wtyczki walutowej, koszt może zbliżyć się do WPML albo go przekroczyć. Licencje to tylko część budżetu — więcej mogą kosztować tłumaczenia, konfiguracja SEO, testy integracji, poprawki motywu, przygotowanie feedów, migracja danych i późniejsze utrzymanie.

Jak działa WPML w sklepie WooCommerce?

WPML tworzy centralny system zarządzania wersjami językowymi i łączy go z WooCommerce przez moduł WooCommerce Multilingual & Multicurrency.

Produkt w języku głównym może być źródłem treści, a jego tłumaczenia są powiązanymi wersjami. WPML synchronizuje dane, których zwykle nie chcesz rozdzielać (SKU, stan magazynowy, część ustawień produktu, warianty, zdjęcia, klasy wysyłkowe), a nazwy, opisy, adresy i meta dane pozostają oddzielne dla każdego języka.

Centralny panel tłumaczeń. Treści można przekazywać do automatycznego tłumaczenia, użytkowników pełniących rolę tłumaczy, zewnętrznych usług albo ręcznej edycji. Przy dużym katalogu można kontrolować, co przetłumaczono, co oczekuje na pracę, które źródło zmieniono i które tłumaczenia wymagają aktualizacji.

Automatyczne tłumaczenie WPML. Pozwala automatyzować tłumaczenie większych partii treści i korzysta z pamięci tłumaczeń (ponowne wykorzystanie wcześniej przetłumaczonych fragmentów). Automatycznego wyniku nie publikuj bez kontroli — sprawdź zwłaszcza nazwy kategorii, terminy branżowe, jednostki, nazwy wariantów, komunikaty sprzedażowe, informacje o dostawie, teksty prawne i frazy SEO.

Wiele walut w WPML. WooCommerce Multilingual & Multicurrency pozwala dodać kilka walut, ustawić automatyczne lub ręczne kursy, wprowadzić osobne ceny dla walut, przypisać domyślną walutę do języka, ograniczyć płatności według waluty/lokalizacji i dodać przełącznik walut. Każdą konfigurację trzeba przetestować z rzeczywistymi operatorami płatności — nie każda bramka obsługuje wszystkie waluty, płatności cykliczne, częściowe zwroty, rozliczenie bez przewalutowania ani zwroty w walucie pierwotnej transakcji.

Jak działa Polylang w sklepie WooCommerce?

Polylang opiera się na osobnych, połączonych wersjach produktów i wykorzystuje standardowy interfejs edycji WordPressa.

Do pełnej obsługi sklepu potrzebujesz Polylang for WooCommerce. Każdy produkt otrzymuje przypisany język i jest łączony ze swoimi odpowiednikami. Taki model jest czytelny dla osoby, która zna panel WordPressa, chce ręcznie kontrolować każdą wersję, nie potrzebuje rozbudowanej kolejki tłumaczeń i pracuje z małym zespołem.

Synchronizacja produktów. Polylang for WooCommerce może synchronizować między tłumaczeniami m.in. stany, ceny, kategorie, tagi, atrybuty, klasy wysyłkowe oraz zdjęcia i galerie. Przed rozpoczęciem trzeba zdecydować, które dane mają pozostać wspólne. Przykład: zdjęcie produktu może być wspólne dla wszystkich wersji, ale jeśli zawiera polski tekst, dla wersji niemieckiej potrzebna będzie osobna grafika.

Tłumaczenie przez DeepL. DeepL to zewnętrzna usługa automatycznego tłumaczenia. Polylang Pro umożliwia korzystanie z DeepL dla wybranych treści — proces nie polega na przetłumaczeniu całego sklepu jednym kliknięciem. Integracja wymaga własnego klucza API DeepL, działa dla stron/produktów/typów treści, pozwala korzystać z glosariusza w Polylang Pro 3.8, jest uruchamiana dla wybranych elementów i nie obsługuje bezpośrednio treści zapisanych przez Elementor, Divi i część innych builderów. Page buildery często przechowują treść w innej strukturze niż standardowy edytor, co utrudnia automatyczne tłumaczenie. Glosariusz to lista zatwierdzonych nazw, marek i terminów — pomaga utrzymać te same tłumaczenia w całym katalogu.

Waluty w Polylang. Polylang for WooCommerce odpowiada za języki, ale nie zapewnia pełnego własnego systemu multicurrency. Jeśli potrzebujesz kilku walut, musisz dobrać osobne rozwiązanie i sprawdzić jego zgodność z Polylang, operatorem płatności, podatkami, kuponami, zwrotami, fakturami, feedem produktowym i ERP.

Kiedy wybrać WPML?

WPML jest zwykle rozsądniejszym wyborem, gdy wielojęzyczność obejmuje duży katalog, kilka walut, zespół tłumaczy i rozbudowane integracje.

Rozważ WPML, gdy sklep ma setki lub tysiące produktów, planujesz kilka języków, potrzebujesz centralnego panelu tłumaczeń, wiele treści będzie tłumaczonych automatycznie, nad tłumaczeniami pracuje kilka osób, potrzebujesz wielu walut, płatności mają zależeć od waluty/rynku, aktualizacje produktów są częste, chcesz śledzić status pracy albo korzystasz z wielu rozszerzeń WooCommerce. Przykład: sklep meblowy z 8000 produktów, wariantami kolorystycznymi, wersjami PL/DE/CZ, walutami PLN/EUR/CZK, importem produktów, Google Merchant Center, integracją z magazynem i kilkoma tłumaczami — tu uporządkowany proces aktualizacji jest ważniejszy niż różnica kilkudziesięciu euro w cenie licencji.

Kiedy wybrać Polylang?

Polylang może być lepszym wyborem, gdy sklep ma prostszą strukturę, a zespół chce bezpośrednio edytować oddzielne wersje produktów.

Rozważ Polylang, gdy katalog jest stosunkowo mały, dodajesz jeden lub dwa języki, tłumaczenia będą przygotowywane ręcznie, zależy Ci na standardowym panelu WordPressa, nie potrzebujesz wbudowanego systemu wielu walut, zespół techniczny zna WordPressa, używane rozszerzenia zostały sprawdzone z Polylang albo nie potrzebujesz centralnego systemu dla wielu tłumaczy. Przykład: sklep producenta ze 120 produktami, wersją polską i niemiecką, jedną walutą, wspólnym magazynem, ręcznie przygotowanymi tłumaczeniami i niewielką liczbą wtyczek — Polylang może zapewnić wszystko, czego sklep rzeczywiście potrzebuje.

Czy Polylang jest szybszy od WPML?

Nie da się uczciwie wskazać uniwersalnego zwycięzcy wydajności bez testu konkretnego sklepu.

Polylang wykorzystuje prostszy model zarządzania treściami; WPML ma bardziej rozbudowany system tłumaczeń i własne mechanizmy przechowywania powiązań. Nie znaczy to, że każdy sklep na WPML będzie wolny, a każdy na Polylang szybki. Na wynik wpływają też liczba produktów, liczba języków, warianty, filtry, motyw, builder, hosting, baza danych, cache, integracje, importy i zapytania do zewnętrznych systemów — w sklepie z 10 000 produktów źle działający filtr może powodować większe problemy niż wtyczka językowa. Przed wdrożeniem i po nim porównaj czas odpowiedzi serwera, stronę kategorii, kartę produktu, filtry, wybór wariantu, koszyk, checkout, panel administracyjny, import produktów i zadania cron. Cron to mechanizm uruchamiający zaplanowane zadania (import produktów, aktualizacja kursów, wysyłka wiadomości). Jeśli sklep zwalnia po dodaniu języków, sprawdź też hosting pod WooCommerce oraz bazę i wtyczki.

Jak zaplanować adresy wersji językowych?

Dla większości sklepów rozwijanych na jednej domenie najprostsze są podkatalogi językowe.

Przykład: sklep.pl/ (polski), sklep.pl/en/ (angielski), sklep.pl/de/ (niemiecki), sklep.pl/cs/ (czeski). Możliwe są też subdomeny (np. de.sklep.pl), oddzielne domeny (np. sklep.de) i różne domeny regionalne.

Podkatalogi są zwykle łatwiejsze w utrzymaniu, analityce, linkowaniu, aktualizowaniu WordPressa i budowaniu autorytetu jednej domeny. Oddzielne domeny mogą mieć sens, jeśli każdy rynek ma odrębną markę, osobny magazyn, inną ofertę, lokalną obsługę, własny budżet SEO i istotnie inne zasady sprzedaży — w praktyce oznacza to jednak prowadzenie kilku projektów zamiast jednego.

Czy tłumaczyć slugi? Slug to końcowa część adresu (np. fotel-biurowy w sklep.pl/meble/fotel-biurowy/). Jeśli zależy Ci na czytelnych adresach, warto tłumaczyć też slugi — zamiast sklep.pl/de/krzesla/krzeslo-drewniane/ lepiej sklep.pl/de/stuehle/holzstuhl/. W Polylang tłumaczenie slugów wymaga wersji Pro; WPML obsługuje je w swoim systemie tłumaczeń.

Zmiana struktury URL jest migracją. Jeśli obecne wersje są już widoczne w Google, zmiana de.sklep.pl/produkt/ na sklep.pl/de/produkt/ wymaga m.in. mapy adresów, przekierowań 301, aktualizacji hreflang i canonicali, zmian w sitemapach, poprawy linków wewnętrznych, zmian w feedach i reklamach oraz monitoringu błędów 404. Pełną procedurę opisujemy w poradniku migracja sklepu bez utraty pozycji.

Hreflang — jak połączyć wersje językowe?

Hreflang informuje Google, które adresy są odpowiednikami tej samej treści przygotowanymi dla różnych języków lub regionów.

Przykładowy zestaw może wskazywać pl (polski), de (niemiecki), en (ogólna wersja angielska) i en-gb (angielski dla Wielkiej Brytanii). WPML i Polylang mogą generować oznaczenia automatycznie — nadal trzeba sprawdzić ich poprawność.

Najczęstsze błędy hreflang: wersja PL wskazuje na DE, ale DE nie wskazuje na PL; adres prowadzi przez przekierowanie; odnośnik prowadzi do błędu 404; połączono różne produkty; użyto błędnego kodu języka/kraju; brakuje odwołania strony do samej siebie; adresy nie są pełnymi adresami HTTPS; nieprzetłumaczony produkt wskazuje przypadkową stronę; canonical prowadzi do innej wersji językowej.

Czy x-default jest obowiązkowy? Nie. Można go wykorzystać dla neutralnej strony wyboru języka albo domyślnej wersji dla osób, dla których nie przygotowano dokładnego wariantu. Brak x-default nie oznacza automatycznie błędu.

Czy WPML i Polylang są równie dobre dla SEO?

Oba rozwiązania mogą stworzyć poprawną strukturę techniczną, ale żadna wtyczka nie zastąpi strategii SEO dla konkretnego rynku.

Oba systemy mogą obsługiwać oddzielne adresy, hreflang, tytuły SEO, meta description, tłumaczone treści, kategorie, mapy strony i linkowanie między wersjami. Na wyniki wpływają przede wszystkim jakość tłumaczeń, dobór lokalnych fraz, architektura kategorii, indeksacja, linkowanie, oferta, lokalne sygnały zaufania i konkurencja.

Nie tłumacz fraz słowo w słowo. Polska fraza nie zawsze ma bezpośredni odpowiednik o podobnej popularności — w Polsce klienci mogą szukać „szafka RTV", a w Niemczech popularne bywają inne określenia zależne od typu i stylu mebla. Przed tłumaczeniem kategorii wykonaj osobny research słów dla każdego rynku.

Przygotuj osobne meta dane. Każda wersja powinna mieć własne meta title, meta description, H1, opis kategorii i linkowanie wewnętrzne — automatyczna podmiana pojedynczych słów nie wystarczy.

Sprawdź sitemapę. Powinna zawierać indeksowalne produkty, ważne kategorie, poprawne adresy kanoniczne i aktywne wersje językowe; nie powinno być w niej pustych tłumaczeń, adresów z noindex, przekierowań, nieaktywnych produktów ani technicznych parametrów.

Jak tłumaczyć produkty i warianty?

Najpierw przetłumacz kategorie i atrybuty, a dopiero później produkty wariantowe.

Przykładowy produkt „Koszulka bawełniana — czarna — rozmiar M" składa się z produktu, atrybutu „kolor", wartości „czarny", atrybutu „rozmiar", wartości „M", wariantu, ceny, stanu i zdjęcia. Jeśli przetłumaczysz tylko produkt, filtr może nadal wyświetlać polskie nazwy atrybutów. Zalecana kolejność: (1) dodaj języki, (2) przetłumacz kategorie, (3) globalne atrybuty, (4) wartości atrybutów, (5) sprawdź slugi, (6) przetłumacz produkt, (7) zweryfikuj warianty, (8) sprawdź stan i SKU, (9) przetestuj filtry, (10) dodaj produkt do koszyka.

Nie twórz niezależnych kopii produktów. Nie dodawaj niemieckiego produktu jako zupełnie osobnej pozycji, jeśli ma korzystać ze wspólnego stanu — może to spowodować podwójne stany, różne SKU, błędy wariantów, duplikaty w feedzie, sprzedaż ostatniej sztuki dwa razy i brak właściwego hreflang. Wersje powinny być powiązane mechanizmem wtyczki.

Co z cenami, walutami i płatnościami?

Język można zmieniać niezależnie od waluty, dlatego konfiguracja cen wymaga osobnej decyzji biznesowej.

Możliwe modele: jeden język i kilka walut (wersja angielska z wyborem EUR/GBP/USD); jedna waluta przypisana do języka (polski → PLN, niemiecki → EUR, angielski → GBP); cena ustalana ręcznie dla rynku (499 zł w Polsce, 129 euro w Niemczech, 119 funtów w UK). Cena zagraniczna nie musi być prostym wynikiem kursu — może uwzględniać koszt dostawy, obsługę zwrotów, prowizje, lokalną konkurencję, marżę i koszt obsługi rynku. Przetestuj zmianę waluty, ceny wariantów, promocje, kupony, podatki, zaokrąglenia, płatność, pełny i częściowy zwrot, fakturę, eksport zamówienia i raport przychodów.

Co z podatkami, dostawą i regulaminami?

Przetłumaczenie sklepu nie dostosowuje automatycznie zasad sprzedaży do nowego kraju.

Sprawdź, czy sprzedajesz B2C/B2B/oba, skąd wysyłasz, do których krajów dostarczasz, jakie stawki podatku mają zastosowanie, czy korzystasz z VAT OSS, jak obsługujesz zwroty, kto płaci za przesyłkę zwrotną, jakie informacje muszą znaleźć się na produkcie i jakie płatności są popularne lokalnie. VAT OSS to unijna procedura pozwalająca rozliczać VAT od części sprzedaży B2C do innych krajów UE przez jeden portal, zamiast rejestrować się osobno w każdym państwie konsumpcji. Nie publikuj regulaminu przetłumaczonego automatycznie bez weryfikacji — prawo, podatki i obowiązki konsumenckie sprawdź z osobą znającą dany rynek.

Tłumaczenie automatyczne czy ręczne?

Automat dobrze przygotowuje szkic, ale nie powinien samodzielnie decydować o języku sprzedażowym, SEO i dokumentach prawnych.

Automatycznie można wstępnie tłumaczyć długie opisy, proste informacje techniczne, treści pomocnicze, wpisy blogowe i powtarzalne parametry. Ręcznie sprawdź nazwy kategorii, nazwy produktów, nagłówki, przyciski, meta dane, główne korzyści, reklamy, regulaminy, warunki dostawy, błędy formularzy i checkout. Przygotuj glosariusz, który pomaga zachować te same nazwy w całym katalogu:

Polski termin	Niemiecki odpowiednik	Uwagi
Szafka RTV	TV-Lowboard	Nie tłumaczyć dosłownie
Dąb artisan	Artisan-Eiche	Nazwa dekoru
Cichy domyk	Soft-Close	Termin branżowy
Paczkomat	Paketautomat	Dopasować do dostawy
Meblościanka	Wohnwand	Termin lokalny

Czy tłumaczyć cały katalog od razu?

Bezpieczniej rozpocząć od ograniczonej grupy produktów, a dopiero po testach rozszerzyć wdrożenie.

W sklepie z 10 000 produktów wybierz na początek jedną kategorię, kilkadziesiąt produktów, produkt prosty, wariantowy, promocyjny i produkt z niestandardowymi polami. Sprawdź tłumaczenia, synchronizację stanów, import, filtry, feed, płatności, dostawy, e-maile i SEO. Błąd wykryty na 30 produktach jest łatwy do poprawienia — ten sam błąd powielony na 10 000 pozycji może wymagać osobnej migracji danych.

Integracje, ERP i importy

System zewnętrzny musi wiedzieć, które dane są wspólne, a które należą do konkretnej wersji językowej.

ERP zarządza m.in. magazynem, fakturami, cenami i zamówieniami. W integracji ustal: czy ERP przechowuje kilka języków, który system jest źródłem opisów, czy stany są wspólne, skąd pobierane są ceny, jak identyfikowane są tłumaczenia, czy warianty mają wspólne SKU, w jakim języku trafia zamówienie, jak zapisywana jest waluta i w jakim języku wystawiana jest faktura.

Google Merchant Center i feedy produktowe

Każda wersja rynku powinna przekazywać do Google zgodne dane: język, walutę, cenę, dostawę i właściwą stronę docelową.

Feed produktowy to plik lub strumień danych przekazujący Google informacje o ofercie. Dla rynku niemieckiego tytuł, opis i landing page powinny być po niemiecku, cena musi zgadzać się ze stroną, waluta musi być obsługiwana, a dostawa powinna odpowiadać krajowi — nie wysyłaj niemieckiego tytułu do polskiej strony produktu. Zweryfikuj język feedu, kraj sprzedaży, walutę, identyfikatory, dostępność, adres produktu, dostawę, politykę zwrotów i zgodność cen. Jeśli planujesz reklamy produktowe, przygotuj sklep i kampanie Google Shopping jako jeden proces.

Jak przetestować zakup w każdym języku?

Test musi obejmować całą transakcję, ponieważ część błędów pojawia się dopiero w checkoutcie albo w wiadomości po zamówieniu.

Dla każdego języka: otwórz kategorię i użyj filtra → wybierz produkt wariantowy → dodaj do koszyka → zastosuj kupon → wybierz dostawę → zmień metodę płatności → wywołaj błąd formularza → złóż zamówienie testowe → sprawdź stronę podziękowania → sprawdź e-mail klienta → sprawdź status i stan magazynowy → wykonaj zwrot. Szukaj przede wszystkim mieszania języków: polski przycisk w niemieckiej wersji, angielski komunikat błędu, nieprzetłumaczona dostawa, polski tytuł e-maila, bramka płatności w innym języku, nieprzetłumaczony status.

Jak wdrożyć wielojęzyczny WooCommerce krok po kroku?

Wdrożenie prowadź od wyboru rynków i spisu integracji, przez staging i jeden język testowy, aż po etapowe uruchomienie.

Krok 1. Wybierz rynki — kraje, języki, waluty, podatki, dostawy, płatności i sposób obsługi klienta. Krok 2. Spisz integracje — motyw, builder, płatności, kurierów, faktury, ERP, magazyn, Base, feedy, filtry, subskrypcje, rezerwacje, konfiguratory, pola niestandardowe. Krok 3. Sprawdź kompatybilność — obsługę wariantów, danych dynamicznych, e-maili, bloków checkoutu, importu, HPOS i używanego buildera. HPOS to sposób przechowywania zamówień WooCommerce w osobnych tabelach bazy. Krok 4. Wybierz strukturę adresów — podkatalogi, subdomeny, domeny, prefiks języka podstawowego, tłumaczenie slugów. Krok 5. Przygotuj staging (kopia sklepu do bezpiecznych testów). Krok 6. Wykonaj backup (pliki, baza, konfiguracja integracji).

Krok 7. Dodaj jeden język testowy — nie zaczynaj od wszystkich planowanych. Krok 8. Przetłumacz taksonomie — kategorie, atrybuty, wartości atrybutów, tagi, klasy wysyłkowe. Krok 9. Przetłumacz próbkę produktów — prosty, wariantowy, promocyjny i z dodatkowymi polami. Krok 10. Skonfiguruj ceny i waluty — kursy, ceny ręczne, podatki, zaokrąglenia, płatności. Krok 11. Przetłumacz elementy techniczne — checkout, konto, formularze, e-maile, komunikaty wtyczek. Krok 12. Skonfiguruj SEO — slugi, meta dane, canonicale, hreflang, sitemapa, linkowanie. Krok 13. Przetestuj integracje. Krok 14. Wykonaj zamówienia testowe — każdy język, kraj, główna metoda dostawy, płatność i waluta. Krok 15. Uruchamiaj etapami — opublikuj najpierw część oferty, kolejne produkty i języki dodawaj po potwierdzeniu, że proces działa.

Najczęstsze błędy przy wielojęzycznym WooCommerce

Najwięcej problemów powodują: wybór wtyczki przed opisaniem procesu, automat bez korekty, brak tłumaczeń atrybutów i nadpisywanie przez import.

Wybór wtyczki przed opisaniem procesu — firma kupuje WPML albo Polylang, zanim ustali rynki, waluty i integracje. Automatyczne tłumaczenie bez korekty — tekst jest formalnie przetłumaczony, ale nazwy produktów i kategorii brzmią nienaturalnie. Brak tłumaczeń atrybutów — opis jest po niemiecku, ale filtr nadal pokazuje „kolor", „szerokość", „materiał". Polski slug w obcym języku — adres niemieckiej strony pozostaje częściowo po polsku.

Co możesz sprawdzić samodzielnie?

Najwięcej dowiesz się, otwierając ten sam produkt w każdym języku i przechodząc całą ścieżkę zakupu.

1. Otwórz ten sam produkt w każdym języku.
2. Zmień język na karcie produktu i sprawdź, czy trafiasz na jego odpowiednik.
3. Zweryfikuj kategorie, atrybuty i filtry.
4. Sprawdź slugi, canonicale i hreflang.
5. Otwórz sitemapę.
6. Dodaj produkt wariantowy do koszyka.
7. Zmień język w koszyku.
8. Sprawdź dostawę i płatność.
9. Złóż testowe zamówienie.
10. Sprawdź język e-maila.
11. Porównaj walutę i kwoty w zamówieniu.
12. Zweryfikuj wspólny stan magazynowy.
13. Sprawdź produkt w Merchant Center.
14. Przetestuj sklep na telefonie.
15. Sprawdź, czy import nie nadpisuje tłumaczeń.

Kiedy warto zlecić to specjaliście?

Pomoc specjalisty jest potrzebna, gdy sklep ma duży katalog, kilka integracji albo istniejące pozycje w Google, których nie można stracić podczas przebudowy.

Warto zlecić wdrożenie, jeśli sklep ma setki lub tysiące produktów, produkty mają wiele wariantów, działa import z ERP lub hurtowni, potrzebujesz kilku walut, korzystasz z kilku bramek płatności, wdrażasz lokalne metody dostawy, sklep używa konfiguratora, sprzedajesz subskrypcje lub rezerwacje, masz aktywne kampanie Google Shopping, adresy są już zaindeksowane, zmieniasz WPML na Polylang albo odwrotnie, tłumaczeniami zarządza kilka osób albo nie masz środowiska testowego. Przy takim projekcie trzeba połączyć WooCommerce, tłumaczenia, SEO, płatności, dostawy, feedy, integracje i późniejsze utrzymanie. Pomocne będą też pozycjonowanie sklepów, SEO techniczne i audyt SEO.

---

WPML czy Polylang — co wybrać?

WPML i Polylang pozwalają zbudować poprawny wielojęzyczny sklep WooCommerce, ale nie są identycznymi rozwiązaniami.

WPML lepiej pasuje zwykle do projektu wymagającego centralnego procesu tłumaczeń, dużej automatyzacji, wielu walut, pracy kilku tłumaczy i szerokich integracji. Polylang warto rozważyć, gdy potrzebujesz prostszego modelu edycji, ręcznej kontroli wersji, jednego lub dwóch dodatkowych języków, mniejszego katalogu i elastycznego wdrożenia prowadzonego przez techniczny zespół.

Najważniejsze pytanie nie brzmi „która wtyczka ma więcej funkcji?". Najpierw ustal, ile masz produktów, kto je tłumaczy, skąd pochodzą dane, jak działają ceny i waluty, które integracje muszą pozostać sprawne i jak będą rozwijane kolejne rynki. Jeśli planujesz wielojęzyczny sklep, możemy sprawdzić katalog, integracje, strukturę adresów i wymagania rynków, a następnie dobrać WPML albo Polylang do rzeczywistego procesu:

• Tworzenie sklepów WooCommerce — języki, produkty, warianty, płatności, SEO i testy całej ścieżki zakupowej.
• Pozycjonowanie sklepów oraz architektura kategorii pod SEO — widoczność na każdym rynku.
• Migracja sklepu bez utraty pozycji — gdy zmieniasz strukturę adresów lub wtyczkę językową.