Canonical URL w PrestaShop – jak ustawić poprawne tagi kanoniczne dla produktów z wielu kategorii?

Produkt przypisany do kilku kategorii może być dostępny pod więcej niż jednym adresem URL. Sam fakt przypisania towaru do kategorii nie jest jeszcze problemem SEO. Problem pojawia się wtedy, gdy PrestaShop generuje różne ścieżki prowadzące do tej samej karty produktu, a sklep nie wskazuje jednoznacznie, który adres jest wersją kanoniczną.

Najczęściej wystarczy poprawnie ustawić kategorię domyślną, sprawdzić, jaki adres znajduje się w elemencie <link rel="canonical">, i uporządkować trasę produktu. W większych lub starszych sklepach potrzebne może być dodatkowe przekierowanie 301, moduł albo modyfikacja szablonu. Kluczowe jest dobranie rozwiązania do rzeczywistego problemu, zamiast instalowania kolejnego dodatku bez sprawdzenia, co już robi natywny mechanizm PrestaShop.

Skąd bierze się problem duplikacji produktów przypisanych do wielu kategorii w PrestaShop?

Relacja między kategorią domyślną a kategoriami powiązanymi

W PrestaShop jeden produkt może należeć jednocześnie do wielu kategorii. Przykładowo „Czarna kurtka przeciwdeszczowa” może być przypisana do kategorii Kurtki damskie, Odzież outdoorowa oraz Promocje. Jedna z tych kategorii jest oznaczona jako kategoria domyślna. To nie musi być kategoria, w której produkt został utworzony jako pierwszy ani ta, która znajduje się najwyżej w panelu. Jest to informacja mówiąca sklepowi, którą kategorię traktować jako podstawową przy budowaniu relacji produktu z katalogiem.

W praktyce kategoria domyślna może wpływać na kilka elementów: sposób prezentowania produktu w nawigacji, breadcrumbs, generowanie adresu produktu przy trasach zawierających kategorię oraz wartość używaną przy tworzeniu adresu kanonicznego. Jeżeli produkt ma przypisane trzy kategorie, ale pole domyślnej kategorii wskazuje przypadkową z nich, adres kanoniczny może być zgodny technicznie, lecz niezgodny z przyjętą strukturą SEO sklepu.

Przykład:

• kategoria domyślna: /kurtki-damskie/,
• kategoria dodatkowa: /odziez-outdoorowa/,
• kategoria dodatkowa: /promocje/,
• produkt: czarna-kurtka-przeciwdeszczowa.

Przy schemacie zawierającym kategorię możliwe są adresy podobne do:

• https://sklep.pl/kurtki-damskie/czarna-kurtka-przeciwdeszczowa.html,
• https://sklep.pl/odziez-outdoorowa/czarna-kurtka-przeciwdeszczowa.html,
• https://sklep.pl/promocje/czarna-kurtka-przeciwdeszczowa.html.

Nie każdy z tych adresów musi być faktycznie generowany i indeksowany w identyczny sposób, ponieważ zależy to od wersji PrestaShop, konfiguracji tras, kontrolera, motywu oraz modułów SEO. Przed zmianą ustawień trzeba sprawdzić zachowanie konkretnego sklepu, a nie zakładać, że sama obecność wielu kategorii zawsze oznacza duplikację.

Adres URL nie jest tym samym co tag kanoniczny

Częsty błąd polega na uznaniu, że skoro produkt jest dostępny pod jednym adresem widocznym w przeglądarce, to automatycznie ma poprawny canonical. To dwie odrębne kwestie. Adres URL to lokalizacja, którą użytkownik odwiedza. Tag kanoniczny to deklaracja umieszczona w sekcji <head> dokumentu HTML, wskazująca wyszukiwarce preferowany adres dla danej treści. ^[2]

W kodzie strony element wygląda najczęściej tak:

<link rel="canonical" href="https://sklep.pl/kurtki-damskie/czarna-kurtka-przeciwdeszczowa.html">

Jeżeli otworzysz stronę produktu pod adresem z kategorii Promocje, a canonical wskazuje adres z kategorii Kurtki damskie, nie oznacza to błędu. To może być prawidłowe rozwiązanie: kilka wariantów dostępu prowadzi do jednej preferowanej wersji. Problemem jest natomiast sytuacja, w której każda wersja wskazuje samą siebie, canonical kieruje do nieistniejącego adresu albo różne moduły wstawiają kilka sprzecznych tagów kanonicznych. ^[3]

