Aktualizacja PrestaShop 1.7 bez utraty ruchu z Google. Co sprawdzić przed migracją i po niej

Aktualizacja sklepu z PrestaShop 1.7 do wersji 8 albo 9 nie musi kosztować pozycji w Google, jeśli przed startem zapiszesz, jak sklep wygląda dziś w wyszukiwarce, i zachowasz stare adresy albo przygotujesz pełną mapę przekierowań 301, a po przełączeniu przez kilka tygodni będziesz pilnować raportów w Search Console i Merchant Center. 

Techniczną stronę takiej aktualizacji, czyli kopie, testy, moduły i wybór między wersją 8 a 9, opisaliśmy w poradniku o aktualizacji PrestaShop 1.7. Równolegle trzeba zadbać o drugą połowę tej pracy, czyli o to, co w tym czasie dzieje się z widocznością sklepu w Google.

Weźmy przykładowy sklep z narzędziami ogrodowymi, który od kilku lat stoi na 1.7.8: cztery tysiące produktów, filtry po marce, rodzaju zasilania i cenie, adresy w rodzaju /kosiarki/1532-kosiarka-spalinowa.html. Producent zapowiedział koniec wsparcia gałęzi 1.7 z wydaniem PrestaShop 9.0, które ukazało się w czerwcu 2025 roku, więc właściciel zleca aktualizację. W zleceniu jest szablon, są moduły i płatności, a o adresach, przekierowaniach i Search Console nie ma nic. Podobnie wyglądało choćby zlecenie aktualizacji sklepu z wersji 1.7.8.8, opublikowane wiosną 2026 roku w jednym z polskich serwisów dla freelancerów.

Dlaczego dla Google to przeprowadzka, a nie łatka?

Szablony z wersji 1.7 nie działają na wersjach 8 i nowszych, więc aktualizacja prawie zawsze kończy się nowym motywem. Właściciel widzi przede wszystkim nowy wygląd, a Google dostaje nowy kod każdej strony w sklepie: nagłówków, nawigacji i danych produktu. Zmienić się mogą nawet adresy zdjęć, bo nowy motyw może używać innych rozmiarów obrazów. Dlatego traktujemy taką aktualizację jak uruchomienie nowego sklepu i planujemy ją tak samo jak przeprowadzkę na nową domenę, z listą adresów, mapą przekierowań i okresem obserwacji po starcie.

Migracja to także najtańszy moment na porządki SEO, bo przed startem ktoś i tak sprawdza w nowym sklepie każdą ważną ścieżkę: koszyk, płatności, wysyłki, maile. Dołożenie do tych testów punktów pod wyszukiwarkę kosztuje mniej niż ich nadrabianie po starcie, kiedy po spadku ruchu trzeba odtwarzać, jak sklep wyglądał przed zmianą.

Czy adresy produktów się zmienią?

To zależy od drogi, którą wybierzesz. W wersjach 1.7 i 8 domyślny wzorzec adresu produktu zawiera kategorię, jak we wspomnianym adresie /kosiarki/1532-kosiarka-spalinowa.html. W wersji 9.0 twórcy PrestaShop zmienili domyślny wzorzec na krótszy, bez kategorii, więc ten sam produkt w świeżo zainstalowanym sklepie dostaje adres /1532-kosiarka-spalinowa.html, którego Google wcześniej nie znał.

Przy aktualizacji działającego sklepu za pomocą modułu Update Assistant (dawniej 1-Click Upgrade) aktualna wersja skryptu zapisuje stary wzorzec jako własne ustawienie sklepu, więc adresy produktów powinny zostać bez zmian. W listopadzie 2025 roku twórcy potwierdzili jednak błąd, przez który aktualizacja z 8.2 do 9.0 zmieniała adresy produktów, a stare linki dawały błąd 404 bez żadnego przekierowania. Poprawkę scalono w repozytorium modułu dzień później, więc jeśli Twój sklep przechodził na 9.0 starszą wersją Update Assistant, między czerwcem a listopadem 2025 roku, sprawdź, czy adresy produktów nie straciły kategorii.

