Tagi kanoniczne, 301, czy noindex? Techniczny poradnik rozwiązywania konfliktów w SEO

Adres URL potrafi robić bałagan szybciej niż zespół zdąży otworzyć Search Console. Ten sam produkt dostępny przez kilka ścieżek. Kategoria z sortowaniem po cenie. Filtr koloru, który wygląda jak osobna podstrona, ale pokazuje prawie ten sam zestaw produktów. Do tego paginacja, parametry UTM, stara wersja kategorii po migracji i ktoś, kto „dla bezpieczeństwa” dorzucił jeszcze noindex albo blokadę w robots.txt.

Problem nie polega na tym, że canonical, 301, noindex i robots.txt są trudne. Problem polega na tym, że często traktuje się je jak zamienniki. A nimi nie są. Każde z tych rozwiązań działa na innym etapie: crawlowania, indeksowania, wyboru adresu kanonicznego albo obsługi użytkownika. Google traktuje przekierowania i rel="canonical" jako silne sygnały kanonikalizacji, ale nie jako gwarancję bezwarunkowego wyboru wskazanego adresu. W dokumentacji Google wprost podkreśla, że może wybrać inny adres kanoniczny, jeśli inne sygnały wskazują na lepszą wersję strony.

Canonical, 301 i noindex: co wybrać w konkretnym konflikcie

Najprostsza zasada decyzyjna jest taka: jeśli użytkownik ma dalej korzystać z obu adresów, nie rób przekierowania 301. Jeżeli jedna wersja ma zniknąć z obiegu, canonical jest za słaby i zbyt grzeczny. Wtedy zwykle potrzebne jest przekierowanie 301 albo 308.

Tag kanoniczny rel="canonical" stosuje się wtedy, gdy dwie lub więcej podstron są duplikatami albo wersjami bardzo podobnymi, ale z jakiegoś powodu nadal muszą istnieć. Typowy przykład: kategoria sklepu dostępna jako:

/buty-damskie/
/buty-damskie/?sort=price-asc
/buty-damskie/?utm_source=newsletter

Dla użytkownika sortowanie po cenie ma sens. Dla Google to często ta sama lista produktów w innej kolejności. W takim przypadku można wskazać wersję podstawową:

<link rel="canonical" href="https://www.example.com/buty-damskie/" />

To nie jest rozkaz. To silny sygnał, że preferowanym adresem ma być wskazany URL. Google wymienia rel="canonical" jako jedną z głównych metod wskazywania wersji kanonicznej, obok przekierowań i sitemap, ale zaznacza też, że różne sygnały mogą się nakładać albo ze sobą kłócić.

W praktyce canonical wybieram, gdy spełnione są trzy warunki:

• podstrona duplikująca lub prawie duplikująca ma zostać dostępna dla użytkownika;
• treść wersji kanonicznej naprawdę odpowiada treści wersji alternatywnej;
• adres kanoniczny zwraca HTTP 200, nie ma noindex, nie przekierowuje dalej i jest linkowany wewnętrznie jako główna wersja.

Najczęstsze błędy są bardzo prozaiczne. I właśnie dlatego regularnie trafiają się w dużych serwisach:

• łańcuch canonicali: A wskazuje na B, B wskazuje na C;
• canonical do adresu przekierowanego: A wskazuje na B, ale B robi 301 do C;
• canonical do strony z noindex;
• canonical do 404 lub soft 404;
• inny adres w canonicalu, inny w sitemapie, a jeszcze inny w linkowaniu wewnętrznym;
• canonical ustawiany przez JavaScript inaczej niż w pierwotnym HTML;
• używanie adresów względnych typu /kategoria/ zamiast pełnych adresów absolutnych.

Google rekomenduje adresy absolutne w canonicalach, bo ścieżki względne są bardziej podatne na błędy, szczególnie przy środowiskach testowych, zmianach domeny i nieoczekiwanym indeksowaniu kopii serwisu.

Przekierowanie 301 jest lepsze od canonicala wtedy, gdy stary adres nie powinien już żyć. Nie tylko dla Google, ale też dla użytkownika. Przykłady:

• migracja z HTTP na HTTPS;
• porządkowanie wersji www i bez www;
• zmiana struktury URL po migracji sklepu;
• połączenie dwóch kategorii w jedną;
• usunięcie starej podstrony i zastąpienie jej nowym odpowiednikiem;
• przeniesienie produktu na nowy, stały adres.

Technicznie 301 mówi: ten zasób został przeniesiony na stałe. Googlebot podąża za przekierowaniem, a system indeksowania używa go jako sygnału, że docelowy adres powinien stać się kanoniczny. Google wskazuje też, że przekierowania serwerowe mają największą szansę poprawnej interpretacji, a przekierowania JavaScript powinny być używane dopiero wtedy, gdy nie da się wdrożyć serwerowego rozwiązania.

Tu pojawia się temat „link juice”. Lepiej nie traktować go jak płynu przelewanego z jednego kubka do drugiego. Bezpieczniej mówić o konsolidacji sygnałów: linków zewnętrznych, linków wewnętrznych, historii adresu i sygnałów kanonicznych. Google w dokumentacji canonicali opisuje to właśnie jako konsolidowanie sygnałów dla podobnych lub zduplikowanych stron, między innymi linków prowadzących do różnych wersji adresu.

Najważniejsze ograniczenie: 301 nie naprawia złego mapowania. Jeżeli stary artykuł o „butach trekkingowych” przekierujesz na stronę główną, to nie jest eleganckie przeniesienie mocy. To często sygnał, że użytkownik nie dostał odpowiednika. Przy większych migracjach trzeba mapować adresy jeden do jednego albo do najbliższej tematycznie kategorii. Gdy odpowiednika nie ma, czasem uczciwsze jest 410 Gone albo dobrze obsłużone 404 niż masowe przekierowania na homepage.

Noindex jest jeszcze innym narzędziem. Nie służy do przekazywania mocy. Nie wybiera wersji kanonicznej. Jego zadanie jest prostsze: strona nie ma być pokazywana w wynikach wyszukiwania. Google wspiera noindex jako meta tag w HTML albo jako nagłówek HTTP X-Robots-Tag; reguła noindex w pliku robots.txt nie jest przez Google wspierana.

Dlatego decyzja powinna wyglądać tak:

• strona ma zostać dostępna, ale nie chcesz jej jako głównej wersji w Google — canonical;
• strona ma zniknąć, a istnieje stały odpowiednik — 301 lub 308;
• strona ma istnieć dla użytkownika, ale nie ma być w indeksie — noindex;
• bot nie powinien tracić czasu na całe wzorce adresów — ostrożnie użyty robots.txt;
• chcesz szybko ukryć wynik w Google — narzędzie usuwania w Search Console może pomóc tymczasowo, ale nie zastępuje docelowej decyzji technicznej.

Najgorszy wariant to wysłanie sprzecznych sygnałów: 301 z A do B, canonical z B do C, linki wewnętrzne do A, sitemap z C, a na B jeszcze noindex. Google może sobie z tym poradzić. Ale równie dobrze może wybrać inaczej, niż chciał właściciel serwisu. I wtedy w Search Console pojawiają się komunikaty typu „Duplikat, Google wybrał inną stronę kanoniczną niż użytkownik”.

Robots.txt, crawl budget i strony wspierające: kiedy blokada pomaga, a kiedy szkodzi

Robots.txt blokuje crawlowanie, a nie indeksowanie. To zdanie powinno wisieć nad każdym wdrożeniem w dużym sklepie. Jeśli adres jest zablokowany w robots.txt, Google zwykle nie pobierze jego treści. Ale sam URL nadal może pojawić się w wynikach, jeśli Google znajdzie go przez linki zewnętrzne lub wewnętrzne. Może wtedy pokazać sam adres bez normalnego opisu, bo nie miało dostępu do zawartości strony. Google opisuje ten mechanizm wprost: aby faktycznie zapobiec pojawieniu się URL-a w wynikach, trzeba użyć noindex, zabezpieczenia dostępu albo usunąć stronę.