Jeszcze inny przypadek występuje wtedy, gdy produkt w przeglądarce otwiera się zawsze pod jednym, niezależnym od kategorii adresem, na przykład:

https://sklep.pl/czarna-kurtka-przeciwdeszczowa.html

W takim modelu kategoria może nadal pojawiać się w breadcrumbs i w linkach wewnętrznych, ale nie jest częścią adresu produktu. Ryzyko duplikacji wynikające wyłącznie z kategorii jest wtedy dużo mniejsze.

Wiele ścieżek dostępu a budżet indeksowania

W sklepie internetowym wyszukiwarka odwiedza nie tylko strony produktów. Analizuje również kategorie, filtry, sortowanie, paginację, wyszukiwanie wewnętrzne, warianty adresów oraz linki umieszczone w menu i modułach. Jeżeli ten sam produkt jest dostępny pod wieloma ścieżkami, robot może wielokrotnie pobierać niemal identyczny dokument.

Nie oznacza to automatycznie kary ani „filtra za duplikację”. Wyszukiwarka potrafi sama wybrać adres kanoniczny, ale nie zawsze wybiera ten, który odpowiada właścicielowi sklepu. Niespójne adresy mogą powodować:

• rozproszenie sygnałów z linków wewnętrznych,
• indeksowanie mniej pożądanej wersji adresu,
• częstsze pobieranie duplikatów zamiast nowych lub zmienionych stron,
• bałagan w raportach dotyczących indeksowania,
• problemy z analizą widoczności produktu i przypisywaniem danych do jednego URL.

Canonical jest wskazówką, a nie absolutnym nakazem. Jeżeli tag kanoniczny wskazuje adres z przekierowaniem, stronę błędną, wersję bez właściwego protokołu albo URL różniący się treścią, wyszukiwarka może go zignorować. Dlatego canonical powinien być częścią spójnego systemu obejmującego adresy, przekierowania, linkowanie wewnętrzne i mapę XML. ^[4]

Jak PrestaShop 1.7 i 8.x zwykle generuje rel canonical

W standardowej instalacji PrestaShop mechanizm canonical dla strony produktu jest tworzony przez kontroler i szablon strony, z uwzględnieniem bieżącej konfiguracji adresów oraz danych produktu. W zależności od wersji, motywu i użytych modułów adres może być budowany na podstawie trasy produktu, kategorii domyślnej albo niezależnego identyfikatora produktu.

W PrestaShop 1.7 oraz 8.x nie należy zakładać, że każde środowisko zachowuje się identycznie. Aktualizacja motywu, modułu SEO, modułu przyjaznych adresów lub modyfikacja plików szablonu może zmienić wynik. Różnice mogą dotyczyć także trybu wielosklepowego, języków i domen dla poszczególnych wersji językowych.

Najprostsza kontrola polega na otwarciu kilku wersji adresu produktu i użyciu funkcji „Wyświetl źródło strony”, a następnie wyszukaniu frazy canonical. Trzeba sprawdzić:

• czy występuje dokładnie jeden tag rel="canonical",
• czy adres jest absolutny i używa właściwej domeny,
• czy odpowiada wersji HTTPS,
• czy nie zawiera niepożądanych parametrów,
• czy prowadzi do strony zwracającej kod 200,
• czy wszystkie warianty produktu wskazują logicznie wybraną wersję.

Wariant 1: domyślna konfiguracja PrestaShop i pilnowanie kategorii głównej

Jak działa rozwiązanie bez dodatkowego kodu

Najtańszym sposobem jest pozostawienie natywnego mechanizmu PrestaShop i uporządkowanie pola Kategoria domyślna przy każdym produkcie. W edycji produktu trzeba sprawdzić listę przypisanych kategorii, wybrać właściwą kategorię główną, zapisać produkt, a następnie wyczyścić pamięć podręczną, jeżeli sklep korzysta z cache szablonów lub cache aplikacji.

Ten wariant ma sens wtedy, gdy obecna konfiguracja tras jest poprawna, a problem wynika głównie z przypadkowego przypisywania kategorii. Nie trzeba wtedy instalować modułu canonical PrestaShop ani zmieniać plików motywu. Zyskujemy rozwiązanie zgodne z mechanizmem platformy, łatwiejsze do utrzymania po aktualizacjach i niewymagające dodatkowego procesu na serwerze.

Przykładowa procedura dla pojedynczego produktu wygląda następująco:

