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 contentu pod różnymi URL-ami. W 2026 to nadal jeden z najważniejszych elementów SEO technicznego — ale też jeden z najczęściej źle wdrażanych. Nieprawidłowy canonical = strona znika z indeksu.

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 content 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.

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)

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.

Cross-domain canonical

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

Przykład: ARDURA Lab pisze artykuł, publikuje na własnym blogu (oryginał), potem syndykuje 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 content 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

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+, content z nich ignoruje

Najczęściej używana: opcja 1 (self-canonical na każdej).

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 contentem (/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?)

Częste case studies

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: 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.

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