Wybór zależy od celu URL. robots.txt ogranicza pobieranie strony przez robota, noindex wyklucza pobraną stronę z wyników, a rel="canonical" wskazuje preferowany adres wśród bardzo podobnych treści. Gdy strona zmieniła miejsce, użyj przekierowania; gdy nie istnieje odpowiednik, właściwy może być 404 lub 410. Najpierw ustal rolę adresu, potem ustaw jeden spójny mechanizm.
Te trzy narzędzia często występują obok siebie w panelu CMS, co sprzyja przypadkowym kombinacjom. Właściciel sklepu zaznacza „blokuj w robots” oraz „noindex”, oczekując podwójnej pewności. Robot nie może jednak odczytać dyrektywy na stronie, której nie pobrał. Inny właściciel ustawia canonical do strony głównej na każdej kategorii, choć kategorie mają własne produkty i zapytania. Efektem nie jest automatyczny porządek w indeksie, tylko sprzeczny plan dla wielu adresów.
Poniżej zaczynamy od zamiaru: czy chcesz ograniczyć skanowanie, wyłączyć wynik, połączyć duplikaty, przenieść stronę czy chronić dostęp. Google rozróżnia skanowanie od indeksowania. Właśnie ten podział pomaga dobrać mechanizm. Jeśli diagnozujesz już istniejący problem, audyt SEO technicznego powinien objąć także status HTTP, linki i canonical wybrany przez Google.
Jaki cel ma konkretny adres?
Zapisz URL i odpowiedz na cztery pytania. Czy użytkownik ma otwierać tę stronę? Czy robot musi ją pobierać, aby zobaczyć treść lub linki? Czy chcesz, aby pojawiła się jako osobny wynik? Czy ma odpowiednik o prawie tej samej głównej treści? Bez tych odpowiedzi nazwy ustawień niewiele znaczą. Strona logowania, filtr ceny, parametr UTM i stary adres przeniesionej usługi wymagają innych decyzji.
Jeśli strona ma być ważnym wynikiem, powinna być dostępna dla robota, bez noindex, z właściwym canonicalem i sensowną treścią. Nie trzeba dodawać znacznika „index” dla każdej strony: brak blokady nie oznacza jednak gwarancji indeksacji. Google może nie dodać strony do indeksu z innych przyczyn. Sprawdź jej rolę w mapie witryny i linkach wewnętrznych.
Jeśli strona jest użyteczna dla odwiedzającego, ale nie ma miejsca w wyszukiwarce, noindex może odpowiadać celowi. Przykładem bywa strona podziękowania po formularzu lub niektóre listy wyników wewnętrznego wyszukiwania. Jeśli wiele URL pokazuje tę samą treść, lecz część wariantów musi pozostać otwieralna, częściej rozważ canonical do strony reprezentatywnej. Google zaleca canonical zamiast noindex do wyboru wersji kanonicznej w obrębie tej samej witryny.
Co dokładnie robi robots.txt?
Plik robots.txt zawiera reguły dostępu dla robotów. Disallow może ograniczyć pobieranie klasy adresów, np. ogromnej liczby kombinacji filtrów. To może zmniejszyć niepotrzebne żądania do serwera. Nie jest to jednak pewny sposób wyłączenia adresu z wyników. Google może znać URL z linków i pokazać go bez treści, mimo że nie mógł pobrać strony. Jeżeli zależy Ci na usunięciu już widocznego wyniku, sama blokada skanowania jest niewłaściwym narzędziem.
Reguła w robots działa na wzorzec, dlatego wymaga próbek pozytywnych i negatywnych. Sprawdź, czy zamierzony filtr rzeczywiście jest zablokowany, a ważna kategoria i jej paginacja nadal dostępne. Jeden zbyt szeroki wzorzec może przeciąć drogę do produktów. Nie kopiuj przykładowego Disallow z poradnika bez sprawdzenia prawdziwych parametrów sklepu. Zwróć też uwagę na zasoby CSS i JavaScript, jeśli są potrzebne Google do wyrenderowania strony.
robots.txt nie chroni tajnych treści. Każdy może go odczytać, a adres może być dostępny w zwykłej przeglądarce. Dla panelu klienta, stagingu z niepublicznymi danymi albo pliku poufnego użyj uwierzytelnienia lub realnej kontroli dostępu. Regułę dla robota można stosować pomocniczo, lecz nie powinna zastępować hasła. To decyzja o prywatności, nie tylko o SEO.
Kiedy użyć noindex?
noindex mówi Google, by nie umieszczał strony w wynikach. Może znajdować się w meta robots HTML albo w nagłówku HTTP X-Robots-Tag, co ma znaczenie dla plików innych niż HTML. Warunek jest prosty: robot musi uzyskać dostęp do odpowiedzi, aby odczytać dyrektywę. Jeśli ten sam URL jest zablokowany w robots.txt, Google nie zobaczy noindex przy pobraniu strony. Nie ustawiaj obu mechanizmów jednocześnie, gdy celem jest usunięcie strony z indeksu.
Przy już zaindeksowanym URL najpierw pozwól Google go pobrać z noindex, a następnie monitoruj zmianę w Search Console. Nie obiecuj natychmiastowego zniknięcia; Google musi ponownie odwiedzić adres i przetworzyć sygnał. Późniejsza decyzja o ograniczeniu skanowania całej klasy URL jest osobnym etapem. Warto też ograniczyć generowanie zbędnych linków do tych stron, bo noindex nie zmniejsza automatycznie liczby URL, które robot odkrywa.
Nie używaj noindex jako zastępstwa dla poprawy ważnej strony. Jeśli kluczowa kategoria ma złą treść lub duplikat, wyłączenie jej z wyników usuwa potencjał tej kategorii. Zdecyduj, czy ją poprawić, połączyć z realnym odpowiednikiem, czy świadomie wycofać. W czasie migracji sprawdź, czy dyrektywa ze środowiska testowego nie trafiła do produkcyjnego szablonu. Jedna globalna opcja może wykluczyć cały dział witryny.
Kiedy canonical jest właściwy?
Znacznik rel="canonical" wyraża preferencję, który URL ma reprezentować identyczną lub bardzo podobną główną treść. Parametr kampanii, alternatywna ścieżka tego samego produktu lub sortowanie tej samej listy to typowe kandydatury do oceny. Canonical nie blokuje pobierania ani nie przenosi użytkownika. Google może wybrać inny adres, jeśli treści lub pozostałe sygnały wskazują coś innego. W osobnym poradniku wyjaśniamy dlaczego Google wybiera inny kanoniczny URL.
Cel canonical powinien być rzeczywistą, dostępną stroną reprezentatywną. Jeśli wskazuje URL zwracający 404, zablokowany przed robotem lub oznaczony noindex, sygnał jest niespójny. Jeżeli dwie strony mają różne usługi albo odrębne produkty, nie łącz ich tylko dlatego, że szablon wygląda podobnie. Ustal, czy kupujący potrzebuje obu stron jako osobnych odpowiedzi. Jeśli tak, każda powinna mieć własną treść i spójne sygnały.
Gdy stary adres został trwale przeniesiony, przekierowanie trwałe zwykle lepiej opisuje stan niż pozostawienie dwóch kopii z canonicalem. Gdy strona została usunięta bez odpowiednika, zwróć poprawny 404 lub 410. Nie kieruj wszystkich nieistniejących produktów do strony głównej tylko po to, by zniknęły błędy w raporcie. Mechanizm ma odzwierciedlać rzeczywistą relację stron.
Tabela celów, metod i częstych pomyłek
Poniższa tabela jest demonstracyjnym modelem decyzji. Adresy z example.com służą tylko do rozpoznania klas URL. Przed wdrożeniem sprawdź konfigurację własnego serwisu i stan już indeksowanych adresów.
| Cel | Przykładowy URL | Metoda do oceny | Oczekiwane zachowanie | Błąd do uniknięcia |
|---|---|---|---|---|
| Ograniczyć masowe skanowanie filtrów | /sklep/?kolor=x&rozmiar=y | Wzorzec robots lub zmiana generowania URL | Robot nie pobiera zbędnych kombinacji | Blokada ważnej podkategorii |
| Wykluczyć publiczną stronę z wyników | /dziekujemy/ | noindex przy dostępnym URL | Google odczytuje dyrektywę | Jednoczesny Disallow |
| Wybrać reprezentanta duplikatu | /usluga/?utm_source=x | Canonical do czystego URL | Obie strony działają; preferowany jeden wynik | Canonical do innej treści |
| Przenieść stronę na nowy adres | /stara-usluga/ | Stałe przekierowanie | Użytkownik i robot trafiają na odpowiednik | Przekierowanie na stronę główną |
| Usunąć stronę bez odpowiednika | /nieaktualny-produkt/ | 404 albo 410 | Serwer mówi, że treść nie istnieje | Fałszywe 200 |
| Chronić prywatny staging | /wersja-testowa/ | Hasło lub kontrola dostępu | Osoba bez uprawnień nie czyta treści | Traktowanie robots jako hasła |
Ta tabela nie mówi, że każdy filtr ma zostać zablokowany. Niektóre kombinacje odpowiadają na realne zapytania i powinny mieć własną, stabilną stronę. Decyzja dotyczy intencji oraz oferty, nie samego znaku zapytania w URL. Podobnie strona „dziękujemy” może mieć techniczne powody do innej konfiguracji; przykład pokazuje tylko różnicę funkcji mechanizmów.
Jak wykryć sprzeczne sygnały po wdrożeniu?
Wybierz próbki wszystkich klas adresów. Dla każdej zapisz HTTP, dostęp według robots.txt, meta robots lub nagłówek, canonical, cel przekierowania i obecność w sitemapie. Otwórz ją też w Search Console, aby porównać deklarację serwisu z tym, co Google widział podczas ostatniego pobrania. Test na żywo może pokazywać nowszy stan niż dane indeksowe; zapisz daty obu pomiarów.
Typowy konflikt to noindex za Disallow. Inny: canonical wskazuje stronę, którą sam serwer przekierowuje dalej. Jeszcze inny: mapa witryny zawiera URL z noindex, mimo że właściciel chce pokazywać jego wersję kanoniczną. Napraw jedną klasę w szablonie i ponownie testuj wszystkie jej warianty. Nie ograniczaj się do pojedynczego URL, bo reguły w CMS i serwerze często działają masowo.
Po poprawce monitoruj właściwy skutek. Dla robots jest nim ograniczenie niepotrzebnych pobrań; dla noindex zniknięcie docelowego URL z wyników po przetworzeniu; dla canonical wybór właściwej reprezentacji; dla redirectu poprawna droga użytkownika. Sama mniejsza liczba „błędów” w Search Console nie jest celem. Jeśli ważna strona pozostaje niewidoczna, przejdź do listy kontroli SEO technicznego i sprawdź także jej treść oraz linki.
Co sprawdzić dalej?
Temat łączy się z kolejnymi decyzjami w serwisie. Zobacz także core web vitals jak sprawdzić, javascript seo renderowanie oraz mapa witryny xml.
