Wielojezyczny sklep PL i DE: jak zrobic poprawnie

Wielojezyczny sklep to URL, hreflang, waluty i podatki, nie sama wtyczka
WPML z WooCommerce Multilingual to najpewniejszy wybor pod sklep PL plus DE
Polylang przy mniejszym budzecie, TranslatePress przy prostej stronie
Jeden jezyk na jeden URL plus poprawny hreflang to fundament SEO
Podatki ustawiasz osobno dla Polski i Niemiec, sprzedaz do DE przez OSS
Najczestszy blad to nieprzetlumaczony checkout, maile i strony prawne
[/dwb_keytakeaways]

Wielojezyczny sklep to cala uklada, nie sama wtyczka

Najczestsze nieporozumienie przy sklepie po polsku i niemiecku brzmi tak: zainstaluje wtyczke do tlumaczen i mam dwa jezyki. Wtyczka to dopiero pierwszy klocek. Sklep wielojezyczny dziala poprawnie dopiero wtedy, gdy zgadza sie piec rzeczy naraz: struktura adresow URL, znaczniki hreflang, tlumaczenie produktow i procesu zamowienia, obsluga walut oraz podatki ustawione osobno dla kazdego kraju.

Jesli ktorykolwiek z tych elementow kuleje, efekty sa bolesne. Google pokazuje Niemcowi polska wersje strony, ceny mieszaja sie z walutami, a klient dochodzi do kasy i nagle widzi pol formularza po polsku. Dlatego do sklepu PL plus DE podchodze jak do jednego spojnego projektu, a nie jak do dolozenia jezyka na koniec.

W tym tekscie przejdziemy po kolei przez wybor wtyczki, strukture URL i hreflang, tlumaczenie produktow i checkoutu, waluty, podatki dla Polski i Niemiec, SEO wielojezyczne oraz bledy, ktore widuje najczesciej. Bez lania wody, z konkretami pod realny sklep.

WPML, Polylang czy TranslatePress

To trzy najczesciej uzywane rozwiazania do wielojezycznego WordPressa i WooCommerce. Kazde zrobi dwa jezyki, ale roznia sie tym, jak radza sobie ze sklepem, czyli z produktami, wariantami, atrybutami i checkoutem.

• WPML: standard dla sklepow. Z dodatkiem WooCommerce Multilingual tlumaczy produkty, warianty, atrybuty, kategorie i proces zamowienia, dobrze wspolpracuje z Germanized i bramkami. Platny, ale najmniej niespodzianek na produkcji.
• Polylang: lzejszy i tanszy, ma wersje darmowa i platna. Do sklepu potrzebuje dodatku do WooCommerce. Dobry wybor przy mniejszym katalogu i ograniczonym budzecie, wymaga troche wiecej recznej pracy przy produktach.
• TranslatePress: tlumaczy wizualnie, na froncie, co jest wygodne dla osob nietechnicznych. Najlepiej dziala na prostszej stronie i mniejszym sklepie. Przy duzym katalogu z wariantami bywa mniej wygodny niz WPML.

W praktyce dla produkcyjnego sklepu PL plus DE z prawdziwym katalogiem najczesciej wybieram WPML, bo najmniej walcze potem z drobiazgami. Polylang biore, gdy sklep jest mniejszy, a klient liczy kazda zlotowke. TranslatePress proponuje, gdy strona jest prostsza, a priorytetem jest latwe tlumaczenie tresci przez samego wlasciciela.

Struktura URL: jeden jezyk, jeden adres

To fundament, ktory rozstrzyga sie na poczatku i zle ustawiony msci sie potem przy kazdej zmianie. Zasada jest prosta: kazdy jezyk ma swoj staly, unikalny adres URL, a Google nie moze widziec dwoch jezykow pod tym samym URL. Masz trzy sensowne warianty.

