Canonical, sitemap i robots.txt: konfiguracja bez konfliktów

Ostatnio puściłem crawl cometweb.io i znalazłem błąd w tym poradniku. Na 44 linki wewnętrzne z 30 stron do 37 adresów z parametrami 40 prowadziło celowo do /contact?topic=…. Pozostałe 4 miały parametr śledzenia ?source_page=, a dwa stały właśnie tutaj.

Każdy z tych adresów miał canonical do czystej wersji, więc Google dostawał poprawny sygnał, a crawler i tak chodził po zbędnych wariantach. Canonical sprzątał tylko skutek, a przyczyna siedziała w moich linkach.

Dlatego o każdym URL-u najpierw decyduję, czy ma być osobnym wynikiem, kopią innej strony, przekierowaniem czy stroną poza wyszukiwarką.

Canonical, sitemap, robots.txt i noindex: co robi każdy sygnał

Canonical to deklaracja preferowanej wersji treści, sitemapa pomaga odkrywać adresy, a robots.txt reguluje ich pobieranie. Publiczną stronę z wyników wyłącza z kolei między innymi noindex.

Według przewodnika Google o wskazywaniu adresu kanonicznego przekierowania i rel="canonical" to silne sygnały, a obecność w sitemapie to sygnał słaby. Głosowania „dwa przeciw jednemu” Google nie publikuje, a omówienie kanonikalizacji dodaje, że przy wyborze reprezentanta duplikatów liczy się też treść i inne informacje.

Canonical: kiedy połączyć podobne adresy

Canonical łączy adresy z tą samą albo bardzo podobną treścią i zostawia każdy dostępny. Gdy ?utm_source=newsletter zostawia treść strony https://example.com/pl/plecaki/model-a bez zmian, oba adresy mogą wskazywać ten sam canonical w <head>:

<link rel="canonical"
      href="https://example.com/pl/plecaki/model-a">

Canonical ma prowadzić do reprezentatywnej treści, nie do strony, którą chcesz promować. Produkt i szeroka kategoria mówią o plecakach, a są dwiema różnymi stronami. RFC 6596 dopuszcza też, żeby cel canonical leżał w innej domenie.

Self-canonical i jeden cel bez łańcuchów

Self-canonical to canonical, który na preferowanej stronie wskazuje ją samą, i Google go zaleca. Strona bez deklaracji też może trafić do indeksu, ale wtedy Google sam wybiera wersję kanoniczną, a ja wolę mu to powiedzieć.

W swojej konfiguracji podaj pełny URL i jeden cel, bez łańcucha A → B → C, pętli A → B → A i celu z błędem. Gdy CMS i wtyczka SEO wstawiają różne cele w nagłówku HTTP i w HTML, trudno ustalić, który był zamierzony. Canonical strony i odpowiedź jego celu sprawdzisz w narzędziu do sprawdzania canonical.

Canonical czy przekierowanie 301

Trwałe przekierowanie stosuj, gdy stary adres ma przestać działać jako osobna strona. Canonical zostaw dla wariantów, które mają pozostać dostępne, np. parametrów obsługujących interfejs.

Według dokumentacji Google o przekierowaniach HTTP 301 i 308 przenoszą ruch pod nowy adres, a canonical tylko wskazuje preferowaną wersję.

Canonical dla PDF-a i aplikacji JavaScript

Dokument bez HTML, np. kopia raportu z preferowaną wersją pod innym adresem, dostaje canonical w nagłówku odpowiedzi.

Link: <https://example.com/pl/raport>; rel="canonical"

PDF leżący obok artykułu konsolidujesz z nim tylko wtedy, gdy zawiera tę samą treść. 5 W aplikacji JavaScript porównaj początkowy HTML z końcowym DOM, a najlepiej podaj canonical już w odpowiedzi serwera i zostaw go już bez zmian.

Uwaga: początkowego noindex nie usuwaj dopiero JavaScriptem, bo według podstaw JavaScript SEO od Google Google po odczytaniu tej reguły może pominąć renderowanie.

Sitemap XML: lista adresów, które chcesz zgłosić

