Kanoniczne URL-e: jedna strona, jeden adres

Dlaczego ta sama strona żyje pod tuzinem adresów, co rel=canonical może, a czego nie może z tym zrobić, i jakie błędy z kanonicznymi po cichu niweczą twoje własne SEO.

SEO · Opublikowano: 29 września 2026 · 5 min czytania · Ольга Мирошник

Dla ciebie strona to kawałek treści. Dla wyszukiwarki strona to URL. Jeśli ta sama treść odpowiada pod dziesięcioma adresami, crawler widzi dziesięć stron, musi ustalić, że to kopie, a potem jeszcze zgadnąć, o którą ci chodziło. Kanonikalizacja polega na tym, żeby zgadywanie nie było potrzebne.

Jak jedna strona dostaje wiele adresów

Nikt nie publikuje duplikatów celowo. Serwer po prostu akceptuje więcej wariantów adresu, niż ci się wydaje:

• Host. Odpowiadają zarówno www.example.com, jak i example.com.
• Protokół. http:// nadal serwuje witrynę zamiast przekierowywać na https://.
• Ukośnik na końcu. /pricing i /pricing/ zwracają ten sam dokument.
• Wielkość liter. Na serwerze niewrażliwym na wielkość liter działają i /Blog/Post, i /blog/post.
• Pliki indeksowe. /docs/ i /docs/index.html to ten sam plik.
• Parametry zapytania. ?utm_source=newsletter, ?sort=price, ?sessionid=… — każda kombinacja to nowy URL z identyczną lub prawie identyczną treścią.
• Paginacja. /blog?page=2 to prawdziwa, odrębna strona, ale często błędnie traktuje się ją jako duplikat pierwszej.

Pomnóż to wszystko, a witryna ze stu stron wystawi na zewnątrz tysiące adresów. Linki, udostępnienia i uwaga crawlera rozkładają się między nie.

Jeden host, wymuszony przez 301

Najtaniej pozbyć się duplikatów na poziomie hosta i protokołu, a właściwym narzędziem jest tu przekierowanie stałe, nie tag. Wybierz jedną formę — na przykład https://example.com — i kieruj tam wszystkie pozostałe kombinacje w jednym skoku:

server {
    listen 80;
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}

Liczą się dwa szczegóły. Przekierowanie musi być 301 (albo 308), a nie 302: przekierowanie tymczasowe mówi wyszukiwarce, że prawdziwym adresem wciąż jest stary. I powinien to być jeden skok: łańcuch http://www → https://www → https:// działa, ale przy każdej pierwszej wizycie marnuje dodatkową wymianę z serwerem. Z ukośnikiem na końcu tak samo: wybierz jeden styl i przekierowuj drugi.

rel=canonical to wskazówka

Dla duplikatów, których nie da się przekierować — parametrów śledzących, sortowania, wersji do druku — preferowany adres deklaruje się w head strony:

<link rel="canonical" href="https://example.com/pricing/">

To wskazówka, a nie dyrektywa. Google waży ją razem z przekierowaniami, linkami wewnętrznymi, mapą witryny i hreflang i może wybrać inny adres kanoniczny, jeśli te sygnały się nie zgadzają. Twoim zadaniem jest sprawić, by wszystkie sygnały wskazywały ten sam URL.

Dobre praktyki:

• Samoodwołujące się kanoniczne. Każda indeksowalna strona wskazuje samą siebie. To chroni ją przed wariantami z parametrami, których nie przewidziałeś.
• Bezwzględne URL-e. Względny href="/pricing/" jest formalnie poprawny, ale rozwiązuje się względem hosta i protokołu, z których podano kopię — czyli dokładnie tego duplikatu, którego chciałeś się pozbyć.
• Paginacja kanonikalizuje się do siebie. Strona 2 wskazuje stronę 2, a nie 1; inaczej wszystko, do czego linkuje tylko strona 2, trudniej odkryć.

Pliki inne niż HTML używają nagłówka. PDF nie ma head, więc wskazanie wysyła się w odpowiedzi serwera:

Link: <https://example.com/guide.pdf>; rel="canonical"

Błędy, które naprawdę szkodzą

Kanoniczny na stronę główną wszędzie. Szablon ustawia ten sam canonical na każdej stronie. Właśnie powiedziałeś wyszukiwarce, że cała witryna to duplikat /.

Kanoniczny na stronę, której nie ma. Adres docelowy przekierowuje, zwraca 404 albo ma noindex. Sygnały sobie przeczą i wyszukiwarka zwykle ignoruje wskazówkę.

Konflikt z hreflang i mapą witryny. Sitemap podaje /pricing, canonical mówi /pricing/, a hreflang prowadzi do trzeciego wariantu. Wszędzie powinien widnieć dokładnie kanoniczny URL.

JavaScript go zmienia. W HTML z serwera jest jedno, a router po stronie klienta lub wtyczka SEO przepisuje tag po załadowaniu. Crawler może zobaczyć dowolną z wersji. Renderuj poprawny canonical na serwerze i więcej go nie ruszaj.

Kilka tagów canonical. Dwie wtyczki dodały po jednym. Przy sprzecznych wartościach wskazówka zwykle jest pomijana w całości.

Jak to sprawdzić

Pobierz surowy HTML i patrz na to, co serwer faktycznie wysyła, a nie na to, co pokazują DevTools po wykonaniu skryptów:

curl -s https://example.com/pricing/ | grep -i 'rel="canonical"'
curl -sI http://www.example.com/ | grep -iE '^(HTTP|location)'

Drugie polecenie powinno pokazać pojedyncze 301 na wybrany host. Raport SiteScan sprawdza część z tego automatycznie: oznacza strony bez linku canonical, strony, których canonical wskazuje inny adres, witryny, w których zarówno host z www, jak i bez www odpowiada 200 zamiast stałego przekierowania z jednego na drugi, oraz przekierowania hosta przez tymczasowe 302.

Lista kontrolna

1. Jeden host i jeden protokół; każda inna kombinacja zwraca pojedyncze 301.
2. Jeden styl ukośnika na końcu, drugi przekierowany.
3. Każda indeksowalna strona ma bezwzględny, samoodwołujący się canonical.
4. Adresy docelowe kanonicznych zwracają 200, są indeksowalne i nie przekierowują.
5. Mapa witryny, hreflang i linki wewnętrzne używają dokładnie kanonicznych URL-i.
6. Strony paginacji kanonikalizują się do siebie.
7. PDF-y i inne pliki w razie potrzeby wysyłają nagłówek Link.
8. Canonical w HTML z serwera zgadza się z tym, który zostaje po wykonaniu JavaScriptu.