Migracja PrestaShop 1.6 na 8.x bez utraty pozycji w Google

Dlaczego migracja z PrestaShop 1.6 jest nieunikniona

PrestaShop 1.6 ma dwanaście lat. Oficjalne wsparcie skończyło się ponad sześć lat temu. Jeśli nadal prowadzisz sklep na tej wersji, to tak, jakbyś jeździł samochodem bez przeglądu technicznego od sześciu lat. Niby jedzie, ale pytanie brzmi: jak długo jeszcze.

To nie jest hipotetyczne zagrożenie. Miałam klienta, którego sklep na PrestaShop 1.6 został przejęty w sobotę w nocy. Ktoś wstrzyknął skrypt przechwytujący dane kart płatniczych. Odkryliśmy to w poniedziałek rano, bo klienci zaczęli pisać, że mają podejrzane transakcje na kontach. Luka, przez którą wszedł atakujący, była znana od trzech lat. PrestaShop 1.6 jest regularnym celem ataków, bo atakujący dokładnie wiedzą, jakie luki istnieją i że nie zostaną naprawione. Wstrzyknięcia SQL, skimming kart płatniczych, przejęcia panelu administracyjnego - to realne scenariusze, nie teoretyczne ryzyka.

Ale bezpieczeństwo to nie jedyny powód migracji. Dochodzą do tego:

• wydajność - PrestaShop 1.6 opiera się na starszej architekturze PHP, która nie korzysta z optymalizacji dostępnych w PHP 8.x; typowy sklep na 1.6 generuje czasy odpowiedzi serwera 2-5x dłuższe niż ten sam katalog na PrestaShop 8
• Core Web Vitals - szablony z epoki 1.6 nie były projektowane z myślą o metrykach Google; LCP powyżej 4 sekund na mobile to norma, nie wyjątek
• kompatybilność z modułami - nowe moduły i integracje (płatności, kurierzy, marketplace’y) coraz częściej wymagają PrestaShop 1.7+ lub 8.x; na 1.6 zostajesz z tym, co masz
• brak wsparcia deweloperów - znalezienie programisty, który chce pracować z kodem 1.6, jest coraz trudniejsze i coraz droższe

Jeśli planujesz migrację, kluczowe pytanie nie brzmi “czy”, ale “jak to zrobić bez utraty widoczności organicznej”. Bo właśnie SEO jest obszarem, w którym migracja potrafi zrobić najwięcej szkód.

Dlaczego migracja to ryzyko dla SEO

Migracja z PrestaShop 1.6 na 8.x to nie aktualizacja. To wymiana silnika. Wersja 8 opiera się na frameworku Symfony, ma inną architekturę, inny system szablonów (przejście z Smarty w frontoffice na nowe podejście), inne nazewnictwo plików i inny ekosystem modułów. Z perspektywy Google to de facto budowa nowego sklepu pod tym samym adresem.

Zmiana struktury URL-i

To najczęstsza przyczyna utraty pozycji po migracji. PrestaShop 1.6 generuje URL-e w formacie zależnym od konfiguracji i zainstalowanych modułów. Typowe schematy:

• /pl/12-nazwa-kategorii (z ID i prefiksem języka)
• /123-nazwa-produktu.html (z ID i rozszerzeniem .html)
• /content/15-nazwa-strony-cms

PrestaShop 8.x domyślnie generuje inne formaty URL-i. Moduł Pretty URLs lub natywna konfiguracja URL-i w 8.x może produkować adresy bez ID, bez rozszerzenia .html, z innym prefiksem językowym. Każda zmiana formatu URL oznacza, że Google traci połączenie między starą stroną (z pozycjami, linkami, historią) a nową.

Niekompatybilność modułów

Moduły SEO, które działały na 1.6, nie przeniosą się na 8.x. To dotyczy modułów odpowiedzialnych za:

• niestandardowe meta tagi (title, description) ustawiane per strona
• ręczne przekierowania 301
• reguły canonical i noindex
• konfigurację sitemap XML
• dane strukturalne Schema.org

Jeśli przez lata ktoś budował konfigurację SEO w module na 1.6, wszystkie te dane mogą zostać utracone przy migracji, jeśli nie zostaną wyeksportowane wcześniej.