Druga droga to czysta instalacja nowej wersji i import danych, wybierana na przykład wtedy, gdy nie chcesz przenosić „śmieci” ze starego sklepu. Wtedy produkty dostają nowy wzorzec adresu. Wzorzec z kategorią da się przywrócić w ustawieniach, ale jeśli import nie zachowa numerów ID, zmienią się także liczby w adresach. Właścicielka jednego ze sklepów opisała na polskim forum PrestaShop taki scenariusz: przeszła na 9.1 przez czystą instalację, produkty dodała od nowa i stare linki przestały działać. Stary serwer zdążyła już usunąć, więc nie miała nawet listy dawnych adresów. Czy da się to później odkręcić? Częściowo tak, ale stare adresy trzeba wtedy wyszukiwać w raportach błędów i archiwach internetu.

Co przygotować, zanim ktokolwiek przełączy sklep?

Mapę przekierowań przygotowujemy przed startem, nie po nim, a po przełączeniu sprawdzamy już tylko, czy plan zadziałał. W przykładowym sklepie ogrodniczym lista przygotowań wygląda tak:

1. Eksport z Search Console: strony z kliknięciami i wyświetleniami z ostatnich miesięcy oraz zapytania, przy których sklep pojawia się w wynikach. To Twoje „zdjęcie przed”, z którym porównasz wyniki po starcie.
2. Pełna lista adresów starego sklepu, czyli skan całego serwisu narzędziem w rodzaju Screaming Frog oraz kopia aktualnej mapy XML. Bez tej listy nie zbudujesz przekierowań, a po wyłączeniu starego serwera nie odtworzysz jej w całości.
3. Mapa przekierowań 1:1, w której każdy stary adres produktu, kategorii i strony informacyjnej wskazuje na swój odpowiednik w nowym sklepie. Nie kieruj wszystkiego na stronę główną. Google w zaleceniach dla migracji mówi o mapowaniu starych adresów na nowe.
4. Plan dla produktów wycofanych. Karta produktu pozwala ustawić przekierowanie do innego produktu albo kategorii, a od wersji 8 także kod 410, ale działa to tylko dla produktów, które nadal są w bazie. Produkt usunięty przy przenosinach nie ma już przekierowania i zwróci błąd.
5. Zabezpieczenie środowiska testowego. Google zaleca chronić hasłem treści, których nie chcesz pokazywać w wynikach, więc kopia sklepu na subdomenie powinna mieć hasło, a nie tylko noindex, który ktoś może przenieść razem z ustawieniami na działający sklep.

Sam rdzeń PrestaShop nie ma narzędzia do przekierowań z dowolnego starego adresu na dowolny nowy, a jego dokumentacja SEO takiego narzędzia nie opisuje, więc mapę wdraża się regułami po stronie serwera albo modułem do przekierowań. Przy okazji sprawdź w ustawieniach SEO i adresów URL opcję przekierowania do adresu kanonicznego. Przy świeżej instalacji jej domyślna wartość to 302, czyli przekierowanie tymczasowe, które Google traktuje jako słaby sygnał. Sam panel PrestaShop podpowiada, żeby po uruchomieniu sklepu przełączyć ją na 301.

Co z filtrami po przejściu na wersję 9?

Filtry w PrestaShop zapisują wybrane opcje w parametrze q, więc każda kombinacja marki, zasilania i ceny tworzy osobny adres. W dużym katalogu to tysiące stron o prawie tej samej treści. Na anglojęzycznym forum PrestaShop właściciel sklepu z około pięcioma tysiącami produktów w wersji 8.1.5 opisał ponad 36 tysięcy adresów z filtrów zgłoszonych w Search Console, mimo blokady w robots.txt.

Wersja 9.0 zmienia tu sporo, bo od niej strony z parametrem filtrów albo sortowania dostają znacznik noindex. To zmiana w rdzeniu, a nie w module filtrów, więc sklep na gałęzi 8 jej nie ma, nawet z najnowszym modułem. Zadziała to jednak tylko wtedy, gdy motyw wystawia ten znacznik, a część starszych motywów ma znacznik meta robots wpisany na sztywno i nadpisuje to, co podaje rdzeń.