Sitemapa XML według przewodnika Google o mapach witryn najbardziej przydaje się w dużych serwisach i przy słabo podlinkowanych ważnych stronach. Uzupełnia linkowanie wewnętrzne, a mała, dobrze połączona witryna bywa poprawnie odkrywana bez niej.

W bieżącej mapie preferowanych stron ja bym wpisywał tylko końcowe, kanoniczne adresy do indeksowania, każdy dostępny, bez noindex i bez dalszego przekierowania. Wyjątkiem jest celowa lista migracyjna, a jeden nieaktualny wpis zostawia resztę pliku ważną.

U siebie zrobiłem to ostatnio z 8 wpisami, do których nie prowadził żaden link. Dostały noindex, follow (poza wynikami, ale robot dalej chodzi po ich linkach) i wypadły z sitemapy (281 → 273), a ich adresy dalej zwracają 200. Całą historię opisuję w artykule o audycie linkowania wewnętrznego.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://example.com/pl/plecaki/model-a</loc>
    <lastmod>2026-09-10</lastmod>
  </url>
  <url>
    <loc>https://example.com/pl/poradnik-doboru-plecaka</loc>
    <lastmod>2026-09-08</lastmod>
  </url>
</urlset>

Limity sitemapy: 50 000 URL-i i 50 MB

Sitemapa mieści do 50 000 URL-i i do 50 MB po rozpakowaniu, czyli według protokołu Sitemaps.org 52 428 800 bajtów. Gzip limitu nie podnosi, więc dłuższą listę dzielisz na pliki połączone indeksem sitemap.

W <loc> wpisuj pełne adresy z protokołem i zachowaj UTF-8 oraz przestrzeń nazw z przykładu. Ampersand zapisuj jako &, więc ?color=black&size=20 zmienia się w ?color=black&size=20.

Na marginesie. Mapa dla kilku witryn wymaga osobnej konfiguracji cross-site submission z dokumentacji Google o indeksie sitemap, a bez niej każda domena ma własne mapy.

lastmod w sitemapie opisuje prawdziwą zmianę

Według instrukcji Google o budowie sitemapy Google korzysta z wiarygodnych dat istotnych aktualizacji. lastmod zmieniaj więc przy zmianie głównej treści, danych strukturalnych albo ważnych linków. Nowy rok przy copyright się nie liczy, a <priority> i <changefreq> Google ignoruje.

Gdy system nie zna daty zmiany, pomiń opcjonalny lastmod i nie wpisuj dzisiejszej daty do całej mapy. W indeksie sitemap ten element opisuje zmianę pliku mapy, a daty stron stoją w samym pliku. 6

Mapę zgłoś w Search Console albo linią Sitemap: w robots.txt, bo „pingowanie” sitemap Google wycofał.

Robots.txt: reguły pobierania dla jednego hosta

Robots.txt leży pod /robots.txt i obowiązuje roboty, które respektują protokół, jak opisuje wprowadzenie Google do robots.txt. Działa dla jednego hosta, protokołu i portu. Według specyfikacji robots.txt w dokumentacji Google plik https://example.com/robots.txt nie ustawia reguł dla https://app.example.com, a katalog /pl/ też nie ma własnego pliku.

Przykład ogranicza pobieranie technicznej przestrzeni URL-i, która nie zawiera poufnych informacji i nie wymaga egzekwowania noindex, ale ścieżki musisz dopasować do swojego serwisu.

User-agent: *
Disallow: /pl/podglady-techniczne/
Allow: /pl/podglady-techniczne/instrukcja$

Sitemap: https://example.com/sitemap.xml

Blokada katalogu to prośba, a hasło to zamek. Człowiek albo bot, który ignoruje protokół, i tak pobierze zasób, więc tajnych adresów nie chroń robots.txt. RFC 9309 wprost oddziela reguły crawlowania od autoryzacji dostępu. Czy konkretny adres jest zablokowany, sprawdzisz w testerze robots.txt.

Reguły robots.txt: wygrywa najbardziej szczegółowa ścieżka

