Sprzeczne sygnały dla Google: czego nie łączyć z noindex i canonical

Krótka odpowiedź

Sprzeczne sygnały to sytuacja, w której jedna część strony mówi Google „indeksuj ten adres”, a inna „nie indeksuj” albo „główny jest inny adres”. Dla wielu takich par, na przykład noindex z canonical, Google nie podaje publicznie, który sygnał wygrywa, więc wynik bywa inny, niż zakładasz. Przykłady takich par to noindex i link kanoniczny do innego adresu, blokada w robots.txt z noindex oraz mapa witryny z adresami, które nie mają być w Google. Zasada jest jedna: każdy adres powinien dostawać ze wszystkich miejsc ten sam komunikat.

Dlaczego Google nie wybiera za Ciebie

Google opisuje w dokumentacji, że sygnały wskazujące adres główny mają różną siłę. Stałe przekierowanie i rel="canonical" to sygnały silne, mapa witryny to sygnał słaby. Żaden z nich nie jest poleceniem, które Google musi wykonać. Gdy się wykluczają, Google waży je po swojemu.

W lipcu 2026 roku John Mueller z Google odpowiedział na Bluesky na pytanie o rozbieżne dane produktu w feedzie i na stronie: nie ma publicznie określonej kolejności, według której Google godzi sprzeczne metadane, a takie sprzeczności trzeba naprawić, zamiast sprawdzać, czy mimo wszystko zadziałają. Pytanie dotyczyło danych produktowych, ale ta sama logika stoi za zaleceniami Google dla tagów indeksowania. Dokumentacja mówi wprost, żeby nie wskazywać różnych adresów kanonicznych dla tej samej strony różnymi metodami.

Tabela zgodności ustawień: co z czym łączyć

Poniżej pary, które warto sprawdzić w audycie, z decyzją dla każdej. Szczegóły trudniejszych przypadków są w dalszych częściach.

Noindex i canonical na jednej stronie

Strona ma noindex i jednocześnie link kanoniczny wskazujący inny adres jako główny. Google w dokumentacji odradza używanie noindex po to, żeby dana strona nie została wybrana jako kanoniczna w obrębie serwisu, bo noindex całkowicie usuwa stronę z wyników.

Obawa, że noindex „przejdzie” razem z canonical na stronę docelową, ma źródło w wypowiedzi Google. W sierpniu 2012 roku John Mueller mówił, według relacji agencji Dejan Marketing, że lepiej unikać łączenia tych tagów, bo może się zdarzyć, że Google weźmie noindex i zastosuje go także do adresu kanonicznego. Logika była taka: canonical oznacza strony równoważne, więc noindex z jednej może zostać przeniesiony na drugą. Nie znaleźliśmy jednak udokumentowanego przypadku, w którym strona docelowa wypadła z indeksu właśnie z tego powodu.

Późniejsze wypowiedzi brzmią inaczej. W 2017 roku Mueller powiedział w hangoucie, że Google w praktyce uznaje wtedy canonical za pomyłkę i traktuje noindex jako sposób wskazania adresu głównego. W kwietniu 2023 roku napisał na Twitterze, że noindex z canonical ma sens, jeśli bardziej zależy Ci na wykluczeniu strony z indeksu niż na scaleniu sygnałów. W 2024 roku na Reddicie radził wybrać jedno: noindex albo linki, z których Google ma korzystać.

Ta para potrafi powstać bez niczyjej decyzji. Szablon, wtyczka SEO albo platforma sklepu może dodawać canonical do każdej strony automatycznie, a ktoś inny ręcznie ustawia noindex na wybranych podstronach. Sprawdź, co faktycznie trafia do kodu.

Dokąd może wskazywać canonical

Adres w rel="canonical" ma być stroną, którą Google może pobrać i pokazać w wynikach. Dokumentacja Google nie opisuje każdego błędnego celu osobno, ale wynika to z jej zasad: noindex usuwa stronę z wyników, a robots.txt nie służy do kanonizacji. Canonical powinien więc wskazywać adres końcowy, który:

• odpowiada kodem 200, bez przekierowania i bez błędu 404;
• nie ma noindex w meta tagu ani w nagłówku;
• nie jest zablokowany w robots.txt;
• sam wskazuje siebie jako kanoniczny, bez dalszego łańcucha A → B → C;
• jest w tym samym języku co strona, która go wskazuje, a gdy takiej wersji nie ma, w najlepszym języku zastępczym.

Wersje językowe to osobny przypadek. Google pisze, że tłumaczenia są duplikatami tylko wtedy, gdy główna treść nie została przetłumaczona. Adres kanoniczny ma być w tym samym języku, a gdy strony w tym języku nie ma, w najlepszym języku zastępczym. Wersje łączy hreflang. Szczegóły opisaliśmy w tekście o tym, jak ustawić hreflang razem z linkiem kanonicznym.

Przy paginacji Google zaleca, żeby nie wskazywać pierwszej strony listy jako kanonicznej dla pozostałych, tylko dać każdej stronie własny adres kanoniczny.

Podobnie z przekierowaniem 301 z adresu A na B, gdy B ma canonical z powrotem na A albo na trzeci adres. Oba sygnały Google uznaje za silne, a wskazują różne adresy.

Hreflang, mapa witryny i linki wewnętrzne

Hreflang. Każda wersja językowa powinna wskazywać siebie i wszystkie pozostałe. Google uwzględnia tylko te pary stron, które wskazują się nawzajem. Według notatki z hangoutu Google z 2014 roku, spisanej przez firmę Lumar, Mueller radził nie wpisywać do hreflang adresów, które przekierowują, mają noindex albo wskazują inny adres jako kanoniczny, bo oznaczenia mogą zostać pominięte. W sierpniu 2026 roku Gary Illyes z Google odpowiedział na pytanie o wersje językowe, z których Google wybrał jedną jako kanoniczną: pozostałe adresy z hreflang są wtedy alternatywnymi nazwami strony kanonicznej i w ścisłym sensie nie są indeksowane osobno.

Mapa witryny. Google każe wpisywać do mapy adresy, które chcesz widzieć w wynikach wyszukiwania, a wszystkie adresy w mapie traktuje jako proponowane strony kanoniczne. Adres z noindex, przekierowaniem albo canonical na inną stronę przeczy więc temu, co podaje strona. Pomoc Search Console wymienia adresy z noindex albo z blokadą w robots.txt w przesłanej mapie jako jedną z przyczyn nagłych skoków błędów. Co jeszcze usunąć z pliku, opisujemy w tekście o tym, co wpisać do mapy witryny, a czego do niej nie dodawać.

Linki wewnętrzne. Google zaleca linkować w obrębie serwisu do adresu kanonicznego. Gdy menu i okruszki prowadzą do wersji z parametrami, a canonical wskazuje wersję bez nich, serwis sam osłabia własną wskazówkę.

Noindex, nofollow, nagłówek i JavaScript

Blokada w robots.txt i noindex. Googlebot nie pobiera zablokowanej strony, więc nie widzi noindex, a strona może zostać w wynikach. Nie powtarzamy tu całej procedury, bo opisujemy ją w tekście o tym, dlaczego Disallow i noindex razem nie działają.

Noindex z follow i noindex z nofollow. Domyślnie Google indeksuje stronę i odczytuje linki. Sam noindex wyklucza stronę z wyników, a linki na niej mogą być dalej odczytane. W 2017 roku Mueller powiedział jednak, że długotrwały noindex z follow działa w praktyce jak noindex z nofollow. W 2024 roku dodał, że linki ze strony z noindex mogą zostać odczytane, ale nie ma na to gwarancji. Jeśli jakaś strona jest dla robota jedyną drogą do ważnych podstron, nie licz na linki ze strony z noindex. Dodaj te podstrony do menu, kategorii albo mapy witryny.

Meta robots i X-Robots-Tag. Każda reguła z meta tagu działa też w nagłówku HTTP. Dokumentacja Google mówi, że przy sprzecznych regułach robots obowiązuje bardziej restrykcyjna. Google nie ma reguły index, bo indeksowanie jest domyślne. Jeśli serwer wysyła nagłówek z noindex dla wszystkich robotów albo dla Googlebota, zakładaj, że strona wypadnie z indeksu bez względu na to, co jest w meta tagu.

