robots.txt i sitemap.xml: jak ich nie ustawić przeciwko sobie

Czy Twój robots.txt blokuje Google? Sprawdzisz to w pięć minut: wpisz w przeglądarce twojadomena.pl/robots.txt. Jeśli widzisz linię Disallow: / pod User-agent: *, blokujesz cały serwis i to jest Twój problem numer jeden. A mapa strony przy 30 podstronach? Nie jest konieczna, o ile do każdej podstrony prowadzi link z menu albo z treści, bo Google znajdzie je sam. Warto ją mieć z innego powodu: w Search Console dostajesz wtedy raport, który pokazuje osobno, ile ze zgłoszonych przez Ciebie adresów faktycznie wylądowało w indeksie. To najszybsza diagnostyka, jaką możesz mieć za darmo.

Co dokładnie robi robots.txt

To zwykły plik tekstowy w katalogu głównym domeny. Zawiera instrukcje dla robotów: do których adresów mają nie zaglądać. Instrukcje, nie zakazy techniczne. Roboty dużych wyszukiwarek je respektują, ale plik niczego nie zabezpiecza i nie chroni. Wszystko, co w nim wypiszesz, jest publiczne i czytelne dla każdego.

Poprawny plik dla typowej strony firmowej jest krótki. Im dłuższy robots.txt, tym większa szansa, że ktoś zablokował w nim coś, czego nie chciał.

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

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

Reguły dopasowują się po początku ścieżki. Disallow: /uslugi zablokuje też /uslugi-dla-firm/, bo pasuje początek. Ukośnik na końcu ma znaczenie i jest najczęstszym źródłem przypadkowych blokad.

Blokada crawlowania to nie blokada indeksowania

To rozróżnienie odpowiada za większość nieporozumień wokół tego pliku. Jeśli chcesz, żeby strona zniknęła z wyników wyszukiwania, robots.txt jest niewłaściwym narzędziem.

Klasyczny scenariusz, w którym te dwa mechanizmy się kłócą: ktoś dodaje noindex na stronę regulaminu, a jednocześnie blokuje ją w robots.txt "na wszelki wypadek". Efekt jest odwrotny do zamierzonego, bo adres zostaje w wynikach, tylko bez opisu, z komunikatem o braku dostępu do treści. Zasada jest prosta: strona, która ma mieć noindex, musi być dostępna dla robota. Jak działa pokrewny mechanizm wskazywania wersji głównej, opisujemy w tekście o tym, jak stosować tag canonical.

Pięć błędów, które widzimy najczęściej

1. Blokada całego serwisu po wdrożeniu. Wersja testowa miała Disallow: /, żeby nie trafiła do Google. Przy przenoszeniu na produkcję plik pojechał razem z resztą. Strona żyje, wygląda dobrze, i przez trzy miesiące nikt nie rozumie, dlaczego nie ma z niej ruchu.
2. Blokada katalogów z CSS i JavaScriptem. Reguły w rodzaju Disallow: /assets/ albo Disallow: /wp-includes/ odcinają robotowi pliki potrzebne do wyrenderowania strony. Google widzi wtedy układ bez stylów i ocenia go jak stronę z 2003 roku.
3. Blokowanie adresów, które mają noindex. Opisane wyżej. Dwa mechanizmy nawzajem się unieważniają.
4. Blokada strony docelowej przekierowania. Stary adres przekierowuje na nowy, a nowy jest w zablokowanym katalogu. Sygnały ze starego adresu przepadają.
5. Mapa strony w robots.txt podana adresem względnym. Dyrektywa Sitemap wymaga pełnego adresu z protokołem. Sitemap: /sitemap.xml jest po prostu ignorowana.

Jeśli podejrzewasz którykolwiek z tych scenariuszy, sprawdź najpierw, ile Twoich podstron faktycznie jest w indeksie. Sposoby diagnostyki i pozostałe przyczyny opisujemy w tekście o tym, dlaczego Google nie indeksuje Twoich podstron.

Jak sprawdzić swój plik w pięć minut