To ma praktyczną konsekwencję. Jeżeli strona jest już w indeksie i chcesz ją wyindeksować, nie zaczynaj od Disallow. Najpierw pozwól Google ją odwiedzić i zobaczyć:

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

albo dla plików innych niż HTML, na przykład PDF:

X-Robots-Tag: noindex

Dopiero gdy adres wypadnie z indeksu, można rozważyć blokadę w robots.txt, jeśli dana sekcja generuje realny problem z crawlowaniem. Odwrócenie kolejności jest częstym błędem: zespół blokuje URL w robots.txt, a potem dziwi się, że noindex nie działa. Nie działa, bo bot nie może wejść na stronę i go przeczytać. Google przypomina, że reguły meta robots i nagłówki mogą być respektowane tylko wtedy, gdy crawler ma dostęp do strony.

Robots.txt ma sens przy adresach, które tworzą crawl trap, czyli techniczną pętlę albo niemal nieskończoną liczbę kombinacji. W e-commerce są to najczęściej:

• wewnętrzne wyniki wyszukiwania;
• sortowania bez wartości SEO;
• kombinacje filtrów typu ?kolor=czarny&rozmiar=39&sort=price&view=grid;
• parametry sesji;
• kalendarze i archiwa generujące tysiące pustych adresów;
• endpointy techniczne, których bot nie powinien odwiedzać.

Ale blokada ma cenę. Jeżeli przez zablokowane adresy prowadzi jedyna ścieżka do produktów, artykułów albo kolejnych stron paginacji, Google może mieć problem z dotarciem do tych zasobów. W takiej sytuacji robots.txt nie „optymalizuje crawl budgetu”. On odcina gałąź, na której siedzi struktura serwisu.

Dla stron wspierających decyzja jest jeszcze bardziej delikatna. Strona wspierająca, czyli na przykład poradnik, podkategoria, landing sezonowy, lista produktów z filtrem albo element klastra tematycznego, może nie mieć dużego ruchu sama w sobie, ale może wzmacniać architekturę informacji. Jeśli ma unikalną treść, sensowne linki wewnętrzne i odpowiada na konkretną intencję, wrzucenie jej na noindex tylko dlatego, że „nie dowozi konwersji”, bywa krótkowzroczne.

Wyindeksowanie ma sens, gdy strona:

• jest potrzebna użytkownikowi, ale nie ma samodzielnej wartości w wynikach wyszukiwania;
• duplikuje inną, lepszą stronę i nie chcesz jej jako landing page;
• jest cienka, techniczna, tymczasowa albo operacyjna;
• powoduje indeksowanie masy wariantów bez realnej różnicy treści;
• ma zostać dostępna po zalogowaniu, ale nie powinna konkurować w SERP-ach.

Blokowanie w robots.txt ma sens dopiero wtedy, gdy:

• nie potrzebujesz, aby Google widziało treść tej sekcji;
• adresy nie są potrzebne do odkrywania ważnych podstron;
• masz alternatywną, crawlowną ścieżkę do produktów lub artykułów;
• problemem jest liczba zapytań, a nie sam fakt obecności strony w indeksie.

W pliku robots.txt liczą się też detale. Reguły działają dla konkretnego hosta, protokołu i portu. Plik musi znajdować się w katalogu głównym hosta, na przykład https://example.com/robots.txt, a nie w podfolderze. Google wskazuje też limit rozmiaru robots.txt: 500 KiB, po którym dalsza część pliku jest ignorowana.

Praktyczna procedura porządkowania wygląda tak:

1. W Search Console sprawdź raport Indeksowanie stron i Statystyki indeksowania.
2. Wyciągnij wzorce adresów, które są indeksowane lub crawlowane bez sensu.
3. Podziel je na trzy grupy: do kanonikalizacji, do wyindeksowania, do zablokowania.
4. Dla stron już zaindeksowanych zastosuj najpierw noindex i zostaw możliwość crawlowania.
5. Dla crawl trapów użyj robots.txt, ale tylko po upewnieniu się, że nie odcinasz linkowania do ważnych URL-i.
6. Po wdrożeniu testuj pojedyncze adresy przez URL Inspection i crawl zewnętrznym narzędziem, bo konfiguracja w CMS-ie często mówi jedno, a HTML wyrenderowany dla bota pokazuje drugie.

