Co robią tagi kanoniczne, gdy użyjesz ich źle
Tagi kanoniczne są przydatne, ale nie są nieszkodliwe. Zły canonical może ukryć stronę, którą chcesz pozycjonować, scalić sygnały z niewłaściwym adresem URL i sprawić, że debugowanie indeksowania będzie znacznie trudniejsze, niż powinno.
Spis treści
- Tag kanoniczny nie jest gumką do usuwania duplikatów treści
- Co się dzieje, gdy canonical wskazuje zły adres URL
- 1. Indeksowany jest niewłaściwy adres URL
- 2. Sygnały rankingowe konsolidują się w złym miejscu
- 3. Wyszukiwarki ignorują tag
- 4. Debugowanie staje się niepotrzebnie trudne
- Najdroższe błędy związane z canonicalami
- Kanonikalizowanie wszystkiego do strony głównej
- Kanonikalizowanie stron paginacji do pierwszej strony
- Kanonikalizowanie stron filtrowanych bez sprawdzenia intencji wyszukiwania
- Wskazywanie canonicali na przekierowane lub zablokowane adresy URL
- Mieszanie canonicala z noindex, jakby oznaczały to samo
- Praktyczny audyt canonicali
- Canonicale wskazujące na siebie są zwykle dobrym ustawieniem domyślnym
- Tagi kanoniczne powinny odpowiadać rzeczywistej polityce adresów URL witryny
- Najważniejszy wniosek
Tag kanoniczny nie jest gumką do usuwania duplikatów treści
Tag kanoniczny mówi wyszukiwarkom, który adres URL preferujesz, gdy kilka adresów zawiera tę samą lub zasadniczo podobną treść. Typowa wersja HTML wygląda tak:
<link rel="canonical" href="https://example.com/preferred-page/">
Istnieje też wersja w nagłówku HTTP, przydatna głównie dla plików innych niż HTML, takich jak PDF-y:
Link: <https://example.com/preferred-file.pdf>; rel="canonical"
Brzmi dość prosto. Problemy zaczynają się wtedy, gdy zespoły traktują tagi kanoniczne jako bezpieczny sposób na uporządkowanie wszystkiego, co niewygodne: nawigacji fasetowej, parametrów śledzących, stron do druku, niemal zduplikowanych stron produktów, paginacji, adresów stagingowych i starych stron kampanii.
Tagi kanoniczne nie są przyciskiem usuwania. Nie są przekierowaniem. Nie zastępują architektury informacji. I nie ma gwarancji, że zostaną zastosowane.
Wyszukiwarki używają canonicali jako silnych wskazówek. Porównują tag kanoniczny z innymi sygnałami: przekierowaniami, linkami wewnętrznymi, adresami URL w mapie witryny, adnotacjami hreflang, podobieństwem treści, kodami statusu HTTP oraz adresami URL, na które faktycznie trafiają użytkownicy i crawlery. Jeśli te sygnały są sprzeczne, wyszukiwarka może zignorować Twój canonical albo wybrać zupełnie inny kanoniczny adres URL.
Właśnie dlatego błędne canonicale potrafią tak dezorientować. Znacznik wygląda poprawnie w przeglądarce, a mimo to w wynikach wyszukiwania pojawia się niewłaściwa strona — albo właściwa znika.
Co się dzieje, gdy canonical wskazuje zły adres URL
Gdy wyszukiwarka widzi zduplikowane lub niemal zduplikowane adresy URL, zwykle grupuje je w klaster i wybiera jeden adres jako kanoniczny. Wybrany canonical to wersja, która najprawdopodobniej zostanie zaindeksowana i pokazana w wynikach wyszukiwania. Sygnały z duplikatów mogą zostać skonsolidowane w tym wybranym adresie URL.
Jeśli Twój tag kanoniczny wskazuje złą stronę, może wydarzyć się kilka rzeczy.
1. Indeksowany jest niewłaściwy adres URL
Załóżmy, że masz dwa adresy URL:
/mens-running-shoes//sale/mens-running-shoes/
Jeśli strona wyprzedaży wskazuje canonicalem główną stronę kategorii, może to być w porządku, jeśli treść jest niemal identyczna, a adres wyprzedażowy jest tylko wersją filtrowaną. Ale jeśli strona wyprzedaży ma unikalny tekst, unikalne produkty i własny popyt w wyszukiwaniu, canonical może ją stłumić.
Strona nadal może być crawlowana. Nadal może być dostępna dla użytkowników. Ale wyszukiwarki mogą zdecydować, że nie zaindeksują jej osobno, ponieważ wskazano im inny adres URL jako preferowaną wersję.
To najczęstsza awaria canonicala: nie spektakularna usterka techniczna, lecz ciche zniknięcie z indeksu.
2. Sygnały rankingowe konsolidują się w złym miejscu
Canonicali często używa się do konsolidowania sygnałów, takich jak linki i warianty zduplikowanej treści. Jest to przydatne, gdy duplikaty są rzeczywiście równoważne. Jest ryzykowne, gdy nie są.
Jeśli artykuł na blogu ma adresy URL ze śledzeniem, takie jak:
/guide-to-canonical-tags/?utm_source=newsletter/guide-to-canonical-tags/?utm_source=linkedin
Wtedy kanonikalizacja obu do /guide-to-canonical-tags/ ma sens.
Ale jeśli wersja hiszpańska, wersja do druku z dodatkową treścią albo wariant produktu o innej intencji wskazuje ten sam canonical, możesz łączyć sygnały, które powinny pozostać oddzielne. Efektem może być słabsza trafność wszystkich tych stron.
Tagi kanoniczne dotyczą równoważności. Jeśli dwie strony odpowiadają na różne intencje wyszukiwania, prawdopodobnie nie powinny wskazywać siebie nawzajem jako canonical.
3. Wyszukiwarki ignorują tag
Canonical nie jest poleceniem. Jeśli docelowy adres kanoniczny przekierowuje, zwraca 404, jest zablokowany, ma noindex albo zawiera bardzo odmienną treść, wyszukiwarki mogą go zignorować.
W pewnym sensie to dobrze: zły canonical nie zawsze niszczy indeksowanie. Oznacza to jednak również, że nie możesz zakładać, iż tag robi to, co myślisz. Strona może deklarować jeden canonical, podczas gdy Google wybierze inny.
Jest to szczególnie częste, gdy linki wewnętrzne, mapy witryny i canonicale nie są ze sobą zgodne. Jeśli każdy link wewnętrzny prowadzi do /product, mapa witryny zawiera /product/, a canonical wskazuje https://www.example.com/product?ref=main, tworzysz mały spór między własnymi sygnałami.
Wyszukiwarki dobrze radzą sobie z rozstrzyganiem takiego sporu. Nie zawsze jednak rozstrzygają go tak, jak zamierzasz.
4. Debugowanie staje się niepotrzebnie trudne
Złe canonicale rzadko psują się głośno. Dają objawy, które wyglądają jak inne problemy SEO:
- „Wykryto, obecnie nie zaindeksowano” albo podobny stan zawieszenia indeksowania
- Niewłaściwy adres URL pozycjonujący się na zapytanie
- Adresy URL z parametrami pojawiające się w raportach
- Strony kategorii niewidoczne mimo możliwości crawlowania
- Strony międzynarodowe składane do niewłaściwej wersji językowej
- Nowe szablony uruchamiane z mniejszą liczbą zaindeksowanych stron niż oczekiwano
Dlatego debugowanie canonicali powinno obejmować surowy HTML, wyrenderowany HTML, nagłówki HTTP, przekierowania i wpisy w mapie witryny. Jeśli już analizujesz łańcuchy przekierowań albo niedopasowane nagłówki, obowiązują te same nawyki; praktyczny workflow inspekcji HTTP, taki jak w naszym przewodniku po debugowaniu przekierowań i nagłówków HTTP na produkcji, zwykle szybciej wychwyci sprzeczności canonicali niż wpatrywanie się w pole w CMS-ie.
Najdroższe błędy związane z canonicalami
Kanonikalizowanie wszystkiego do strony głównej
To wciąż się zdarza. Pole w szablonie zostaje puste, wtyczka wraca awaryjnie do katalogu głównego witryny i nagle setki stron deklarują stronę główną jako canonical.
Wyszukiwarki mogą to zignorować, bo treść jest oczywiście inna. Ale jeśli wystarczająco dużo sygnałów jest chaotycznych, niektóre strony mogą zostać usunięte albo błędnie zgrupowane. Co najmniej wysyłasz bezużyteczną i sprzeczną wskazówkę na każdej stronie.
Strona główna prawie nigdy nie jest canonicalem dla strony wewnętrznej.
Kanonikalizowanie stron paginacji do pierwszej strony
Przez długi czas niektóre serwisy kanonikalizowały /category/page/2/, /page/3/ i kolejne strony z powrotem do strony pierwszej. Celem było uniknięcie zduplikowanych stron kategorii.
Problem polega na tym, że strony paginacji nie są duplikatami. Zawierają inne elementy i pomagają crawlerom odkrywać głębszą treść. Kanonikalizowanie ich wszystkich do strony pierwszej może zmniejszyć szansę, że wyszukiwarki w pełni przetworzą późniejsze strony.
Zwykle strony paginacji powinny mieć canonicale wskazujące na siebie, chyba że istnieje konkretny powód do konsolidacji.
Kanonikalizowanie stron filtrowanych bez sprawdzenia intencji wyszukiwania
Nawigacja fasetowa tworzy trudne wybory. Niektóre filtrowane adresy URL to śmieci:
?sort=price_ascending?view=grid?sessionid=123
Inne mogą być wartościowymi stronami docelowymi:
/sofas/blue//laptops/16gb-ram//hotels/paris/pet-friendly/
Reguły canonical stosowane hurtowo często usuwają użyteczne strony wyszukiwania razem z bezużytecznym szumem parametrów. Zanim skanonikalizujesz strony filtrowane, zapytaj, czy filtrowana strona ma stabilną treść, linki wewnętrzne, popyt w wyszukiwaniu i odrębną potrzebę użytkownika.
Jeśli odpowiedź brzmi tak, może zasługiwać na indeksowanie z canonicalem wskazującym na siebie.
Wskazywanie canonicali na przekierowane lub zablokowane adresy URL
Docelowy adres kanoniczny powinien być czysty, indeksowalny i zwracać 200 OK. Nie wskazuj canonicali na adresy URL, które przekierowują, zwracają błędy, wymagają cookies, są zablokowane przez robots.txt albo mają noindex.
To jedna z najłatwiejszych kontroli do automatyzacji. Przecrawluj witrynę i oznacz docelowe adresy canonical, które nie zwracają czystej odpowiedzi 200.
Mieszanie canonicala z noindex, jakby oznaczały to samo
rel="canonical" i noindex rozwiązują różne problemy.
Używaj canonicala, gdy istnieją duplikaty i chcesz skonsolidować sygnały do preferowanego adresu URL. Używaj noindex, gdy w ogóle nie chcesz, aby strona była indeksowana.
Użycie obu naraz wysyła niezręczny komunikat: „Nie indeksuj tej strony, ale jednocześnie użyj jej jako sygnału duplikatu dla innej strony”. Wyszukiwarki często potrafią sobie z tym poradzić, ale nie jest to czysta instrukcja. Jeśli strona jest duplikatem, skanonikalizuj ją. Jeśli nie powinna pojawiać się w wyszukiwarce i nie ma użytecznej relacji duplikatu, rozważ noindex.
Praktyczny audyt canonicali
Nie potrzebujesz wielkiej platformy SEO, aby znaleźć wiele problemów z canonicalami. Zacznij od crawlu, kilku próbek adresów URL i arkusza kalkulacyjnego.
Dla każdego ważnego szablonu sprawdź:
- Czy strona ma dokładnie jeden tag kanoniczny? Wiele tagów kanonicznych tworzy niejednoznaczność.
- Czy canonical jest bezwzględny? Użyj pełnego adresu URL, łącznie z protokołem i nazwą hosta.
- Czy docelowy adres canonical zwraca
200 OK? Unikaj celów przekierowanych, zablokowanych lub zwracających błędy. - Czy docelowy adres canonical jest indeksowalny? Bez
noindex, bez blokady robots, bez wymogu uwierzytelnienia. - Czy treść jest rzeczywiście równoważna? Podobna nie zawsze znaczy równoważna.
- Czy linki wewnętrzne są zgodne? Linkuj do kanonicznego formatu adresu URL wszędzie tam, gdzie to możliwe.
- Czy mapa witryny jest zgodna? Mapy witryny powinny zazwyczaj zawierać kanoniczne, indeksowalne adresy URL.
- Czy tagi hreflang są zgodne? Strony międzynarodowe potrzebują spójnych relacji canonical i hreflang.
- Czy wyrenderowany HTML zgadza się z surowym HTML? JavaScript może zmieniać lub wstrzykiwać tagi.
- Jaki canonical wybrała wyszukiwarka? Narzędzia inspekcji mogą pokazać, kiedy deklarowany canonical różni się od wybranego canonicala.
W tym miejscu Lighthouse także może być pomocny, ale tylko w swoich granicach. Może sygnalizować niektóre problemy z crawlowaniem i dokumentem, ale nie rozumie Twojej intencji biznesowej ani strategii canonical. Traktuj go jako jedno ze źródeł, nie jako wyrok. Jeśli potrzebujesz spokojniejszego sposobu oddzielenia użytecznych ustaleń od szumu, zobacz, jak czytać raport Lighthouse bez paniki.
Canonicale wskazujące na siebie są zwykle dobrym ustawieniem domyślnym
Każda ważna, indeksowalna strona powinna zwykle deklarować samą siebie jako canonical. Nie dlatego, że wyszukiwarki nie potrafią tego ustalić bez tagu. Dlatego, że canonicale wskazujące na siebie ograniczają niejednoznaczność, gdy parametry, linki śledzące, skopiowane adresy URL i osobliwości CMS-a tworzą alternatywne ścieżki do tej samej treści.
Dla czystej strony produktu to zwykle właściwe:
<link rel="canonical" href="https://example.com/products/linen-shirt/">
Dla adresu URL ze śledzeniem canonical powinien zwykle wskazywać z powrotem czystą wersję:
<link rel="canonical" href="https://example.com/products/linen-shirt/">
W przypadku rzeczywiście innego wariantu produktu odpowiedź zależy od sytuacji. Jeśli czerwona koszula, niebieska koszula i czarna koszula mają ten sam opis i zmienia się tylko kolor, jedna kanoniczna strona produktu może wystarczyć. Jeśli każdy wariant ma osobny popyt, recenzje, obrazy, stan magazynowy i linki wewnętrzne, oddzielne indeksowalne strony mogą mieć sens.
Nie ma uniwersalnej reguły canonical dla wariantów. Jest tylko pytanie: czy te strony są zamienne dla osoby wyszukującej?
Tagi kanoniczne powinny odpowiadać rzeczywistej polityce adresów URL witryny
Większość błędów canonical to objawy głębszego problemu z polityką adresów URL. Witryna nie zdecydowała, czy końcowe ukośniki mają znaczenie, czy adresy URL z wielkimi literami powinny się rozwiązywać, czy parametry są dozwolone, czy HTTP przekierowuje do HTTPS albo czy www jest kanoniczne.
Wybierz jedną czystą wersję każdego adresu URL i spraw, aby cały system był zgodny:
- Przekierowuj niepreferowane wersje adresów URL do wersji preferowanych.
- Linkuj wewnętrznie do wersji preferowanych.
- Umieszczaj wersje preferowane w mapach witryny XML.
- Używaj canonicali wskazujących na siebie na stronach preferowanych.
- Kanonikalizuj tylko prawdziwe duplikaty do preferowanego adresu URL.
Gdy wszystkie te sygnały wskazują ten sam kierunek, tagi kanoniczne stają się nudne. I o to chodzi.
Najważniejszy wniosek
Tagi kanoniczne są potężne, ponieważ wpływają na indeksowanie i konsolidację sygnałów. Z tego samego powodu są niebezpieczne.
Błędny canonical nie zawsze usunie stronę z wyszukiwania. Wyszukiwarki mogą go zignorować. Ale liczenie na to, że wyszukiwarki uratują złe sygnały, nie jest strategią. Bezpieczniejsze podejście polega na rezerwowaniu kanonikalizacji dla prawdziwych duplikatów, utrzymywaniu celów w czystej i indeksowalnej formie oraz sprawieniu, by linki wewnętrzne, przekierowania, mapy witryny i canonicale opowiadały tę samą historię.
Canonicale nie są miejscem, w którym ukrywa się chaotyczną architekturę. Są miejscem, w którym potwierdza się, że została uporządkowana.