Canonical, przekierowanie czy noindex: co stosować i kiedy

Poradnik decyzyjny: canonical, przekierowanie 301, noindex i robots.txt przy duplikatach, filtrach, kampaniach i usuniętych treściach.

Canonical, przekierowanie czy noindex: co stosować i kiedy
Krótka odpowiedź

Przekierowania należy używać przy rzeczywistym przeniesieniu, canonical przy dostępnych podobnych wariantach, noindex przy przydatnej stronie, która nie wymaga indeksacji, a robots.txt wyłącznie do sterowania crawlowaniem.

Canonical, przekierowanie i noindex są często stosowane jako wymienne poprawki SEO, jednak każdy z tych mechanizmów rozwiązuje inny problem. Canonical wskazuje preferowaną wersję podobnej treści, przekierowanie kieruje zarówno użytkownika, jak i robota pod inny URL, a noindex prosi, aby dostępna strona nie pojawiała się w wynikach. Robots.txt jedynie ogranicza indeksowanie przez roboty (crawling).

Niewłaściwe połączenie może wywołać konflikt: strona zablokowana z noindexem może nie zostać odczytana, przekierowany adres URL nie może już przekazać własnego canonical, a odmienna treść skanonizowana do innej strony może zostać zignorowana. Decyzja zaczyna się więc od celu adresu URL, potrzeby użytkownika i stopnia zgodności treści.

Trwałe przeniesienie wymaga przekierowania

Jeśli stary URL nie ma już pełnić samodzielnej funkcji, a istnieje merytorycznie odpowiadający mu nowy adres, należy zastosować przekierowanie stałe. Użytkownik trafi do aktualnej treści, a linki wewnętrzne można stopniowo poprawić. Typowym przykładem jest zmiana przyjaznego URL usługi, połączenie dwóch takich samych artykułów lub konsolidacja hosta i protokołu.

Cel musi być adekwatny. Masowe przekierowanie usuniętych pozycji na stronę główną nie wyjaśnia, co się stało. Unikajcie łańcuchów przekierowań i zaktualizujcie mapę witryny, canonical oraz linki wewnętrzne do docelowego URL. Stare reguły pozostawcie wystarczająco długo, zgodnie z rzeczywistym wykorzystaniem i linkami, a nie tylko do końca migracji.

Canonical pozostawia wariant dostępnym

Canonical jest odpowiedni, gdy kilka dostępnych URL zawiera taką samą lub bardzo podobną główną treść, na przykład przy parametrach śledzących, alternatywnym sortowaniu lub wersji do druku. Preferowana strona powinna być indeksowalna, zwracać kod 200 i odpowiadać treścią wariantowi. Każda strona kanoniczna zwykle wskazuje sama na siebie.

To sygnał, a nie bezwzględne polecenie. Wyszukiwarka może wybrać inną wersję, jeśli linki wewnętrzne, sitemap i przekierowania wskazują co innego. Nie należy używać canonical dla treści o innej intencji tylko po to, by uniknąć decyzji o jej jakości. Niespójny wybór lepiej poprawić już na etapie tworzenia URL.

  • kanoniczny cel zwraca 200 i jest indeksowalny
  • treść wariantów jest rzeczywiście podobna
  • linki wewnętrzne kierują do preferowanej wersji
  • sitemap zawiera wyłącznie kanoniczne adresy URL

Noindex dla dostępnej strony poza wynikami wyszukiwania

Noindex sprawdza się na stronie, której użytkownik lub proces potrzebuje, ale która nie powinna być wejściem z wyszukiwania organicznego. Mogą to być wewnętrzne wyniki, potwierdzenia, niektóre archiwa lub tymczasowa kampania. Strona musi pozostać dostępna dla robota, aby mógł odczytać dyrektywę, dopóki nie zostanie przetworzona i usunięta z indeksu.

Strony długotrwale oznaczone jako noindex mogą mieć mniejszą wartość jako źródło linków wewnętrznych, dlatego nie opierajcie na nich głównej architektury. Noindex nie jest rozwiązaniem dla słabej strony, która zgodnie ze strategią ma pozyskiwać ruch. W takim przypadku poprawcie treść, połączcie ją z inną lub przemyślcie jej cel.