1. Podkatalog: sklep.pl dla polskiego i sklep.pl/de dla niemieckiego. Najprostsze w utrzymaniu, cala moc SEO zostaje na jednej domenie. To moj domyslny wybor dla wiekszosci sklepow PL plus DE.
2. Osobne domeny: sklep.pl i sklep.de. Ma sens, gdy budujesz dwie odrebne, mocne marki na dwa rynki i chcesz pelnego rozdzielenia. Wiecej pracy i kosztu, ale czysty podzial.
3. Subdomena: de.sklep.pl. Dziala technicznie, ale rzadziej daje przewage nad podkatalogiem, a bywa trudniejsza w SEO. Uzywam jej raczej wyjatkowo.

Czego unikac: parametrow w stylu sklep.pl/?lang=de albo przelaczania jezyka bez zmiany adresu. Dla wyszukiwarki to jeden URL z mieszana trescia i prosta droga do problemow z indeksacja. Jezyk zawsze musi byc widoczny w samym adresie.

Hreflang: zeby Google pokazal wlasciwa wersje

Hreflang to znacznik w kodzie strony, ktory mowi wyszukiwarce: ta strona ma odpowiednik w innym jezyku. Polska karta produktu wskazuje swoja niemiecka wersje, a niemiecka wskazuje polska. Dzieki temu Google pokazuje Polakowi polska wersje, a Niemcowi niemiecka, i nie traktuje obu jako duplikatu.

Dobra wiadomosc: WPML, Polylang i TranslatePress dodaja hreflang automatycznie dla powiazanych stron. Zla wiadomosc: automat dziala dobrze tylko wtedy, gdy strony sa poprawnie sparowane. Jesli niemiecka karta produktu nie jest powiazana z polska, znacznik bedzie niepelny albo go zabraknie.

Tlumaczenie produktow i checkoutu

Tu sklep rozni sie od zwyklej strony. Nie tlumaczysz tylko opisow, ale caly lancuch, ktory prowadzi klienta do zaplaty. Jesli przetlumaczysz opisy, a checkout zostawisz po polsku, niemiecki klient porzuci koszyk w ostatnim kroku.

• Produkty: nazwa, opis, opis krotki, atrybuty (kolor, rozmiar) i warianty. Atrybuty to czesty pominiety element, bo siedza osobno od opisu.
• Kategorie i tagi: nazwy i opisy kategorii, bo pojawiaja sie w menu i adresach URL.
• Checkout i koszyk: etykiety pol, komunikaty, metody dostawy i platnosci. To miejsce, ktore decyduje o sprzedazy.
• Maile transakcyjne: potwierdzenie zamowienia, wysylki i faktura musza przychodzic w jezyku klienta.
• Strony prawne: regulamin, polityka prywatnosci, na rynek DE rowniez AGB, Widerruf i Datenschutz.

Co do samego tlumaczenia: maszyna jak DeepL jest dobra na pierwsza wersje i do opisow technicznych, ale na rynek niemiecki nie wystarczy sama. Niemiecki klient wyczuwa sztuczny jezyk, a strony prawne i opisy sprzedazowe wymagaja korekty native. Najlepiej dziala model mieszany: maszyna robi szkielet, czlowiek poprawia checkout, maile, AGB i kluczowe opisy.

Waluty: zloty i euro w jednym sklepie

Polski klient chce widziec ceny w zlotowkach, niemiecki w euro. WooCommerce natywnie ma jedna walute, wiec wielowalutowosc dodajesz przez funkcje wtyczki (na przyklad WPML ma WooCommerce Multilingual z obsluga wielu walut) albo osobny dodatek do walut.

Tu trzeba podjac decyzje biznesowa, nie tylko techniczna: czy euro to po prostu przeliczony zloty po kursie, czy ustawiasz osobne, rowne ceny na rynek niemiecki. Przeliczanie po kursie daje brzydkie ceny typu 19,37 euro, co na froncie wyglada slabo. Czesto lepiej ustawic ladne ceny rowne dla DE, na przyklad 19,90 euro, i traktowac rynek niemiecki jako osobny cennik.

Podatki per kraj: Polska i Niemcy osobno