Pierwszeństwo ma najbardziej szczegółowe dopasowanie ścieżki, niezależnie od kolejności wpisów. Przy równoważnych Allow i Disallow wygrywa Allow, a wielkość liter w ścieżkach ma znaczenie.

* oznacza dowolny ciąg znaków, a $ koniec dopasowania, więc instrukcja$ nie obejmie instrukcja?tryb=druk. 8 Dla Google grupa User-agent napisana dla Googlebota nie dziedziczy blokad z grupy *, więc po dodaniu nowej grupy przejrzyj wszystkie reguły tego robota. crawl-delay Google nie obsługuje.

Pusty plik ze statusem 200 oznacza brak ograniczeń, bo RFC 9309 dopuszcza plik bez grup, a Disallow: / blokuje cały host.

Awaria robots.txt: 404, błąd serwera i 30 dni starej kopii

Robots.txt ze statusem 404 oznacza dla Google brak ograniczeń z tego pliku. Odpowiedzi 401 i 403 dla robots.txt nie są metodą ograniczania crawlu, a 429 jest wyjątkiem od zwykłego traktowania 4xx.

Przy awarii zapisz więc jej czas trwania i to, czy Google miał wcześniejszą kopię.

Noindex działa tylko wtedy, gdy robot może go odczytać

noindex wyłącza stronę z wyników, pod warunkiem że robot pobierze zasób i przeczyta regułę. Na stronie HTML wstawiasz go w <head> jako meta tag:

<meta name="robots" content="noindex">

Plik PDF i inne zasoby bez HTML dostają nagłówek odpowiedzi:

X-Robots-Tag: noindex

Jeśli ten sam adres zablokujesz w robots.txt, Google nie odczyta nowej odpowiedzi, a URL może zostać w wynikach. Wpis Noindex: w samym robots.txt jest nieobsługiwany, jak podaje dokumentacja Google o blokowaniu indeksowania.

Sprawdzaj HTML i nagłówki HTTP, bo usunięcie meta tagu w CMS zostawia X-Robots-Tag dodany przez serwer albo CDN. Według specyfikacji meta robots i X-Robots-Tag pozostały noindex wygrywa z index ustawionym w drugim miejscu.

Zaindeksowaną, niepoufną stronę usuwasz, pozwalając robotowi odczytać noindex, i potwierdzasz efekt w Search Console. Blokada crawlu dodana później nie gwarantuje już trwałego wykluczenia.

Usunięta strona bez odpowiednika zwraca 404 albo 410, a stronę z danymi prywatnymi zamykasz kontrolą dostępu. Ukrycie wyniku w Search Console działa doraźnie, a problem zamykasz na serwerze, jak opisują przewodniki Google o kodach statusu HTTP i usuwaniu informacji z Google.

Parametry, paginacja i tłumaczenia: które warianty URL-a konsolidować

Zacznij od tego, co wariant zmienia dla użytkownika, a pytania do każdego typu zebrałem w tabeli.

Przy filtrach, które generują ogromną liczbę zbędnych kombinacji, Google dopuszcza ograniczenie crawlu, a canonical jest tu mniej bezpośrednim narzędziem. Zanim skopiujesz globalną blokadę adresów ze znakiem ?, sprawdź, czy nie odcina wartościowych stron.

Najwięcej takich kombinacji generują sklepy, gdzie filtry i warianty nakładają się na paginację. Audyt SEO sklepu internetowego pokazuje, w jakiej kolejności je rozplątywać.

Dla paginacji Google zaleca osobny canonical każdej strony i dostępne linki dalej, bo przekierowanie całej paginacji na pierwszą stronę odbiera użytkownikowi dalsze wyniki. Tłumaczenia też mają własne canonicale, a hreflang według dokumentacji Google o wersjach zlokalizowanych jest wzajemny, obejmuje też daną wersję i treści nie kanonikalizuje.

Konflikty sygnałów: diagnozuj według celu URL-a

Konflikt sygnałów oceniasz względem celu URL-a, bo ta sama konfiguracja bywa błędem na landing page'u i poprawnym ustawieniem na stronie technicznej. Wiersze tabeli poniżej to scenariusze diagnostyczne, bez pomiaru u klienta.

