PrestaShop a SEO techniczne: gdzie najczęściej pojawiają się problemy

PrestaShop SEO techniczne: od czego zacząć sprawdzanie sklepu

W PrestaShop problem techniczny rzadko znajduje się w jednym miejscu. Adres produktu może być generowany przez mechanizm linków, canonical może pochodzić z kontrolera lub szablonu, a dodatkową wersję strony może tworzyć moduł filtra albo wyszukiwarki. Dlatego przy sprawdzaniu sklepu nie wystarczy przejść przez kilka ustawień w panelu administracyjnym.

Pierwszy krok to zebranie rzeczywistych adresów, które sklep wystawia do internetu. Sprawdź stronę główną, kategorie, produkty, producentów, strony CMS, wyniki wyszukiwania oraz adresy z parametrami. Następnie porównaj je z tym, co znajduje się w mapie XML, linkach wewnętrznych i kodzie HTML.

Jeżeli sklep ma problemy z błędami serwera, nie ograniczaj diagnostyki do komunikatu wyświetlanego w przeglądarce. Przydatne jest również sprawdzenie logów i odpowiedzi HTTP, ponieważ źródło błędów 500 w sklepie może znajdować się poza samą stroną, na przykład w module, kontrolerze albo konfiguracji serwera.

Przy większym sklepie dobrze zacząć od listy adresów i dopiero potem przechodzić do kodu. Pozwala to zobaczyć, czy problem dotyczy pojedynczych stron, konkretnego typu podstron, czy całego mechanizmu generowania URL.

Adresy URL i routing w PrestaShop

PrestaShop korzysta z własnego mechanizmu generowania adresów. W dokumentacji deweloperskiej opisano komponent Link, który odpowiada między innymi za generowanie adresów produktów, kategorii, modułów i innych stron oraz obsługę przyjaznych URL. W praktyce oznacza to, że problem z adresem nie musi wynikać z samego pola URL widocznego w panelu.

Przy audycie otwórz kilka produktów z różnych kategorii i sprawdź, czy adresy są spójne. Następnie wykonaj to samo dla kategorii, producentów i stron CMS. Zwróć uwagę na końcowe ukośniki, wielkość liter, protokół HTTPS, prefiksy kategorii oraz ewentualne parametry.

Google traktuje różne warianty adresu jako osobne URL-e. Dotyczy to także różnic, które dla użytkownika mogą wyglądać nieistotnie. Jeżeli serwer odpowiada treścią na kilka wariantów adresu, trzeba ustalić, który z nich jest docelowy, a pozostałe odpowiednio obsłużyć.

W praktyce sprawdź:

• czy wersja HTTP przekierowuje na HTTPS,
• czy wersja z www i bez www prowadzi do jednej wersji sklepu,
• czy stare adresy produktów zwracają właściwe przekierowanie lub status,
• czy zmiana nazwy produktu nie pozostawiła kilku działających wariantów URL,
• czy parametry sortowania i filtrowania nie tworzą niekontrolowanej liczby adresów,
• czy linki wewnętrzne prowadzą do preferowanych wersji adresów.

W PrestaShop problem może również powstać po zmianie konfiguracji przyjaznych URL. Po takiej zmianie nie sprawdzaj tylko kilku stron ręcznie. Przejdź przez reprezentatywną próbkę produktów i kategorii, ponieważ błędna konfiguracja routingu może ujawnić się dopiero przy określonym typie strony.

Jeżeli chcesz wiedzieć, jak sprawdzić głębokość kliknięć produktów, przeanalizuj także sposób, w jaki produkty są osiągalne z kategorii i innych elementów nawigacji. Sam poprawny URL nie wystarczy, jeżeli ważna podstrona nie ma logicznej ścieżki linków prowadzących do niej.

Canonical w PrestaShop: gdzie szukać sprzecznych sygnałów

Canonical to jeden z pierwszych elementów, który sprawdzam przy technicznym audycie sklepu. W PrestaShop informacja o canonicalu może być przekazywana do szablonu strony, a następnie umieszczana w sekcji head. Dokumentacja PrestaShop pokazuje zmienną odpowiadającą za canonical oraz sposób jej wykorzystania w szablonie.

Nie zakładaj jednak, że obecność jednego znacznika canonical oznacza poprawną konfigurację. Sprawdź jego wartość na kilku typach stron. Produkt, kategoria, strona producenta i wynik wyszukiwania mogą mieć zupełnie inne problemy.

Na karcie produktu sprawdź, czy canonical wskazuje właściwy adres produktu. Następnie otwórz wariant URL z parametrem, filtrem lub dodatkowym identyfikatorem i zobacz, czy canonical prowadzi do tej samej wersji, którą sklep traktuje jako podstawową.