Utrata danych strukturalnych

PrestaShop 1.6 i 8.x generują różne dane strukturalne (o ile w ogóle je generują). Motyw na 1.6 mógł mieć ręcznie dodany markup Product, breadcrumbs, Organization. Nowy motyw na 8.x prawdopodobnie generuje inny zestaw danych lub nie generuje ich wcale. Dla Google to zmiana, która wpływa na wyświetlanie rozszerzonych wyników.

Zmiana wewnętrznego linkowania

Nowy motyw, nowa nawigacja, nowy układ strony. Linkowanie wewnętrzne zmienia się automatycznie przy zmianie szablonu. Strony, które wcześniej były silnie linkowane z menu, sidebara czy stopki, mogą stracić te linki. A linkowanie wewnętrzne to jeden z kluczowych sygnałów, na podstawie których Google ustala hierarchię stron w serwisie.

Plan migracji SEO: krok po kroku

Poniższy plan zakłada, że migracja techniczna (instalacja PrestaShop 8.x, przeniesienie bazy danych, konfiguracja serwera) jest prowadzona przez dewelopera. Skupiam się na tym, co trzeba zrobić po stronie SEO przed, w trakcie i po migracji.

Krok 1: pełny crawl starego sklepu

Zanim cokolwiek ruszysz, musisz mieć kompletny obraz obecnego stanu. Uruchom crawl całego sklepu w Screaming Frog lub Sitebulb i wyeksportuj:

• wszystkie URL-e (produkty, kategorie, strony CMS, blog, producenci, dostawcy)
• status HTTP każdego URL-a
• tagi canonical
• dyrektywy meta robots (index/noindex, follow/nofollow)
• tagi hreflang (jeśli sklep jest wielojęzyczny)
• meta title i meta description każdej strony
• dane strukturalne (typy i zawartość JSON-LD / Microdata)
• linki wewnętrzne (skąd, dokąd, anchor text)

To jest Twoja mapa referencyjna. Wszystko, co zrobisz dalej, będziesz porównywać z tym stanem.

Dodatkowo wyeksportuj dane z Google Search Console:

• raport wydajności (kliknięcia, wyświetlenia, CTR, pozycja per strona) za ostatnie 12-16 miesięcy
• raport pokrycia indeksu (ile stron zaindeksowanych, ile z błędami)
• raport Core Web Vitals

Te dane pozwolą Ci po migracji porównać “przed” i “po” na twardych liczbach, a nie na wrażeniach.

Krok 2: mapowanie URL-i stary na nowy

To najbardziej czasochłonny i jednocześnie najważniejszy krok. Dla każdego URL-a w starym sklepie musisz ustalić, jaki będzie odpowiadający mu URL w nowym.

W praktyce wygląda to tak:

• eksport wszystkich URL-i ze starego sklepu do arkusza kalkulacyjnego
• konfiguracja struktury URL-i w PrestaShop 8.x (format, prefiksy językowe, rola ID w adresie)
• import bazy produktów i kategorii do nowej instalacji na środowisku staging
• eksport URL-i z nowego sklepu
• połączenie obu list po identyfikatorze produktu/kategorii/strony CMS

Dla sklepu z 5000 produktów i 200 kategoriami to praca na kilka godzin (z pomocą arkusza lub skryptu). Dla sklepu z 50 000 produktów to praca na kilka dni. Nie ma tu drogi na skróty. Każdy pominięty URL to potencjalnie utracona pozycja w Google.

Zwróć szczególną uwagę na:

• produkty wycofane ze sprzedaży - jeśli stary URL miał ruch organiczny, przekieruj go na najbliższą sensowną stronę (kategoria, zamiennik), a nie na stronę główną
• strony CMS - regulamin, polityka prywatności, O nas, Kontakt; te strony często mają linki zewnętrzne
• strony producentów i dostawców - PrestaShop tworzy dla nich dedykowane strony, które mogą mieć pozycje w Google
• URL-e bloga - jeśli stary sklep miał blog z ruchem organicznym, format URL-i blogowych też musi być zmapowany
• URL-e obrazów - jeśli do zdjęć produktów prowadzą linki z zewnątrz (np. z porównywarek), zmiana ścieżki obrazów oznacza utratę tych linków

