Robots.txt pod kątem SEO - jak ustawić plik bez blokowania wyników?

Robots.txt kontroluje pobieranie strony przez crawlera

Plik robots.txt odpowiada na pytanie: czy robot może pobrać daną ścieżkę? Widoczność URL-a w indeksie Google zależy od innych sygnałów, dyrektyw i statusów. Ta różnica jest krytyczna, bo wiele błędów SEO zaczyna się od założenia, że Disallow i noindex mają ten sam skutek.

W praktyce robots.txt jest elementem szerszej diagnostyki technicznej: crawlowania, statusów HTTP, sitemap, linkowania wewnętrznego, canonicali, renderowania i raportów w Google Search Console.

Jak działa robots.txt w procesie SEO?

Najprostszy model wygląda tak: robot zna URL, sprawdza plik robots.txt dla właściwego hosta, dopasowuje regułę, a dopiero potem decyduje, czy pobrać stronę lub zasób. Jeśli pobieranie jest zablokowane, Google może nie zobaczyć treści, meta robots, canonicala ani pełnego renderu.

Kiedy używać robots.txt, a kiedy innego mechanizmu?

Robots.txt ma sens, gdy problemem jest pobieranie dużych lub mało wartościowych grup URL-i. Jeśli problemem jest obecność strony w indeksie, prywatność danych, duplikacja albo trwałe usunięcie adresu, potrzebny jest inny mechanizm.

Czego robots.txt nie robi?

Robots.txt nie wymusza zachowania każdego bota, nie zabezpiecza prywatnych danych i nie gwarantuje usunięcia strony z Google. To instrukcja dla crawlerów, które ją respektują, a nie warstwa autoryzacji ani kontrola dostępu.

Najważniejsze reguły składni robots.txt

Składnia jest prosta, ale błędy mają duży zasięg. Warto trzymać plik krótki, komentować powód reguł i testować dopasowanie na realnych adresach, zwłaszcza przy symbolach wieloznacznych.

Przykłady robots.txt - od bezpiecznych reguł do ryzykownych blokad

Dobry robots.txt opisuje typy adresów URL i ich rolę w serwisie. Lista pojedynczych, przypadkowych adresów szybko robi się trudna w utrzymaniu. Poniższe przykłady traktuj jako wzorce decyzyjne: przed wdrożeniem trzeba je porównać z realną strukturą hosta, sitemapą, logami i rolą konkretnych ścieżek w SEO.

User-agent: *
Disallow:
Sitemap: https://example.com/sitemap.xml

User-agent: *
Disallow: /

User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /cart/
Disallow: /checkout/
Disallow: /my-account/
Sitemap: https://example.com/sitemap_index.xml

