Decyzja o ekspansji zagranicznej pojawia się zazwyczaj wtedy, gdy rynek krajowy zaczyna być za ciasny. Właściciel sklepu odkrywa, że PrestaShop obsługuje wiele języków, włącza drugi język, tłumaczy menu i produkty — i uważa sprawę za załatwioną.
Potem dziwi się, dlaczego zagraniczni klienci nie konwertują. Dlaczego Google indeksuje złe strony. Dlaczego księgowa mówi, że fakturowanie do Niemiec nie działa prawidłowo.
Wielojęzyczny PrestaShop to nie zadanie techniczne. To decyzja biznesowa z konsekwencjami technicznymi. I właśnie te konsekwencje — te, o których w poradnikach się nie mówi — są tematem tego artykułu.
Problem pierwszy: hreflang, którego nikt nie sprawdza
PrestaShop generuje tagi hreflang automatycznie. Brzmi świetnie — do momentu, gdy sprawdzisz, jak to działa w praktyce.
Hreflang mówi Google'owi: "Ta strona jest przeznaczona dla użytkowników w konkretnym języku i regionie. Tutaj jest jej odpowiednik w innym języku." Jeśli ten sygnał jest błędny lub niespójny, Google poradzi sobie po swojemu — a to zazwyczaj nie oznacza wyświetlenia tej wersji, którą chcesz.
Typowe problemy, które widzę:
Wersja językowa istnieje, ale nie ma własnej struktury URL. Wszystkie języki działają pod tą samą domeną bez prefiksu językowego, albo z prefiksami, które PrestaShop wymyślił sam. Wynik: Google nie wie, co indeksować.
Hreflang odsyła do stron, które zwracają 301 lub 404. Wystarczy jeden przekierowany URL w zestawie hreflang i cały sygnał jest zakwestionowany.
Brakuje x-default — wersji zapasowej dla użytkowników spoza docelowych regionów. Bez niej Google zgaduje.
To nie jest kwestia szablonów ani modułów. To kwestia tego, jak wielojęzyczna struktura została zaprojektowana od początku — i czy ktoś po uruchomieniu sprawdził ją w Google Search Console.
Problem drugi: waluty, które nie są tylko estetyką
PrestaShop obsługuje wiele walut. Ale sposób, w jaki je skonfigurujesz, decyduje o tym, czy klient widzi cenę, która ma sens — czy cenę, która go odstraszy.
Dynamiczny kurs to ustawienie domyślne. PrestaShop pobiera kurs ze źródła, przelicza cenę i wyświetla ją klientowi. Problem: kursy się zmieniają. Klient widzi dziś inną cenę niż wczoraj. Klient, który doda do koszyka i wróci następnego dnia, widzi inną sumę. To niszczy zaufanie.
Do poważnej sprzedaży zagranicznej rekomenduje stałe ceny w docelowej walucie — nie przelicznik, ale rzeczywistą cenę katalogową dla danego rynku. To oznacza decyzję o marży, a nie tylko techniczne ustawienie kursu.
Druga rzecz: bramka płatnicza musi obsługiwać daną walutę. Przelewy24 działa w PLN. Stripe obsługuje EUR, GBP, CZK i dziesiątki innych. Ale to połączenie musi być zweryfikowane przed uruchomieniem — nie po pierwszej nieudanej próbie płatności.
Problem trzeci: podatki, które różnią się w zależności od kraju klienta
To obszar, w którym najczęściej widzę poważne błędy — i gdzie konsekwencje są najkosztowniejsze.
VAT w e-commerce podlega zasadzie kraju przeznaczenia. Jeśli sprzedajesz klientowi w Niemczech, naliczasz niemiecki VAT. Jeśli klientowi w Czechach, czeski VAT. Od określonego obrotu masz obowiązek rejestracji VAT w tych krajach lub możesz skorzystać z procedury OSS (One Stop Shop) w Polsce.
PrestaShop technicznie to obsługuje — ale musisz mu powiedzieć jak. Strefy podatkowe, stawki dla każdego kraju, przypisanie do kategorii produktowych. A potem musisz zadbać, żeby faktura wyglądała prawidłowo — z numerem VAT klienta w przypadku transakcji B2B, z właściwą stawką, w języku klienta.
Widzę sklepy, które ekspandują za granicę i przez rok fakturują polskim VAT-em klientom z Niemiec. To nie jest tylko błąd w systemie. To problem podatkowy.
Co się psuje, gdy uruchamiasz bez przygotowania
Trzy scenariusze z praktyki:
Scenariusz A: Sklep uruchamia wersję niemiecką. Tłumaczy teksty. Google indeksuje obie wersje pod tymi samymi URL-ami, bez hreflang. Wersja niemiecka nie zdobywa żadnego ruchu organicznego, bo Google traktuje ją jako duplikat.
Scenariusz B: Sklep włącza EUR z dynamicznym kursem. Klient dodaje do koszyka, wraca następnego dnia i widzi inną sumę. Porzuca koszyk. Właściciel nie wie dlaczego.
Scenariusz C: Sklep zaczyna sprzedawać do Niemiec. Fakturuje polski VAT wszystkim. Po roku przychodzi kontrola. Wynik: zaległości podatkowe, kary, administracja.
Każdy z tych scenariuszy dało się przewidzieć — nie po uruchomieniu, ale na etapie projektowania.
Jak zrobić to porządnie
Wielojęzyczna ekspansja w PrestaShop to nie projekt na weekend. Zaczyna się od decyzji biznesowych:
- Na jakie rynki wchodzę i dlaczego właśnie teraz?
- Jaką strukturę URL wybieram — subdomeny, podkatalogi czy osobne domeny?
- Jak ustalam ceny w docelowych walutach?
- Jak zapewniam właściwą logikę podatkową dla każdego kraju?
- Kto będzie na bieżąco kontrolował jakość danych i sygnały SEO?
Dopiero po odpowiedzi na te pytania ma sens sięgać po technikę.
Jeśli planujesz ekspansję zagraniczną i chcesz uniknąć błędów, które spowolnią lub zablokują wejście na nowy rynek — napisz do mnie. Pomagam sklepom zaprojektować wielojęzyczną architekturę tak, żeby działała od pierwszego dnia.
📧 janek@jhdev.cz | janekherkowiak.pl
Janek Herkowiak — freelance developer e-commerce, 15+ lat doświadczenia. Certyfikowany Base Partner i PrestaShop Expert.