Szczególnie podejrzane są sytuacje, w których canonical wskazuje jeden adres, sitemap zawiera inny, a linki wewnętrzne prowadzą jeszcze gdzie indziej. Google traktuje canonical jako sygnał, a nie absolutny nakaz. Dlatego przy audycie trzeba sprawdzić cały zestaw sygnałów, a nie tylko pojedynczy tag.

Jeżeli sklep działa w kilku językach, dochodzą kolejne zależności. W takim przypadku przydatna jest analiza błędów canonical w sklepie wielojęzycznym, ponieważ pomylenie wersji językowych może prowadzić do wskazywania niewłaściwego adresu jako preferowanego.

Sprawdzenie canonicala zrób bezpośrednio w kodzie źródłowym. Nie wystarczy patrzeć na pasek adresu. W narzędziach deweloperskich przeglądarki wyszukaj rel="canonical" i zapisz dokładną wartość. Potem porównaj ją z adresem strony, sitemapą oraz linkami wewnętrznymi.

Jeżeli canonical zmienia się po działaniu modułu, filtra albo JavaScriptu, trzeba ustalić, który element go nadpisuje. W tym miejscu często kończy się możliwość rozwiązania problemu samym panelem administracyjnym.

PrestaShop indeksacja i strony, których nie powinno być w Google

PrestaShop może generować znacznie więcej adresów niż właściciel sklepu świadomie publikuje. W wynikach wyszukiwania mogą pojawiać się strony wyszukiwania, filtry, kombinacje parametrów, strony sortowania, niepotrzebne warianty oraz adresy techniczne tworzone przez moduły.

Dlatego podczas audytu nie zaczynaj od pytania, ile produktów znajduje się w sklepie. Najpierw sprawdź, ile różnych typów URL faktycznie odpowiada kodem 200 i które z nich są dostępne dla crawlera.

Dobrym punktem kontroli jest raport indeksowania w Google Search Console. Porównaj adresy znane Google z listą adresów znajdujących się w sitemapie. Jeżeli sitemap zawiera strony, których nie chcesz traktować jako podstawowych, problem leży nie tylko w indeksacji, ale także w sposobie generowania danych przez sklep lub moduł.

Sprawdź również robots.txt, ale nie traktuj go jako zamiennika noindex. Robots.txt kontroluje dostęp crawlera do URL, natomiast nie jest właściwym mechanizmem do usuwania strony z indeksu. Jeżeli strona ma być dostępna dla crawlera, ale nie powinna być indeksowana, trzeba rozważyć odpowiednią dyrektywę noindex.

W PrestaShop szczególnie dokładnie sprawdź wyniki wewnętrznej wyszukiwarki. Takie strony często mają niewielką wartość dla użytkownika z wyszukiwarki, a jednocześnie mogą tworzyć wiele kombinacji adresów. Jeżeli moduł wyszukiwania albo filtrów generuje własne kontrolery, sprawdzenie ustawień SEO może wymagać wejścia w konfigurację modułu, jego kod albo logikę kontrolera.

Przydatne pytanie brzmi: jak zrobić audyt techniczny PrestaShop bez zgadywania? Zacznij od eksportu URL-i, sprawdź statusy HTTP, canonicale, dyrektywy robots, źródła linków i obecność adresów w sitemapie. Dopiero później szukaj przyczyny w kodzie.

Paginacja, filtry i dodatkowe strony kategorii

Paginacja w sklepie może wyglądać poprawnie dla użytkownika, a jednocześnie być źle przygotowana technicznie. Otwórz drugą, trzecią i kolejne strony kategorii. Sprawdź, czy każda z nich ma własny adres, czy linki do kolejnych stron są zwykłymi linkami HTML i czy adres pozostaje stabilny po ponownym załadowaniu.

Nie zakładaj, że przycisk „Pokaż więcej” rozwiązuje problem. Jeżeli kolejne produkty są pobierane wyłącznie po wykonaniu akcji JavaScript, sprawdź, czy crawler może odkryć kolejne adresy. Google zaleca, aby kolejne części paginowanej zawartości miały własne, trwałe URL-e i były połączone linkami, które crawler może odczytać.

W PrestaShop problem często pojawia się przy modułach filtrów. Filtr koloru, rozmiaru, producenta czy ceny może tworzyć osobny adres. Jeżeli każda kombinacja jest dostępna dla crawlera, liczba URL-i rośnie bardzo szybko.

Nie wszystkie takie strony trzeba usuwać. Najpierw ustal, czy dana kombinacja ma własną wartość dla użytkownika i czy ma być stroną indeksowalną. Jeżeli nie, ogranicz sposób jej odkrywania i ustal odpowiednie sygnały indeksacyjne. Nie rób masowego blokowania parametrów bez wcześniejszego sprawdzenia, ponieważ możesz odciąć crawlerowi dostęp do wartościowych stron.

Tabela poniżej pokazuje, gdzie szukać problemu i co sprawdzić w pierwszej kolejności.

