Robots.txt – jak skonfigurować plik i nie zablokować Google?

Plik robots.txt jest jednym z podstawowych elementów technicznego SEO. Pozwala określić, do których części serwisu roboty wyszukiwarek mogą uzyskiwać dostęp, a które obszary powinny pozostać poza ich zasięgiem.

Brzmi prosto, ale błędna konfiguracja potrafi zablokować Google dostęp do całej witryny, ważnych kategorii, produktów, artykułów albo zasobów potrzebnych do prawidłowego renderowania strony.

Dlatego robots.txt SEO wymaga ostrożności. Plik nie służy do usuwania stron z wyników Google, nie zastępuje noindex i nie powinien być używany jako uniwersalny sposób rozwiązywania problemów z indeksacją.

Google wyjaśnia, że robots.txt służy przede wszystkim do zarządzania dostępem robotów do adresów URL i ograniczania niepotrzebnego crawlowania. Zablokowany adres nadal może w pewnych sytuacjach pojawić się w wynikach wyszukiwania, np. jeśli Google zna go z linków zewnętrznych.

Co to jest plik robots.txt?

robots.txt to zwykły plik tekstowy umieszczany w katalogu głównym hosta.

Dla strony:

https://www.example.com/

plik powinien znajdować się pod adresem:

https://www.example.com/robots.txt

Może zawierać reguły określające:

• którego robota dotyczą instrukcje,
• do jakich katalogów może wejść,
• których adresów nie powinien odwiedzać,
• gdzie znajduje się mapa witryny.

Przykład:

User-agent: *
Disallow: /panel/
Disallow: /koszyk/

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

Taka konfiguracja oznacza, że wszystkie roboty stosujące się do protokołu nie powinny odwiedzać adresów rozpoczynających się od /panel/ i /koszyk/, a mapa witryny znajduje się pod wskazanym adresem.

Google stosuje Robots Exclusion Protocol i odczytuje plik przed crawlowaniem serwisu.

Do czego służy robots.txt?

Najważniejszym zastosowaniem jest zarządzanie ruchem robotów.

Można dzięki niemu ograniczyć odwiedzanie:

• paneli administracyjnych,
• wewnętrznych wyników wyszukiwania,
• parametrów sortowania,
• niektórych filtrów,
• adresów sesji,
• koszyka,
• etapów zamówienia,
• technicznych katalogów,
• zasobów generujących dużą liczbę zbędnych URL-i.

W dużym sklepie może to pomóc ograniczyć marnowanie crawl budgetu na tysiące niepotrzebnych kombinacji adresów.

Nie oznacza to jednak, że należy blokować wszystko, czego nie chcemy zobaczyć w Google.

Robots.txt nie służy do usuwania strony z Google

To jedna z najważniejszych zasad.

Jeżeli wpiszesz:

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

Googlebot nie powinien pobierać zawartości tego URL-a. Sam adres może jednak nadal zostać znaleziony np. poprzez linki prowadzące z innych stron.

Google może wtedy wyświetlić sam URL bez prawidłowego fragmentu treści.

Google wprost zaleca, aby do usuwania strony z wyników stosować noindex albo zabezpieczenie dostępu, a nie sam robots.txt.

Robots.txt a noindex – najważniejsza różnica

Robots.txt

Kontroluje crawlowanie:

Czy robot może wejść na stronę?

Noindex

Kontroluje indeksowanie:

Czy strona może pojawiać się w wynikach?

Przykład noindex:

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

Aby Google mogło zastosować noindex, musi najpierw odwiedzić stronę i odczytać kod.

Dlatego błędna konfiguracja wygląda tak:

User-agent: *
Disallow: /strona/

oraz jednocześnie:

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

Googlebot jest zablokowany przez robots.txt, więc może nie zobaczyć noindex.

Google wyraźnie wskazuje, że jeśli chcesz używać noindex, musisz pozwolić robotowi na pobranie strony.

Czy można wpisać noindex do robots.txt?

Nie.

Reguła:

Noindex: /strona/

nie jest obsługiwana przez Google jako metoda wykluczania z wyników.

Do tego celu użyj:

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

lub nagłówka HTTP:

X-Robots-Tag: noindex

Jak wygląda podstawowy robots.txt?

Najprostsza konfiguracja dla strony, na której Google może odwiedzać wszystko:

User-agent: *
Disallow:

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

Można też całkowicie pominąć Disallow.

