Robots.txt - jak nie zablokować sobie strony w Google?

Robots.txt to prosty plik tekstowy, który mówi robotom wyszukiwarek, do których części strony mogą zaglądać, a których nie powinny crawlować. Problem w tym, że jeden zły zapis w robots.txt może sprawić, że Google przestanie widzieć najważniejsze podstrony Twojej witryny.

To jeden z tych plików, które wyglądają niewinnie.

Kilka linijek tekstu.

Żadnego skomplikowanego kodu.

A mimo to robots.txt potrafi zablokować całą stronę przed Googlebotem.

I to często przypadkiem.

Wystarczy jeden zapis:

User-agent: *
Disallow: /

Taki plik mówi wszystkim robotom:

Nie wchodźcie nigdzie na tej stronie.

Jeśli taki zapis zostanie przypadkowo na produkcyjnej stronie po wdrożeniu, migracji albo pracy na wersji testowej, problem może być poważny.

Google może przestać crawlować ważne adresy, nie zobaczy zmian na stronie, nie odczyta meta tagów, nie przejdzie przez linkowanie wewnętrzne i nie będzie mieć pełnego obrazu witryny.

Robots.txt nie jest plikiem do "ukrywania strony przed Google". To plik do zarządzania dostępem robotów do crawlowania. Jeśli pomylisz crawling z indeksacją, możesz zablokować coś, czego wcale nie chciałeś blokować.

Ten poradnik pokazuje, czym jest robots.txt, jak działa, czego nie robi, jakich błędów unikać i jak sprawdzić, czy Twoja strona przypadkiem sama nie podcina sobie widoczności w Google.

Robots.txt - co to jest?

Robots.txt to plik tekstowy umieszczany w katalogu głównym strony internetowej.

Najczęściej znajduje się pod adresem:

https://example.pl/robots.txt

Jego zadaniem jest przekazanie robotom internetowym informacji, które adresy URL mogą crawlować, a których nie powinny odwiedzać.

Crawlować, czyli pobierać i analizować.

To ważne rozróżnienie.

Robots.txt nie mówi:

Nie indeksuj tej strony.

Robots.txt mówi raczej:

Nie wchodź pod ten adres.

To różnica, która ma ogromne znaczenie w SEO.

Jeżeli zablokujesz stronę w robots.txt, Google może nie mieć dostępu do jej treści, meta tagów, canonicala i linków.

Ale jeśli zna adres z innych źródeł, na przykład z linków zewnętrznych, nadal może pokazać go w wynikach jako adres z ograniczonym opisem.

Dlatego robots.txt nie jest najlepszym narzędziem do usuwania stron z Google.

Do tego używa się najczęściej:

• meta robots noindex,
• nagłówka HTTP X-Robots-Tag,
• zabezpieczenia hasłem,
• usunięcia strony i odpowiedniego statusu HTTP,
• przekierowania 301, jeśli treść została przeniesiona.

Robots.txt jest potrzebny, ale trzeba wiedzieć, do czego służy.

Najwięcej problemów bierze się właśnie z mylenia crawlowania z indeksacją.

Po co stronie internetowej plik robots.txt?

Robots.txt pomaga zarządzać tym, co roboty mogą odwiedzać na stronie.

W małej stronie firmowej często nie trzeba robić w nim nic skomplikowanego.

Ale w większych serwisach, sklepach, portalach i katalogach robots.txt może być ważnym elementem technicznego SEO.

Dobry robots.txt pomaga:

• ograniczyć crawlowanie niepotrzebnych sekcji,
• chronić crawl budget w dużych serwisach,
• nie wpuszczać robotów do wybranych parametrów i zasobów technicznych,
• wskazać lokalizację mapy strony XML,
• uporządkować dostęp do wyników wyszukiwania wewnętrznego,
• ograniczyć crawlowanie koszyka, konta klienta i paneli użytkownika,
• zmniejszyć obciążenie serwera przez boty,
• oddzielić ważne adresy SEO od technicznego szumu.