1. Otwórz produkt w panelu administracyjnym.
2. Przejdź do sekcji kategorii.
3. Zostaw zaznaczone wszystkie kategorie, w których produkt ma być widoczny.
4. Ustaw kategorię, która ma być główną ścieżką katalogową, jako domyślną.
5. Zapisz produkt.
6. Wyczyść cache PrestaShop i cache serwera, jeśli jest używany.
7. Sprawdź źródło strony oraz adres canonical.

Wybór kategorii domyślnej powinien wynikać z logiki katalogu, a nie wyłącznie z nazwy kategorii. Jeśli sklep sprzedaje sprzęt turystyczny, produkt może być przypisany do „Namioty”, „Camping” i „Promocje”. Jeżeli głównym miejscem prezentacji jest „Namioty”, ta kategoria powinna być bazą dla adresu, breadcrumbs i canonical. Kategoria „Promocje” może pozostać dodatkowym wejściem do produktu, ale nie powinna przejmować głównej identyfikacji produktu tylko dlatego, że produkt jest chwilowo przeceniony.

Korzyści i ograniczenia wariantu bezkosztowego

Największą zaletą jest zerowy koszt wdrożenia. Nie trzeba kupować modułu, zlecać modyfikacji programiście ani utrzymywać własnego override’u. Nie dochodzi też kolejna warstwa logiki, która może spowalniać generowanie strony lub kolidować z modułem SEO.

Ograniczeniem jest ryzyko błędu ludzkiego. Przy ręcznym dodawaniu produktów ktoś może oznaczyć jako domyślną kategorię kampanii, sezonu albo producenta. Jeszcze częściej problem powstaje przy imporcie CSV lub integracji z hurtownią. Import może nadpisać powiązania kategorii, ustawić pierwszą kategorię z pliku jako domyślną albo pozostawić niepełne dane.

W sklepie prowadzonym przez kilka osób potrzebna jest prosta reguła redakcyjna: każdemu produktowi przypisujemy jedną kategorię katalogową jako domyślną, a pozostałe traktujemy jako dodatkowe miejsca ekspozycji. Takie ustalenie jest tańsze niż późniejsze naprawianie setek adresów i analizowanie, dlaczego Google wybrał inną wersję URL.

Kiedy ten model wystarczy

Wariant pierwszy jest odpowiedni dla małego lub średniego sklepu, który:

• nie ma tysięcy produktów importowanych codziennie,
• nie przechodzi właśnie migracji adresów,
• ma jedną spójną domenę i jeden główny język,
• korzysta z działającego, niewadliwego motywu,
• może kontrolować kategorię domyślną podczas dodawania produktów.

Wariant 2: uproszczenie globalnego schematu adresów URL produktów

Na czym polega adres niezależny od kategorii

Drugi model zakłada, że adres produktu nie zawiera ścieżki kategorii. Zamiast kilku potencjalnych wariantów zależnych od miejsca ekspozycji produkt otrzymuje jeden, stały URL, na przykład:

https://sklep.pl/czarna-kurtka-przeciwdeszczowa.html

Kategorie nadal mogą być używane w menu, breadcrumbs, filtrach i linkach wewnętrznych. Nie są jednak elementem adresu strony produktu. Niezależnie od tego, czy użytkownik przejdzie do produktu z kategorii „Kurtki damskie”, „Odzież outdoorowa” czy „Promocje”, docelowa strona będzie miała ten sam adres.

W takim układzie canonical produktu może wskazywać jego niezależny URL, a nie adres uzależniony od kategorii domyślnej. Ogranicza to liczbę równorzędnych adresów prowadzących do tej samej treści i upraszcza zarządzanie linkowaniem wewnętrznym. ^[1]

Trzeba jednak odróżnić dwie sytuacje. Jeśli sklep od początku korzysta z prostego schematu adresów, jego utrzymanie jest stosunkowo łatwe. Jeżeli natomiast działający sklep ma już adresy zawierające kategorie, przejście na nowy model jest migracją URL-i, a nie zwykłą zmianą jednego pola w panelu.

Zalety uproszczonego schematu

Najważniejszą korzyścią jest jednoznaczna identyfikacja produktu. Nazwa kategorii nie wpływa na URL, więc zmiana kategorii domyślnej, przeniesienie produktu do innego działu albo dodanie go do kampanii nie musi tworzyć kolejnej wersji adresu.

