Google wybrał inną stronę kanoniczną: dlaczego ignoruje twój tag

Search Console pokazuje, że Google wybrał inną stronę kanoniczną niż ta, którą wskazałeś. Co się stało? Google potraktował tag rel=canonical jako wskazówkę, sprawdził pozostałe sygnały w serwisie i zaindeksował inny URL. Sam tag rzadko jest winny. Znajdź sygnały, które wskazują gdzie indziej, i zgraj je ze swoim wyborem.

Co znaczy „Google wybrał inną stronę kanoniczną niż użytkownik”?

Wskazałeś preferowany URL, inne sygnały wskazały inny adres i Google postawił na ten drugi. Ten stan znajdziesz wśród niezaindeksowanych adresów w raporcie indeksowania stron w Search Console. Twoja strona jest traktowana jako duplikat, a do indeksu trafia URL wybrany przez Google, co wyjaśnia przewodnik Google po raporcie indeksowania. Warto rozróżniać dwa pojęcia. Strona kanoniczna wskazana przez użytkownika to URL, który podajesz ty. Strona kanoniczna wybrana przez Google to URL, który Google faktycznie indeksuje. To też odróżnia ten stan od „Duplikat, użytkownik nie oznaczył strony kanonicznej”, gdzie nie wskazałeś niczego. Tutaj URL wskazałeś. Google po prostu się z tobą nie zgodził.

Dlaczego Google ignoruje poprawny tag canonical?

Bo to tylko jeden z kilku sygnałów, a reszta wskazuje gdzie indziej. Google traktuje kanonikalizację jako wskazówkę, a nie regułę. Dla każdej grupy duplikatów sprawdza linki wewnętrzne, mapy witryny, przekierowania, protokół i sam tag, a potem wybiera URL, za którym stoi większość z nich. Technicznie poprawny tag może więc przegrać głosowanie. Załóżmy, że nawigacja linkuje do wersji HTTP, mapa witryny podaje wariant z ukośnikiem na końcu, a stare przekierowanie wysyła użytkowników jeszcze gdzie indziej. Idealna składnia nie uratuje tu tagu. Zostaje po prostu przegłosowany.

Jakie sprzeczne sygnały przeważają nad rel=canonical?

Najczęściej winne są te wymienione w przewodniku Google o scalaniu zduplikowanych adresów. Każdy z nich powinien wskazywać ten sam URL co twój tag:

• Niezgodność z mapą witryny: mapa witryny podaje jeden URL, a rel=canonical wskazuje inny dla tej samej strony.
• Fragmenty URL: canonical wskazujący adres z fragmentem, którego Google zasadniczo nie obsługuje.
• Wersje HTTP: Google woli strony HTTPS jako kanoniczne, chyba że problemy albo sprzeczne sygnały pchają go w stronę HTTP.
• Przekierowania: przekierowania stałe to samodzielna metoda kanonikalizacji, więc mogą przeważyć nad tagiem na przekierowywanej stronie.
• Nagłówek HTTP rel canonical: wymaga bezwzględnych adresów URL, tak samo jak element link.

Jest jeden haczyk. Wpisy w mapie witryny to słabszy sygnał niż rel=canonical, więc sama poprawka mapy nie rozwiąże niezgodności. Nie zapominaj też o starych regułach (zwykle zapomina się o nich właśnie dlatego, że „po prostu działają”). Logika przekierowań jako sygnałów kanonicznych często wyjaśnia, dlaczego Google ląduje na adresie, którego się nie spodziewałeś.

Jak sprawdzić, który URL wybrał Google

Zacznij od narzędzia do sprawdzania adresów URL w Search Console. Dla każdego sprawdzanego adresu pokazuje zarówno stronę kanoniczną wskazaną przez użytkownika, jak i wybraną przez Google. Porównaj je. Potem otwórz adres wybrany przez Google i zastanów się, co działa na jego korzyść: linki wewnętrzne, wpisy w mapie witryny, przekierowania czy protokół? Pamiętaj, że lista przykładów w raporcie jest ograniczona do 1000 pozycji i może nie pokazywać wszystkich problematycznych adresów, jak podaje strona pomocy Google o tym raporcie. Mój sprawdzony sposób to grupowanie problematycznych adresów według wzorca: HTTP kontra HTTPS, ukośnik na końcu, parametry, warianty hosta. Wspólny wzorzec zwykle oznacza wspólną przyczynę.

Jak zgrać sygnały, żeby Google wybrał twoją stronę kanoniczną

Doprowadź do tego, żeby każdy sygnał wskazywał ten sam URL. Potem poczekaj, aż Google ponownie zaindeksuje stronę. Przejdź przez te kroki na swoim serwerze źródłowym, w CMS albo w konfiguracji NGINX:

1. Ustaw jeden bezwzględny URL kanoniczny w tagu albo w nagłówku HTTP rel canonical, nigdy w obu z różnymi wartościami.
2. W mapie witryny umieszczaj tylko kanoniczne adresy URL.
3. Kieruj linki wewnętrzne do wersji kanonicznej.
4. Przekieruj na stałe duplikaty, których chcesz się pozbyć.
5. Serwuj jeden protokół i jeden host, z przekierowaniem HTTP na HTTPS.

W WordPressie wycieki protokołu są wszędzie. Uporządkowanie pomieszanych adresów http i https często sprawia, że ten stan znika sam. Serwis działa za proxy? Sprawdź, jaką nazwę hosta faktycznie zgłasza serwer źródłowy - wpis o hoście kanonicznym za proxy pokazuje to krok po kroku. W przypadku wersji językowych zostaw na każdej z nich canonical wskazujący na samą siebie i trzymaj się zaleceń dotyczących hreflang w sieciach wielojęzycznych. I niezależnie od tego, czy ruch idzie przez adresy IP proxy w UE i USA, czy prosto na serwer, te reguły są w twojej konfiguracji. Nikt inny ich za ciebie nie poprawi.

Kiedy zostawić wybór Google w spokoju

Czasem Google wybrał inną stronę kanoniczną, a wybrany URL to dokładnie ten, który i tak chciałbyś widzieć w wynikach wyszukiwania. Wtedy nie ma czego naprawiać. Pomoc Google do raportu mówi, że zduplikowane adresy nie powinny być indeksowane, a warianty stron z zastosowanymi filtrami mają zostać poza indeksem. Działaj więc tylko wtedy, gdy wybór jest naprawdę błędny: zły protokół, niewłaściwy host, wersja z parametrem albo strona o innej treści. Po poprawce sprawdź kluczowy URL, poproś o zaindeksowanie i obserwuj stan przez kilka kolejnych indeksowań.

Podsumowując? Gdy Google wybrał inną stronę kanoniczną, twój tag jest jednym głosem, a nie poleceniem. Ustaw mapę witryny, linki, przekierowania i protokół za tym samym adresem URL, a tag zwykle wygra.

FAQ

Czytaj też:

• Błędy soft 404: dlaczego Google usuwa strony zwracające 200
• Noindex vs Disallow: jak poprawnie usunąć strony z Google
• Dlaczego adresy IP z odzysku mogą zaszkodzić nowej stronie
• Nadużywanie reputacji witryny w EOG: Google zmienia egzekwowanie zasad