Największy priorytet mają konflikty, które dotyczą stron zarabiających: kategorii, produktów, usług, leadowych landingów i treści z linkami zewnętrznymi. Filtry i sortowania są drugie w kolejce. Kosmetyczne duplikaty parametrów można sprzątać później, o ile nie zjadają crawl budgetu w dużej skali.

Paginacja kategorii: jak zatrzymać kanibalizację strony pierwszej

Najbardziej szkodliwy mit o paginacji brzmi: „strona 2, 3 i 4 powinny mieć canonical do strony 1”. Nie powinny — przynajmniej nie jako domyślna konfiguracja kategorii. Google w aktualnych zaleceniach dla paginacji pisze, żeby każda strona sekwencji miała unikalny URL i własny canonical, a nie canonical do pierwszej strony.

Dlaczego? Bo strona 2 kategorii nie jest duplikatem strony 1, jeśli pokazuje inne produkty. Ma podobny szablon, podobny title, podobny układ, ale jej główna zawartość jest inna. Canonical z /buty-damskie/?page=2 do /buty-damskie/ mówi mniej więcej: „ta druga strona reprezentuje tę samą treść”. To nieprawda. Efekt uboczny może być taki, że Google rzadziej potraktuje dalsze strony jako źródło odkrywania produktów.

Poprawna konfiguracja bazowa wygląda tak:

/buty-damskie/
canonical: /buty-damskie/

/buty-damskie/?page=2
canonical: /buty-damskie/?page=2

/buty-damskie/?page=3
canonical: /buty-damskie/?page=3

Do tego linki sekwencyjne muszą być zwykłymi linkami HTML:

<a href="https://www.example.com/buty-damskie/?page=2">2</a>
<a href="https://www.example.com/buty-damskie/?page=3">3</a>

Nie przyciskiem, który ładuje kolejne produkty dopiero po kliknięciu. Google zaznacza, że crawlerzy zwykle odkrywają adresy z atrybutu href w elementach <a> i nie klikają przycisków ani nie wykonują akcji użytkownika potrzebnych do załadowania kolejnej porcji treści.

Jeśli kategoria korzysta z infinite scrolla albo „załaduj więcej”, trzeba zapewnić crawlowną alternatywę: osobne adresy dla kolejnych stron, linki w HTML i brak blokady w robots.txt. Samo dociąganie produktów JavaScriptem po kliknięciu jest dobre dla UX, ale nie może być jedyną drogą do zasobów.

Jak ograniczyć kanibalizację strony 1? Nie przez canonical do pierwszej strony. Lepiej zrobić to sygnałami strukturalnymi:

• strona 1 powinna mieć najmocniejsze linkowanie wewnętrzne;
• strony 2, 3 i kolejne powinny linkować z powrotem do strony 1;
• główny opis kategorii najlepiej umieścić tylko na stronie 1 albo mocno go ograniczyć na kolejnych stronach;
• title można zostawić podobny, ale w praktyce często warto dodać „strona 2”, „strona 3”, żeby ułatwić diagnostykę;
• nie indeksuj sortowań i alternatywnych kolejności tej samej listy;
• nie blokuj paginacji w robots.txt, jeśli prowadzi do produktów;
• nie używaj fragmentów URL typu #page=2, bo Google ignoruje fragmenty przy rozpoznawaniu osobnych stron paginacji.

W praktyce dla kategorii sklepu najczęściej stosuję taki podział:

Paginacja: indeksowalna, crawlowna, self-canonical.
Sortowanie: zwykle canonical do bazowej kategorii albo noindex, jeśli adres ma zostać dostępny i crawlowny.
Filtry bez popytu SEO: zwykle noindex albo blokada wzorców po analizie crawla.
Filtry z popytem SEO: osobna, indeksowalna podstrona z self-canonical, unikalnym title, H1, opisem i linkowaniem wewnętrznym.
Kombinacje filtrów: zazwyczaj ograniczane, bo potrafią stworzyć miliony adresów bez realnej wartości.

