Co to jest canonical tag?

Canonical tag (` `) to atrybut HTML wskazujący Google preferowaną wersję strony, gdy istnieją duplikaty. Przykład: /produkt?color=red i /produkt?color=blue mogą mieć ten sam content — canonical wskazuje jeden URL jako 'oryginał'. Bez canonical Google sam wybiera (i nie zawsze dobrze).

Czy każda strona powinna mieć canonical?

Tak — best practice to self-referencing canonical na każdej indeksowanej stronie. Strona /blog/post powinna mieć ` `. To zapobiega indeksowaniu wariantów URL z parametrami tracking (?utm_source=...).

Czym różni się canonical od redirect 301?

301 redirect przekierowuje użytkownika i Google na inny URL — stary URL znika z indeksu. Canonical NIE przekierowuje — obie strony są dostępne, Google wybiera kanoniczną do indeksu. Stosuj 301 dla stałych zmian URL, canonical dla różnych wersji tego samego contentu.

Co to jest cross-domain canonical?

Canonical wskazujący URL na innej domenie. Przykład: artykuł publikowany na własnym blogu i na Medium — canonical na Medium wskazuje na własny blog (oryginał). Stosuj ostrożnie — Google może zignorować, jeśli content różni się znacząco.

Canonical tag — kiedy używać i jak nie zepsuć SEO?

Canonical tag mówi Google „to jest preferowana wersja tej strony" w sytuacjach, gdy istnieją duplikaty treści pod różnymi URL-ami. W audytach technicznych, które robimy w ARDURA Lab, to jeden z pierwszych elementów na liście kontrolnej — bo błędny canonical to cichy zabójca indeksacji. Strona znika z wyników, a właściciel długo nie wie dlaczego.

TL;DR — Canonical w pigułce