Robots.txt nie oznacza usunięcia z indeksu

Blokada w robots.txt uniemożliwia lub ogranicza crawlowanie ścieżki, ale znany adres URL może pojawić się w wynikach bez wczytanej treści. Robot nie zobaczy też noindex ani canonical w zablokowanej odpowiedzi. Robots.txt używaj dla przestrzeni crawlowania, których nie ma sensu odwiedzać, a nie jako uniwersalnego narzędzia do usuwania wyników.

Przy zmianie z blokowania na noindex należy najpierw zezwolić na crawlowanie, aby wyszukiwarka mogła odczytać dyrektywę. Wrażliwe URL należy monitorować osobno: robots.txt nie jest zabezpieczeniem, a jego treść jest publiczna. Naprawdę niepubliczne dane wymagają uwierzytelniania i kontrolowanych uprawnień.

Macierz decyzyjna i kontrola konfliktów

Dla każdej grupy URL należy odpowiedzieć na pytania: czy ma pozostać dostępna, czy ma pojawiać się w wynikach wyszukiwania, czy treść jest identyczna z inną stroną i czy istnieje trwały zamiennik? Z tych odpowiedzi wynika mechanizm. Decyzje należy stosować na poziomie szablonu i przetestować próbkę oraz przypadki brzegowe.

Za pomocą crawla należy wyszukać przekierowane URL z canonical, strony noindex w mapie witryny, canonical wskazujące na błąd, zablokowane zasoby i łańcuchy przekierowań. Warto porównać zadeklarowaną wersję kanoniczną z wersją wybraną przez wyszukiwarkę. Przy naprawie należy zmieniać jeden logiczny sygnał naraz, aby móc ocenić efekt i nie wywołać kolejnego konfliktu.

  • trwałe przeniesienie treści wykorzystuje odpowiednie przekierowanie
  • zduplikowany dostępny wariant wskazuje właściwy canonical
  • publiczna strona pomocnicza może używać noindex
  • treści prywatne chroni uwierzytelnianie, a nie robots.txt
  • sitemap zawiera wyłącznie kanoniczne, indeksowalne adresy URL
  • linki wewnętrzne prowadzą bezpośrednio do preferowanego celu
  • żaden sygnał nie koliduje z kodem statusu strony
  • kontrola po każdej regule masowej

Najczęstsze pytania

Czy strona może mieć jednocześnie noindex i canonical wskazujący na inny URL?

Technicznie tak, ale sygnały mogą być niejednoznaczne. Wybierz mechanizm zgodnie z celem: dostępny wariant zduplikowany lub strona, która nie powinna być indeksowana.

Czy robots.txt usunie stronę z wyników wyszukiwania?

Nie w sposób niezawodny. Blokuje crawlowanie, a nie wiedzę o adresie URL. Do usunięcia należy, w zależności od sytuacji, użyć odpowiedniego statusu, noindex na dostępnej stronie lub autoryzowanych narzędzi.

Czy canonical powinien prowadzić przez przekierowanie?

Nie jest to czyste rozwiązanie. Canonical należy kierować bezpośrednio na docelowy, poprawnie działający i indeksowalny URL, a także odpowiednio zaktualizować linki wewnętrzne i mapę witryny.

Źródła i dalsza lektura

Adam Antoni, programista rozwiązań cyfrowych
Adam Antoni · Webiant

Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.

Potrzebujesz rozwiązać ten temat w swoim projekcie?

Proszę napisać, co chcą Państwo poprawić, z czym obecnie się zmagają i jakiego rezultatu oczekują. Podczas wstępnej konsultacji omówimy odpowiedni zakres i dalsze kroki.

Proszę wybrać, na które pliki cookie Państwo zezwalają. Wybór można w każdej chwili zmienić za pomocą linku w stopce lub przycisku cookies.

Ochrona prywatności i szczegóły dotyczące plików cookie