Google domyślnie zakłada, że crawlowanie jest dozwolone, jeśli żadna reguła go nie ogranicza.

Co oznacza User-agent?

User-agent określa robota, którego dotyczą kolejne reguły.

Przykład:

User-agent: Googlebot

dotyczy głównego robota Google.

Z kolei:

User-agent: *

oznacza wszystkie roboty pasujące do grupy ogólnej.

Przykład:

User-agent: Googlebot
Disallow: /test/

User-agent: *
Disallow:

Googlebot nie powinien odwiedzać /test/, natomiast pozostałe roboty mogą korzystać z całego serwisu.

Co oznacza Disallow?

Disallow określa ścieżkę, której robot nie powinien pobierać.

Przykład:

User-agent: *
Disallow: /panel/

blokuje adresy rozpoczynające się od:

/panel/

np.:

/panel/
/panel/logowanie/
/panel/uzytkownik/

Wartości ścieżek są w Google rozróżniane pod względem wielkości liter.

Czyli:

Disallow: /Sklep/

nie musi oznaczać tego samego co:

Disallow: /sklep/

Co oznacza Allow?

Allow pozwala udostępnić fragment katalogu, który w szerszej regule został zablokowany.

Przykład:

User-agent: *
Disallow: /private/
Allow: /private/public/

Robot nie powinien odwiedzać większości katalogu /private/, ale może wejść do:

/private/public/

Google obsługuje dyrektywę Allow.

Jak Google wybiera regułę Allow i Disallow?

Jeśli kilka reguł pasuje do tego samego URL-a, Google analizuje najbardziej szczegółową ścieżkę.

Przykład:

User-agent: *
Disallow: /sklep/
Allow: /sklep/produkty/

adres:

/sklep/

jest zablokowany.

Natomiast:

/sklep/produkty/buty/

może być dostępny, ponieważ bardziej szczegółowa reguła Allow dotyczy właśnie tego katalogu.

Przy skomplikowanych regułach nie warto zgadywać — trzeba testować konkretne adresy.

Jak zablokować całą stronę w robots.txt?

Technicznie:

User-agent: *
Disallow: /

oznacza blokadę całego hosta.

To właśnie jedna z najbardziej niebezpiecznych reguł podczas publikowania nowej wersji serwisu.

Często pojawia się ona na środowisku testowym:

User-agent: *
Disallow: /

a następnie zostaje przypadkowo przeniesiona na produkcję.

Efekt:

Googlebot nie może normalnie crawlowac serwisu.

Dlatego po każdej migracji trzeba sprawdzić plik robots.txt natychmiast po uruchomieniu strony.

Robots.txt po migracji

Po migracji strony sprawdzenie robots.txt powinno znaleźć się wśród pierwszych czynności.

Należy zweryfikować:

• czy Disallow: / został usunięty,
• czy nie zablokowano nowych kategorii,
• czy ścieżki odpowiadają nowej strukturze,
• czy mapa XML wskazuje aktualną domenę,
• czy nie pozostawiono reguł środowiska stagingowego.

Przykład błędu:

User-agent: *
Disallow: /

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

Po wdrożeniu produkcyjnym obie linie mogą być problemem.

Więcej informacji znajdziesz w poradniku „Migracja strony a SEO – jak nie stracić pozycji i ruchu z Google?”.

Gdzie dokładnie musi znajdować się robots.txt?

Plik musi być dostępny w katalogu głównym hosta.

Poprawnie:

https://example.com/robots.txt

Nie:

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

Reguły robots.txt dotyczą konkretnego:

• protokołu,
• hosta,
• portu.

Google podkreśla, że zakres działania pliku ogranicza się właśnie do hosta, protokołu i portu, z których został udostępniony.

Czy robots.txt z HTTP działa dla HTTPS?

Nie należy tego zakładać.

Adres:

http://example.com/robots.txt

dotyczy hosta w wersji HTTP.

Strona:

https://example.com/

powinna mieć właściwy plik dostępny pod:

https://example.com/robots.txt

Podobnie:

www.example.com

i:

blog.example.com

to różne hosty.

Każdy może wymagać własnego robots.txt.

Robots.txt dla subdomeny

Jeżeli serwis ma:

https://www.example.com/

oraz:

https://blog.example.com/

każdy host może mieć własną konfigurację:

https://www.example.com/robots.txt

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