Kod HTML i JavaScript. Gdy Google znajdzie noindex w pierwotnym kodzie strony, może pominąć renderowanie i wykonanie JavaScriptu. Skrypt, który ten tag usuwa, może więc nie zadziałać. Dodanie noindex skryptem Google opisuje jako dopuszczalne, choć zadziała tylko wtedy, gdy Google wyrenderuje stronę. Z canonical jest podobnie: Google radzi umieścić go w HTML i nie zmieniać skryptem na inny adres.

<!-- Kod HTML wysłany przez serwer -->
<meta name="robots" content="noindex">
<!-- Skrypt zmienia go później na "index": Google może tego nie zobaczyć -->

Co łączy się bez problemu

• Canonical do siebie i hreflang. Każda wersja językowa wskazuje siebie jako kanoniczną i wymienia pozostałe wersje.
• Noindex i follow. Strona nie trafia do wyników, a robot może korzystać z linków, z zastrzeżeniem z poprzedniej części.
• Paginacja z własnym canonical. Druga, trzecia i kolejna strona listy wskazują same siebie.
• Noindex na wariantach filtrowania i sortowania. Google podaje go w dokumentacji o paginacji jako sposób na niechciane warianty listy.
• Przekierowanie 301 i mapa witryny z adresem docelowym. Oba sygnały wskazują ten sam adres.
• Canonical w nagłówku HTTP dla plików PDF. To miejsce, w którym nagłówek ma sens, bo plik nie ma sekcji <head>. Dla zwykłych stron Google radzi wybrać jedną metodę.

Jak sprawdzić każdą parę w Search Console

1. Wklej adres w pole na górze Search Console, czyli w narzędzie do sprawdzania adresów URL.
2. W sekcji o indeksowaniu sprawdź pole „Czy skanowanie jest dozwolone”. Jeśli strona jest zablokowana w robots.txt, pole „Czy indeksowanie jest dozwolone” zawsze pokazuje „Tak”, bo Google nie widzi noindex. Nie daj się zmylić.
3. Przy stronie z noindex pole „Czy indeksowanie jest dozwolone” powinno wskazywać, że indeksowanie blokuje dyrektywa noindex. Kliknij „Sprawdź URL wersji opublikowanej”, żeby zobaczyć, czy tag nadal jest na stronie.
4. Porównaj „Adres kanoniczny określony przez użytkownika” z „Adres kanoniczny wybrany przez Google”. Różne wartości znaczą, że Google nie przyjął Twojej wskazówki. Wybór Google widać tylko w danych z indeksu, test wersji opublikowanej go nie pokaże.
5. W polu „Mapy witryn” sprawdź, czy adres z noindex albo z canonical na inną stronę nie jest w mapie. Pole pokazuje tylko mapy przesłane w Search Console albo podane w robots.txt, więc w razie wątpliwości przejrzyj też sam plik mapy.
6. Kod strony i nagłówki odpowiedzi sprawdź w przeglądarce, w narzędziach dla programistów. Szukaj drugiego tagu canonical, nagłówka X-Robots-Tag i noindex dodawanego przez wtyczkę.

Statusy, które wynikają z niezgodnych adresów kanonicznych, opisujemy w tekście o tym, co znaczą statusy duplikatów w raporcie Indeksowanie stron.

curl -sI https://twojadomena.pl/strona/ | grep -iE "^HTTP|x-robots-tag|^link"

To polecenie pokazuje kod odpowiedzi oraz nagłówki z regułami robots i canonical, których nie widać w kodzie HTML.

Kiedy poprosić o pomoc

Pojedynczą sprzeczność naprawisz sam. Gdy kilka wtyczek, platforma sklepu i serwer ustawiają tagi niezależnie od siebie, a Search Console pokazuje inne adresy kanoniczne niż te, które wskazałeś, warto sprawdzić wszystkie sygnały naraz w ramach audytu technicznego SEO.