Co canonical robi, a czego nie robi

Tag informuje wyszukiwarkę, że wśród kilku adresów o tej samej albo bardzo podobnej treści jeden jest wersją podstawową. Skutki są dwa: w indeksie ma znaleźć się wskazany adres, a sygnały zebrane przez pozostałe wersje mają być mu przypisane.

Czego canonical nie robi:

• Nie blokuje skanowania. Robot nadal odwiedza wszystkie wersje adresu, więc jeśli problemem jest zużycie budżetu skanowania, canonical go nie rozwiąże.

• Nie usuwa strony z indeksu. Do tego służy znacznik noindex — i te dwa mechanizmy nie powinny występować razem na jednej stronie, bo dają sprzeczne wskazania.

• Nie zastępuje przekierowania. Jeśli adres ma przestać istnieć, właściwe jest przekierowanie stałe, nie canonical.

• Nie działa jako sposób łączenia stron o różnej treści. Wskazanie jako wersji podstawowej strony o czymś innym zostanie zignorowane.

Warto też pamiętać, że narzędzie do obsługi parametrów w Search Console, którym kiedyś sterowano częścią tych spraw, zostało wycofane w 2022 roku. Dziś zostają canonical, robots i przekierowania.

Zasady, które warto trzymać bez wyjątków

Lista, którą przechodzę przy każdym audycie technicznym.

Każda strona ma canonical, także wskazujący na siebie. Samowskazujący tag jest najprostszym zabezpieczeniem przed adresami, których nie przewidziałeś — parametrami kampanii, identyfikatorami sesji, śmieciami dopisywanymi przez zewnętrzne serwisy.

Adres w tagu jest bezwzględny i kanoniczny co do znaku. Ten sam protokół, ta sama wersja domeny z prefiksem lub bez, ta sama konwencja ukośnika na końcu. Niespójność tutaj jest najczęstszą przyczyną ignorowania tagu.

Jeden tag na stronę. Dwa różne wskazania sprawiają, że Google wybiera sam, a najczęściej ignoruje oba.

Wskazany adres musi zwracać status poprawny i być indeksowalny. Canonical prowadzący na stronę z przekierowaniem, błędem albo znacznikiem noindex jest sprzeczny sam w sobie.

Canonical jest spójny z mapą witryny i z linkowaniem wewnętrznym. Jeśli mapa podaje jedną wersję adresu, linki w treści drugą, a canonical trzecią, wysyłasz trzy różne sygnały.

Typowe konfiguracje w sklepie

Tu zapada większość realnych decyzji, więc przejdę przez najczęstsze przypadki.

Sortowanie i widok listy. Adresy z parametrem porządku wyświetlania albo liczby produktów na stronie wskazują jako wersję podstawową adres kategorii bez parametrów. Treść jest ta sama, kolejność nie tworzy nowej wartości.

Filtry. Najtrudniejszy przypadek i wymagający decyzji biznesowej. Kombinacje filtrów odpowiadające realnym zapytaniom — na przykład „buty trekkingowe damskie z membraną” — bywają warte własnego miejsca w indeksie i wtedy dostają canonical wskazujący na siebie oraz własne treści. Pozostałe kombinacje wskazują na kategorię nadrzędną. Kryterium jest proste: czy ktoś tego szuka.

Paginacja. Kolejne strony listingu powinny wskazywać na siebie, nie na pierwszą stronę. Wskazanie wszystkich podstron na pierwszą sprawia, że produkty widoczne tylko na dalszych stronach mogą wypaść z indeksu.

Warianty produktu. Jeśli rozmiar albo kolor mają osobne adresy, a treść jest praktycznie identyczna, wskazuję wersję podstawową produktu. Jeśli warianty mają własne zdjęcia, opisy i są osobno wyszukiwane, mogą zasługiwać na własne miejsce.

Parametry kampanii. Adresy z oznaczeniami z systemów reklamowych zawsze wskazują na wersję bez parametrów. To jedyny przypadek na tej liście, w którym nie ma nad czym się zastanawiać.

Jak sprawdzić, czy to działa

Nie zakładam, że wdrożenie zadziałało, dopóki tego nie zobaczę.

Narzędzie do sprawdzania adresów w Search Console pokazuje dwie rzeczy naraz: canonical zadeklarowany przez Ciebie oraz ten wybrany przez Google. Rozbieżność między nimi jest sygnałem, że wskazówka została odrzucona.

Raport indeksowania stron ma kategorie mówiące wprost o duplikatach — w tym o sytuacji, w której Google wybrało inną wersję niż zadeklarowana. To najszybszy sposób oszacowania skali problemu w całym serwisie.

Skan własnym crawlerem pozwala wychwycić błędy techniczne: strony bez tagu, strony z kilkoma tagami, canonical prowadzący do przekierowania, niespójność protokołu.

Sprawdzam też, jak to wygląda w wersji renderowanej strony, a nie tylko w kodzie źródłowym. Jeśli tag jest wstawiany albo modyfikowany skryptem po stronie przeglądarki, warto się upewnić, że robot widzi to, co powinien.

Kiedy canonical to zły wybór

Trzy sytuacje, w których sięgam po coś innego.

Gdy strona ma przestać istnieć — przekierowanie stałe, nie canonical. Canonical zostawia adres żywym i skanowanym.

Gdy strona nie ma trafić do indeksu w ogóle, na przykład koszyk, wyniki wyszukiwania wewnętrznego, panel klienta — znacznik noindex.

Gdy problemem jest liczba skanowanych adresów, a nie ich obecność w indeksie — reguły w pliku robots. Tu jednak ostrożnie: adres zablokowany dla robota nie zostanie odczytany, więc jego canonical nie będzie widziany. Blokowanie i wskazywanie wersji podstawowej wykluczają się wzajemnie i mieszanie ich to jeden z częstszych błędów w dużych sklepach.

Na koniec zasada, która oszczędza najwięcej pracy: lepiej nie tworzyć duplikatów, niż je potem porządkować. Jeśli da się zaprojektować adresy tak, żeby filtry i sortowania nie mnożyły wersji, canonical staje się zabezpieczeniem, a nie podstawowym narzędziem utrzymania porządku.