1. Otwórz twojadomena.pl/robots.txt w przeglądarce. Jeśli dostajesz błąd 404, plik nie istnieje. To nie jest problem: brak pliku oznacza zgodę na pobieranie wszystkiego.
2. Poszukaj linii Disallow: / bez niczego po ukośniku. To blokada całego serwisu.
3. Sprawdź, czy nie blokujesz katalogów z zasobami: nazwy w rodzaju assets, static, dist, themes, includes, media.
4. W Google Search Console użyj narzędzia sprawdzania adresu URL na trzech podstronach: głównej, jednej usługowej i jednym wpisie. Raport pokazuje, czy pobieranie jest dozwolone i kiedy robot był ostatnio.
5. Obejrzyj zrzut wyrenderowanej strony w tym samym narzędziu. Jeśli wygląda jak tekst bez formatowania, blokujesz style.

Nazwy raportów odpowiadają interfejsowi Google Search Console z sierpnia 2026. Google zmieniał już nazewnictwo tych narzędzi, układ mógł się przesunąć.

Ten test rozstrzyga jedno pytanie: czy robot w ogóle wchodzi. Dostępność jest warunkiem wstępnym, nie strategią. Strona, która się otwiera, ale nie odpowiada na żadne realne zapytanie, generuje dokładnie tyle ruchu co strona zablokowana. Kolejny krok po odblokowaniu to decyzja, na jakie frazy chcesz być znajdowany.

Kiedy mapa strony XML naprawdę ma sens

Mapa to lista adresów, które chcesz zgłosić wyszukiwarce. Nie gwarantuje indeksowania i nie poprawia pozycji. Daje dwie rzeczy: pomaga znaleźć adresy, do których nie prowadzą linki, i daje Ci raport w Search Console.

Zasada porządkowa dla mapy jest jedna: umieszczaj w niej wyłącznie adresy, które mają być w wynikach. Bez przekierowań, bez stron z noindex, bez wersji, które mają canonical wskazujący gdzie indziej, bez błędów 404. Mapa pełna śmieci przestaje być użytecznym raportem, bo w Search Console widzisz wtedy dużą liczbę adresów niezaindeksowanych i nie wiesz, które z nich to problem, a które celowe wykluczenie.

Czego mapa nie robi: nie zastępuje linkowania wewnętrznego. Adres, do którego nie prowadzi żaden link z Twojego serwisu, jest stroną osieroconą. Zgłoszenie go w mapie sprawia, że Google go znajdzie, ale nie daje żadnego sygnału, że jest to strona ważna, bo taki sygnał niosą linki, nie wpisy w pliku XML. Dlatego mapa jest dobrym testem porządku, a nie sposobem na jego brak: jeśli w Search Console widzisz adresy zgłoszone i nieodwiedzane od miesięcy, sprawdź najpierw, czy prowadzi do nich cokolwiek z menu, z listy wpisów albo z treści innej podstrony. Linki wewnętrzne masz za darmo i pod pełną kontrolą, w odróżnieniu od zewnętrznych, przy których osobną kwestią jest, co naprawdę kupujesz, płacąc za linki.

W większości systemów CMS mapa generuje się sama. W WordPressie robi to wtyczka SEO, w Shoperze i PrestaShopie moduł wbudowany. Nie ma powodu pisać jej ręcznie, jest natomiast powód, żeby raz na kwartał do niej zajrzeć i sprawdzić, czy nie zbiera adresów testowych. Gorzej wygląda to w serwisach pisanych od zera: tam generowanie mapy i kontrola nad robots.txt muszą trafić do specyfikacji przed startem prac, bo dokładanie ich po odbiorze projektu to zwykle osobne zlecenie. To jedna z tych pozycji, które podnoszą wycenę strony przygotowanej pod SEO, i jedna z tych, na których oszczędność wraca po kilku miesiącach. Porządkowanie tej warstwy na gotowym serwisie wchodzi w zakres optymalizacji technicznej strony.

robots.txt a boty AI: to osobna decyzja