Krok 3: plan przekierowań 301

Na podstawie mapowania URL-i przygotuj plik z przekierowaniami 301. Każda linia to para: stary URL -> nowy URL.

Przekierowania wdrażaj na poziomie serwera (w pliku .htaccess dla Apache lub w konfiguracji nginx). To najszybsza i najbardziej niezawodna metoda. Moduły PrestaShop do przekierowań działają, ale dodają overhead na poziomie aplikacji (PHP musi się załadować, żeby przetworzyć redirect, zamiast serwer obsłużyć go natychmiast).

Kilka zasad:

• przekierowania 301, nie 302 (301 mówi Google, że zmiana jest permanentna i sygnały rankingowe powinny przejść na nowy URL)
• jeśli stary i nowy URL są identyczne, nie potrzebujesz przekierowania (ale sprawdź, czy na pewno są identyczne, z uwzględnieniem wielkości liter, ukośników na końcu i rozszerzenia .html)
• nie przekierowuj wszystkich starych URL-i na stronę główną (to tak zwany soft 404, Google traktuje to jako błąd)
• uwzględnij URL-e z parametrami (np. ?id_lang=1, ?page=2), które mogą być zaindeksowane

Dla dużych sklepów z tysiącami przekierowań rozważ użycie reguł regex w .htaccess. Na przykład, jeśli jedyna zmiana to usunięcie ID z URL-a:

1
2
3
4
5
6

# Przekierowanie produktów: /123-nazwa-produktu.html -> /nazwa-produktu
RedirectMatch 301 ^/([0-9]+)-(.+)\.html$ /$2

# Przekierowanie kategorii: /pl/12-nazwa-kategorii -> /pl/nazwa-kategorii
RedirectMatch 301 ^/(pl|en)/([0-9]+)-(.+)$ /$1/$3

Reguły regex oszczędzają czas przy typowych, powtarzalnych zmianach formatu. Ale testuj je dokładnie na środowisku staging, bo błąd w regex potrafi przekierować cały sklep w pętlę lub na stronę 404.

Krok 4: audyt danych strukturalnych

Przed migracją sprawdź, jakie dane strukturalne generuje stary sklep. Użyj Google Rich Results Test na kilku reprezentatywnych stronach (produkt, kategoria, strona CMS, wpis blogowy, strona główna).

Następnie sprawdź, co generuje nowy motyw na PrestaShop 8.x (na środowisku staging). Porównaj oba zestawy i upewnij się, że nowy sklep generuje co najmniej te same typy danych strukturalnych, co stary. Jeśli stary motyw miał Product z AggregateRating, a nowy generuje sam Product bez ocen, to jest regresja, którą trzeba naprawić.

W PrestaShop 8.x dane strukturalne najłatwiej wdrożyć przez dedykowany moduł (np. Schema Markup Pro lub SEO Expert). Wybierz jeden moduł i upewnij się, że generuje:

• Product z pełnymi danymi oferty (cena, dostępność, waluta, SKU)
• BreadcrumbList odzwierciedlający hierarchię kategorii
• Organization na stronie głównej
• Article / BlogPosting na wpisach blogowych (jeśli masz blog)

Krok 5: testowanie na środowisku staging

Zanim nowy sklep wejdzie na produkcję, przetestuj go na środowisku staging z perspektywy SEO:

• crawl staging w Screaming Frog (dodaj regułę autoryzacji, bo staging prawdopodobnie jest chroniony hasłem); porównaj wyniki z crawlem starego sklepu
• przekierowania - sprawdź losową próbkę (50-100) starych URL-i i zweryfikuj, że każdy poprawnie przekierowuje na nowy URL z kodem 301
• canonical - upewnij się, że każda strona ma poprawny tag canonical wskazujący na siebie (nie na staging)
• robots.txt - nowy sklep musi mieć poprawny robots.txt (nie blokuj ważnych zasobów); upewnij się, że staging ma Disallow: / (żeby Google go nie zaindeksował), ale produkcja tego nie będzie miała
• sitemap XML - wygeneruj sitemap na staging i sprawdź, czy zawiera wszystkie ważne URL-e w nowym formacie
• dane strukturalne - przetestuj Rich Results Test na staging dla każdego typu strony
• hreflang - jeśli sklep jest wielojęzyczny, zweryfikuj poprawność tagów hreflang
• nawigacja fasetowa - sprawdź, czy filtry w nowym sklepie nie generują niechcianych URL-i z parametrami