Podatki to czesc, ktora najczesciej jest zrobiona po lebkach, a potrafi narobic problemow z ksiegowoscia. WooCommerce pozwala ustawic osobne stawki podatku dla roznych krajow i z tego trzeba skorzystac. Polska ma swoje stawki VAT, Niemcy swoje, a sposob naliczania zalezy od tego, dokad wysylasz i kto jest klientem.

W skrocie i ostroznie, bo to temat ksiegowy: przy sprzedazy do konsumentow w Niemczech po przekroczeniu wspolnego unijnego progu 10 000 euro rocznie naliczasz niemiecki VAT i rozliczasz go przez procedure OSS. W WooCommerce ustawiasz wtedy osobne klasy i stawki podatku dla Niemiec, a ceny dla rynku DE pokazujesz z dopiskiem inkl. MwSt. Na rynek niemiecki praktycznie zawsze dochodzi tez wtyczka Germanized, ktora porzadkuje obowiazkowe elementy sklepu pod prawo niemieckie.

Konkretna konfiguracje stawek i progow zawsze potwierdzam z ksiegowa klienta, bo decyduje miejsce wysylki, status klienta (konsument czy firma z numerem VAT) i biezace przepisy. Moja robota to ustawic sklep technicznie tak, zeby liczyl to, co ustali ksiegowosc.

SEO wielojezyczne: jak nie zmarnowac potencjalu

Dobrze zrobiony sklep dwujezyczny to dwa razy wieksza powierzchnia w wyszukiwarce, pod warunkiem ze SEO jest pomyslane od poczatku. Kilka zasad, ktorych pilnuje.

• Tlumacz, nie kopiuj slow kluczowych: niemiecki klient szuka innych fraz niz doslowne tlumaczenie polskich. Slowa kluczowe pod rynek DE dobierasz osobno, nie przez DeepL na polskiej liscie.
• Przetlumacz slugi w adresach: niemiecka karta produktu powinna miec niemiecki slug, nie polski przepisany na /de. To realnie pomaga w lokalnym wyszukiwaniu.
• Meta title i opis na kazdy jezyk: nie zostawiaj polskich metadanych na niemieckiej wersji. Rank Math i podobne narzedzia pozwalaja ustawic je osobno.
• Pilnuj hreflang: to on rozdziela wersje w oczach Google i chroni przed traktowaniem ich jako duplikat.

Jesli to ogarniesz, kazdy jezyk zaczyna pracowac na siebie i sklep laduje sie na frazy w dwoch krajach naraz. To jest wlasnie powod, dla ktorego sklep wielojezyczny robi sie poprawnie, a nie na szybko.

Najczesciej popelniane bledy

Na koniec lista bledow, ktore widuje najczesciej przy sklepach PL plus DE. Wiekszosc z nich wynika z traktowania jezyka jako dodatku doklejonego na koniec.

• Nieprzetlumaczony checkout, maile i strony prawne: opisy po niemiecku, ale kasa i potwierdzenie zamowienia po polsku. Klient ucieka w ostatnim kroku.
• Brak lub bledny hreflang: Google miesza wersje jezykowe albo traktuje je jako duplikaty, przez co niemiecka wersja sie nie wybija.
• Doslowne tlumaczenie maszynowe bez korekty: na rynek niemiecki to widac od razu i obniza zaufanie do sklepu.
• Zle podatki dla Niemiec: brak osobnych stawek i procedury OSS, przez co ceny i faktury sa niezgodne z tym, co powinno byc.
• Ceny przeliczane w locie: brzydkie kwoty z groszami zamiast rownych cen ustawionych pod rynek DE.

Jesli stawiasz sklep dwujezyczny od zera albo chcesz dolozyc poprawnie niemiecki do istniejacego, w DawidWeb robie to regularnie: dobor wtyczki pod skale Twojego katalogu, struktura URL i hreflang, tlumaczenie produktow i checkoutu, waluty oraz podatki ustawione osobno dla Polski i Niemiec z Germanized na pokladzie. Sklepy buduje od 1800 zl, jestem Partnerem Shoper, mam za soba ponad 120 projektow na rynek PL i DE, a wycene konkretnego wdrozenia dostajesz w 24 godziny.