User-agent: *
Disallow: /search/
Disallow: /*?s=
Disallow: /*?sort=
Disallow: /*?orderby=

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

Gdzie powinien znajdować się plik robots.txt?

Plik musi być dostępny jako /robots.txt w katalogu głównym konkretnego hosta. Reguły nie przechodzą automatycznie na inne subdomeny, protokoły ani niestandardowe porty. Dla Googlehttps://example.com/robots.txt i https://shop.example.com/robots.txt dotyczą innych hostów.

• Nazwa pliku to dokładnie robots.txt.
• Plik powinien być tekstowy i zakodowany w UTF-8.
• Reguły są ważne tylko dla hosta, protokołu i portu, na których plik jest udostępniony.
• Plik w podkatalogu, np. /folder/robots.txt, nie jest właściwym plikiem dla całej witryny.
• Warto utrzymywać plik poniżej limitu rozmiaru i bez zbędnej listy pojedynczych wyjątków.

Co się dzieje, gdy robots.txt zwraca 404, 5xx albo przekierowanie?

Status HTTP pliku robots.txt wpływa na to, czy Googlebot uzna, że ma ograniczenia crawlowania. To ważne przy awariach, migracjach i konfiguracjach CDN, gdzie sam plik bywa przypadkowo przekierowany, zablokowany lub generowany przez aplikację.

Robots.txt a noindex - najczęściej popełniane błędy

Jeśli chcesz, żeby strona HTML nie była widoczna w Google, użyj noindex w meta robots albo odpowiedniego nagłówka HTTP. Nie blokuj jednocześnie crawlowania tej strony w robots.txt, bo Google może nie pobrać HTML-u i nie zobaczyć dyrektywy noindex.

Robots.txt a canonical - inna decyzja dla podobnych URL-i

Canonical pomaga wskazać reprezentatywną wersję podobnych stron. Robots.txt ogranicza pobieranie. Jeśli zablokujesz warianty w robots.txt, Google może nie zobaczyć canonicala na tych wariantach. Przy małej liczbie duplikatów często lepsza jest spójna kanonikalizacja, linkowanie i sitemap niż natychmiastowy Disallow.

Przy ogromnych przestrzeniach URL-i, na przykład sortowaniach i parametrach w sklepie, decyzja może być mieszana: część filtrów indeksować jako wartościowe landing pages, część kanonikalizować, a część ograniczyć w robots.txt.

Czy blokować CSS, JavaScript i obrazy?

Zasobów potrzebnych do renderowania zwykle nie należy blokować. Jeśli Google nie może pobrać CSS, JavaScriptu lub krytycznych plików, może zobaczyć stronę inaczej niż użytkownik. Blokada ma sens tylko wtedy, gdy brak zasobu nie utrudnia interpretacji strony.

Robots.txt w sklepie internetowym - filtry, parametry i koszyk

W e-commerce robots.txt może realnie poprawić efektywność crawlu, ale tylko wtedy, gdy wynika z mapy URL-i. Najpierw trzeba rozdzielić adresy z popytem i unikalną wartością od kombinacji, które generują nieskończoną przestrzeń crawlowania.

Czy robots.txt oszczędza crawl budget?

Może ograniczyć pobieranie URL-i, których Google nie powinien przetwarzać, ale crawl budget nie jest głównym problemem każdej strony. Według dokumentacji Google temat jest szczególnie istotny przy bardzo dużych serwisach, często aktualizowanych witrynach i dużych grupach adresów wykrytych, ale niezaindeksowanych.

Robots.txt w WordPressie, WooCommerce i innych CMS-ach

W CMS-ach plik robots.txt może być fizycznym plikiem albo generowaną odpowiedzią pod adresem /robots.txt. To normalne, ale przy audycie trzeba sprawdzić efekt końcowy, nie tylko ustawienie w panelu lub wtyczce.

• Sprawdź publiczny plik, a nie tylko konfigurację wtyczki SEO.
• Upewnij się, że środowisko produkcyjne nie przejęło blokady ze stagingu.
• W WooCommerce kontroluj koszyk, konto, checkout, wyszukiwarkę i wybrane parametry.
• Nie blokuj /wp-admin/admin-ajax.php, jeśli strona używa go do działania frontu.
• Po zmianach wyczyść cache aplikacji, hostingu i CDN, jeśli plik jest generowany dynamicznie.

Staging, subdomeny i migracje - gdzie robots.txt najczęściej szkodzi?

Największe ryzyko pojawia się przy przejściu ze stagingu na produkcję. Reguła Disallow: / jest poprawna na środowisku testowym, ale na produkcji może odciąć crawling całej witryny. Przy migracji trzeba też sprawdzić, czy nowy host, subdomena, wersja HTTPS i CDN zwracają właściwy plik.

Robots.txt a boty AI - decyzja o dostępie to także decyzja o widoczności

Część botów AI i wyszukiwarek respektuje robots.txt, ale nie wszystkie systemy działają identycznie. Z perspektywy firmy decyzja nie brzmi tylko „blokować AI czy nie”, lecz: które boty mogą pobierać stronę, w jakim celu i czy blokada nie ograniczy widoczności w odpowiedziach AI.

Jeśli analizujesz ten obszar, rozdziel crawling pod wyszukiwanie, pobrania inicjowane przez użytkownika i wykorzystanie treści do treningu. W KEO przygotowaliśmy do tego tester robots.txt dla AI.

Jak testować robots.txt przed i po wdrożeniu?

Test nie powinien kończyć się na otwarciu pliku w przeglądarce. Trzeba sprawdzić dostępność pliku, dopasowanie reguł do realnych URL-i, interpretację Google i wpływ na ważne sekcje serwisu.

• Otwórz publiczny adres /robots.txt w przeglądarce i sprawdź, czy plik zwraca treść tekstową.
• Zweryfikuj, który plik robots.txt dotyczy konkretnego URL-a: liczy się protokół, host i port.
• Użyj raportu robots.txt w Google Search Console, jeśli jest dostępny dla danej usługi.
• Dla pojedynczego adresu użyj Inspekcji URL i sprawdź, czy Google widzi blokadę crawlowania.
• Sprawdź ważne typy URL-i na realnych przykładach, a nie tylko na wzorcach reguł.
• Jeśli korzystasz z Google Ads, nazwij roboty AdsBot jawnie, bo globalna grupa * nie obejmuje ich tak samo jak standardowych crawlerów Google.
• Uwzględnij cache: Google zwykle może pamiętać robots.txt do 24 godzin.
• Po zmianie krytycznej poproś o ponowne zindeksowanie pliku robots.txt w GSC, ale nie traktuj tego jako gwarancji natychmiastowego crawlu URL-i.
• Przy dużym serwisie porównaj reguły z logami serwera i statystykami indeksowania.

Jak mierzyć efekt zmian w robots.txt?

Efektem nie jest sama obecność pliku. Efektem jest lepszy rozkład crawlu: mniej żądań do URL-i bez wartości i więcej uwagi dla stron, które mają generować widoczność, leady lub sprzedaż.

Diagnostyka robots.txt - objaw, przyczyna i szybkie sprawdzenie

Robots.txt rzadko występuje jako izolowany problem. Najszybsza diagnoza łączy objaw w Google, regułę w pliku, status HTTP, linkowanie i dane z crawlu lub logów.

Najczęstsze błędy robots.txt pod kątem SEO

Jak ustalić priorytet poprawek w robots.txt?

Nie każda zmiana w robots.txt ma taki sam ciężar. Najpierw napraw blokady, które zatrzymują crawling ważnych sekcji albo uniemożliwiają Google odczytanie noindex, canonicala i renderu.

Checklista robots.txt przed publikacją zmian

• Plik jest dostępny pod /robots.txt dla właściwego hosta, protokołu i portu.
• Nie ma reguły blokującej całą produkcyjną domenę.
• Ważne strony usług, kategorii, produktów i artykułów nie są zablokowane.
• CSS, JS i zasoby potrzebne do renderowania są dostępne dla Googlebota.
• Sitemap ma pełny URL i prowadzi do adresów kanonicznych, które mają być crawlowane.
• Plik ma poniżej 500 KiB i nie zawiera niepotrzebnej listy pojedynczych wyjątków.
• Nie używasz Crawl-delay jako mechanizmu sterowania Googlebotem.
• Reguły dla Googlebota i grupy globalnej są świadomie rozdzielone.
• Jeśli reguły dotyczą AdsBot, robot jest nazwany jawnie w osobnej grupie.
• Adresy do usunięcia z indeksu mają noindex, X-Robots-Tag, 404/410 albo ochronę hasłem, a nie sam Disallow.
• Filtry i parametry e-commerce mają decyzję na poziomie typu URL-a.
• Zmiana została sprawdzona w GSC, crawlerze technicznym i, przy dużym serwisie, w logach.

Powiązane tematy i narzędzia

Robots.txt jest jednym elementem technicznego SEO. Poniższe materiały prowadzą do sąsiednich etapów: crawlingu, indeksowania, linkowania, audytu i testowania botów.

FAQ