Ale dobry robots.txt nie powinien blokować:

• strony głównej,
• ważnych stron usługowych,
• artykułów blogowych,
• kategorii, które mają rankować,
• kart produktów, które mają być widoczne w Google,
• plików CSS i JavaScript potrzebnych do renderowania strony,
• obrazów, jeśli zależy Ci na widoczności w grafice Google,
• mapy strony XML.

Robots.txt ma pomagać robotom, a nie odcinać im dostęp do tego, co najważniejsze.

Najprostsza zasada:

Blokuj tylko to, co rozumiesz i czego naprawdę nie chcesz crawlować. Nie blokuj na zapas.

Jak działa robots.txt w praktyce?

Kiedy robot wyszukiwarki odwiedza stronę, najpierw może sprawdzić plik robots.txt.

Dla domeny:

https://example.pl/

robot szuka pliku:

https://example.pl/robots.txt

Potem odczytuje reguły przypisane do swojego user-agenta.

User-agent to nazwa robota.

Przykład:

• Googlebot - robot Google dla wyników wyszukiwania,
• Googlebot-Image - robot Google dla obrazów,
• Bingbot - robot Bing,
• * - zapis ogólny dla wszystkich robotów.

Przykładowy plik:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.pl/sitemap_index.xml

Ten zapis mówi:

• reguły dotyczą wszystkich robotów,
• roboty nie powinny wchodzić do /wp-admin/,
• wyjątkiem jest plik admin-ajax.php,
• mapa strony znajduje się pod wskazanym adresem.

Robots.txt działa na podstawie ścieżek URL.

Nie działa na podstawie intencji.

Jeśli zapiszesz:

Disallow: /blog/

blokujesz robotom dostęp do wszystkiego, co znajduje się pod /blog/.

Czyli również do artykułów, które mogą być dla Ciebie bardzo ważne SEO.

Jeśli zapiszesz:

Disallow: /

blokujesz całą stronę.

Dlatego każda reguła w robots.txt powinna być świadoma.

Gdzie powinien znajdować się plik robots.txt?

Plik robots.txt musi znajdować się w katalogu głównym hosta.

Poprawny adres:

https://example.pl/robots.txt

Niepoprawny adres:

https://example.pl/blog/robots.txt

Niepoprawny adres:

https://example.pl/wp-content/robots.txt

Robots.txt działa dla konkretnego hosta, protokołu i subdomeny.

To oznacza, że:

• https://example.pl/robots.txt dotyczy https://example.pl/,
• https://www.example.pl/robots.txt dotyczy https://www.example.pl/,
• https://sklep.example.pl/robots.txt dotyczy https://sklep.example.pl/,
• http://example.pl/robots.txt dotyczy wersji HTTP.

Jeśli masz kilka subdomen, każda może mieć własny plik robots.txt.

Przykład:

• https://example.pl/robots.txt
• https://blog.example.pl/robots.txt
• https://app.example.pl/robots.txt
• https://panel.example.pl/robots.txt

To ważne przy wersjach testowych, panelach, aplikacjach i sklepach na subdomenach.

Nie zakładaj, że jeden robots.txt zabezpiecza wszystko.

Sprawdź każdy host osobno.

Jak wygląda poprawny plik robots.txt?

Prosty, bezpieczny plik robots.txt dla wielu stron firmowych może wyglądać tak:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.pl/sitemap_index.xml

To podstawowy wariant dla WordPressa.

Nie blokuje strony głównej.

Nie blokuje usług.

Nie blokuje bloga.

Nie blokuje CSS i JavaScript.

Wskazuje mapę strony.

Dla bardzo prostej strony można mieć nawet taki plik:

User-agent: *
Disallow:

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

Taki zapis oznacza, że nic nie jest zablokowane dla robotów.

