Canonical w adresach z parametrami: gdzie pomaga, gdzie przeszkadza

Adresy sklep.pl/buty?utm_source=newsletter oraz sklep.pl/buty?kolor=czarny różnią się parametrem, ale na tym podobieństwa się kończą. Pierwszy zazwyczaj pokazuje dokładnie tę samą stronę co czysty URL. Drugi może prezentować osobną ofertę, odpowiadającą na konkretne zapytanie „czarne buty”. Wysłanie obu canonicalem do /buty byłoby technicznie proste, lecz biznesowo nierozsądne.

Canonical nie służy do mechanicznego usuwania wszystkiego, co znajduje się po znaku zapytania. To sygnał wskazujący wyszukiwarce preferowaną wersję powielonej lub bardzo podobnej treści. Pomaga przy parametrach kampanii, identyfikatorach sesji i zmianie sposobu wyświetlania listy. Przeszkadza, gdy skleja zbyt różne strony: filtry produktowe, warianty językowe, osobne rynki oraz kolejne strony paginacji.

Największy błąd powstaje wtedy, gdy programista wdraża jedną globalną regułę: „canonical zawsze prowadzi do URL-a bez parametrów”. Taka konfiguracja naprawia część duplikacji, ale przy okazji może wyciąć wartościowe strony kategorii i utrudnić Google dotarcie do produktów znajdujących się dalej niż na pierwszej stronie listy.

Kiedy parametr jest duplikatem i powinien wskazywać czysty adres

Canonical pomaga wtedy, gdy parametr nie zmienia głównej treści strony albo zmiana ogranicza się do kolejności, wyglądu bądź sposobu przypisania wizyty do kampanii.

Typowy kod wygląda następująco:

<link rel="canonical" href="https://www.sklep.pl/buty-do-biegania">

Adres powinien być bezwzględny, zawierać protokół HTTPS i prowadzić bezpośrednio do właściwej strony. Lepiej nie stosować wersji względnych, takich jak:

<link rel="canonical" href="/buty-do-biegania">

Technicznie mogą działać, ale zwiększają ryzyko błędów podczas migracji, pracy na środowisku testowym albo zmiany domeny.

Najbardziej oczywistym zastosowaniem canonicala są parametry analityczne:

• utm_source
• utm_medium
• utm_campaign
• gclid
• fbclid
• ref
• identyfikatory afiliacyjne

Adres:

https://www.sklep.pl/buty-do-biegania?utm_source=newsletter&utm_campaign=wyprzedaz

powinien zazwyczaj wskazywać canonicalem:

https://www.sklep.pl/buty-do-biegania

Treść, lista produktów i intencja użytkownika pozostają te same. Parametr służy jedynie do pomiaru kampanii. Self-canonical zawierający UTM jest tutaj błędem, ponieważ tworzy dodatkową wersję tej samej strony i wysyła wyszukiwarce sygnał, że adres kampanijny ma być traktowany jako samodzielny.

Nie należy jednak automatycznie przekierowywać wszystkich adresów z UTM kodem 301. Jeżeli przekierowanie nastąpi przed uruchomieniem systemu analitycznego, Google Analytics 4, Matomo albo inne narzędzie może nie zarejestrować źródła kampanii. Bezpieczniejszy schemat wygląda tak:

1. Strona otwiera się z parametrami.
2. System analityczny rejestruje kampanię.
3. Canonical wskazuje czysty URL.
4. Strona nie tworzy wewnętrznych linków z UTM.
5. Opcjonalnie skrypt usuwa parametry z paska adresu po zapisaniu danych.

Podobnie należy traktować parametry odpowiadające wyłącznie za sposób prezentacji:

?view=grid
?view=list
?items=24
?sort=default
?print=1

Jeżeli zmieniają tylko układ kafelków, liczbę elementów na ekranie albo wersję do druku, nie tworzą nowej strony z perspektywy wyszukiwarki. Canonical powinien prowadzić do wersji podstawowej.

W przypadku parametrów całkowicie zbędnych można pójść dalej i zastosować stałe przekierowanie 301 lub 308. Dotyczy to szczególnie takich adresów jak:

/kategoria?page=1
/kategoria?sort=default
/kategoria?view=grid

Jeżeli użytkownik nie musi pozostać na takim URL-u, przekierowanie do czystego adresu jest silniejsze i bardziej jednoznaczne niż canonical. Ogranicza też liczbę stron, które robot musi pobierać.

Inaczej wygląda zwykłe sortowanie:

?sort=price_asc
?sort=price_desc
?sort=popular
?sort=newest

Gdy zmienia się wyłącznie kolejność tych samych produktów, strona jest bardzo bliska duplikatowi. Najczęściej sprawdza się:

• canonical do kategorii podstawowej, jeżeli celem jest konsolidacja duplikatów;
• noindex, jeżeli strona ma działać dla użytkownika, lecz nie powinna trafiać do wyników;
• ograniczenie crawlowania w robots.txt, jeżeli sortowania tworzą ogromną przestrzeń adresów i nie muszą być w ogóle pobierane przez robota.

Tych metod nie należy mieszać bez planu. Strona zablokowana w robots.txt nie może zostać pobrana, więc Google nie odczyta umieszczonego na niej canonicala ani dyrektywy noindex.

Sam tag nie wystarczy. Canonical musi być spójny z pozostałymi sygnałami. Jeżeli kod wskazuje czysty URL, ale sitemap zawiera wersję z parametrem, menu linkuje do adresu kampanijnego, a przekierowanie prowadzi jeszcze gdzie indziej, Google dostaje sprzeczne instrukcje.

Prawidłowy cel canonicala powinien:

• zwracać kod 200 OK;
• być dostępny dla robota;
• nie zawierać noindex;
• nie prowadzić przez łańcuch przekierowań;
• mieć canonical wskazujący na siebie;
• znajdować się w mapie XML, jeżeli strona jest ważna;
• być używany w linkowaniu wewnętrznym;
• odpowiadać treściowo stronie źródłowej.

Na jednej stronie powinien znaleźć się jeden jednoznaczny canonical. Częsty problem pojawia się w sklepach opartych na gotowych szablonach: CMS generuje pierwszy tag w kodzie serwera, a moduł SEO lub JavaScript dokłada drugi. Jeden wskazuje czysty adres, drugi aktualny URL wraz z parametrami. Rezultat jest nieprzewidywalny.

Filtry, warianty i paginacja: przypadki, w których canonical szkodzi

Filtr produktowy nie jest automatycznie duplikatem kategorii. Adres:

/buty-do-biegania?marka=asics&plec=damskie

może prezentować tylko damskie modele marki Asics. To inny zestaw produktów, inna intencja i potencjalnie osobna odpowiedź na zapytanie wpisywane w Google. Skierowanie takiej strony canonicalem do ogólnej kategorii /buty-do-biegania oznacza rezygnację z możliwości indeksowania filtra.

Nie znaczy to, że każdy filtr powinien otrzymać self-canonical. Nawigacja fasetowa potrafi wygenerować absurdalną liczbę adresów. Przy 10 kolorach, 12 rozmiarach, 8 markach, 6 przedziałach cenowych i 3 sortowaniach powstaje 17 280 kombinacji dla jednej kategorii. Jeżeli każda lista ma pięć stron paginacji, przestrzeń rośnie do 86 400 adresów.

Robot nie wie z góry, że większość kombinacji jest bezużyteczna. Musi najpierw odkryć URL, a często również go pobrać. Canonical może z czasem ograniczyć częstotliwość odwiedzania wersji uznanych za duplikaty, ale nie zapobiega ich początkowemu crawlowaniu.

Dlatego filtry trzeba podzielić na trzy grupy.

Pierwsza grupa: filtry przeznaczone do indeksowania

Powinny otrzymać:

• self-canonical;
• unikalny tytuł i nagłówek H1;
• stabilny adres;
• linki wewnętrzne z kategorii, menu lub sekcji tematycznej;
• użyteczny opis albo elementy pomagające dokonać wyboru;
• sensowną liczbę produktów;
• obecność w dedykowanej mapie XML, jeżeli są ważnymi landing page’ami.

