Materiał porządkuje temat: robots txt blokuje wazne sekcje strony po migracji strony.
Po migracji strony jednym z częstszych problemów technicznego SEO jest sytuacja, w której Google przestaje crawlowac kategorie, podstrony usług, wpisy blogowe albo inne sekcje odpowiedzialne za widoczność i sprzedaż. W raportach Google Search Console pojawiają się komunikaty o zablokowaniu przez plik robots.txt, liczba zaindeksowanych adresów spada, a nowe treści nie wchodzą do indeksu mimo poprawnego działania strony dla użytkowników.
Problem „robots txt blokuje wazne sekcje strony po migracji strony” zwykle nie wynika z jednej awarii, ale z połączenia zmian środowiska, błędnie przeniesionych reguł, nowych ścieżek URL i braku kontroli po wdrożeniu. Poniżej znajdziesz praktyczną diagnostykę, typowe przyczyny i działania naprawcze dla właścicieli firm, marketerów B2B, e-commerce managerów i osób odpowiedzialnych za stronę.
Najważniejsza zasada: robots.txt nie usuwa strony z indeksu sam w sobie. Blokuje lub ogranicza crawling. Jeśli Google nie może crawlowac ważnych adresów, może nie zobaczyć treści, linków wewnętrznych, canonicali, zmian po migracji i przekierowań. W praktyce może to doprowadzić do utraty widoczności.
Spis treści
Objawy problemu po migracji
Najczęstszy objaw jest prosty: Google nie crawluje kategorii, usług lub wpisów, które wcześniej były widoczne w wynikach wyszukiwania albo które powinny generować ruch po migracji. Strona działa poprawnie w przeglądarce, ale robot Google nie ma dostępu do części adresów lub zasobów potrzebnych do pełnej oceny witryny.
Spadek liczby crawlowanych adresów
W Google Search Console maleje liczba adresów wykrywanych i crawlowanych przez Google. Nowe adresy pozostają długo poza indeksem, mimo że są podlinkowane w menu lub mapie strony.
Komunikat o blokadzie przez robots.txt
W narzędziu kontroli adresu URL pojawia się informacja, że indeksowanie albo pobranie strony jest ograniczone przez plik robots.txt. Problem może dotyczyć całych katalogów, na przykład /blog/, /category/ lub /oferta/.
Brak widoczności nowych sekcji
Po migracji uruchomiono nowe kategorie, landing page lub opisy usług, ale Google nie pokazuje ich w wynikach. Czasem widoczne są tylko pojedyncze adresy, a reszta sekcji pozostaje niewidoczna.
Nielogiczne dane w sitemapie
Mapa XML zawiera adresy, które robots.txt blokuje. To sygnał niespójności technicznej: strona jednocześnie zgłasza adresy do Google i zabrania robotowi ich odwiedzać.
Jeśli problem pojawił się bezpośrednio po migracji, rebrandingu, zmianie CMS, przejściu na nowy szablon, wdrożeniu wersji headless lub przeniesieniu sklepu na inną platformę, plik robots.txt powinien być jednym z pierwszych elementów audytu technicznego. Więcej podobnych scenariuszy opisujemy w obszarze problemów SEO technicznego.
Dlaczego blokada robots.txt jest groźna dla SEO
Plik robots.txt działa na poziomie dostępu robota do określonych ścieżek. Jeśli dyrektywa Disallow obejmuje ważną sekcję, Googlebot może nie pobrać jej treści. Dla biznesu oznacza to problem nie tylko techniczny, ale też sprzedażowy: robot nie widzi stron, które mają pozyskiwać zapytania, leady albo transakcje.
W praktyce blokada może zatrzymać ocenę nowych treści, opóźnić indeksację, uniemożliwić rozpoznanie przekierowań po migracji i ograniczyć przepływ linkowania wewnętrznego. W e-commerce szczególnie groźne są blokady kategorii, filtrów o wartości SEO, kart produktów i treści poradnikowych. W B2B dotyczy to najczęściej usług, stron branżowych, case studies i artykułów wspierających proces zakupowy.
Uwaga: jeżeli adres jest zablokowany w robots.txt, Google może nadal znać jego URL z linków zewnętrznych lub sitemap, ale nie musi widzieć zawartości strony. To może prowadzić do sytuacji, w której w indeksie pojawiają się szczątkowe informacje albo adres nie rankuje mimo istnienia wartościowej treści.
Najczęstsze przyczyny blokady ważnych sekcji po migracji
Po migracji plik robots.txt często jest traktowany jako mały element techniczny, który „po prostu trzeba skopiować”. To błąd. Reguły z poprzedniej wersji serwisu mogą nie pasować do nowej struktury adresów, a ustawienia środowiska testowego mogą przez przypadek trafić na produkcję.
Przeniesienie blokady ze środowiska testowego
Najczęstszy przypadek to pozostawienie reguły Disallow: / po uruchomieniu produkcji. Taka dyrektywa blokuje crawling całej witryny dla robotów, jeśli nie została ograniczona do środowiska staging.
Stare reguły niepasujące do nowych adresów
Po migracji zmieniły się ścieżki URL, na przykład /produkty/ stało się /sklep/ albo /blog/ stało się /poradnik/. Stara reguła mogła przypadkowo objąć nową, wartościową sekcję.
Błędne dyrektywy dla katalogów CMS
W WordPressie lub innym CMS blokuje się czasem katalogi techniczne, ale zbyt szeroka reguła może objąć zasoby potrzebne do renderowania albo strony generowane dynamicznie. W takich przypadkach warto przeanalizować też optymalizację WordPress.
Automatyczne generowanie robots.txt przez wtyczkę
Wtyczka SEO, moduł cache, platforma sklepowa albo konfiguracja serwera mogą generować robots.txt dynamicznie. Po migracji plik widoczny pod adresem /robots.txt może nie być tym, który zespół techniczny edytował ręcznie.
Niespójność między domeną, protokołem i subdomeną
Osobny robots.txt działa dla konkretnego hosta. Wersja https, http, www, bez www lub subdomena mogą zwracać różne pliki i różne reguły. Po migracji to częsty powód błędnej diagnozy.
Blokada zasobów potrzebnych do renderowania
Jeśli robots.txt blokuje pliki CSS, JavaScript, endpointy API albo katalogi zasobów, Google może nie zobaczyć strony tak jak użytkownik. To szczególnie istotne przy migracjach na nowoczesne frameworki i strony z dużą ilością renderowania po stronie klienta.
Diagnostyka krok po kroku
Diagnostykę zacznij od sprawdzenia, czy problem rzeczywiście wynika z robots.txt, a nie z tagu noindex, canonicala, błędnych przekierowań, blokady serwera lub błędów 4xx/5xx. Te elementy często występują jednocześnie po migracji, dlatego sama informacja „zablokowane przez robots.txt” nie powinna kończyć analizy.
- Sprawdź aktualny plik /robots.txtWejdź pod adres domena.pl/robots.txt dla właściwej wersji hosta, czyli tej, która jest indeksowana. Porównaj wersję www i bez www oraz http i https, jeśli przekierowania nie są jeszcze pewne.
- Znajdź dyrektywy dotyczące problematycznych sekcjiSzukaj reguł Disallow obejmujących katalogi kategorii, usług, bloga, produktów, tagów, filtrów i zasobów. Zwróć uwagę na dopasowania częściowe, które mogą blokować więcej adresów niż zakładano.
- Przetestuj konkretne adresy w Google Search ConsoleUżyj narzędzia kontroli adresu URL dla przykładowych kategorii, usług i wpisów. Sprawdź, czy Google może pobrać adres i jaki jest powód ewentualnego braku indeksacji.
- Porównaj robots.txt z mapą XMLJeśli sitemap zgłasza adresy, które są blokowane przez robots.txt, priorytetem jest usunięcie tej niespójności. Mapa strony nie powinna promować adresów niedostępnych dla robota.
- Sprawdź logi serwera lub dane crawl budgetJeśli masz dostęp do logów, zobacz, czy Googlebot próbuje odwiedzać problematyczne adresy i czy otrzymuje blokadę, przekierowanie lub błąd. To pozwala odróżnić blokadę robots.txt od problemów z dostępnością.
- Zweryfikuj ustawienia CMS i wtyczekW WordPressie sprawdź ustawienie widoczności dla wyszukiwarek, konfigurację wtyczki SEO i ewentualne reguły generowane przez hosting lub plugin. W sklepach sprawdź moduły indeksacji, filtry i konfigurację katalogów.
- Przetestuj renderowanie stronyJeśli robots.txt blokuje zasoby, sprawdź, czy Google widzi właściwą treść po renderowaniu. Dotyczy to zwłaszcza stron, które ładują listingi, ceny, produkty lub formularze przez JavaScript.
Praktyczna wskazówka: nie diagnozuj wyłącznie strony głównej. Wybierz reprezentatywne próbki: jedną kategorię, jedną podstronę usługi, jeden wpis blogowy, jedną stronę produktu, jedną stronę paginacji i jeden adres z parametrami. Migracje rzadko psują wszystko w taki sam sposób.
Tabela diagnostyczna
| Co sprawdzić | Jak rozpoznać problem | Co zrobić |
|---|---|---|
| Reguła Disallow: / | Cała witryna lub większość adresów jest zablokowana dla robotów. Google Search Console pokazuje ograniczenie dostępu. | Usuń blokadę z produkcji. Zostaw ją tylko na środowiskach testowych zabezpieczonych hasłem lub ograniczonych dostępem. |
| Blokada katalogu z kategoriami | Adresy typu /kategoria/, /category/, /produkty/ lub /sklep/ nie są crawlowane mimo obecności w sitemapie. | Zmień reguły tak, aby blokowały tylko niepotrzebne parametry lub sekcje techniczne, a nie główne landing page SEO. |
| Blokada katalogu usług | Podstrony ofertowe nie pojawiają się w indeksie, a narzędzie kontroli URL wskazuje robots.txt jako ograniczenie. | Odblokuj katalog usług i sprawdź, czy strony mają poprawny status 200, canonical do siebie oraz linkowanie wewnętrzne. |
| Blokada wpisów blogowych | Nowe artykuły nie są pobierane przez Google, a starsze tracą widoczność po zmianie struktury /blog/ lub /poradnik/. | Usuń zbyt szeroką regułę i zweryfikuj mapę XML dla wpisów. Następnie wyślij przykładowe adresy do ponownego sprawdzenia. |
| Różne robots.txt dla hostów | Inny plik pojawia się na www, bez www, http lub https. Testowany adres nie jest tym, który widzi Google. | Ujednolić przekierowania i konfigurację hostów. Sprawdzić robots.txt na wersji kanonicznej domeny. |
| Blokada zasobów JS/CSS | Google widzi niepełną stronę, puste listingi, brak menu, brak treści albo inny układ niż użytkownik. | Odblokuj zasoby potrzebne do renderowania. Nie blokuj plików, które wpływają na widoczność treści i linków. |
| Niespójność sitemap i robots.txt | Sitemap zawiera adresy zablokowane w robots.txt. Google otrzymuje sprzeczne sygnały. | Usuń z sitemap adresy, które faktycznie nie mają być indeksowane, albo odblokuj adresy, które są ważne biznesowo i SEO. |
Jak naprawić robots.txt po migracji
Naprawa nie polega na mechanicznym usunięciu wszystkich reguł. Dobrze skonfigurowany robots.txt powinien chronić crawl budget przed sekcjami bez wartości, ale nie może blokować stron, które odpowiadają za widoczność, sprzedaż i generowanie leadów. Najpierw ustal, które sekcje są strategiczne, a dopiero potem zmieniaj reguły.
1. Oddziel sekcje techniczne od sekcji biznesowych
Ważne sekcje to najczęściej kategorie, podkategorie, usługi, wpisy poradnikowe, case studies, landing page kampanii, produkty oraz treści evergreen. Sekcje techniczne to koszyk, konto użytkownika, wyniki wyszukiwania wewnętrznego, panele logowania, niektóre parametry filtrowania, duplikaty i adresy generowane automatycznie.
- Nie blokuj kategorii, które mają potencjał SEO i są częścią ścieżki zakupowej.
- Nie blokuj podstron usług, jeśli mają rankować na frazy ofertowe.
- Nie blokuj wpisów blogowych, jeśli budują widoczność informacyjną i wspierają lead generation.
- Nie blokuj zasobów, które Google musi pobrać, aby zobaczyć treść i linki.
2. Popraw reguły zbyt szerokie
Najbardziej ryzykowne są reguły, które obejmują całe katalogi lub ciągi znaków występujące w nowych adresach. Po migracji nazwy katalogów mogły się zmienić, a reguła utworzona dla starej platformy może przypadkowo blokować nową architekturę informacji.
Przykład: jeśli po migracji wartościowe poradniki znajdują się w katalogu /blog/, reguła blokująca /blog/ zatrzyma crawling całej sekcji contentowej. Jeśli intencją było zablokowanie tylko archiwów lub parametrów, reguła powinna być znacznie bardziej precyzyjna.
3. Sprawdź zgodność z canonicalami i noindex
Robots.txt, canonical i meta robots powinny pracować razem. Jeśli strona jest zablokowana w robots.txt, Google może nie zobaczyć tagu canonical ani noindex umieszczonego w kodzie HTML. Dlatego nie używaj robots.txt jako zamiennika dla noindex tam, gdzie robot musi wejść na stronę, aby odczytać dyrektywę.
Jeżeli nie masz pewności, czym różnią się poszczególne dyrektywy i jak wpływają na indeksowanie, pomocny będzie słownik pojęć SEO i marketingu. Przy migracjach te różnice mają duże znaczenie, bo niewłaściwy sygnał potrafi zablokować całą sekcję na wiele tygodni.
4. Ujednolić wersje domeny i środowiska
Każdy host może mieć osobny plik robots.txt. Jeśli po migracji działają równolegle wersje www i bez www, subdomeny, środowisko testowe, stary serwer lub tymczasowe adresy techniczne, łatwo sprawdzić nie ten plik, który faktycznie widzi Google. Ustal wersję kanoniczną domeny, wymuś przekierowania i testuj robots.txt tylko dla właściwego hosta produkcyjnego.
5. Zgłoś zmiany i monitoruj reakcję Google
Po poprawieniu robots.txt sprawdź przykładowe adresy w Google Search Console. Następnie poproś o ponowne sprawdzenie wybranych adresów, wyślij aktualną mapę XML i obserwuj raport indeksowania. W większych serwisach zmiana nie musi przynieść efektu natychmiast, ale w danych powinny pojawić się sygnały ponownego crawlowania.
Lista kontrolna po naprawie
- Plik /robots.txt na wersji produkcyjnej nie zawiera przypadkowej reguły Disallow: /.
- Ważne kategorie, usługi, wpisy i produkty są dostępne dla Googlebota.
- Sitemap XML nie zawiera adresów zablokowanych przez robots.txt.
- Wersje www, bez www, http i https prowadzą do właściwej wersji kanonicznej.
- Środowisko testowe jest zablokowane inaczej niż produkcja, najlepiej przez autoryzację, nie przez kopiowanie ustawień na żywą domenę.
- Adresy strategiczne zwracają status 200 lub poprawne przekierowanie 301 po migracji.
- Canonicale wskazują właściwe adresy docelowe i mogą być odczytane przez robota.
- Zasoby CSS, JavaScript i kluczowe endpointy niezbędne do renderowania nie są blokowane.
- Google Search Console pokazuje poprawiony status dla reprezentatywnych adresów.
- Po zmianach monitorowane są logi, indeksacja i widoczność najważniejszych sekcji.
Rekomendacja dla B2B i e-commerce: po każdej migracji warto przygotować listę krytycznych adresów SEO. Powinna obejmować strony generujące przychody, leady, ruch organiczny i linki. Te adresy należy ręcznie przetestować przed uruchomieniem oraz po wdrożeniu.
Kiedy warto skonsultować problem z ekspertem?
Samodzielna korekta robots.txt jest możliwa, jeśli problem dotyczy pojedynczej, oczywistej reguły. Warto jednak skonsultować temat, gdy migracja objęła większą architekturę strony, sklep internetowy, wiele wersji językowych, zmianę domeny, zmianę platformy albo wdrożenie nowego frontendu. W takich przypadkach robots.txt jest tylko jednym z elementów układanki.
Spadła widoczność po migracji
Jeśli strona straciła pozycje i ruch, trzeba sprawdzić nie tylko robots.txt, ale też przekierowania, canonicale, mapy XML, statusy HTTP, linkowanie wewnętrzne i zmiany treści.
Google nie crawluje sekcji sprzedażowych
Brak crawlowania kategorii, usług lub produktów to problem bezpośrednio wpływający na przychody. Wymaga szybkiej diagnozy i priorytetyzacji adresów o największym znaczeniu biznesowym.
Masz wiele reguł i wyjątków
Rozbudowany robots.txt z wieloma regułami dla botów, parametrów i katalogów łatwo błędnie zinterpretować. Audyt pozwala ograniczyć ryzyko kolejnej blokady.
Zmiany wprowadza kilka zespołów
Przy pracy developerów, agencji, administratora hostingu i zespołu marketingu potrzebna jest jedna techniczna lista priorytetów oraz jasna odpowiedzialność za wdrożenie.
W RankHero analizujemy problemy z crawlowaniem, indeksacją i migracjami w kontekście wpływu na widoczność oraz sprzedaż. Jeśli chcesz sprawdzić, czy robots.txt blokuje ważne sekcje lub czy problem leży głębiej, skorzystaj z konsultacji SEO.
Potrzebujesz szybkiej diagnozy po migracji?
Sprawdzimy robots.txt, indeksację, mapy XML, przekierowania, canonicale i dostępność najważniejszych sekcji. Otrzymasz konkretne rekomendacje, co poprawić w pierwszej kolejności, aby ograniczyć straty widoczności.
FAQ
Czy robots.txt może całkowicie usunąć stronę z Google?
Sam plik robots.txt nie usuwa strony z indeksu w taki sposób jak dyrektywa noindex. Może jednak zablokować Googlebotowi dostęp do treści, przez co Google nie będzie mógł poprawnie ocenić strony, zobaczyć zmian po migracji ani odczytać tagów w kodzie. Efektem może być brak indeksacji nowych adresów lub spadek widoczności.
Dlaczego Google zna adres, skoro robots.txt go blokuje?
Google może poznać adres z linków wewnętrznych, linków zewnętrznych, mapy XML lub wcześniejszego indeksu. Jeśli jednak robots.txt blokuje crawling, robot może nie pobrać zawartości strony. To tłumaczy sytuację, w której URL jest wykryty, ale nie ma pełnych danych o jego treści.
Czy po migracji wystarczy skopiować stary robots.txt?
Nie. Stary plik może zawierać reguły dopasowane do poprzedniego CMS, starej struktury adresów lub dawnego sposobu obsługi filtrów. Po migracji trzeba porównać reguły z nową architekturą strony i przetestować najważniejsze typy adresów.
Jak szybko Google zauważy poprawiony robots.txt?
To zależy od wielkości i popularności serwisu, częstotliwości crawlowania oraz skali problemu. W Google Search Console można przetestować konkretne adresy i poprosić o ponowne sprawdzenie. W większych serwisach pełna stabilizacja może wymagać monitorowania przez kilka dni lub tygodni.
Czy lepiej blokować niepotrzebne strony przez robots.txt czy noindex?
To zależy od celu. Jeśli robot ma nie odwiedzać sekcji technicznej, robots.txt może być właściwy. Jeśli Google ma wejść na stronę i odczytać dyrektywę niewłączania do indeksu, potrzebny jest noindex dostępny w kodzie strony. Nie należy blokować przez robots.txt stron, na których Google ma odczytać noindex lub canonical.
Czy robots.txt wpływa na crawl budget?
Tak, może wpływać na sposób wykorzystywania crawlowania, szczególnie w dużych sklepach i serwisach z wieloma parametrami. Dobrze użyty pomaga ograniczyć dostęp do sekcji bez wartości. Źle użyty blokuje ważne kategorie, usługi i treści, przez co oszczędność crawl budgetu zamienia się w utratę widoczności.
Co zrobić, jeśli nie wiem, która reguła blokuje adres?
Najpierw przetestuj konkretny URL w Google Search Console i porównaj go z aktualnym plikiem /robots.txt na właściwym hoście. Następnie sprawdź dopasowanie katalogów i znaków w regułach Disallow. Jeśli plik jest rozbudowany lub dotyczy kilku wersji domeny, bezpieczniej wykonać audyt techniczny przed wdrożeniem zmian.