• Mniejsze ryzyko duplikacji adresów – wiele kategorii nie powoduje automatycznie powstawania wielu URL-i produktu.
• Łatwiejsze linkowanie – menu, moduły, wyszukiwarka wewnętrzna i rekomendacje mogą wskazywać ten sam adres.
• Prostsze raportowanie – dane dotyczące widoczności i ruchu są skupione wokół jednego URL-a.
• Większa odporność na zmiany katalogu – przeniesienie produktu między kategoriami nie musi zmieniać jego adresu.
• Prostsza obsługa produktów promowanych – kategoria „Promocje” lub „Nowości” może być miejscem ekspozycji bez wpływu na główny adres produktu.

Ten model ogranicza również zależność między strukturą SEO a organizacją katalogu. Kategorie mogą być zmieniane ze względów biznesowych, sezonowych lub sprzedażowych, bez konieczności traktowania każdej zmiany jako potencjalnej zmiany adresu produktu.

Ograniczenia i ryzyko migracji

Uproszczenie adresów nie rozwiązuje wszystkich problemów automatycznie. Nadal trzeba sprawdzić, czy PrestaShop, motyw oraz moduły generują jeden zgodny canonical. Niezależny URL będzie korzystny tylko wtedy, gdy linki wewnętrzne, mapa XML, przekierowania i tag kanoniczny wskazują ten sam model.

Największe ryzyko pojawia się przy zmianie istniejącego sklepu. Jeżeli wcześniej produkt był dostępny pod adresem zawierającym kategorię, zmiana schematu może doprowadzić do powstania nowych URL-i. Wtedy należy:

• ustalić docelowy adres dla każdego produktu,
• przygotować przekierowania 301 ze starych adresów,
• zaktualizować linki wewnętrzne,
• sprawdzić adresy w mapie XML,
• zweryfikować canonical po wdrożeniu,
• przetestować strony produktów, które mają wiele kategorii,
• obserwować błędy indeksowania i przekierowania po publikacji zmian.

Nie należy kierować wszystkich starych adresów na stronę główną ani na ogólną kategorię. Przekierowanie powinno prowadzić do odpowiadającego mu produktu, o ile produkt nadal istnieje. Jeśli produkt został usunięty i nie ma bliskiego zamiennika, właściwe działanie może być inne niż automatyczne kierowanie na przypadkowy URL.

Trzeba też uważać na moduły, które samodzielnie budują adresy lub canonical. Moduł SEO, integracja z systemem ERP, generator mapy XML albo niestandardowy motyw może nadal używać starego schematu. Po zmianie konfiguracji warto sprawdzić nie tylko panel administracyjny, lecz także rzeczywisty HTML odpowiedzi serwera.

Dla jakich sklepów ten wariant ma sens

Model z adresem niezależnym od kategorii jest szczególnie uzasadniony, gdy:

• produkty są często przypisywane do wielu kategorii,
• katalog jest regularnie przebudowywany,
• te same produkty pojawiają się w kampaniach, kolekcjach i kategoriach sezonowych,
• sklep korzysta z automatycznych importów lub integracji,
• występują problemy z niespójnymi adresami produktów,
• planowana jest większa przebudowa struktury kategorii,
• właściciel chce utrzymywać jeden stabilny URL produktu przez cały jego cykl sprzedaży.

To rozwiązanie jest również praktyczne w dużym katalogu, w którym ręczne pilnowanie kategorii domyślnej byłoby trudne. Nie eliminuje potrzeby kontroli danych, ale zmniejsza liczbę zależności, które trzeba utrzymywać przy imporcie i aktualizacji produktów.

Porównanie obu wariantów

Jak wybrać właściwy model

Jeśli sklep ma niewielką lub średnią liczbę produktów, a adresy działają poprawnie, nie ma potrzeby przebudowywania schematu tylko dlatego, że produkty należą do kilku kategorii. W takiej sytuacji rozsądniejszy będzie wariant pierwszy: uporządkowanie kategorii domyślnej, kontrola importów oraz okresowa weryfikacja canonical.

Wariant drugi warto rozważyć wtedy, gdy kategoria jest przede wszystkim miejscem ekspozycji, a nie częścią trwałej tożsamości produktu. Dotyczy to między innymi sklepów, w których jeden produkt może jednocześnie należeć do działu produktowego, kolekcji sezonowej, kampanii promocyjnej i kategorii producenta.

Przed decyzją należy sprawdzić trzy kwestie:

1. Jak wyglądają obecne adresy? Ustal, czy produkt rzeczywiście ma wiele dostępnych URL-i, czy tylko wiele miejsc wejścia prowadzących do tego samego adresu.
2. Co wskazuje canonical? Zweryfikuj, czy tag kanoniczny jest pojedynczy, spójny i prowadzi do działającej wersji produktu.
3. Jak często zmienia się katalog? Im częściej produkty są przenoszone, importowane lub dodawane do kampanii, tym większą wartość ma niezależny adres.

Najbezpieczniejsza rekomendacja dla działającego sklepu brzmi: nie zmieniaj globalnego schematu URL bez potwierdzenia, że obecny model faktycznie generuje problem. Jeżeli canonical i adresy są spójne, zacznij od wariantu natywnego. Jeżeli natomiast sklep ma wiele wariantów adresów, regularne zmiany kategorii i trudne do opanowania importy, niezależny od kategorii URL może być trwalszym rozwiązaniem, ale powinien zostać wdrożony jako zaplanowana migracja, z przekierowaniami i kontrolą wszystkich elementów indeksowania.

Praktyczny wybór rozwiązania w zależności od sytuacji sklepu

Nie każdy sklep powinien dążyć do tego samego modelu adresów. Decyzję warto powiązać z tym, jak powstają produkty, kto zarządza katalogiem i jak często zmienia się struktura kategorii.

Jak wdrożyć wybrany wariant bez niespójności

Po wyborze modelu należy ustalić jedną zasadę obowiązującą dla całej instalacji. Nie wystarczy zmienić sposób generowania linków w jednym miejscu, jeśli motyw, moduł SEO i mapa XML nadal korzystają z innych adresów.

Przy pozostaniu przy wariancie natywnym warto utrzymać spójność między kategorią domyślną a adresem produktu oraz ograniczyć ręczne nadpisywanie tych danych. Szczególnej uwagi wymagają importy, ponieważ mogą zastępować wcześniejsze wartości albo przypisywać produkt do nowej kategorii według reguł, których nie widać w panelu administracyjnym.

Przy przejściu na URL niezależny od kategorii punktem odniesienia powinien być jeden docelowy adres każdego produktu. Dopiero do tej listy należy dopasować przekierowania, linki wewnętrzne, wpisy w mapie XML i wartości generowane w kodzie strony. Dzięki temu można odróżnić planowaną zmianę adresu od przypadkowego powstania kolejnej wersji URL.

W obu wariantach warto sprawdzić kilka reprezentatywnych grup produktów:

• produkt należący tylko do jednej kategorii,
• produkt przypisany do kilku kategorii o różnych poziomach zagnieżdżenia,
• produkt dodany do kategorii promocyjnej lub sezonowej,
• produkt utworzony albo zaktualizowany przez import,
• produkt, którego kategoria domyślna została później zmieniona.

Takie testy pozwalają sprawdzić rzeczywiste zachowanie sklepu, a nie tylko ustawienia widoczne w panelu. Najważniejsze jest, aby niezależnie od miejsca wejścia użytkownik i robot trafiali do ustalonego adresu produktu, a pozostałe elementy strony nie wskazywały równolegle konkurencyjnych wersji.

Rekomendacja dla istniejącego sklepu PrestaShop

W działającym sklepie pierwszym wyborem powinno być utrzymanie obecnego modelu, jeśli adresy produktów są stabilne, canonical jest prawidłowy, a zmiany kategorii nie powodują problemów z indeksowaniem. W takim przypadku wystarczy uporządkować pracę z kategorią domyślną i monitorować produkty obsługiwane automatycznie.

URL niezależny od kategorii warto wybrać wtedy, gdy problemy wynikają z samej zależności adresu od struktury katalogu albo gdy sklep będzie regularnie zmieniał kategorie, kolekcje i miejsca ekspozycji. Wdrożenie powinno wtedy obejmować nie tylko konfigurację PrestaShop, lecz także pełną obsługę starych adresów i weryfikację wszystkich źródeł linkowania.

Najważniejszym kryterium nie jest więc liczba kategorii przypisanych do produktu, lecz faktyczna spójność adresów, canonical oraz procesów, które tworzą i aktualizują URL-e. Dopiero na tej podstawie można zdecydować, czy wystarczy natywna konfiguracja, czy potrzebny jest niezależny schemat adresów wdrożony w ramach kontrolowanej migracji.

Źródła

• [1] Google Search Central – Ecommerce URL Structure Best Practices
• [2] Google Search Central – How to Specify a Canonical with rel=”canonical” and Other Methods
• [3] PrestaShop Help Center – SEO Expert (Search Engine Optimization) – PrestaShop
• [4] Google Search Central – Fix Canonicalization Issues