Można też spotkać taki wariant:

User-agent: *
Allow: /

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

To również jasny sygnał, że roboty mogą crawlować stronę.

Ale trzeba uważać na błędne wersje.

Źle:

User-agent: *
Disallow: /

Źle, jeśli strona ma być widoczna w Google:

User-agent: Googlebot
Disallow: /

Źle, jeśli blog ma rankować:

User-agent: *
Disallow: /blog/

Źle, jeśli produkty mają być w Google:

User-agent: *
Disallow: /produkt/

Robots.txt nie powinien być kopiowany z internetu bez zrozumienia.

To, co jest dobre dla jednej strony, może być katastrofą dla drugiej.

Najgroźniejszy błąd: Disallow: /

Najbardziej niebezpieczny zapis w robots.txt to:

User-agent: *
Disallow: /

Ten zapis blokuje dostęp wszystkim robotom do całej strony.

Czasem jest stosowany celowo na wersjach testowych.

Problem zaczyna się wtedy, gdy po wdrożeniu nowej strony na produkcję ktoś zapomina go usunąć.

Typowy scenariusz:

1. Agencja albo developer tworzy nową stronę na wersji testowej.
2. Wersja testowa ma robots.txt z Disallow: /.
3. Strona zostaje przeniesiona na właściwą domenę.
4. Plik robots.txt zostaje skopiowany razem z całą stroną.
5. Googlebot dostaje informację, że nie powinien crawlować witryny.
6. Właściciel strony po kilku tygodniach pyta, dlaczego nie ma widoczności.

To nie jest rzadki przypadek.

Szczególnie przy migracjach stron, zmianach CMS-a i pracach developerskich.

Objawy problemu:

• spadek crawlowania w Google Search Console,
• komunikaty o blokadzie przez robots.txt,
• brak indeksacji nowych podstron,
• Google nie widzi aktualnych treści,
• spadek widoczności po wdrożeniu nowej strony,
• ważne URL-e są oznaczone jako zablokowane.

Przy każdej publikacji strony powinno się sprawdzić:

https://twojadomena.pl/robots.txt

To zajmuje kilkanaście sekund.

A może uratować całą widoczność strony.

Robots.txt a indeksacja w Google

To najważniejsza część całego tematu.

Robots.txt nie jest narzędziem do blokowania indeksacji.

Robots.txt jest narzędziem do blokowania crawlowania.

Czyli mówi robotowi:

Nie pobieraj tej strony.

Ale jeśli Google zna adres z innych źródeł, może nadal pokazać go w wynikach.

Może wtedy nie mieć normalnego tytułu, opisu i treści, bo nie mógł wejść na stronę.

W Search Console można spotkać komunikaty typu:

Zindeksowano, choć zablokowano przez robots.txt.

Dla wielu osób brzmi to nielogicznie.

Ale jest logiczne, jeśli rozumiesz różnicę między crawlingiem a indeksacją.

Element	Co robi?	Czego nie robi?
Robots.txt	Ogranicza crawling	Nie gwarantuje usunięcia z indeksu
Noindex	Blokuje indeksację strony	Wymaga, żeby robot mógł odczytać stronę
Hasło	Blokuje dostęp do treści	Nie jest rozwiązaniem SEO, tylko dostępowym
404/410	Informuje, że strona nie istnieje	Nie przenosi wartości na inny URL
301	Przenosi adres na inny URL	Nie służy do ukrywania treści

Jeśli chcesz, żeby strona nie była w Google, nie blokuj jej najpierw w robots.txt.

Dlaczego?

Bo jeśli Googlebot nie może wejść na stronę, nie może też zobaczyć meta tagu noindex.

Dobra kolejność przy usuwaniu strony z indeksu:

1. Pozwól Google wejść na stronę.
2. Dodaj noindex.
3. Poczekaj, aż Google przetworzy zmianę.
4. Dopiero potem, jeśli trzeba, ogranicz crawling.

