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.