Reguła z głównej domeny nie kontroluje automatycznie wszystkich subdomen.

Jak dodać sitemap do robots.txt?

Można wykorzystać:

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

W przypadku indeksu sitemap:

Sitemap: https://www.example.com/sitemap_index.xml

Można podać kilka map:

Sitemap: https://www.example.com/sitemap-products.xml
Sitemap: https://www.example.com/sitemap-blog.xml

Google obsługuje pole Sitemap. Adres powinien być pełnym URL-em zawierającym protokół i host.

Szczegóły dotyczące tworzenia map znajdziesz w poradniku „Mapa strony XML – jak ją utworzyć i poprawnie zgłosić w Google?”.

Co warto blokować w robots.txt?

Nie istnieje uniwersalna lista dla każdej strony.

Można rozważyć ograniczenie crawlowania:

Wewnętrznych wyników wyszukiwania

Przykład:

/search/?q=buty

Wewnętrzna wyszukiwarka może generować ogromną liczbę adresów.

Przykładowa reguła:

User-agent: *
Disallow: /search/

Ostateczna konfiguracja zależy jednak od struktury URL-i.

Parametrów sortowania

Przykład:

/kategoria/?sort=price
/kategoria/?sort=new

Jeżeli nie mają wartości jako osobne strony, można ograniczyć ich crawlowanie.

Identyfikatorów sesji

Adresy typu:

/?sessionid=12345

mogą prowadzić do powstawania wielu wariantów tej samej strony.

Najlepszym rozwiązaniem jest często usunięcie parametrów z linkowania i struktury, a nie wyłącznie blokowanie ich.

Panelu użytkownika

Np.:

/konto/
/panel/
/checkout/

Robot nie musi zwykle odwiedzać tych sekcji.

Technicznych filtrów

W dużych sklepach filtry potrafią stworzyć niemal nieskończoną liczbę kombinacji.

Tu robots.txt może być jednym z elementów strategii zarządzania crawl budgetem.

Czego nie należy blokować?

Stron przeznaczonych do pozycjonowania

Jeśli chcesz, aby:

/oferta/seo/

pojawiła się w Google, nie blokuj:

Disallow: /oferta/

Kategorii produktów

Blokada:

Disallow: /kategoria/

może odciąć Google od bardzo ważnej części e-commerce.

Plików CSS i JavaScript potrzebnych do renderowania

Dawniej blokowanie katalogów takich jak:

/css/
/js/

było popularną praktyką.

Dziś może powodować problemy.

Google musi zobaczyć stronę w sposób zbliżony do użytkownika. Jeśli kluczowe CSS lub JavaScript są niedostępne, wyszukiwarka może mieć trudności z prawidłowym renderowaniem treści.

Przykładowo nie należy bez analizy blokować:

Disallow: /wp-content/

jeżeli znajdują się tam potrzebne zasoby motywu lub wtyczek.

Obrazów, jeśli chcesz widoczności w Google Images

Jeśli grafiki mają generować ruch z wyszukiwarki obrazów, nie powinny być odcinane od Googlebota.

Robots.txt w WordPressie

WordPress może posiadać wirtualny plik robots.txt generowany automatycznie.

Najczęściej jest dostępny pod:

https://domena.pl/robots.txt

Popularna konfiguracja może wyglądać np.:

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

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

Nie należy kopiować tego przykładu bez sprawdzenia konkretnego serwisu.

Wtyczki SEO i hosting mogą również umożliwiać edycję robots.txt.

Ustawienie „Zniechęcaj wyszukiwarki” w WordPressie

WordPress posiada ustawienie widoczności dla wyszukiwarek.

Jeżeli zostanie aktywowane, system może generować instrukcje ograniczające indeksowanie.

Przy przenoszeniu strony ze stagingu na produkcję zawsze trzeba sprawdzić:

• ustawienia WordPressa,
• robots.txt,
• meta robots,
• nagłówki HTTP.

Samo sprawdzenie jednego elementu nie wystarczy.

Robots.txt a crawl budget

W bardzo dużych serwisach robots.txt może pomóc ograniczyć crawlowanie niepotrzebnych przestrzeni URL.

Przykład:

User-agent: *
Disallow: /*?sort=
Disallow: /*?session=

może ograniczyć część parametrów.

Ale blokada robots.txt nie usuwa ich z architektury serwisu.

Jeżeli tysiące linków prowadzą do takich adresów, lepsze rozwiązanie może obejmować również:

• zmianę linkowania,
• uproszczenie filtrów,
• usunięcie parametrów,
• poprawę canonicali,
• odpowiednią strukturę kategorii.

Szczegóły znajdziesz w poradniku „Crawl budget – czym jest i jak poprawić indeksowanie dużego serwisu?”.

Czy blokowanie Googlebota poprawia crawl budget?

Tylko wtedy, gdy blokowane są rzeczywiście zbędne adresy.

Nie można poprawić indeksowania wartościowych treści przez przypadkowe ograniczenie dostępu do ważnych sekcji.

Przed dodaniem każdej reguły należy wiedzieć:

1. Jakie URL-e obejmuje?
2. Ile takich adresów istnieje?
3. Czy generują ruch?
4. Czy Google już je indeksuje?
5. Czy prowadzą do ważnych produktów?
6. Czy znajdują się na nich linki wewnętrzne?

Robots.txt a canonical

Google musi odwiedzić stronę, aby odczytać jej:

<link rel="canonical">

Jeżeli adres jest zablokowany w robots.txt, robot może nie zobaczyć canonicala.

Dlatego nie należy próbować rozwiązywać duplikacji w taki sposób:

Disallow: /duplikat/

oraz jednocześnie:

<link rel="canonical" href="/wersja-glowna/">

Jeżeli celem jest konsolidacja duplikatów, stosuje się właściwą kanonikalizację i odpowiednią strukturę.

Robots.txt a przekierowania

Adres zwracający 301 nie musi być dodatkowo blokowany w robots.txt.

Przy migracji Google powinno mieć możliwość odwiedzenia starego URL-a i zobaczenia:

301 → nowy URL

Jeżeli zablokujesz go przed crawlowaniem, możesz utrudnić Google przetworzenie zmiany.

Więcej informacji znajdziesz w poradniku „Przekierowania 301 i 302 – jak stosować je bez szkody dla SEO?”.

Robots.txt a bezpieczeństwo

Plik robots.txt nie zabezpiecza poufnych danych.

To bardzo ważne.

Nie należy używać:

Disallow: /tajne-dokumenty/

jako zabezpieczenia katalogu.

Robots.txt jest publicznie dostępny pod adresem:

/drobots.txt

i każdy może zobaczyć jego zawartość.

Jeżeli materiał jest poufny, zastosuj:

• logowanie,
• uwierzytelnianie,
• odpowiednie uprawnienia serwera,
• ograniczenie dostępu.

Google również zaleca ochronę hasłem, jeśli treść ma być niedostępna publicznie.

Jak sprawdzić robots.txt?

Najprościej otworzyć:

https://twojadomena.pl/robots.txt

i przeanalizować reguły.

Nie wystarczy jednak samo spojrzenie na plik.

Trzeba sprawdzić konkretne URL-e.

Google Search Console

Dla konkretnej strony użyj Narzędzia do sprawdzania adresów URL.

Może pokazać, czy crawlowanie jest dozwolone.

Google rekomenduje także korzystanie z raportów:

• Indeksowanie stron,
• Statystyki indeksowania.

Mogą one pomóc znaleźć strony, które są niedostępne dla Google, mimo że powinny znajdować się w wynikach.

Analiza crawlerem

Przy dużym serwisie warto przeskanować:

• wszystkie strony,
• status indeksowania,
• robots directives,
• zablokowane zasoby,
• błędy linkowania.

Crawler może pomóc znaleźć adresy oznaczone jako zablokowane przez robots.txt.

Najczęstsze błędy w robots.txt

1. Disallow: /

Najgroźniejszy klasyk:

User-agent: *
Disallow: /

Blokuje cały host dla pasujących robotów.

2. Blokada całej kategorii przez pomyłkę

Przykład:

Disallow: /produkty/

mimo że wszystkie ważne produkty znajdują się właśnie w tym katalogu.

3. Próba usuwania stron z Google przez robots.txt

Blokujesz stronę, ale jej URL nadal może występować w wynikach.

Do wykluczenia z indeksu użyj noindex.

4. Robots.txt + noindex

Google nie może odczytać instrukcji, ponieważ strona została wcześniej zablokowana.

5. Blokowanie CSS i JavaScript

Robot nie może prawidłowo zobaczyć strony.

6. Stara konfiguracja po migracji

Nowy serwis korzysta z reguł przygotowanych dla starej struktury.

7. Robots.txt ze środowiska testowego

Na produkcję trafia:

Disallow: /

8. Zablokowane przekierowania

Google nie może łatwo przetworzyć zmiany adresu.

9. Brak aktualnej sitemap

Robots.txt wskazuje mapę starej domeny:

Sitemap: https://stara-domena.pl/sitemap.xml

10. Nadmierna liczba reguł

Po kilku latach plik zawiera dziesiątki wyjątków, których nikt już nie rozumie.

Im bardziej skomplikowany plik, tym większe ryzyko błędu.

Przykład prostego robots.txt dla strony firmowej

User-agent: *
Disallow: /panel/
Disallow: /koszyk/

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

Jeżeli nie ma żadnych sekcji wymagających blokowania, konfiguracja może być jeszcze prostsza.

Przykład dla WordPressa

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

Sitemap: https://www.example.com/sitemap_index.xml

To jedynie przykład. Nie należy zakładać, że każda instalacja WordPressa potrzebuje identycznych reguł.

Przykład dla dużego sklepu

Hipotetyczna konfiguracja:

User-agent: *
Disallow: /konto/
Disallow: /koszyk/
Disallow: /checkout/
Disallow: /search/
Disallow: /*?sort=
Disallow: /*?session=

Sitemap: https://www.example.com/sitemap_index.xml

Przed wdrożeniem reguł parametrów należy dokładnie sprawdzić, jakie URL-e zostaną objęte blokadą.

Jak skonfigurować robots.txt krok po kroku?

Krok 1. Zbierz rodzaje URL-i

Przygotuj listę:

• stron ofertowych,
• kategorii,
• produktów,
• artykułów,
• filtrów,
• parametrów,
• paneli,
• wyszukiwania,
• koszyka,
• stron technicznych.

Krok 2. Podziel je na grupy

Dla każdej grupy odpowiedz:

• Czy powinna pojawiać się w Google?
• Czy Google musi ją odwiedzać?
• Czy prowadzi do ważnych stron?
• Czy jest duplikatem?
• Czy generuje tysiące adresów?

Krok 3. Zidentyfikuj obszary do blokady

Blokuj przede wszystkim te przestrzenie, których crawlowanie rzeczywiście nie ma wartości.

Krok 4. Przygotuj możliwie prostą konfigurację

Unikaj tworzenia dziesiątek reguł, jeśli wystarczą trzy.

Krok 5. Dodaj sitemap

Przykład:

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

Krok 6. Sprawdź ważne adresy

Zweryfikuj:

• stronę główną,
• główne usługi,
• kategorie,
• produkty,
• artykuły.

Krok 7. Przetestuj po wdrożeniu

Sprawdź ponownie po:

• migracji,
• zmianie CMS-a,
• zmianie filtrów,
• zmianie struktury URL-i.

Checklista robots.txt

Sprawdź, czy:

• plik znajduje się pod /robots.txt,
• zwraca poprawną treść,
• nie zawiera przypadkowego Disallow: /,
• ważne strony nie są blokowane,
• kategorie SEO są dostępne,
• produkty są dostępne,
• artykuły są dostępne,
• pliki CSS i JS potrzebne do renderowania nie są blokowane,
• reguły pasują do aktualnych adresów,
• wielkość liter w ścieżkach jest poprawna,
• sitemap wskazuje aktualny adres,
• nie próbujesz stosować noindex w robots.txt,
• strony z noindex mogą być crawlowane,
• przekierowania nie są niepotrzebnie blokowane,
• poufne materiały są zabezpieczone inaczej,
• Search Console nie pokazuje blokady ważnych URL-i,
• po migracji wykonano ponowną kontrolę.

Kiedy warto wykonać audyt robots.txt?

Szczegółowa analiza jest szczególnie potrzebna, gdy:

• ważne strony nagle zniknęły z Google,
• Search Console pokazuje adresy zablokowane przez robots.txt,
• serwis przeszedł migrację,
• zmienił się CMS,
• sklep generuje tysiące filtrów,
• Googlebot odwiedza wiele niepotrzebnych URL-i,
• plik zawiera dziesiątki skomplikowanych reguł,
• nikt nie wie, dlaczego konkretne dyrektywy zostały dodane.

W takich przypadkach warto przeanalizować nie tylko robots.txt, ale również indeksowanie, canonicale, mapy XML, linkowanie i strukturę adresów.

Specjaliści 4PEOPLE mogą zweryfikować techniczną dostępność serwisu dla Google, konfigurację robots.txt, indeksowanie oraz inne elementy wpływające na widoczność. Szczegóły znajdziesz w ofercie audytu SEO strony.

Jeżeli potrzebujesz również stałego rozwoju widoczności, sprawdź SEO i pozycjonowanie stron 4PEOPLE.

Robots.txt powinien być prosty i świadomie skonfigurowany

Dobry plik robots.txt nie musi być rozbudowany.

Jego zadaniem jest przede wszystkim kontrolowanie dostępu robotów do niepotrzebnych obszarów serwisu, a nie sterowanie rankingami czy usuwanie stron z indeksu.

Najważniejsze zasady to:

• nie blokuj stron, które mają być widoczne,
• nie używaj robots.txt zamiast noindex,
• nie blokuj strony z noindex, jeśli Google ma odczytać dyrektywę,
• uważaj na Disallow: /,
• nie blokuj potrzebnych plików CSS i JS,
• testuj reguły po każdej dużej zmianie,
• wskaż aktualną sitemap,
• w dużym serwisie blokuj tylko rzeczywiście zbędne przestrzenie.

Jedna błędna linia w robots.txt może mieć większy wpływ na SEO niż wiele godzin optymalizacji treści. Dlatego każdą zmianę warto dokładnie zweryfikować przed wdrożeniem na produkcji.

FAQ – robots.txt

Co to jest plik robots.txt?

Robots.txt to plik tekstowy zawierający reguły określające, do których adresów roboty wyszukiwarek mogą uzyskiwać dostęp.

Gdzie znajduje się robots.txt?

Powinien być dostępny w katalogu głównym hosta, np.:

https://domena.pl/robots.txt.

Czy robots.txt wpływa na indeksowanie?

Pośrednio. Może uniemożliwić Googlebotowi pobranie strony, ale nie jest właściwym narzędziem do usuwania URL-a z wyników. Zablokowany adres może w pewnych sytuacjach nadal pojawiać się w Google.

Jak usunąć stronę z Google?

Jeżeli strona ma pozostać publicznie dostępna, zastosuj noindex i pozwól Googlebotowi ją odwiedzić. Jeśli treść ma być prywatna, zabezpiecz ją dostępem.

Czy można dodać noindex do robots.txt?

Nie. Google nie obsługuje noindex umieszczonego w robots.txt jako sposobu wykluczania strony z wyników.

Co oznacza Disallow: /?

Blokuje crawlowanie całej witryny dla robotów objętych daną grupą. To jedna z najniebezpieczniejszych reguł, jeśli zostanie przypadkowo wdrożona na produkcji.

Czy pusty Disallow blokuje Google?

Nie. Puste:

Disallow:

nie blokuje żadnej ścieżki.

Czy robots.txt powinien zawierać sitemapę?

Nie jest to obowiązkowe, ale warto podać pełny adres sitemap lub sitemap index za pomocą dyrektywy Sitemap:.

Czy należy blokować wp-admin w WordPressie?

Zwykle katalog administracyjny nie wymaga crawlowania. Konkretna konfiguracja powinna jednak uwzględniać działanie danej instalacji i zasobów.

Czy można zablokować CSS i JavaScript?

Technicznie można, ale zazwyczaj nie należy blokować zasobów potrzebnych Google do renderowania i zrozumienia strony.

Czy robots.txt zabezpiecza poufne pliki?

Nie. Plik jest publiczny. Materiały poufne trzeba zabezpieczyć hasłem lub odpowiednimi mechanizmami serwera.

Czy robots.txt pomaga w crawl budget?

Może ograniczyć odwiedzanie niepotrzebnych przestrzeni URL w dużych serwisach. Nie zastępuje jednak poprawnej architektury, usuwania duplikatów i zarządzania parametrami.

Czy po migracji trzeba sprawdzić robots.txt?

Tak. To jeden z najważniejszych punktów kontroli. Szczególnie trzeba sprawdzić, czy nie pozostało Disallow: /, stara sitemap albo reguły środowiska testowego.

Jak sprawdzić, czy Google jest blokowane?

Sprawdź konkretny adres za pomocą Narzędzia do sprawdzania adresów URL w Google Search Console oraz przejrzyj raport Indeksowanie stron i Statystyki indeksowania.