W praktyce wiele błędów bierze się z tego, że ktoś chce "ukryć" stronę i wrzuca ją do robots.txt.

To może nie dać oczekiwanego efektu.

Robots.txt a noindex - czym to się różni?

Robots.txt i noindex są często mylone.

A to dwa różne narzędzia.

Robots.txt działa przed wejściem robota na stronę.

Noindex działa po wejściu robota na stronę.

Przykład noindex w kodzie HTML:

<meta name="robots" content="noindex, follow" />

Ten zapis mówi:

Nie pokazuj tej strony w wynikach, ale możesz śledzić linki na stronie.

Ale żeby Google mógł to zobaczyć, musi mieć możliwość wejścia na stronę.

Jeśli strona jest zablokowana w robots.txt, Google może nie odczytać noindex.

Dlatego zapis:

User-agent: *
Disallow: /prywatna-strona/

nie jest tym samym co:

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

Kiedy użyć robots.txt?

• gdy chcesz ograniczyć crawlowanie technicznych sekcji,
• gdy nie chcesz, żeby roboty wchodziły w parametry,
• gdy chcesz zmniejszyć crawl śmieciowych adresów,
• gdy chcesz zabezpieczyć zasoby, które nie mają znaczenia SEO, ale nie są poufne.

Kiedy użyć noindex?

• gdy strona nie ma być widoczna w Google,
• gdy strona może być odwiedzona przez robota, ale nie powinna trafić do indeksu,
• gdy masz strony filtrów bez wartości SEO,
• gdy masz strony tagów bez sensownej treści,
• gdy masz podstrony pomocnicze, które nie powinny rankować.

Kiedy użyć hasła?

• gdy strona jest poufna,
• gdy to wersja testowa,
• gdy to panel klienta,
• gdy nie chcesz, żeby ktokolwiek spoza zespołu miał dostęp.

Robots.txt nie jest zabezpieczeniem danych.

To publiczny plik, który każdy może otworzyć.

Nie wpisuj tam ścieżek do naprawdę poufnych zasobów z założeniem, że są "ukryte".

Robots.txt a sitemap.xml

W robots.txt można wskazać lokalizację mapy strony XML.

Przykład:

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

Albo dla WordPressa z popularnymi wtyczkami SEO:

Sitemap: https://example.pl/sitemap_index.xml

To dobra praktyka.

Dzięki temu roboty mogą łatwiej znaleźć mapę strony.

Ale sitemap nie naprawia złego robots.txt.

Jeśli w mapie strony masz adres:

https://example.pl/uslugi/audyt-seo/

ale w robots.txt masz:

User-agent: *
Disallow: /uslugi/

wysyłasz sprzeczne sygnały.

Z jednej strony mówisz:

To ważny adres, dodaję go do mapy strony.

Z drugiej:

Nie wchodź do katalogu /uslugi/.

Dobra mapa strony powinna zawierać tylko adresy, które:

• mają być indeksowane,
• zwracają status 200,
• nie są zablokowane w robots.txt,
• nie mają noindex,
• są kanoniczne,
• mają wartość dla użytkownika.

Robots.txt i sitemap.xml muszą mówić jednym głosem.

Jeśli jedno zaprasza Google, a drugie zamyka drzwi, powstaje techniczny bałagan.

Robots.txt w WordPressie

WordPress często generuje wirtualny plik robots.txt, nawet jeśli fizycznie nie ma go na serwerze.

Popularne wtyczki SEO, takie jak Rank Math, Yoast SEO czy All in One SEO, pozwalają edytować robots.txt z poziomu panelu.

Dla zwykłej strony firmowej na WordPressie bezpieczny robots.txt może wyglądać tak:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.pl/sitemap_index.xml

Czego zwykle nie warto blokować na WordPressie?