Ten sam plik obsługuje też roboty modeli językowych, ale reguły dla nich są innym tematem i wymagają innej decyzji biznesowej. Googlebot odpowiada za Twoją widoczność w wynikach wyszukiwania. Boty w rodzaju GPTBot czy PerplexityBot odpowiadają za to, czy Twoja firma pojawi się w odpowiedziach ChatGPT i Perplexity.

Problem polega na tym, że blokady botów AI trafiają na strony przypadkiem: przez domyślne ustawienia hostingu, przez włączony tryb ochrony w panelu Cloudflare albo przez skopiowany szablon pliku. Firma, która płaci za widoczność w AI, jednocześnie odcina modelom dostęp do treści. Jak to sprawdzić i co dokładnie odblokować, opisujemy w tekście o tym, jak strony niechcący blokują boty AI.

Po stronie wpuszczania botów AI dochodzi drugi plik, którego nie ma w klasycznym SEO: llms.txt. Co w nim umieścić i jak sprawdzić, czy modele naprawdę dochodzą do treści, prowadzi krok po kroku skill llms.txt i dostęp dla crawlerów AI.

Decyzja o botach AI nie jest oczywista i nie brzmi "zawsze wpuszczać". Wydawcy treści premium mają powody, żeby blokować. Firma usługowa, która chce być cytowana jako wykonawca, ma powody odwrotne. Ważne, żeby to była decyzja, a nie efekt uboczny ustawienia, o którym nikt nie pamięta.

FAQ: robots.txt i mapa strony

Jak sprawdzić, czy mój robots.txt nie blokuje Google?

Wpisz w przeglądarce adres swojadomena.pl/robots.txt i przeczytaj plik. Linia Disallow: / pod User-agent: * blokuje cały serwis. Następnie w Google Search Console użyj narzędzia sprawdzania adresu URL na kilku podstronach: pokaże, czy pobranie strony jest dozwolone.

Czy mapa strony XML jest potrzebna przy 30 podstronach?

Nie jest niezbędna, jeśli wszystkie podstrony są dostępne z menu i z linków w treści. Google i tak je znajdzie. Mapa zaczyna się opłacać przy stronach osieroconych, przy serwisach ponad kilkuset adresów oraz wtedy, gdy chcesz w Search Console widzieć raport indeksowania osobno dla zgłoszonych adresów.

Czym różni się Disallow w robots.txt od znacznika noindex?

Disallow zabrania robotowi pobrania strony, noindex zabrania jej pokazywania w wynikach. To dwie różne rzeczy i dwa różne miejsca. Strona zablokowana w robots.txt może trafić do wyników bez opisu, jeśli prowadzą do niej linki. Żeby usunąć stronę z wyników, użyj noindex i nie blokuj jej w robots.txt, bo wtedy robot nie zobaczy znacznika.

Czy blokowanie plików CSS i JavaScript w robots.txt szkodzi?

Tak. Google renderuje stronę jak przeglądarka i potrzebuje arkuszy stylów oraz skryptów, żeby ocenić układ, wersję mobilną i widoczność treści. Blokada katalogów z zasobami sprawia, że robot widzi stronę rozsypaną. To jeden z najczęstszych błędów w plikach robots.txt kopiowanych z gotowych szablonów.

Zablokowałem serwis podczas wdrożenia i zapomniałem odblokować. Co teraz?

Usuń regułę Disallow: /, sprawdź plik pod adresem swojadomena.pl/robots.txt, a potem w Search Console zgłoś ponownie mapę strony i poproś o indeksowanie kilku kluczowych adresów. Powrót do indeksu trwa zwykle od kilku dni do kilku tygodni, zależnie od tego, jak długo blokada obowiązywała.

Powiązane strony

• Dlaczego Google nie indeksuje Twoich podstron: 9 przyczyn
• Twoja strona blokuje boty AI i nie wiesz o tym
• Optymalizacja techniczna strony i Core Web Vitals
• Tag canonical: kiedy stosować i jak nie zepsuć indeksowania