Według pomocy Search Console o raporcie indeksowania stron „Alternatywna strona zawierająca prawidłowy tag strony kanonicznej” i „Strona z przekierowaniem” mogą być pożądanymi wynikami, bo celem jest indeksacja ważnych stron kanonicznych.

Poza konfliktem tagów inny canonical Google może wynikać z podobieństwa treści, błędów CMS, konfiguracji serwera albo kopii w innych domenach. Google radzi najpierw ocenić, czy ten wybór ma sens dla użytkownika, i ja zrobiłbym to, zanim ruszę jakąkolwiek deklarację.

Migracja adresu: stary URL → nowy URL

Przy migracji stary URL przekierowuje trwale na nowy, a pozostałe sygnały wskazują już nowy adres. W fikcyjnym przykładzie treść przechodzi z /pl/stary-poradnik na /pl/poradnik-doboru-plecaka.

HTTP/1.1 301 Moved Permanently
Location: https://example.com/pl/poradnik-doboru-plecaka

Wielu niepowiązanych, usuniętych stron nie kieruj na stronę główną, bo takie przekierowania mogą być traktowane jako soft 404. Dopasuj cele albo zostaw właściwy status usunięcia.

Przewodnik Google o przenosinach witryny zaleca utrzymywać przekierowania możliwie długo, zasadniczo co najmniej rok, a dla użytkowników przydaje się dłużej. Dopuszcza też osobną starą sitemapę do obserwowania starej grupy adresów. Ostrzeżenia o przekierowaniach są w niej oczekiwane, dopóki trzymasz ją osobno od bieżącej mapy.

Jak sprawdzić canonical, sitemap i robots.txt w 6 krokach

Ja bym szedł w tej kolejności, bo każdy krok zawęża listę przyczyn.

Krok 1: Zapisz oczekiwany stan URL-a

Zanim ruszysz konfigurację, zapisz, do czego służy adres: indeksowanie, konsolidacja, przekierowanie, wykluczenie albo usunięcie. Bez tego łatwo „naprawić” poprawne przekierowanie, przywracając staremu adresowi status 200.

Zanotuj też preferowany URL, a przy nim datę i wersję wdrożenia.

Krok 2: Odczytaj odpowiedź HTTP i HTML

Polecenie zapisuje nagłówki i treść pierwszej odpowiedzi, celowo bez podążania za przekierowaniem, a fikcyjny URL podmień na swój:

curl --max-time 20 --silent --show-error \
  --dump-header headers.txt \
  --output page.html \
  'https://example.com/pl/poradnik-doboru-plecaka'

Sprawdź status, Location, Link i X-Robots-Tag, potem meta robots i canonical w HTML, a w aplikacji JavaScript także w wyrenderowanym DOM. Powtórz to dla celu przekierowania, bo sam końcowy 200 ukrywa problemy wcześniejszych odpowiedzi.

Krok 3: Porównaj dane indeksu z testem aktywnego URL-a

W Inspekcji adresu URL sprawdź ostatnie pobranie, możliwość indeksowania i oba canonicale: zadeklarowany oraz wybrany przez Google. Według pomocy Search Console o Inspekcji adresu URL canonical wybrany przez Google pochodzi z danych indeksu, a test aktywnego URL-a tego wyboru nie przewiduje. Po poprawce test bywa więc dobry, choć indeks opisuje starszy stan.

Komunikat „URL jest dostępny dla Google” mówi tylko o dostępności. Zapisz daty obu odczytów, a brak danych oznacz jako niewiadomą.

Krok 4: Przeczytaj raporty sitemap i robots.txt

Raport Sitemaps pokazuje historię zgłoszeń i problemy z pobraniem oraz przetworzeniem map, a indeksację stron z listy sprawdzasz osobno.

Raport robots.txt w ustawieniach Search Console pokazuje znalezione pliki z datami pobrania i błędami, a w awarii pozwala zgłosić ponowne pobranie. Dawny edytor reguł z niego zniknął, więc regułę dla konkretnego URL-a zestaw z Inspekcją adresu URL.