• /wp-content/ jako całości,
• /wp-includes/ bez analizy,
• plików CSS,
• plików JavaScript,
• folderu z obrazami,
• całego bloga,
• całych kategorii, jeśli mają rankować.

Dawniej częściej blokowano różne zasoby techniczne.

Dzisiaj trzeba uważać, bo Google renderuje strony i potrzebuje dostępu do zasobów, które wpływają na wygląd i działanie witryny.

Jeśli zablokujesz CSS i JavaScript, Google może gorzej zrozumieć stronę.

Typowy zły zapis:

User-agent: *
Disallow: /wp-content/
Disallow: /wp-includes/

Może wyglądać sensownie, bo te katalogi są techniczne.

Ale w praktyce mogą zawierać zasoby potrzebne do poprawnego renderowania strony.

Przy WordPressie najczęściej większy problem robią:

• tagi bez treści,
• archiwa autorów,
• archiwa dat,
• wyniki wyszukiwania,
• parametry,
• duplikacja kategorii.

Ale nie zawsze rozwiązuje się to robots.txt.

Często lepszym wyborem jest noindex dla wybranych archiwów.

Robots.txt w sklepie internetowym

W sklepie internetowym robots.txt ma większe znaczenie niż na prostej stronie firmowej.

Sklep może generować tysiące adresów z filtrów, sortowań i parametrów.

Przykłady:

• /buty/?sort=price
• /buty/?color=black
• /buty/?size=42
• /buty/?filter_brand=nike
• /buty/?min_price=100&max_price=300
• /koszyk/
• /moje-konto/
• /checkout/

Nie każdy z tych adresów powinien być crawlowny.

Ale uwaga.

Nie każdy filtr jest śmieciem.

Przykład wartościowego filtra:

/buty-do-biegania-damskie/

albo:

/buty-nike-meskie/

Jeśli takie strony mają popyt w Google, unikalną treść, produkty i sensowne linkowanie, mogą być ważnymi landing page'ami SEO.

Nie blokuj ich automatycznie.

W sklepie trzeba podzielić adresy na trzy grupy:

Typ adresu	Przykład	Rekomendacja
Ważna kategoria SEO	/buty-do-biegania/	Pozostawić crawl i indeksację
Wartościowy filtr	/buty-nike-damskie/	Rozważyć indeksację jako landing SEO
Sortowanie	?sort=price	Zwykle canonical/noindex lub blokada crawlowania zależnie od strategii
Koszyk	/koszyk/	Nie powinien być w indeksie
Checkout	/checkout/	Nie powinien być crawlowny ani indeksowany
Konto klienta	/moje-konto/	Nie powinno być w Google

Przykładowy robots.txt dla sklepu trzeba dopasować do platformy.

Nie ma jednego uniwersalnego pliku dla WooCommerce, PrestaShop, Shopify, Magento czy customowego sklepu.

Wspólny cel jest jeden:

Google ma crawlować strony, które mogą zarabiać i budować widoczność. Nie powinien marnować czasu na koszyk, checkout, konto klienta i bezwartościowe kombinacje parametrów.

Robots.txt dla stron testowych i stagingowych

Strony testowe to miejsce, gdzie robots.txt bywa szczególnie zdradliwy.

Wersje stagingowe często mają zapis:

User-agent: *
Disallow: /

I na wersji testowej to może mieć sens.

Ale samo robots.txt nie jest pełnym zabezpieczeniem.

Dlaczego?

Bo plik robots.txt jest publiczny.

Każdy może wejść pod:

https://staging.example.pl/robots.txt

i zobaczyć, co blokujesz.

Jeśli wersja testowa ma być niewidoczna i niedostępna, najlepszym rozwiązaniem jest zabezpieczenie hasłem albo ograniczenie dostępu po IP.

Bezpieczne podejście do stagingu:

• hasło HTTP auth,
• blokada po IP,
• noindex jako dodatkowe zabezpieczenie, jeśli robot ma dostęp,
• osobny robots.txt z blokadą crawlowania,
• kontrola przed publikacją na produkcji.

Najważniejsza procedura przed startem strony:

1. Sprawdź robots.txt na domenie produkcyjnej.
2. Sprawdź meta robots na stronie głównej i podstronach.
3. Sprawdź, czy nie ma globalnego noindex.
4. Sprawdź sitemap.xml.
5. Sprawdź kilka URL-i w Google Search Console.

Migracja strony bez kontroli robots.txt to proszenie się o problem.

Jakie sekcje warto blokować, a jakich nie?

Nie da się stworzyć jednej listy dla każdej strony.

Ale można wskazać typowe sekcje, które często nie powinny być priorytetem dla robotów.

Sekcja	Blokować w robots.txt?	Uwagi
Strona główna	Nie	To zwykle najważniejszy adres serwisu
Strony usługowe	Nie	Powinny być dostępne dla Google
Blog	Nie	Jeśli artykuły mają budować ruch organiczny
Kategorie produktów	Nie	Jeśli mają potencjał SEO
Karty produktów	Nie	Jeśli mają być widoczne w Google
Koszyk	Często tak	Nie ma wartości w wynikach wyszukiwania
Checkout	Często tak	Strona techniczna procesu zakupowego
Konto użytkownika	Tak	Nie powinno być publiczną stroną SEO
Wewnętrzne wyniki wyszukiwania	Często tak lub noindex	Zależy od struktury i platformy
CSS i JS	Nie	Google może ich potrzebować do renderowania
Obrazy	Zwykle nie	Zwłaszcza jeśli zależy Ci na Google Grafika

Największa pułapka to blokowanie całych katalogów bez sprawdzenia, co w nich jest.

Przykład:

Disallow: /media/

Jeśli w tym katalogu masz obrazy produktów, zdjęcia realizacji albo grafiki blogowe, możesz utrudnić Google dostęp do ważnych zasobów.

Przykład:

Disallow: /category/

Jeśli kategorie bloga mają rankować, właśnie je zablokowałeś.

Robots.txt powinien być wynikiem audytu, a nie zgadywania.

Najczęstsze błędy w robots.txt

Błędy w robots.txt często są krótkie.

Ale ich skutki potrafią być duże.

Błąd	Skutek	Co zrobić?
Disallow: / na produkcji	Blokada crawlowania całej strony	Usunąć zapis albo ograniczyć go do stagingu
Blokada CSS i JS	Google może gorzej renderować stronę	Pozwolić na dostęp do zasobów renderujących
Blokada bloga	Artykuły nie są crawlownane	Odblokować sekcję, jeśli ma generować ruch
Blokada kategorii produktów	Sklep traci ważne strony SEO	Odblokować kategorie z potencjałem
Używanie robots.txt do noindex	Strona może nadal pojawiać się w Google	Użyć meta noindex lub X-Robots-Tag
Blokada sitemap.xml	Robot ma utrudniony dostęp do mapy	Nie blokować mapy strony
Kopiowanie robots.txt z innej strony	Reguły mogą nie pasować do Twojej struktury	Przygotować plik pod konkretną witrynę
Brak kontroli po migracji	Stagingowe blokady trafiają na produkcję	Dodać robots.txt do checklisty wdrożeniowej
Blokowanie adresów z noindex	Google może nie odczytać noindex	Najpierw pozwolić na crawl i przetworzenie noindex

Największy błąd?

Myślenie, że robots.txt to techniczny detal, którego nikt nie musi sprawdzać.

W rzeczywistości to jeden z pierwszych plików, które warto kontrolować przy audycie SEO.

Jak sprawdzić, czy robots.txt nie blokuje strony?

Zacznij od najprostszego testu.

Wejdź pod adres:

https://twojadomena.pl/robots.txt

Sprawdź, czy widzisz tam coś takiego:

User-agent: *
Disallow: /

Jeśli tak, a strona ma być widoczna w Google, masz poważny problem.

Potem sprawdź, czy nie są blokowane ważne katalogi:

• /blog/
• /uslugi/
• /oferta/
• /produkty/
• /kategoria/
• /wp-content/
• /images/
• /media/

Następnie użyj Google Search Console.

W narzędziu inspekcji URL sprawdź ważny adres, na przykład:

• stronę główną,
• najważniejszą usługę,
• ważny artykuł,
• kategorię produktów,
• kartę produktu.

Zwróć uwagę na komunikaty:

• zablokowano przez robots.txt,
• zindeksowano, choć zablokowano przez robots.txt,
• wykryto, obecnie nie zindeksowano,
• zeskanowano, obecnie nie zindeksowano,
• strona nie jest dostępna dla Googlebota.

Przy większych stronach wykonaj crawl narzędziem SEO.

Sprawdź:

• które URL-e są blokowane przez robots.txt,
• czy blokady dotyczą ważnych stron,
• czy sitemap zawiera zablokowane adresy,
• czy linkowanie wewnętrzne prowadzi do zablokowanych URL-i,
• czy blokowane są zasoby CSS, JS i obrazy.

Narzędzia pomocne przy kontroli:

• Google Search Console,
• Screaming Frog SEO Spider,
• Sitebulb,
• Ahrefs Site Audit,
• Semrush Site Audit,
• logi serwera,
• ręczna kontrola pliku robots.txt.

Jak naprawić błędny robots.txt?

Naprawa robots.txt zależy od typu problemu.

Jeśli strona produkcyjna ma:

User-agent: *
Disallow: /

i ma być widoczna w Google, usuń globalną blokadę.

Bezpieczniejsza wersja dla WordPressa:

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php

Sitemap: https://example.pl/sitemap_index.xml

Jeśli zablokowane są ważne katalogi, usuń konkretne reguły.

Przykład błędny:

User-agent: *
Disallow: /blog/

Jeśli blog ma generować ruch z Google, usuń tę blokadę.

Jeśli blokujesz CSS i JS, sprawdź, czy Google może poprawnie renderować stronę.

Przykład potencjalnie problematyczny:

User-agent: *
Disallow: /wp-content/
Disallow: /assets/
Disallow: /js/
Disallow: /css/

W wielu przypadkach lepiej nie blokować tych zasobów.

Jeśli chcesz usunąć stronę z indeksu, nie polegaj wyłącznie na robots.txt.

Użyj:

<meta name="robots" content="noindex, follow" />

albo nagłówka:

X-Robots-Tag: noindex

Jeśli strona jest poufna, zabezpiecz ją hasłem.

Jeśli adres został przeniesiony, zastosuj 301.

Po zmianie robots.txt:

1. Sprawdź plik ręcznie w przeglądarce.
2. Wykonaj test kilku URL-i w Google Search Console.
3. Sprawdź sitemap.xml.
4. Wykonaj crawl strony.
5. Monitoruj raport indeksowania.
6. Sprawdź logi serwera, jeśli strona jest duża.

Sama poprawka pliku nie zawsze daje natychmiastowy efekt.

Google musi ponownie pobrać robots.txt i przejść przez adresy strony.

Checklista bezpiecznego robots.txt

Poniżej masz praktyczną checklistę do wykorzystania przy audycie strony, wdrożeniu nowej witryny albo migracji.