Obszar PrestaShop	Typowy problem techniczny	Co sprawdzić	Gdzie szukać przyczyny
URL produktów	Duplikaty adresów lub stare ścieżki	Status HTTP, przekierowania, linki	Konfiguracja URL, routing, kod
Kategorie	Niespójne adresy i paginacja	Kolejne strony, linki, canonical	Szablon, kontroler, moduły
Canonical	Wskazanie niewłaściwego URL	Kod HTML, sitemap, redirect	Kontroler, szablon, moduł
Warianty	Powielone strony produktów	Adresy kombinacji, parametry	Moduł wariantów, szablon
Filtry	Duża liczba dodatkowych URL	Parametry, statusy, indeksacja	Moduł filtrów, routing
Wyszukiwarka	Indeksowane wyniki wyszukiwania	noindex, linki, sitemap	Kontroler, moduł wyszukiwania
Paginacja	Kolejne strony niedostępne dla crawlera	href, URL-e stron	Szablon, JavaScript, moduł
Moduły	Dodatkowe kontrolery i strony	Nowe ścieżki, statusy	Konfiguracja i kod modułu
Sitemap	Adresy niezgodne z preferowaną wersją	Lista URL, canonical	Moduł sitemap, konfiguracja
Robots	Blokowanie niewłaściwych zasobów	Reguły Disallow	robots.txt, moduł, serwer

Warianty produktów i duplikaty treści

Kombinacje produktów są częstym źródłem zamieszania w sklepach PrestaShop. Sam fakt istnienia wariantów nie oznacza jeszcze problemu SEO. Problem zaczyna się wtedy, gdy warianty powodują powstanie wielu adresów, które są dla wyszukiwarki bardzo podobne albo prowadzą do tej samej oferty.

Sprawdź kilka produktów posiadających rozmiary, kolory lub inne kombinacje. Zobacz, czy wybór wariantu zmienia tylko stan strony, czy również adres URL. Jeżeli URL się zmienia, trzeba sprawdzić, czy nowy adres zwraca osobną stronę, jaki ma canonical i czy jest obecny w linkach lub sitemapie.

Następnie sprawdź, czy moduł wariantów nie dodaje własnych parametrów. Niektóre rozszerzenia zmieniają sposób generowania linków albo dodają dodatkowe kontrolery. Wtedy problemu nie znajdziesz w standardowej konfiguracji produktu.

Przy dużym katalogu można szybko znaleźć powtarzalny schemat, porównując adresy produktów z różnymi kombinacjami. Jeżeli wiele adresów prowadzi do bardzo podobnego HTML, przeanalizuj canonical, status HTTP, linkowanie wewnętrzne i obecność w sitemapie. W przypadku bardziej złożonych sklepów przydatne jest też sprawdzenie, jak rozpoznać duplikaty produktów przez warianty, ponieważ źródłem problemu może być sposób obsługi kombinacji, a nie sama karta produktu.

Moduły PrestaShop i dodatkowe strony generowane przez sklep

Moduły są jednym z pierwszych miejsc, które sprawdzam, gdy sklep ma nietypowe problemy z indeksacją. Rozszerzenie może dodawać własny kontroler, generować adresy, modyfikować nagłówki HTML, dodawać linki albo wpływać na routing.

Zrób listę modułów, które mają wpływ na front office. Szczególną uwagę zwróć na wyszukiwarkę, filtry, blog, producentów, przekierowania, integracje zewnętrzne, dane strukturalne i moduły SEO. Nie chodzi o wyłączanie ich po kolei. Chodzi o ustalenie, który moduł odpowiada za konkretny element strony.

Jeżeli podejrzewasz moduł, porównaj kod HTML przed i po jego konfiguracji albo sprawdź, jakie hooki wykorzystuje. W PrestaShop moduły mogą generować własne elementy strony przez hooki i szablony. Jeżeli taki moduł dodaje linki lub zmienia element head, jego konfigurację trzeba analizować razem z szablonem sklepu.

Przydatne jest także sprawdzenie źródła strony, a nie tylko DOM po wykonaniu JavaScript. W przypadku problemów z JS Google przechodzi przez etap renderowania, ale sposób odkrywania linków i treści nadal ma znaczenie. Jeżeli chcesz sprawdzić linki generowane przez JavaScript, zacznij od tego, czy link ma prawidłowy element a i atrybut href, a następnie porównaj źródło i wyrenderowany DOM.

Kiedy panel PrestaShop nie wystarczy

Część problemów można rozwiązać w Back Office. Dotyczy to między innymi podstawowych ustawień produktu, kategorii, przekierowań czy konfiguracji wybranych modułów. Są jednak sytuacje, w których zmiana ustawienia nie wystarczy.