Krok 5: Odróżnij błąd techniczny od decyzji o indeksacji

Status „Strona zeskanowana, ale jeszcze niezindeksowana” oznacza, że Google stronę pobrał, czyli robots.txt jej nie zablokował. 9 Zanim przestawisz canonical, sprawdź treść strony, jej rolę i podobne adresy.

Przy dużej witrynie dołóż jeszcze logi serwera i raporty crawlu. Według Google budżet crawlowania dotyczy głównie ogromnych albo szybko zmieniających się zbiorów URL-i, więc przy małej stronie nie szukałbym w nim przyczyny.

Krok 6: Zapisz poprawkę i monitoruj tę samą grupę adresów

Dla ważnych URL-i możesz poprosić o ponowne indeksowanie, a dla większego zbioru zadbaj o mapę. Według instrukcji Google o ponownym crawlowaniu zgłoszenia mają limity i nie zapewniają przyjęcia do indeksu, a ponowne wysyłanie tego samego adresu nic nie przyspiesza.

Brak zmiany po umownych czterech czy sześciu tygodniach uzasadnia ponowną diagnozę z konfliktem sygnałów jako jedną z kilku hipotez. Porównuj te same URL-e z tymi samymi oczekiwanymi stanami. Przy migracji stare adresy trzymaj osobno od nowych, bo inaczej poprawny wzrost liczby przekierowań wygląda jak pogorszenie.

Sprawdź zestaw sygnałów indeksacji przed przekazaniem poprawki

Pomocnik sprawdza spójność deklaracji na danych wpisanych ręcznie, bez pobierania strony. W polu adresu podaj docelowy URL, który ma być indeksowany, czyli nowy adres po przekierowaniu.

Większy zbiór adresów lepiej przejść crawlem, a Moduł SEO w CometWeb Insight sprawdza canonical i status HTTP, a do tego dostęp dla robota i dyrektywy indeksowania. Moduł Crawl znajduje publiczne adresy przez linki i sitemapę albo z twojej listy i sprawdza ich kody HTTP oraz łańcuchy przekierowań.

Szczegóły opisuje metodologia, a sam raport czytaj obok danych Search Console. Jeśli chcesz przejść tę listę na całym serwisie, załóż konto w Insight i uruchom pierwszy audyt.

Trzy wnioski o sygnałach indeksacji

1. Najpierw cel URL-a, potem składnia. Składnia to łatwa część, a trudna to decyzja, czym adres ma być, zanim cokolwiek zmienisz.
2. Czyste raporty usuwają konkretne przeszkody. Potem Google osobno przetwarza treść i sam wybiera strony do indeksu.
3. Jutro rano sprawdź jeden ważny adres. Zapisz jego cel i przejdź sześć kroków, a po kilku tygodniach wróć z nim do Search Console.

Wszystkie cztery sygnały mają mówić o nim to samo.

Najczęstsze pytania

Źródła odpowiedzi: adres kanoniczny, robots.txt, blokowanie indeksacji, RFC 6596, naprawa kanonikalizacji, sitemapy i raport Sitemaps.

Źródła

Tekst dotyczy przede wszystkim Google Search. RFC i protokół sitemap opisują szersze reguły, a szczegóły implementacji mogą się różnić między robotami. Przykłady z example.com są fikcyjne.

1. Google Search Central: How to specify a canonical URL.
2. Google Search Central: Introduction to robots.txt.
3. Google Search Central: Block Search indexing with noindex.
4. Google Search Central: Learn about sitemaps.
5. RFC Editor / IETF: RFC 6596: The Canonical Link Relation.
6. Sitemaps.org: Sitemaps XML format.
7. Google Crawling Infrastructure: How Google interprets the robots.txt specification.
8. RFC Editor / IETF: RFC 9309: Robots Exclusion Protocol.
9. Google Search Console Help: Page indexing report.
10. Google Search Central: Fix canonicalization issues.
11. Google Search Console Help: Sitemaps report.
12. HTTP Archive: Web Almanac 2025: SEO.