Google nadal dopuszcza blokowanie niechcianych wariantów filtrów i sortowania przez noindex albo zniechęcanie do crawlowania konkretnych wzorców w robots.txt, ale to nie powinno być przenoszone automatycznie na paginację kategorii.

A co z rel="prev" i rel="next"? Google już ich nie używa do rozpoznawania sekwencji paginacji, choć inne wyszukiwarki mogą nadal z nich korzystać. Jeśli są poprawnie wdrożone, nie trzeba ich panicznie usuwać. Nie wolno jednak opierać na nich całej strategii. Dla Google ważniejsze są dziś crawlable linki, unikalne URL-e i poprawne canonicale.

Najpierw sprawdź więc trzy rzeczy: czy strona 2 ma własny canonical, czy link do niej istnieje w HTML jako <a href>, i czy nie jest przypadkiem zablokowana w robots.txt. To są błędy, które potrafią realnie odciąć produkty od crawlowania. Dopiero potem warto dopieszczać title, opisy i detale szablonu.

FAQ: najczęstsze pytania o canonical, 301, noindex, robots.txt i paginację

Czy canonical przenosi „link juice” tak samo jak 301?
Nie tak samo. 301 jest właściwym wyborem, gdy stary URL ma zostać trwale zastąpiony nowym. Canonical pomaga konsolidować sygnały między duplikatami lub bardzo podobnymi stronami, ale jest sygnałem, a nie twardym poleceniem.

Czy można użyć canonicala i noindex jednocześnie?
Technicznie można, ale zwykle jest to zły pomysł. Noindex mówi „nie pokazuj tej strony w wynikach”, a canonical mówi „potraktuj inną stronę jako wersję reprezentatywną”. Jeśli chcesz rozwiązać duplikację w obrębie serwisu, użyj canonicala. Jeśli chcesz usunąć stronę z indeksu, użyj noindex.

Czy noindex w robots.txt działa?
Nie w Google. Google nie wspiera reguły noindex w robots.txt. Noindex trzeba wdrożyć jako meta tag w HTML albo jako nagłówek HTTP X-Robots-Tag.

Czy strona 2 paginacji powinna mieć canonical do strony 1?
Nie jako standard. Strona 2 pokazuje inny zestaw produktów lub wpisów, więc powinna mieć własny adres i najczęściej self-canonical. Canonical do strony 1 może utrudnić Google odkrywanie dalszych elementów listy.

Kiedy 301 jest lepsze od canonicala?
Gdy stary adres nie powinien być już dostępny. Dotyczy to migracji URL-i, połączenia kategorii, trwałego przeniesienia produktu lub porządkowania wersji domeny. Jeśli obie wersje mają nadal działać dla użytkownika, zwykle lepszy jest canonical.

Kiedy robots.txt może zaszkodzić?
Gdy blokuje adresy potrzebne do odkrywania ważnych stron. Jeśli produkty są dostępne głównie przez paginację lub filtry, a te zostaną zablokowane, Google może nie dotrzeć do części oferty.

Czy sortowania w sklepie powinny być indeksowane?
Zwykle nie. Sortowanie po cenie, popularności czy nazwie najczęściej pokazuje ten sam zestaw produktów w innej kolejności. Lepiej zastosować canonical do bazowej kategorii, noindex albo ograniczenie crawlowania wzorców URL — zależnie od skali problemu i roli tych adresów w linkowaniu.

Od czego zacząć audyt konfliktów SEO?
Najpierw sprawdź strony z ruchem, linkami i znaczeniem biznesowym: kategorie, produkty, usługi i leadowe landingi. Dla każdego adresu porównaj status HTTP, canonical, meta robots, robots.txt, sitemapę i linkowanie wewnętrzne. Pierwszy błąd do usunięcia to sprzeczny sygnał: na przykład canonical do URL-a, który przekierowuje, ma noindex albo jest zablokowany przed crawlowaniem.