Nie istnieje oficjalny minimalny próg produktów wymagany przez Google. W praktyce dla typowego polskiego sklepu przyjmuję jako punkt startowy co najmniej 6 dostępnych produktów przez większość sezonu. W kategoriach drogich i wąskich, takich jak pompy ciepła, rowery cargo czy profesjonalne ekspresy gastronomiczne, wartościowa strona może mieć trzy lub cztery pozycje. W przypadku koszulek, obuwia albo kosmetyków trzy produkty zwykle oznaczają zbyt ubogą ofertę.

Próg jest regułą operacyjną, nie algorytmiczną. Ważniejsze są:

• popyt na konkretną frazę;
• stabilność asortymentu;
• możliwość utrzymania strony po wyprzedaniu pojedynczej serii;
• odrębność od kategorii nadrzędnej;
• jakość linkowania wewnętrznego.

Strona „damskie buty Asics do biegania” ma sens, gdy użytkownicy faktycznie szukają takiego zestawienia i sklep stale oferuje odpowiednie modele. Filtr „damskie czarne buty Asics do biegania, rozmiar 37, poniżej 300 zł, sortowane od najnowszych” najczęściej nie zasługuje na indeksację. Jest zbyt wąski, niestabilny i może okresowo pokazywać zero wyników.

Druga grupa: filtry przydatne użytkownikowi, ale niepotrzebne w Google

Tutaj sprawdza się noindex, o ile robot może pobrać stronę i odczytać dyrektywę:

<meta name="robots" content="noindex, follow">

Nie ma sensu wskazywać canonicalem ogólnej kategorii tylko dlatego, że filtr nie powinien być indeksowany. Jeżeli zestaw produktów wyraźnie się różni, strony nie są bliskimi duplikatami i Google może taki canonical zignorować.

Trzecia grupa: filtry tworzące praktycznie nieskończoną przestrzeń adresów

Dotyczy to kombinacji cen, rozmiarów, parametrów technicznych, lokalizacji, dat, sortowań i wielokrotnie powtarzanych wartości. Jeżeli strony nie mają żadnej wartości z wyszukiwarki, priorytetem staje się ograniczenie ich odkrywania i crawlowania, a nie umieszczanie canonicala na każdej z nich.

Można wtedy:

• usunąć linki do niedozwolonych kombinacji;
• dopuścić tylko zdefiniowane filtry SEO;
• normalizować kolejność parametrów;
• zwracać 404 dla kombinacji niemożliwych;
• blokować określone wzorce w robots.txt;
• korzystać z fragmentów #, jeżeli filtr nie musi tworzyć adresu indeksowalnego.

Kombinacje bez wyników wymagają zdecydowanej obsługi. URL technicznie niemożliwy, na przykład powtarzający ten sam filtr albo wskazujący nieistniejącą wartość, powinien zwracać 404, a nie kod 200 z komunikatem „brak produktów”. Przekierowywanie wszystkich pustych filtrów do kategorii głównej też jest złe: użytkownik traci wybrane kryteria, a wyszukiwarka widzi masę pozornych przekierowań do mało powiązanej strony.

Paginacji nie wolno sklejać do strony pierwszej

Adres:

/kurtki-damskie?page=2

powinien mieć canonical wskazujący na siebie:

<link rel="canonical" href="https://www.sklep.pl/kurtki-damskie?page=2">

Druga strona zawiera inne produkty niż pierwsza. Trzecia także. Canonical całej paginacji do /kurtki-damskie sugeruje, że kolejne listy są duplikatami pierwszej strony, choć nimi nie są.

Skutkiem może być:

• ograniczenie indeksowania kolejnych stron;
• słabsze odkrywanie produktów znajdujących się głębiej;
• nadmierne uzależnienie crawlowania od mapy XML;
• problemy po zmianie kolejności produktów;
• zbyt częste odwiedzanie pierwszej strony i zbyt rzadkie pozostałych.

Każda strona paginacji potrzebuje unikalnego URL-a oraz zwykłych linków HTML w formacie <a href>. Przycisk „pokaż więcej” obsługiwany wyłącznie przez JavaScript nie jest wystarczającym zamiennikiem, ponieważ robot nie wykonuje wszystkich interakcji użytkownika.