W wersji 9 wygenerowany na nowo plik robots.txt blokuje też adresy z parametrem q. Tymczasem według Google znacznik noindex działa tylko na stronie, której robots.txt nie blokuje, bo robot musi na nią wejść, żeby ten znacznik odczytać. Jeśli adresy z filtrami już są w indeksie, regułę dla q lepiej dopisać do robots.txt dopiero wtedy, gdy znikną z raportu. Pamiętaj też, że ponowne wygenerowanie robots.txt z panelu kasuje wszystko, co ktoś dopisał do pliku ręcznie.

Po przejściu na 9 liczba zaindeksowanych stron może więc wyraźnie spaść i nie musi to być powód do niepokoju, jeśli z indeksu znikają właśnie adresy z filtrami. Patrzeć trzeba na strony produktów i kategorii, bo to one przynoszą ruch, i to ich liczba ma zostać na poziomie sprzed migracji.

Na co patrzeć w Search Console w pierwszych tygodniach?

Google uprzedza, że przy zmianie adresów pozycje przez jakiś czas się wahają, a w serwisie średniej wielkości mija kilka tygodni albo więcej, zanim w wynikach pojawią się nowe adresy. W tym czasie o sytuacji Twojego sklepu najwięcej mówią trzy miejsca:

• raport Indeksowanie stron, w którym sprawdzasz, czy rośnie liczba błędów 404 i czy produkty z Twojego „zdjęcia przed” są nadal zaindeksowane,
• raport Mapy witryn, w którym zgłaszasz nową mapę XML i obserwujesz, ile adresów z niej trafia do indeksu,
• narzędzie do sprawdzania adresów URL, w którym ręcznie przechodzisz przez kilkadziesiąt produktów i kategorii z największym ruchem.

Czytając błędy 404, weź pod uwagę, że kategorie wyłączone w starym sklepie dawały dotąd 404, a według skryptu aktualizacji do wersji 9 domyślnie przekierowują kodem 301 do kategorii nadrzędnej. W przykładowym sklepie wyłączona kiedyś podkategoria kosiarek zacznie więc prowadzić do swojej kategorii nadrzędnej, a jej błąd zniknie z raportu.

Dwie rzeczy warto sprawdzić osobno: nagłówki i dane strukturalne. Zarówno stary motyw Classic, jak i nowy domyślny motyw Hummingbird mają na stronie kategorii więcej niż jeden nagłówek H1, na przykład w miniaturach podkategorii, więc porównaj skan sklepu sprzed zmiany ze skanem po niej. Dane strukturalne w wersji 9.2 generuje już rdzeń PrestaShop, więc moduł SEO, który dodaje własne, może je zdublować. Poprawka kodowania znaków (także polskich) w cechach produktu w tych danych jest zaplanowana dopiero na wersję 9.2.1, dlatego kilka kart produktu przepuść przez Test wyników z elementami rozszerzonymi.

Merchant Center po zmianie adresów

Jeśli sklep prowadzi kampanie produktowe, błędy w adresach odbiją się też w Merchant Center. Google wycofuje produkt z reklam i z bezpłatnych informacji o produktach, gdy strona docelowa zwraca 404, błąd serwera albo więcej niż dwa przekierowania. Po naprawie błąd powinien zniknąć w ciągu paru dni. Według Google link produktu zmienia się wtedy, gdy przenosi się strona docelowa, więc plik produktowy powinien po starcie wskazywać od razu nowe adresy.

Sprawdź też, z czego Twój moduł buduje identyfikator produktu w pliku dla Merchant Center. Jeśli z numeru ID w sklepie, czysta instalacja z nowymi numerami zmieni go w całym katalogu, w przykładowym sklepie ogrodniczym dla wszystkich czterech tysięcy produktów. Google prosi, żeby raz nadanego identyfikatora nie zmieniać, bo zmiana nadpisuje produkt razem z jego historią.

Trzy pytania przed podpisaniem zlecenia

