Materiał porządkuje temat: googlebot traci czas na niewazne adresy po migracji strony.
Po migracji strony Googlebot powinien stosunkowo szybko zacząć crawlować nowe, kanoniczne adresy. Jeżeli zamiast tego crawl skupia się na filtrach, parametrach, starych URL-ach, adresach testowych albo przekierowaniach łańcuchowych, oznacza to, że część budżetu indeksowania jest wykorzystywana poza priorytetowymi zasobami. Problem, który często opisuje się jako: googlebot traci czas na niewazne adresy po migracji strony, jest szczególnie groźny w e-commerce, serwisach B2B z dużą bazą treści oraz stronach po zmianie CMS, struktury kategorii lub domeny.
Najważniejsze jest to, aby nie diagnozować tego wyłącznie na podstawie wrażeń z Google Search Console. Kluczowe są logi serwera, ponieważ pokazują, jakie adresy Googlebot faktycznie odwiedza, z jaką częstotliwością, z jakimi statusami HTTP i czy wraca do URL-i, które po migracji nie powinny już mieć znaczenia. Poniżej znajdziesz konkretną procedurę diagnostyczną i plan naprawczy dla zespołów odpowiedzialnych za SEO techniczne.
Jeżeli migracja była niedawno, pewien udział crawla na starych adresach jest normalny. Problem zaczyna się wtedy, gdy po kilku tygodniach Googlebot nadal masowo odwiedza stare URL-e, parametry, filtry lub błędne przekierowania, a nowe adresy biznesowo ważnych podstron są odwiedzane rzadko.
Spis treści
Jak rozpoznać, że Googlebot marnuje crawl po migracji?
Po poprawnej migracji Google powinien stopniowo przenosić uwagę z adresów historycznych na nowe, docelowe URL-e. Jeżeli w logach serwera widać odwrotną proporcję, na przykład tysiące wejść Googlebota na stare ścieżki produktowe, warianty filtrów lub parametry sortowania, to sygnał, że architektura po migracji nie jest dla robota wystarczająco jednoznaczna.
Objaw nie zawsze oznacza spadek pozycji od razu. Często najpierw widać wolniejszą indeksację nowych treści, opóźnione odświeżanie cen i dostępności produktów, wzrost liczby adresów „Odkryto – obecnie nie zindeksowano” oraz problemy z utrzymaniem widoczności po przeniesieniu serwisu.
Crawl skupia się na starych URL-ach
Googlebot nadal odwiedza adresy sprzed migracji, stare katalogi, stare slug-i produktów lub dawne ścieżki kategorii, mimo że powinny kierować do nowych odpowiedników.
Parametry generują nadmiarowe wejścia
W logach dominują adresy z parametrami typu sort, filter, color, size, utm, page, view, sessionid lub kombinacjami filtrów, które nie mają wartości indeksacyjnej.
Nowe strony są odwiedzane zbyt rzadko
Kluczowe landing page, kategorie, produkty lub artykuły po migracji mają niski udział w crawlu, mimo że powinny być priorytetem dla SEO i sprzedaży.
Rośnie liczba błędów i przekierowań
Googlebot często trafia na 3xx, 404, 410, 5xx, soft 404 lub łańcuchy przekierowań. To utrudnia szybkie zrozumienie nowej struktury serwisu.
Ten problem należy traktować jako element szerszego obszaru SEO technicznego. Same przekierowania 301 nie wystarczą, jeśli serwis wewnętrznie nadal podpowiada robotowi złe adresy albo generuje ogromną liczbę wariantów URL.
Najczęstsze przyczyny po migracji strony
Przyczyną rzadko jest jeden błąd. Zwykle to suma decyzji technicznych: niepełna mapa przekierowań, nieoczyszczone linkowanie wewnętrzne, automatyczne generowanie parametrów, błędne canonicale, stare mapy XML oraz blokady robots.txt wdrożone w złym momencie.
Niepełna mapa przekierowań
Stare adresy nie mają odpowiedników 1:1, przekierowują do strony głównej albo wpadają w 404. Googlebot wraca do nich wielokrotnie, próbując potwierdzić ich status.
Łańcuchy i pętle przekierowań
Adres A prowadzi do B, B do C, a czasem C znów do A lub do wersji z innym protokołem. Każdy dodatkowy skok zwiększa koszt crawlowania i spowalnia konsolidację sygnałów.
Stare linki wewnętrzne
Menu, breadcrumbs, moduły podobnych produktów, stopka lub treści blogowe nadal linkują do dawnych URL-i. Googlebot traktuje je jako ważne, bo są obecne w strukturze serwisu.
Stare lub mieszane sitemap XML
Mapa strony zawiera adresy sprzed migracji, URL-e z przekierowaniami, warianty niekanoniczne albo strony wyłączone z indeksacji. To wysyła sprzeczny sygnał do Google.
Filtry i facety bez kontroli indeksacji
Kategorie generują setki tysięcy kombinacji filtrów. Po migracji nowy CMS lub platforma e-commerce może udostępniać je robotom szerzej niż poprzednio.
Błędne canonicale
Canonical wskazuje na stary URL, wersję z parametrem, stronę z przekierowaniem albo adres niedostępny. W efekcie Googlebot dostaje niespójne instrukcje.
Parametry z kampanii i sesji
Adresy z UTM, identyfikatorami sesji, parametrami sortowania lub widoku są dostępne jako pełnoprawne URL-e i pojawiają się w linkowaniu, logach oraz czasem w indeksie.
Blokady robots.txt użyte zbyt wcześnie
Jeżeli stare adresy zostaną zablokowane, zanim Google zobaczy przekierowania lub status 410, robot może nie zaktualizować sygnałów prawidłowo.
Najczęstszy błąd po migracji: zespół blokuje parametry i stare katalogi w robots.txt, ale wcześniej nie pozwala Googlebotowi zobaczyć przekierowań 301, statusów 410 lub canonicali. Blokada ogranicza crawl, ale nie zawsze rozwiązuje problem indeksacji i konsolidacji sygnałów.
Diagnostyka krok po kroku w logach serwera
Logi serwera są podstawowym źródłem prawdy, bo pokazują realne zachowanie Googlebota, nie tylko próbkę danych. W analizie warto połączyć logi z danymi z Google Search Console, sitemap XML, crawlera technicznego oraz listą przekierowań przygotowaną do migracji.
Jeżeli nie masz pewności, jak interpretować pojęcia takie jak crawl budget, status HTTP, canonical czy robots.txt, pomocny będzie słownik pojęć SEO. W praktyce jednak sama znajomość definicji nie wystarczy – trzeba sprawdzić proporcje, segmenty URL-i i reakcję Googlebota w czasie.
- Zweryfikuj, że analizujesz prawdziwego GooglebotaNie opieraj się wyłącznie na user-agent. Sprawdź reverse DNS i potwierdź, że adres IP należy do Google. W logach często występują boty podszywające się pod Googlebota.
- Podziel adresy na segmentyOznacz nowe URL-e kanoniczne, stare URL-e, przekierowania, parametry, filtry, paginację, pliki statyczne, błędy 404, adresy z noindex i strony zablokowane.
- Policz udział crawla dla każdego segmentuSprawdź, jaki procent wejść Googlebota trafia do adresów biznesowo ważnych, a jaki do śmieciowych wariantów. Sama liczba wizyt nic nie mówi bez segmentacji.
- Porównaj statusy HTTPOddziel 200, 301, 302, 404, 410, 500 i soft 404. Po migracji część crawla na 301 jest normalna, ale nadmiar 3xx lub 4xx po kilku tygodniach wskazuje na problem.
- Sprawdź częstotliwość powrotów do tych samych URL-iJeżeli Googlebot stale wraca do tych samych starych adresów, prawdopodobnie nadal znajduje do nich linki, ma je w sitemapach lub otrzymuje niespójne sygnały.
- Zderz logi z mapą przekierowańKażdy często odwiedzany stary URL powinien mieć jasny status: 301 do właściwego odpowiednika, 410 dla trwale usuniętej treści albo 404 tylko wtedy, gdy jest to świadoma decyzja.
- Sprawdź źródła odkrywania adresówPrzejrzyj linkowanie wewnętrzne, sitemap XML, hreflangi, canonicale, feedy produktowe, linki zewnętrzne, kampanie płatne i moduły automatyczne w CMS.
- Monitoruj trend po wdrożeniachPo zmianach analizuj logi minimum przez kilka cykli crawlowania. Celem jest przesunięcie udziału crawla na nowe, wartościowe adresy, nie jednorazowy spadek liczby błędów.
Tabela diagnostyczna: co oznaczają konkretne wzorce w logach?
| Wzorzec w logach | Najbardziej prawdopodobna przyczyna | Co sprawdzić | Rekomendowane działanie |
|---|---|---|---|
| Dużo wejść Googlebota na stare URL-e z kodem 301 | Google nadal przetwarza migrację albo znajduje stare linki | Linkowanie wewnętrzne, sitemap XML, linki w treściach, breadcrumbs | Zamień linki wewnętrzne na docelowe URL-e i usuń stare adresy z map XML |
| Stare adresy zwracają 404 | Brak mapy przekierowań lub utracone odpowiedniki treści | Najczęściej odwiedzane 404, historyczny ruch SEO, linki zewnętrzne | Wdróż 301 do najbliższych odpowiedników lub 410 dla treści trwale usuniętych |
| Googlebot masowo crawluje parametry filtrów | Nieograniczone facety, sortowanie, parametry widoku | Reguły generowania URL-i, canonicale, robots.txt, linki follow do filtrów | Ogranicz linkowanie do filtrów, ustaw canonicale, użyj noindex lub blokad po ocenie ryzyka |
| Wysoki udział 302 po migracji | Tymczasowe przekierowania użyte zamiast trwałych | Konfigurację serwera, reguły CMS, CDN, przekierowania domen i protokołów | Zamień 302 na 301 tam, gdzie zmiana adresu jest trwała |
| Łańcuchy przekierowań | Nałożenie starych i nowych reguł migracyjnych | Ścieżkę od starego URL-a do finalnego adresu, wersje http, https, www, bez www | Skróć przekierowanie do jednego skoku z adresu źródłowego do finalnego |
| Nowe ważne URL-e prawie nie są odwiedzane | Słabe linkowanie wewnętrzne lub błędy w sitemapach | Głębokość kliknięć, obecność w mapie XML, status indexability, canonical | Wzmocnij linkowanie wewnętrzne i zgłoś czyste mapy XML z adresami 200 indexable |
| Crawl na adresach z noindex | Adresy nadal są linkowane lub obecne w mapach | Źródła linków, sitemap XML, szablony filtrów, paginacja | Usuń je z map, ogranicz linkowanie i zostaw noindex tylko tam, gdzie robot może go odczytać |
| Wiele odpowiedzi 5xx dla Googlebota | Problemy wydajnościowe po migracji, limity serwera, błędy aplikacji | Godziny występowania, obciążenie, cache, CDN, endpointy generujące błędy | Napraw stabilność serwera, cache i błędy aplikacyjne przed dalszą optymalizacją crawla |
Rekomendowane działania naprawcze
Naprawa powinna iść od sygnałów najważniejszych do pomocniczych. Najpierw trzeba zapewnić poprawne odpowiedzi serwera i spójne przekierowania, potem oczyścić linkowanie wewnętrzne, a dopiero później regulować crawling parametrów przez robots.txt, noindex lub inne mechanizmy.
1. Uporządkuj przekierowania po migracji
Każdy stary adres z historią ruchu, linkami lub widocznością powinien prowadzić do najbardziej zbliżonego nowego odpowiednika. Przekierowanie do strony głównej jest często gorsze niż brak przekierowania, bo rozmywa intencję i może zostać potraktowane jako soft 404.
- stosuj 301 dla trwałych zmian adresów,
- unikaj łańcuchów i pętli przekierowań,
- nie przekierowuj masowo wszystkich starych URL-i na stronę główną,
- dla usuniętych treści bez odpowiednika rozważ 410,
- kontroluj reguły na poziomie serwera, CMS, CDN i wtyczek.
2. Oczyść linkowanie wewnętrzne
Jeżeli strona po migracji nadal linkuje do starych URL-i, Googlebot będzie je traktował jako część aktualnej struktury. Dotyczy to nie tylko menu, ale także modułów automatycznych, okruszków, rekomendacji produktów, artykułów blogowych, linków w stopce i linków w danych strukturalnych.
Wewnętrzny link do starego adresu, który następnie przekierowuje, nie jest neutralny. Działa, ale zwiększa koszt crawlowania i spowalnia przeniesienie sygnałów na adres docelowy.
3. Wyczyść sitemap XML
Mapa XML po migracji powinna zawierać tylko adresy, które są kanoniczne, dostępne pod 200, indeksowalne i ważne dla serwisu. Nie powinna zawierać przekierowań, adresów z noindex, filtrów, parametrów, wariantów sortowania ani starych URL-i.
- podziel mapy XML według typów treści, na przykład produkty, kategorie, poradniki, landing page,
- usuń URL-e z parametrami i niekanoniczne warianty,
- sprawdź daty lastmod, aby nie były generowane sztucznie dla wszystkich adresów,
- porównaj sitemapę z logami i indeksem Google.
4. Opanuj filtry, facety i parametry
W e-commerce największym źródłem marnowania crawla są zwykle filtry. Po migracji nowy silnik sklepu może tworzyć indeksowalne kombinacje cech, na przykład kategoria plus marka plus kolor plus rozmiar plus sortowanie. Część takich stron może mieć potencjał SEO, ale większość jest duplikacją lub stronami o bardzo niskiej wartości.
Parametry techniczne
Parametry sesji, sortowania, widoku, paginacji technicznej i śledzenia kampanii zwykle nie powinny generować osobnych stron indeksowalnych.
Filtry z potencjałem SEO
Wybrane kombinacje, na przykład kategoria plus marka lub kategoria plus istotna cecha, mogą mieć wartość, jeśli mają popyt, unikalną treść i stabilny URL.
Kombinacje bez wartości
Wielopoziomowe filtry, puste wyniki, sortowania i losowe kolejności produktów powinny być ograniczone, aby nie konkurowały z kategoriami głównymi.
5. Ustaw spójne canonicale
Canonical nie jest dyrektywą bezwzględną, ale jest ważnym sygnałem. Po migracji musi wskazywać na nowy, finalny adres kanoniczny, który zwraca 200 i nie jest zablokowany. Canonical do URL-a z przekierowaniem, błędem 404 albo parametrem może utrwalić chaos.
6. Ostrożnie korzystaj z robots.txt i noindex
Robots.txt ogranicza crawling, ale nie usuwa automatycznie adresów z indeksu. Noindex może usunąć stronę z indeksu, ale Googlebot musi mieć możliwość ją odwiedzić i odczytać tag. Dlatego kolejność działań ma znaczenie.
- nie blokuj w robots.txt adresów, które najpierw muszą przekazać sygnały przez 301,
- nie używaj noindex na stronach, które jednocześnie blokujesz w robots.txt, jeśli oczekujesz usunięcia z indeksu,
- dla dużych grup parametrów ustal reguły po analizie logów, a nie intuicyjnie,
- testuj wpływ zmian na segmentach, zanim zastosujesz je globalnie.
7. Wzmocnij nowe adresy biznesowo ważne
Googlebot szybciej przenosi crawl na nowe URL-e, gdy są dobrze podlinkowane, obecne w sitemapach i technicznie jednoznaczne. Dotyczy to szczególnie kategorii z wysoką marżą, stron usług B2B, produktów strategicznych i treści wspierających sprzedaż.
Jeżeli migracja wpłynęła na widoczność lub sprzedaż, działania techniczne powinny być powiązane z planem pozycjonowania, a nie traktowane jako jednorazowe sprzątanie po wdrożeniu.
Lista kontrolna: co sprawdzić, gdy Googlebot traci czas na nieważne adresy?
- Czy logi serwera obejmują okres przed i po migracji?
- Czy zweryfikowano prawdziwego Googlebota, a nie tylko user-agent?
- Czy stare URL-e z ruchem i linkami mają mapę przekierowań 1:1?
- Czy przekierowania kończą się jednym skokiem na adresie 200?
- Czy w sitemapach XML są wyłącznie adresy kanoniczne i indeksowalne?
- Czy linkowanie wewnętrzne nie prowadzi do starych adresów?
- Czy canonicale wskazują finalne, nowe URL-e?
- Czy filtry i parametry są podzielone na wartościowe oraz techniczne?
- Czy robots.txt nie blokuje adresów, które powinny przekazać sygnały?
- Czy strony z noindex nie są jednocześnie zablokowane przed crawlem?
- Czy najważniejsze kategorie, produkty i landing page mają odpowiedni udział w crawlu?
- Czy błędy 404, 410, 5xx i soft 404 są analizowane według liczby wejść Googlebota?
- Czy po wdrożeniach mierzysz trend, a nie tylko stan z jednego dnia?
Priorytetem nie jest to, aby Googlebot odwiedzał mniej adresów za wszelką cenę. Priorytetem jest to, aby większa część crawla trafiała do adresów, które mogą generować widoczność, leady lub sprzedaż.
Kiedy warto skonsultować problem z ekspertem?
Warto skorzystać z konsultacji, gdy problem dotyczy dużego serwisu, migracja objęła zmianę domeny, CMS lub struktury URL, a w logach widać wysoki udział starych adresów, parametrów i błędów. Im większy serwis, tym bardziej ryzykowne są proste reguły typu „zablokuj wszystko w robots.txt” albo „przekieruj wszystko na kategorię główną”.
Ekspert od SEO technicznego pomoże rozdzielić działania pilne od kosmetycznych. W praktyce często okazuje się, że kilka typów URL-i odpowiada za większość strat crawla, a naprawa wymaga współpracy SEO, dewelopera, administratora serwera i osoby zarządzającej treścią.
Po migracji spadła widoczność
Jeżeli spadki dotyczą ważnych kategorii, produktów lub stron usługowych, trzeba połączyć analizę logów z analizą indeksacji, przekierowań i zmian w strukturze treści.
Serwis ma dużo filtrów lub parametrów
E-commerce i rozbudowane katalogi wymagają kontroli faceted navigation. Bez tego Googlebot może crawlowac miliony kombinacji bez realnej wartości SEO.
Nie wiadomo, co blokować
Decyzje o robots.txt, noindex, canonicalach i przekierowaniach powinny wynikać z danych, nie z ogólnych checklist. Błąd może utrudnić odzyskanie widoczności.
Zespół potrzebuje planu dla devów
Analiza powinna kończyć się konkretną listą wdrożeń: reguły przekierowań, poprawki szablonów, sitemap, canonicali, linkowania i obsługi parametrów.
Jeżeli potrzebujesz niezależnej diagnozy, możesz skorzystać z konsultacji SEO. W RankHero analizujemy logi, indeksację, strukturę URL, przekierowania i sygnały techniczne, a następnie przygotowujemy priorytety napraw dopasowane do wpływu na biznes.
Potrzebujesz analizy logów po migracji?
Sprawdzimy, gdzie Googlebot traci crawl, które adresy blokują konsolidację sygnałów i jakie zmiany wdrożyć w pierwszej kolejności.
FAQ
Czy to normalne, że Googlebot odwiedza stare adresy po migracji?
Tak, w pierwszych tygodniach po migracji jest to normalne. Google musi ponownie odwiedzić stare URL-e, zobaczyć przekierowania lub statusy usunięcia i zaktualizować swoje dane. Problem pojawia się, gdy po dłuższym czasie stare adresy nadal dominują w logach albo nowe strony są crawlowane zbyt rzadko.
Czy wystarczy ustawić przekierowania 301?
Nie zawsze. Przekierowania 301 są podstawą migracji, ale nie rozwiążą problemu, jeśli serwis nadal linkuje do starych URL-i, mapa XML zawiera błędne adresy, canonicale wskazują stare strony albo filtry generują ogromną liczbę parametrów.
Czy blokada w robots.txt rozwiąże problem parametrów?
Może ograniczyć crawling, ale nie zawsze rozwiąże problem indeksacji. Jeśli adresy z parametrami są już znane Google, sama blokada może utrudnić odczytanie canonicala lub noindex. Przed blokadą trzeba ustalić, czy adresy mają zostać przekierowane, usunięte z indeksu, czy tylko ograniczone w crawlu.
Jak długo trzeba monitorować logi po migracji?
Minimum kilka tygodni, a przy dużych serwisach nawet kilka miesięcy. Ważny jest trend: udział crawla na nowych adresach powinien rosnąć, a udział starych URL-i, parametrów i błędów powinien spadać.
Czy Google Search Console wystarczy do diagnozy?
Google Search Console jest pomocne, ale nie zastępuje logów serwera. GSC pokazuje wybrane raporty i próbki danych, natomiast logi pokazują rzeczywiste żądania Googlebota do serwera. Najlepsza diagnoza łączy oba źródła.
Co jest lepsze dla usuniętych stron: 404 czy 410?
Jeżeli treść została trwale usunięta i nie ma dobrego odpowiednika, 410 może być czytelniejszym sygnałem. Jeżeli istnieje adekwatna nowa strona, lepsze będzie przekierowanie 301. Nie warto przekierowywać wszystkiego automatycznie na stronę główną.
Czy crawl budget ma znaczenie tylko dla bardzo dużych stron?
Największe znaczenie ma w dużych serwisach, ale mniejsze strony też mogą odczuć skutki złej migracji. Jeśli Googlebot trafia głównie na błędy, przekierowania i duplikaty, nowe lub ważne adresy mogą być indeksowane wolniej.
Kto powinien zajmować się naprawą: SEO czy deweloper?
Najczęściej potrzebna jest współpraca. SEO techniczne powinno określić diagnozę, priorytety i oczekiwane reguły, a deweloper lub administrator wdraża zmiany w CMS, serwerze, CDN, sitemapach, szablonach i mechanizmach generowania URL-i.