Tagi rel="next" i rel="prev" nie są już wykorzystywane przez Google do rozpoznawania paginacji. Można je pozostawić ze względu na inne systemy, lecz nie zastępują self-canonicali i linków prowadzących do kolejnych stron.

Dla pierwszej strony trzeba wybrać jeden wariant:

/kurtki-damskie

albo:

/kurtki-damskie?page=1

Najczyściej jest używać pierwszego, a ?page=1 przekierować kodem 301 do adresu bez parametru. Menu, canonical, mapa XML i linki paginacji muszą stosować tę samą wersję.

Warianty produktów wymagają decyzji architektonicznej

Parametr koloru lub rozmiaru może działać na dwa sposoby.

W modelu jednostronicowym wszystkie warianty znajdują się na jednej karcie produktu:

/kurtka-narciarska
/kurtka-narciarska?color=red
/kurtka-narciarska?size=m

Parametr jedynie wybiera wariant na tej samej stronie. Wtedy canonical zwykle powinien prowadzić do bazowego adresu:

/kurtka-narciarska

W modelu wielostronicowym każdy wariant ma natomiast własny adres, zdjęcia, dostępność, GTIN, cenę, opis i może stanowić osobną stronę wejścia:

/kurtka-narciarska-czerwona
/kurtka-narciarska-czarna

Tutaj automatyczne sklejenie wszystkich wariantów do jednego produktu może być błędem. Jeżeli strony są samodzielne i równie ważne, mogą mieć self-canonical, kompletne dane produktu oraz prawidłowo wdrożone dane strukturalne Product i ProductGroup.

Najgorsza jest konfiguracja pośrednia: warianty mają osobne adresy i różne oferty, lecz canonical prowadzi do produktu podstawowego, a mapa XML zawiera wszystkie warianty. Takie sygnały wzajemnie się podważają.

Język, kraj i waluta nie zawsze są zwykłymi parametrami

Adresy:

?lang=de
?country=DE
?currency=EUR

mogą wyglądać jak techniczne dodatki, ale czasami zmieniają język, ceny brutto, wysokość VAT, dostępność dostawy i warunki zwrotu. W sklepie działającym w Polsce i Niemczech nie wolno automatycznie kierować niemieckiej wersji canonicalem do polskiej tylko dlatego, że obie sprzedają ten sam produkt.

Dla realnie zlokalizowanych wersji lepsza jest struktura:

sklep.pl/pl/produkt
sklep.pl/de/produkt

Każda wersja powinna mieć własny canonical oraz prawidłowe oznaczenia hreflang.

Jeżeli parametr zmienia wyłącznie sposób wyświetlania ceny w euro, ale oferta, język, dostawa i rynek pozostają te same, canonical do wersji podstawowej może być uzasadniony. Gdy zmienia się faktyczna oferta dla kraju, strona przestaje być prostym duplikatem.

Audyt parametrów i wdrożenie reguł bez błędów indeksowania

Audytu nie zaczyna się od wpisania Disallow w robots.txt. Najpierw trzeba ustalić, jakie parametry istnieją, skąd pochodzą i co rzeczywiście zmieniają.

Pierwszym krokiem jest zebranie adresów z kilku miejsc:

• crawl wykonany w Screaming Frog albo Sitebulb;
• raport indeksowania w Google Search Console;
• narzędzie sprawdzania konkretnego adresu URL;
• logi serwera;
• landing pages w Google Analytics 4;
• pliki sitemap;
• linki wygenerowane przez menu, filtry i moduły rekomendacji.

Logi są szczególnie ważne. Crawl wykonany przez specjalistę pokazuje adresy dostępne z bieżącej struktury strony, ale nie zawsze ujawnia stare parametry, linki zewnętrzne albo kombinacje nadal odwiedzane przez Googlebota. W typowym audycie analizuję minimum 30 dni logów, a w biznesie sezonowym 60–90 dni.

Każdy parametr powinien otrzymać funkcję:

• śledzenie kampanii;
• sesja;
• sortowanie;
• paginacja;
• filtrowanie;
• wariant produktu;
• język lub rynek;
• wyszukiwanie wewnętrzne;
• tymczasowy eksperyment;
• parametr bez rozpoznanego zastosowania.

Nierozpoznanego parametru nie wolno od razu usuwać. Może obsługiwać płatności, zapis koszyka, konfigurator produktu, afiliację albo wersję językową. Najpierw trzeba sprawdzić kod, dokumentację CMS-a i zachowanie strony.

Następnie porównuje się treść. Dla list produktowych najprościej zestawić:

• identyfikatory produktów;
• liczbę produktów;
• kolejność produktów;
• tytuł strony;
• H1;
• opis kategorii;
• breadcrumbs;
• ceny i dostępność;
• kod odpowiedzi HTTP;
• canonical i robots meta.

Jeżeli dwie strony zawierają dokładnie te same identyfikatory produktów, a różni je tylko kolejność, mamy sortowanie. Jeżeli jedna zawiera wyraźny podzbiór drugiej, mamy filtr. To rozróżnienie jest ważniejsze niż sama nazwa parametru.

Kolejność decyzji powinna być następująca:

1. Usunąć parametr albo zastosować przekierowanie, jeżeli nie jest potrzebny.
2. Użyć canonicala, jeżeli URL musi istnieć, ale pokazuje duplikat.
3. Zostawić self-canonical, jeżeli strona jest wartościowa i ma trafiać do wyników.
4. Zastosować noindex, jeżeli strona jest potrzebna użytkownikowi, ale nie wyszukiwarce.
5. Ograniczyć crawlowanie, jeżeli parametry tworzą wielką, nieprzydatną przestrzeń URL-i.

Canonical nie powinien być pierwszym odruchem. Czasem właściwym rozwiązaniem jest przebudowanie linkowania albo całkowite zaprzestanie generowania zbędnego adresu.

Reguły wdrożeniowe, które trzeba sprawdzić w kodzie

Canonical najlepiej generować po stronie serwera, w początkowym kodzie HTML. JavaScript może go dodać, ale komplikuje diagnostykę i zwiększa ryzyko powstania dwóch tagów.

Implementacja powinna uwzględniać:

• protokół HTTPS;
• jedną wersję hosta, na przykład z www albo bez;
• jednolite użycie końcowego ukośnika;
• małe i wielkie litery;
• usuwanie parametrów kampanijnych;
• zachowanie parametrów strategicznych;
• stałą kolejność parametrów;
• usuwanie wartości domyślnych;
• prawidłową obsługę page=1;
• brak canonicali prowadzących do 404, noindex lub przekierowania.

Kolejność parametrów ma znaczenie techniczne. Dla serwera adresy:

?kolor=czarny&rozmiar=42

oraz:

?rozmiar=42&kolor=czarny

mogą zwracać tę samą treść, ale nadal są dwoma osobnymi URL-ami. System powinien generować jeden ustalony wariant i nie linkować do pozostałych.

Po wdrożeniu trzeba przetestować minimum pięć przypadków dla każdej reguły:

• adres bez parametru;
• adres z jednym parametrem;
• adres z kilkoma parametrami;
• adres z wartością pustą lub nieprawidłową;
• adres paginowany;
• kombinację filtrów przeznaczoną do indeksowania;
• kombinację, która ma pozostać poza indeksem.

Sprawdzenie obejmuje kod źródłowy, wyrenderowany DOM, nagłówki HTTP, kod odpowiedzi oraz canonical wybrany przez Google. Samo użycie rozszerzenia do przeglądarki nie wystarcza. Rozszerzenie może pokazać tag obecny w DOM użytkownika, ale nie odpowie, czy Google zobaczył tę samą wersję podczas ostatniego crawlowania.

W Search Console należy porównać:

• canonical zadeklarowany przez użytkownika;
• canonical wybrany przez Google;
• status indeksowania adresu;
• datę ostatniego crawlowania;
• wyrenderowany kod strony.