Krok 6: uruchomienie (launch day)

Dzień uruchomienia to moment, w którym nowy sklep zastępuje stary na produkcji. Z perspektywy SEO kluczowe czynności:

• wdróż przekierowania przed przełączeniem DNS lub jednocześnie z nim; przekierowania muszą działać od pierwszej sekundy, kiedy nowy sklep jest publicznie dostępny
• zaktualizuj robots.txt - usuń ewentualny Disallow: / (który mógł być na staging) i upewnij się, że plik jest identyczny z planowaną wersją produkcyjną
• wyślij sitemap do GSC - w Google Search Console zgłoś nową sitemap XML; jeśli URL sitemapy się zmienił, zgłoś nowy i usuń stary
• wymuś ponowne indeksowanie kluczowych stron (strona główna, najważniejsze kategorie, bestsellery) przez “Request Indexing” w GSC
• sprawdź, czy HTTPS działa poprawnie - certyfikat SSL, brak mixed content, poprawne przekierowanie HTTP na HTTPS

Najlepszy czas na uruchomienie to wtorek-środa rano. Serio, nie ruszaj tego w piątek. Jeśli coś pójdzie nie tak, nie chcesz debugować w weekend. Poniedziałek też odpada, bo ruch e-commerce jest zwykle najwyższy na początku tygodnia.

Krok 7: monitoring po migracji

Migracja nie kończy się w dniu uruchomienia. Następne trzy miesiące to okres intensywnego monitoringu.

Harmonogram monitoringu po migracji

Tydzień 1: codzienne kontrole

W pierwszym tygodniu sprawdzaj codziennie:

• błędy crawlowania w GSC - nowe błędy 404 i 500 to sygnał, że mapa przekierowań jest niekompletna; każdy błąd wymaga natychmiastowej reakcji
• ruch organiczny w GA4 - porównanie dzień do dnia z analogicznym okresem sprzed migracji; spadek o 10-20% w pierwszych dniach jest normalny (Google musi ponownie przetworzyć strony)
• indeksowanie - w GSC raport “Strony” pokaże, czy Google zaczął indeksować nowe URL-e; szukaj statusu “Zaindeksowane, nie przesłane w mapie witryny” dla nowych URL-i
• działanie przekierowań - testuj codziennie losową próbkę starych URL-i; szukaj łańcuchów przekierowań (redirect chain) i pętli

Miesiąc 1: tygodniowe analizy

Po pierwszym tygodniu przejdź na tygodniowy rytm:

• pozycje kluczowych fraz - porównaj pozycje top 50 fraz z okresu sprzed migracji; frazy, które spadły o więcej niż 5 pozycji, wymagają analizy (czy strona jest zaindeksowana, czy przekierowanie działa, czy treść jest kompletna)
• ruch organiczny per landing page - zidentyfikuj strony, które straciły ruch; sprawdź, czy przekierowanie ze starego URL-a działa poprawnie
• Core Web Vitals - dane CrUX potrzebują ok. 28 dni na zebranie; pod koniec pierwszego miesiąca powinieneś mieć pierwsze porównanie wydajności nowej vs. starej wersji
• dane strukturalne w GSC - raport “Ulepszenia” pokaże, czy Google rozpoznaje nowe dane strukturalne; błędy wymagają natychmiastowej naprawy
• profil linków - sprawdź w Ahrefs lub Semrush, czy linki zewnętrzne prowadzące do starego sklepu poprawnie przekierowują na nowe URL-e

Miesiąc 2-3: stabilizacja

W drugim i trzecim miesiącu ruch organiczny powinien wrócić do poziomu sprzed migracji lub go przekroczyć (dzięki lepszej wydajności nowego sklepu). Jeśli tak się nie dzieje, szukaj przyczyn:

• niezaindeksowane strony - czy wszystkie ważne strony z nowego sklepu są w indeksie Google
• utracone linki - czy linki zewnętrzne nie prowadzą na 404 (bo przekierowanie nie objęło jakiejś grupy URL-i)
• crawl budget - czy Google crawluje nowy sklep z wystarczającą częstotliwością; duże sklepy mogą potrzebować kilku tygodni, zanim Googlebot przeskanuje wszystkie nowe strony
• treść - czy nowy motyw nie ukrył lub nie zmienił treści, która wcześniej generowała ruch (np. opisy kategorii, FAQ na stronach produktowych)

Checklista post-migracyjna

Poniższa lista to minimum do sprawdzenia po uruchomieniu nowego sklepu:

Indeksowanie i crawlowanie

• robots.txt nie blokuje ważnych zasobów
• sitemap.xml zgłoszona w GSC i poprawnie przetworzona
• brak masowych błędów 404 w raporcie pokrycia GSC
• brak łańcuchów przekierowań (max jeden hop: stary URL -> nowy URL)
• canonical na każdej stronie wskazuje poprawny URL

Treść i meta dane

• meta title i description przeniesione ze starego sklepu (nie domyślne szablony)
• opisy kategorii i produktów kompletne (nie ucięte przez nowy motyw)
• tagi H1 poprawne i unikalne na każdej stronie
• atrybuty alt na obrazach przeniesione

Dane strukturalne

• Product z ceną, dostępnością, SKU na stronach produktów
• BreadcrumbList na stronach kategorii i produktów
• Organization na stronie głównej
• walidacja w Rich Results Test dla każdego typu strony

Wydajność

• Core Web Vitals w PageSpeed Insights (cel: zielone metryki na mobile)
• czas odpowiedzi serwera (TTFB) poniżej 600ms
• kompresja Brotli lub GZIP aktywna
• CDN skonfigurowany dla zasobów statycznych

Linkowanie wewnętrzne

• nawigacja główna zawiera linki do najważniejszych kategorii
• breadcrumbs działają i odzwierciedlają hierarchię
• stopka zawiera linki do kluczowych stron (regulamin, kontakt, kategorie)
• linkowanie kontekstowe w treściach (opisy kategorii, blog) działa poprawnie

Czego nie robić przy migracji

Kilka błędów, które regularnie widzę przy migracjach PrestaShop:

Nie zmieniaj domeny jednocześnie z silnikiem. Migracja z 1.6 na 8.x to jeden duży projekt. Zmiana domeny (np. z stary-sklep.pl na nowy-sklep.pl) to drugi. Robienie obu naraz podwaja ryzyko i utrudnia diagnostykę, gdy coś pójdzie nie tak. Jeśli musisz zmienić domenę, zrób to osobno: najpierw migracja na nowy silnik (pod starą domeną), potem po stabilizacji zmiana domeny.

Nie ignoruj starych URL-i z niskim ruchem. Słyszę to na każdej migracji: “Ta strona ma tylko 5 wizyt miesięcznie, nie potrzebuje przekierowania”. To częsty argument. Problem w tym, że 500 takich stron to 2500 wizyt miesięcznie. A każdy 404 to negatywny sygnał dla Google. Przekieruj wszystko, co było zaindeksowane.

Nie wyłączaj starego sklepu przed uruchomieniem nowego. Nie powinno być ani sekundy, w której Twoja domena zwraca błąd. Przełączenie ze starego na nowy sklep powinno być atomowe: jeden moment serwujesz stary kod, w następnym nowy.

Nie polegaj na module SEO z 1.6 na nowym sklepie. Nawet jeśli jakiś moduł “działa” na 8.x, jego wewnętrzna logika i struktura danych mogą być niekompatybilne. Lepiej wybrać nowy moduł dedykowany dla 8.x i zaimportować do niego dane ze starego.

Ile kosztuje migracja i ile trwa

To zależy od rozmiaru sklepu i stopnia customizacji, ale orientacyjne ramy:

• mały sklep (do 1000 produktów, standardowy motyw, 5-10 modułów): 2-4 tygodnie pracy, z czego SEO to ok. 20-30% czasu
• średni sklep (1000-10 000 produktów, motyw niestandardowy, 20+ modułów): 4-8 tygodni, SEO to 25-35% czasu
• duży sklep (10 000+ produktów, wielojęzyczny, integracje z ERP/WMS): 2-4 miesiące, SEO to osobny workstream z dedykowanym specjalistą

Koszt pracy SEO przy migracji obejmuje: audyt przed migracją, mapowanie URL-i, plan przekierowań, konfigurację danych strukturalnych, testowanie na staging i monitoring po uruchomieniu. Dla średniego sklepu to 40-80 godzin pracy specjalisty.

Jeśli planujesz migrację i chcesz mieć pewność, że widoczność organiczna nie ucierpi, skontaktuj się z nami. Mamy doświadczenie z migracjami PrestaShop i wiemy, na co uważać. Więcej o audytach SEO na PrestaShop znajdziesz w artykule o audycie SEO sklepu PrestaShop.

📋 Zobacz checklistę: Checklista migracji PrestaShop - lista kontrolna online: URL-e, przekierowania, dane strukturalne i monitoring po uruchomieniu.

FAQ

Czy migracja z PrestaShop 1.6 na 8.x zawsze powoduje spadek ruchu organicznego?

Krótkoterminowy spadek (10-20% w pierwszych 1-2 tygodniach) jest normalny i wynika z tego, że Google musi ponownie przetworzyć zmienione URL-e i nową strukturę. Przy poprawnie przeprowadzonej migracji (kompletne przekierowania 301, zachowanie treści, działające dane strukturalne) ruch powinien wrócić do normy w ciągu 2-4 tygodni i często przekracza poziom sprzed migracji dzięki lepszej wydajności nowego sklepu.

Czy mogę migrować stopniowo, np. najpierw kategorie, potem produkty?

Technicznie to możliwe, ale w praktyce bardziej ryzykowne niż migracja jednorazowa. Częściowa migracja oznacza, że przez pewien czas sklep działa na dwóch silnikach jednocześnie (np. kategorie na 8.x, produkty na 1.6). To komplikuje zarządzanie przekierowaniami, danymi strukturalnymi i sitemap. Lepiej migrować cały sklep naraz na środowisku staging, przetestować i przełączyć jednym ruchem.

Ile przekierowań 301 może obsłużyć PrestaShop / serwer?

Na poziomie serwera (.htaccess lub nginx) limit praktycznie nie istnieje. Dziesiątki tysięcy przekierowań działają bez zauważalnego wpływu na wydajność, bo serwer przetwarza je przed załadowaniem PHP. Na poziomie modułu PrestaShop limit zależy od implementacji, ale przy tysiącach przekierowań moduły potrafią spowalniać sklep, bo każdy request musi przejść przez listę reguł w PHP. Dlatego preferuj przekierowania na poziomie serwera.

Co zrobić, jeśli po migracji widzę masowe błędy 404 w Search Console?

To sygnał, że mapa przekierowań jest niekompletna. Wyeksportuj listę błędów 404 z GSC, porównaj ze swoją mapą przekierowań i uzupełnij brakujące. Priorytetyzuj URL-e, które miały ruch organiczny lub linki zewnętrzne (sprawdź w Ahrefs/Semrush). Wdróż brakujące przekierowania i wymuś ponowne indeksowanie tych URL-i w GSC. Google powinien przetworzyć nowe przekierowania w ciągu kilku dni.

Czy warto przy okazji migracji zmienić strukturę URL-i na “ładniejszą”?

Tak, ale z pełną świadomością konsekwencji. Migracja to jedyny moment, w którym zmiana struktury URL-i nie generuje dodatkowego kosztu (i tak musisz robić przekierowania). Jeśli stare URL-e zawierały ID numeryczne, rozszerzenia .html czy inne artefakty, migracja to dobra okazja do przejścia na czystszy format. Upewnij się tylko, że nowy format jest stabilny i nie będzie wymagał kolejnej zmiany za rok. Każda zmiana URL to reset sygnałów rankingowych dla danej strony, nawet z poprawnym przekierowaniem 301.