Zanim zaakceptujesz wycenę aktualizacji, zadaj wykonawcy i sobie trzy pytania. Czy po aktualizacji adresy produktów i kategorii zostaną takie same, a jeśli nie, kto przygotuje mapę przekierowań i kiedy? Kto przed startem wyeksportuje listę starych adresów i dane z Search Console? Kto przez pierwsze tygodnie po przełączeniu będzie patrzył w raporty i reagował na błędy?

Najczęstsze pytania

Czy przejście przez wersję 8 zmienia coś w adresach?

Samo przejście na 8 nie, bo domyślne wzorce adresów w wersjach 1.7 i 8 są takie same, a zmiana wzorca produktu dotyczy dopiero wersji 9. Sklep z naszego przykładu, który stoi na 1.7.8, i tak przejdzie zwykle przez gałąź 8, bo 1.7.8 działa na PHP najwyżej 7.4, a wersja 9 wymaga co najmniej PHP 8.1. Adresy i przekierowania sprawdź po każdym kroku, a najdokładniej po przejściu na 9.

Czy po migracji spadek ruchu jest nieunikniony?

Wahania są normalne i Google sam o nich uprzedza. Jeśli spadek się utrzymuje, zacznij od błędów 404 w raporcie Indeksowanie stron i porównaj je z listą stron, które przed startem miały ruch.

Jak długo trzymać przekierowania ze starych adresów?

Według Google możliwie długo, zwykle co najmniej rok. Do starych adresów prowadzą linki z innych stron, zakładki klientów i stare kampanie, a bez przekierowań każde takie wejście kończy się błędem 404.

Autorem tekstu jest zespół agencji digitalk, która prowadzi SEO i kampanie dla sklepów internetowych. Więcej o tym, jak wygląda pozycjonowanie sklepu na PrestaShop i od czego zaczynamy przy przejmowaniu takiego sklepu, piszemy na naszym blogu.

Bibliografia

1. Google, Site moves with URL changes, „Google Search Central”, developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes [dostęp: 22.10.2026]. 
2. Google, How HTTP status codes, and network and DNS errors affect Google Search, „Google Search Central”, developers.google.com/search/docs/crawling-indexing/http-network-errors [dostęp: 22.10.2026]. 
3. Google, Block Search indexing with noindex, „Google Search Central”, developers.google.com/search/docs/crawling-indexing/block-indexing [dostęp: 22.10.2026]. 
4. Google, Control what you share with Google, „Google Search Central”, developers.google.com/search/docs/crawling-indexing/control-what-you-share [dostęp: 22.10.2026]. 
5. Google, Raport Indeksowanie stron, „Centrum pomocy Search Console”, support.google.com/webmasters/answer/7440203?hl=pl [dostęp: 22.10.2026]. 
6. Google, Unavailable landing page, „Pomoc Google Merchant Center”, support.google.com/merchants/answer/6098155 [dostęp: 22.10.2026]. 
7. Google, specyfikacja atrybutów id i link, „Pomoc Google Merchant Center”, support.google.com/merchants/answer/6324405 i support.google.com/merchants/answer/6324416 [dostęp: 22.10.2026]. 
8. PrestaShop, PrestaShop 9.0 is available, „PrestaShop Project”, build.prestashop-project.org/news/2025/prestashop-9-0-available [dostęp: 22.10.2026]. 
9. PrestaShop, System requirements, „PrestaShop Developer Documentation”, devdocs.prestashop-project.org/9/basics/installation/system-requirements [dostęp: 22.10.2026]. 
10. PrestaShop, Do not index filtered pages (PR 37066), „GitHub”, github.com/PrestaShop/PrestaShop/pull/37066 [dostęp: 22.10.2026]. 
11. PrestaShop, zgłoszenie 40063 o zmianie adresów produktów po aktualizacji do 9.0, „GitHub”, github.com/PrestaShop/PrestaShop/issues/40063 [dostęp: 22.10.2026]. 
12. PrestaShop, poprawka utrwalająca dotychczasową ścieżkę produktu (PR 1535), „GitHub”, github.com/PrestaShop/autoupgrade/pull/1535 [dostęp: 22.10.2026].