Co	Detale
Składnia	`<link rel="canonical" href="https://example.com/strona" />`
Lokalizacja	`<head>` strony
Format URL	Absolute (https://...), nie relative
Self-referencing	Każda strona linkuje do siebie
Cross-domain	OK, ale Google może zignorować
301 vs canonical	301 = redirect, canonical = sygnał (obie strony żyją)
Pułapka #1	Canonical na noindex page = chaos
Pułapka #2	Łańcuchy canonical (A → B → C)

Co robi canonical tag?

Canonical tag (<link rel="canonical">) wskazuje Google preferowaną wersję strony, gdy istnieją duplikaty lub bardzo podobne wersje. Przykłady duplicate content:

/produkt i /produkt/ (trailing slash)
/produkt i /produkt?utm_source=facebook (tracking parameters)
/blog/post i /blog/post?ref=newsletter (referrer parameter)
/produkt?color=red i /produkt?color=blue (jeśli treść w 95% taki sam)

Bez canonical Google wybiera „canoniczny" URL sam. Wybór bywa nieprzewidywalny — czasem indeksuje wersję z parametrem zamiast clean URL, co dzieli autorytet linków. To dokładnie ten scenariusz łapiemy najczęściej przy pierwszym audycie klienta: parametry trackingowe zjadające budżet indeksacji, zanim ktokolwiek zdążył ustawić self-canonical.

Składnia

<head>
  <link rel="canonical" href="https://arduralab.com/blog/canonical-tag-jak-uzywac" />
</head>

Zasady:

Absolute URL (z https://, pełen path)
Jedna canonical na stronie (nie wiele)
Tylko w <head> (nie w <body>)
Nie na noindex (sprzeczne sygnały)

Self-referencing canonical (best practice)

Każda strona powinna linkować do siebie:

<!-- Na stronie https://example.com/blog/post -->
<link rel="canonical" href="https://example.com/blog/post" />

To brzmi trywialnie, ale zapobiega:

Indeksowaniu wariantów z UTM parametrami
Konfuzji Google przy duplikatach
Indeksowaniu HTTP gdy strona ma być HTTPS (jeśli redirect zawiedzie)

W praktyce to jedna z pierwszych rzeczy, które sprawdzamy w audycie: czy każda strona faktycznie linkuje do siebie, czy canonical został po prostu skopiowany z szablonu i nikt nie sprawdził, czy się zgadza.

301 redirect vs canonical — kiedy co?

Częsta konfuzja. Decyzyjnik:

Sytuacja	Co wybrać
Stale przeniosłem stronę pod nowy URL	301 redirect
Mam parametry tracking (?utm_, ?ref=)	Canonical
Mam paginację (/page/1, /page/2)	Canonical (do strony 1) lub rel="next/prev"
Mam wersje językowe	Hreflang (nie canonical)
Publikuję na 2 domenach	Cross-domain canonical lub 301
Mam wariant z trailing slash	301 (wybierz jedną wersję, redirect drugą)
Mam HTTPS i HTTP	301 z HTTP na HTTPS + self-canonical na HTTPS

Zasada nadrzędna: 301 jest silniejszy niż canonical. Canonical to sygnał, którego Google może (ale nie musi) słuchać. 301 to twarda komenda.

W naszej pracy trzymamy się prostej reguły: jeśli wahasz się między 301 a canonical, wybierz 301. Jest jednoznaczny. Canonical bywa sugestią, którą Google zignoruje akurat w chwili, gdy najbardziej Ci zależy.

Cross-domain canonical

Canonical wskazujący na inną domenę. Stosowany, gdy treść jest celowo opublikowany w wielu miejscach.

Przykład z naszej praktyki: piszemy artykuł, publikujemy go na własnym blogu ARDURA Lab (oryginał), a potem czasem syndykujemy na Medium.

Na Medium artykule:

<link rel="canonical" href="https://arduralab.com/blog/post-original" />

To mówi Google: „oryginał jest na arduralab.com, indeksuj tamtą wersję".

Limitacje:

Google może zignorować, jeśli treść różni się od podanej canonical
Wymaga pełnej zgodności tekstu między wersjami
Niektóre platformy (LinkedIn) nie pozwalają edytować canonical

Pułapki, które zabijają SEO

W audytach widzimy te same błędy powtarzające się z klienta na klienta — poniższa szóstka to nasza lista najczęstszych.

Pułapka 1: Canonical na noindex page

<meta name="robots" content="noindex" />
<link rel="canonical" href="https://example.com/inna-strona" />

Sprzeczne sygnały: „nie indeksuj" + „indeksuj inną wersję". Google ignoruje, nie wiadomo co zrobi. Zasada: noindex = brak canonical (strona nie istnieje dla SEO).

Pułapka 2: Łańcuchy canonical

A.html → canonical: B.html
B.html → canonical: C.html
C.html → canonical: D.html

Google podąża, ale każdy hop traci „signal strength". Po 2-3 hops może przestać. Lepiej bezpośrednio:

A.html → canonical: D.html

Pułapka 3: Self-canonical do innej strony

<!-- Na stronie /produkt-A -->
<link rel="canonical" href="https://example.com/produkt-B" />

Mówisz Google: „indeksuj produkt-B zamiast tej strony". Strona /produkt-A znika z indeksu.

Pułapka 4: HTTP w canonical na HTTPS stronie

<!-- Na https://example.com/strona -->
<link rel="canonical" href="http://example.com/strona" />

HTTPS i HTTP to różne URL-e. Canonical do HTTP wersji = strona HTTPS znika z indeksu (na rzecz HTTP, której być może nie istnieje).

Pułapka 5: Canonical do redirectowanego URL-a

A.html → canonical: B.html
B.html → 301 redirect → C.html

Google traktuje jako łańcuch i może zignorować. Lepiej:

A.html → canonical: C.html (bezpośrednio do final destination)

Pułapka 6: Canonical w sitemap.xml

Niektóre CMS-y dodają canonical do sitemap. Sitemap powinien zawierać tylko canonical URLs, nie ich kanoniczne wersje. Konfuzja → Google ignoruje sitemap.

Canonical dla paginacji (2026 update)

W 2019 Google zdeprekował rel="next"/rel="prev". Co teraz robić z paginacją (e.g. /blog/page/1, /blog/page/2)?

Opcja 1: Każda strona paginacji indexowalna

Każda ma self-canonical (/blog/page/2 → canonical: /blog/page/2)
Plus internal linking między stronami

Opcja 2: View-all page jako canonical

Wszystkie strony paginacji → canonical do /blog/all
Tylko jeśli „all page" istnieje i nie jest gigantyczna (>5 MB)

Opcja 3: Pierwszą stronę jako canonical (controversial)

/blog/page/1, /blog/page/2 → canonical: /blog
Ryzyko: Google nie indeksuje stron 2+, treść z nich ignoruje

Najczęściej używana i ta, którą sami rekomendujemy klientom: opcja 1 (self-canonical na każdej) — najmniej ryzykowna i najlepiej udokumentowana przez Google.

Canonical dla parametrów

Sklep e-commerce ma dla produktu:

/produkt
/produkt?color=red
/produkt?size=L
/produkt?color=red&size=L

Strategia: wszystkie warianty z parametrami → canonical do /produkt:

<!-- Na /produkt?color=red -->
<link rel="canonical" href="https://example.com/produkt" />

Wyjątek: gdy każdy wariant ma odrębną stronę z dedykowanym treścią (/produkt-czerwony vs /produkt-niebieski) — wtedy każdy ma self-canonical.

Weryfikacja canonical

Przed wdrożeniem

Lista wszystkich URL-i (Screaming Frog crawl)
Mapa canonical — każdy URL → docelowy canonical
Walidacja: każda canonical musi zwracać 200 (nie 301, nie 404)

Po wdrożeniu

Screaming Frog → Canonicals tab → 0 errors
GSC URL Inspection → „User-declared canonical" + „Google-selected canonical" — czy się zgadzają?
Manual sample — view-source: na 5-10 random URL → sprawdzić canonical

Sygnały problemu

W GSC:

„Duplicate without user-selected canonical" → brak self-canonical, Google wybiera za Ciebie
„Duplicate, Google chose different canonical than user" → Twój canonical sprzeczny z innymi sygnałami
„Excluded by canonical" → strona nie indeksowana (zamierzone czy bug?)

Ten drugi komunikat — „Duplicate, Google chose different canonical than user" — rozwiązaliśmy u siebie w sposób, który da się sprawdzić z zewnątrz. W pliku public/_redirects na arduralab.com stoi datowany blok „2026-06-26 de-cannibalization: redirect duplicate pages to Google-chosen canonicals": siedem par przekierowań 301, w tym /blog/geo-vs-seo-co-wybrac → /blog/seo-vs-geo-roznice oraz /slownik/canonical-tag → /slownik/canonical-url, plus lustrzane pary dla wersji angielskiej. Ważniejsza od liczby jest tu metoda: przekierowaliśmy duplikaty na canonical, który wybrał Google (ten widoczny w GSC), a nie na ten, który bardziej nam się podobał. Spór z algorytmem o to, która z dwóch naszych własnych stron jest ważniejsza, jest sporem nie do wygrania — taniej przyjąć jego wybór i skonsolidować wokół niego wszystkie sygnały.

Częste case studies

Zacznijmy od przypadku, który mieliśmy realnie na biurku. W audycie integratora IT znaleźliśmy duplikat strony głównej pod osobnym adresem — z kodem 200, własnym canonicalem wskazującym na siebie, bez noindex i obecny w sitemapie. Technicznie canonical był ustawiony poprawnie: strona wskazywała sama na siebie, dokładnie tak, jak każe zasada z sekcji o self-referencing wyżej. Praktycznie utrwalał kanibalizację strony głównej, zamiast ją gasić — bo self-canonical na duplikacie mówi Google „ta kopia też jest oryginałem". Przy powtórnym audycie trzy miesiące później nic się nie zmieniło, duplikat dalej żył pod tym samym adresem. To jest ta różnica, o której warto pamiętać przy każdym audycie: „canonical jest ustawiony" i „canonical robi to, co powinien" to dwa różne zdania.

Poza tym wracają trzy sytuacje, które widujemy najczęściej u klientów zgłaszających się po audyt techniczny.

Case 1: WordPress + WooCommerce

WooCommerce domyślnie generuje:

/produkt/?attribute_color=red
/produkt/?orderby=price

Bez canonical: każdy URL indeksuje się osobno → tysiące duplikatów

Z canonical: wszystkie warianty → canonical do /produkt/ → jeden URL w indeksie

Case 2: Multilingual subdomeny

pl.example.com i en.example.com to różne języki, nie duplikaty. Nie używaj canonical między nimi — używaj hreflang.

Case 3: Mobile vs Desktop URLs (legacy)

Stare strony miały:

example.com/strona (desktop)
m.example.com/strona (mobile)

Mobile-first indexing 2024+ wymaga: canonical mobile → desktop + hreflang lub responsive.

Podsumowanie

Canonical tag 2026:

Self-referencing na każdej indeksowanej stronie
Absolute URL w canonical
Brak konfliktów z noindex / 301 / hreflang
Bezpośrednio do final destination — bez łańcuchów
Weryfikacja Screaming Frog + GSC URL Inspection
Cross-domain ostrożnie — preferuj 301

Złota zasada, którą powtarzamy każdemu klientowi: canonical to sygnał, nie komenda. Google może zignorować, jeśli sygnały konfliktują. Konsystencja wszystkich sygnałów (canonical + sitemap + internal links + redirects) to klucz — i to jest dokładnie to, co sprawdzamy jako pierwsze, zanim zaczniemy cokolwiek zmieniać.

Sprawdź audyt SEO technicznego — zmapujemy obecny stan canonical i wskażemy duplicates rzucających autorytet.

Chcesz osiągnąć podobne rezultaty? Zamów bezpłatną wycenę.