Jeżeli canonical jest generowany nieprawidłowo, trzeba znaleźć miejsce, które go tworzy. Dokumentacja PrestaShop pokazuje, że dane SEO strony są przekazywane do szablonu, a canonical może być ustawiany przez kontroler. Wtedy poprawka może wymagać zmiany modułu, override, kontrolera albo szablonu.

Podobnie wygląda sytuacja z routingiem. Jeżeli konkretny moduł tworzy niepoprawne adresy, samo ustawienie przyjaznych URL nie naprawi logiki tego modułu. Trzeba przeanalizować sposób generowania adresu i ustalić, czy problem leży w trasie, parametrach, kontrolerze czy szablonie.

Zwróć też uwagę na aktualizacje PrestaShop i modułów. Po aktualizacji może zmienić się sposób renderowania head, generowania linków albo działania konkretnego rozszerzenia. Jeżeli sklep po aktualizacji zaczyna tworzyć inne canonicale lub adresy, porównaj kod strony przed zmianą z aktualnym kodem.

W trudniejszych przypadkach audyt powinien więc obejmować cztery warstwy: konfigurację PrestaShop, moduły, szablon oraz kod serwera. Dopiero zestawienie tych elementów pozwala ustalić, gdzie faktycznie powstaje problem.

Jak zrobić audyt techniczny PrestaShop krok po kroku

Jeżeli prowadzisz sklep samodzielnie, nie zaczynaj od poprawiania przypadkowych błędów znalezionych w narzędziu SEO. Najpierw przygotuj próbkę URL-i reprezentującą wszystkie typy stron.

Na początek sprawdź stronę główną, kilka kategorii, kilka produktów, producentów, CMS, wyniki wyszukiwania i adresy z filtrami. Dla każdego URL zanotuj status HTTP, canonical, robots, adres w sitemapie oraz sposób, w jaki strona jest osiągalna z linków wewnętrznych.

Potem przejdź do Search Console. Porównaj dane o indeksowaniu z tym, co sklep rzeczywiście publikuje. Jeżeli Google zna adres, którego nie ma w sitemapie, sprawdź skąd został odkryty. Jeżeli sitemap zawiera adres, którego nie powinno tam być, sprawdź sposób generowania mapy.

Następnie przejdź do modułów. Jeżeli problem występuje tylko na określonym typie strony, sprawdź, jakie moduły są aktywne na tej stronie i jakie elementy HTML modyfikują. Przy problemach z canonicalem porównaj kod źródłowy z wartością widoczną po renderowaniu.

Na końcu sprawdź serwer i routing. Zobacz przekierowania, odpowiedzi HTTP, błędy PHP i logi. Jeżeli pojawiają się nietypowe odpowiedzi, błędy 404 lub 500 albo przekierowania zależne od parametrów, przyczyna może znajdować się poza panelem PrestaShop.

Tak przeprowadzony audyt daje mapę problemów zamiast przypadkowej listy ostrzeżeń. Dopiero na tej podstawie można ustalić, które zmiany zrobić w konfiguracji, które w module, a które w szablonie lub kodzie. Taki audyt pokazuje też, że SEO techniczne w PrestaShop nie sprowadza się do jednej zakładki w panelu administracyjnym.

Co sprawdzić technicznie w PrestaShop przed wdrożeniem zmian

Przed każdą zmianą wykonaj kopię konfiguracji i upewnij się, że wiesz, jaki element chcesz zmienić. Nie modyfikuj kilku mechanizmów jednocześnie, bo później trudno ustalić, który z nich wpłynął na wynik.

Jeżeli zmieniasz URL, sprawdź stary i nowy adres. Jeżeli poprawiasz canonical, porównaj źródło HTML, sitemapę i linkowanie. Jeżeli ograniczasz indeksację, upewnij się, że nie blokujesz crawlerowi dostępu do dyrektywy noindex. Jeżeli zmieniasz filtr albo moduł, sprawdź, jakie nowe adresy zaczyna generować.

Po wdrożeniu ponownie przejdź przez tę samą próbkę URL-i. Sprawdź statusy, canonicale, robots, linki i sitemapę. Przy większych zmianach użyj URL Inspection w Search Console dla najważniejszych stron i obserwuj raporty indeksowania.

Jeżeli analiza pokazuje, że problemy są powiązane z kilkoma warstwami sklepu, audyt techniczny sklepu PrestaShop pozwala przejść od listy błędów do wskazania ich źródła i zakresu wymaganych zmian.

PrestaShop techniczne SEO wymaga przede wszystkim sprawdzenia zależności między konfiguracją, kodem, modułami i tym, co faktycznie widzi crawler. Właśnie dlatego dobry audyt nie kończy się na odczytaniu komunikatów z jednego narzędzia. Trzeba przejść od adresu URL, przez odpowiedź serwera i kod HTML, aż do sposobu, w jaki sklep generuje kolejne strony.