Status strony alternatywnej z prawidłowym canonicalem nie jest automatycznie błędem. Dla URL-a z UTM to oczekiwany wynik. Problem zaczyna się wtedy, gdy jako alternatywne oznaczane są strategiczne filtry albo druga, trzecia i czwarta strona paginacji.

Nie należy też szukać dawnego narzędzia „Parametry URL” w Search Console. Zostało wycofane w kwietniu 2022 roku. Obecnie kontrola odbywa się przez architekturę strony, linkowanie, canonicale, robots meta, robots.txt, przekierowania i mapy XML.

Pierwszą ocenę wdrożenia można zrobić po około dwóch tygodniach, ale dla większego sklepu bardziej miarodajny jest okres 4–8 tygodni. Nie istnieje gwarantowany termin ponownego przetworzenia wszystkich adresów. Strony często odwiedzane mogą zareagować szybko, a stare kombinacje filtrów obecne tylko w linkach zewnętrznych pozostają w raportach znacznie dłużej.

Najbardziej użyteczne wskaźniki kontrolne są proste:

• strony paginacji powinny mieć self-canonical;
• strategiczne filtry nie powinny wskazywać canonicalem ogólnej kategorii;
• adresy kampanijne powinny prowadzić do czystej wersji;
• sitemap nie powinna zawierać przypadkowych parametrów;
• linki wewnętrzne nie powinny generować UTM ani identyfikatorów sesji;
• strony z noindex nie mogą być jednocześnie blokowane przed crawlowaniem, jeżeli Google ma odczytać dyrektywę;
• cel canonicala nie powinien zwracać błędu ani przekierowania.

Pierwszą rzeczą do usunięcia jest globalna reguła „canonical równa się URL bez query string”. Następnie trzeba naprawić paginację, oddzielić filtry SEO od filtrów użytkowych i dopiero na końcu ograniczać crawl parametrów niskiej wartości. Odwrotna kolejność często kończy się zablokowaniem stron, zanim Google zdąży odczytać właściwe sygnały.

FAQ: canonical i parametry URL

Czy canonical gwarantuje usunięcie adresu z parametrem z indeksu?
Nie. Canonical jest silnym sygnałem, ale Google może wybrać inną wersję, jeżeli treść stron lub pozostałe sygnały nie potwierdzają wskazania.

Czy adres z parametrem UTM powinien mieć self-canonical?
Zazwyczaj nie. Powinien wskazywać czysty URL bez parametrów kampanii, ponieważ UTM nie zmienia głównej treści strony.

Czy canonical i noindex oznaczają to samo?
Nie. Canonical grupuje duplikaty i wskazuje wersję preferowaną, natomiast noindex wyklucza konkretną stronę z wyników wyszukiwania.

Czy można jednocześnie zablokować URL w robots.txt i dodać na nim noindex?
Technicznie można, ale Google nie odczyta noindex, jeżeli robots.txt uniemożliwi pobranie strony. Trzeba wybrać rozwiązanie odpowiadające właściwemu celowi.

Czy druga strona kategorii powinna wskazywać canonicalem stronę pierwszą?
Nie. ?page=2, ?page=3 i kolejne strony powinny mieć self-canonical, ponieważ zawierają inne produkty lub artykuły.

Kiedy filtr produktowy powinien mieć self-canonical?
Gdy odpowiada na osobne zapytanie, ma stabilny asortyment, unikalne elementy strony, linkowanie wewnętrzne i ma być samodzielną stroną wejścia z Google.

Czy zmiana kolejności parametrów tworzy nowy adres?
Tak. ?kolor=czarny&rozmiar=42 i ?rozmiar=42&kolor=czarny są technicznie różnymi URL-ami. System powinien generować i linkować tylko jeden ustalony wariant.

Jak sprawdzić, czy Google zaakceptował canonical?
W narzędziu sprawdzania adresu URL w Google Search Console należy porównać canonical zadeklarowany w kodzie z canonicalem wybranym przez Google.

Od czego zacząć naprawę parametrów?
Najpierw trzeba sporządzić listę parametrów i usunąć regułę, która automatycznie obcina wszystkie. Następny priorytet to self-canonical paginacji, a dopiero potem selekcja filtrów przeznaczonych do indeksowania.