Punkt kontroli	Tak/Nie	Uwagi
Plik robots.txt istnieje pod /robots.txt		Sprawdź właściwą domenę i subdomenę
Nie ma globalnego Disallow: / na produkcji		Najważniejszy punkt kontroli
Strona główna nie jest zablokowana		Sprawdź w Search Console
Usługi i landing page'e nie są zablokowane		To zwykle strony sprzedażowe
Blog nie jest zablokowany		Jeśli ma generować ruch SEO
Kategorie produktów nie są zablokowane		Jeśli mają potencjał organiczny
CSS i JS są dostępne dla Google		Ważne dla renderowania strony
Sitemap jest wskazana w robots.txt		Dodaj pełny adres mapy XML
Sitemap nie zawiera zablokowanych adresów		Unikaj sprzecznych sygnałów
Strona testowa jest zabezpieczona hasłem		Sam robots.txt nie wystarczy
Nie używasz robots.txt jako zamiennika noindex		To częsty błąd
Robots.txt został sprawdzony po migracji		Obowiązkowo po wdrożeniu strony

Tę checklistę warto dodać do procedury publikacji każdej nowej strony.

Szczególnie jeśli pracujesz na WordPressie, WooCommerce, Shopify, PrestaShop, Magento albo customowym CMS-ie.

Plan 30 dni na uporządkowanie crawlowania strony

Jeśli podejrzewasz, że robots.txt blokuje za dużo albo strona ma chaos indeksacyjny, podejdź do tego etapami.

Okres	Priorytet	Działania
Dni 1-3	Diagnoza	Sprawdzenie robots.txt, sitemap.xml, Search Console i najważniejszych URL-i
Dni 4-7	Crawl strony	Analiza blokowanych adresów, statusów HTTP, noindex, canonicali i sitemap
Dni 8-12	Mapa typów stron	Podział na strony sprzedażowe, blog, kategorie, produkty, filtry, koszyk, konto i parametry
Dni 13-17	Decyzje SEO	Ustalenie, co ma być crawlownane, co indeksowane, co noindex, a co blokowane
Dni 18-22	Wdrożenie	Poprawa robots.txt, sitemap, meta robots, canonicali i linkowania wewnętrznego
Dni 23-26	Testy	Inspekcja URL-i w Google Search Console, ponowny crawl i kontrola zasobów CSS/JS
Dni 27-30	Monitoring	Obserwacja raportów indeksacji, crawlowania, błędów i zmian w widoczności

Po takim procesie powinieneś mieć:

• bezpieczny robots.txt,
• odblokowane ważne strony SEO,
• ograniczone crawlowanie sekcji technicznych,
• spójną sitemapę XML,
• mniej sprzecznych sygnałów,
• lepszą kontrolę nad indeksacją,
• mniejsze ryzyko błędów po migracjach,
• czytelniejszą strukturę dla Google.

Robots.txt nie powinien być plikiem, do którego nikt nie zagląda przez lata.

Warto go sprawdzać przy każdej większej zmianie strony.

Najczęstsze pytania

Robots.txt może pomóc Google, ale może też zamknąć mu drzwi.

Robots.txt jest jednym z najprostszych plików na stronie.

Ale jego wpływ na SEO może być bardzo duży.

Dobrze skonfigurowany pomaga uporządkować crawlowanie, ograniczyć techniczny szum i wskazać mapę strony.

Źle skonfigurowany może zablokować blog, usługi, produkty, kategorie albo nawet całą stronę.

Najważniejsze, co trzeba zapamiętać:

• robots.txt zarządza crawlowaniem, nie indeksacją,
• Disallow: / na produkcji to ogromne ryzyko,
• noindex wymaga, żeby robot mógł wejść na stronę,
• CSS i JavaScript zwykle nie powinny być blokowane,
• sitemap i robots.txt muszą być spójne,
• strony testowe najlepiej zabezpieczać hasłem,
• robots.txt trzeba sprawdzać po każdej migracji i większej zmianie strony.

Jeśli chcesz sprawdzić, czy Twoja strona nie blokuje przypadkiem Google, zarezerwuj darmową analizę SEO z Digitay. Sprawdzimy robots.txt, sitemapę, indeksację, canonicale, noindex, przekierowania i techniczne błędy, które mogą ograniczać widoczność strony.