Ten case opisuje serwis e-commerce średniej wielkości, który w ciągu siedmiu tygodni stracił z indeksu Google około 900 podstron. Nie było kary ręcznej, nie było migracji, nie zmieniał się szablon. Spadek zaczął się cicho, w raporcie indeksowania, a do ruchu dotarł dopiero po miesiącu. Publikujemy przebieg diagnozy i wdrożenia, bo wzorzec jest powtarzalny: winna okazała się architektura paginacji, filtrów i parametrów URL, a nie jakość treści.
Punkt wyjścia i pierwsze objawy
Serwis liczył około 4300 adresów w sitemapie: 2800 kart produktowych, 240 kategorii i podkategorii, reszta to wpisy blogowe i strony informacyjne. Ruch organiczny stabilnie rósł przez półtora roku, a widoczność opierała się głównie na kategoriach z długim ogonem typu „regały metalowe do garażu”.
Pierwszym sygnałem nie był spadek sesji, tylko wykres „Zaindeksowane” w Search Console. W ciągu trzech tygodni krzywa zjechała z 3950 do 3410 stron. Klient zgłosił się do nas dopiero wtedy, gdy zauważył, że przestały wchodzić nowe produkty, a kilkanaście kategorii zniknęło z wyników na frazy, które trzymały pozycje 4–8 przez ponad rok.
Objawy wyglądały mylnie. Zespół po stronie klienta założył, że to efekt aktualizacji algorytmu, i przez miesiąc przepisywał opisy kategorii. Widzieliśmy to już wcześniej przy okazji fali masowego wypadania stron z indeksu, którą opisywaliśmy w tekście o tym, jak Google zaostrza indeksowanie. Reakcja odruchowa to poprawianie treści. Problem jednak prawie zawsze siedzi wtedy w tym, ile adresów serwis wystawia crawlerowi i w jakiej proporcji są to adresy warte pobrania.
Diagnoza w raporcie indeksowania
Zaczęliśmy od eksportu pełnego raportu indeksowania i rozbicia go na statusy zamiast patrzenia na jedną sumaryczną liczbę. Rozkład wyglądał tak:
| Status | Przed spadkiem | Po 7 tygodniach |
|---|---|---|
| Zaindeksowane | 3950 | 3050 |
| Wykryto, obecnie niezaindeksowane | 410 | 2980 |
| Zeskanowano, obecnie niezaindeksowane | 620 | 1740 |
| Duplikat bez kanonicznego wybranego przez użytkownika | 180 | 1120 |
Kluczowa obserwacja: liczba adresów znanych Google urosła w tym samym czasie z około 5200 do ponad 8900. Serwis nie stracił stron. Serwis wygenerował 3700 nowych adresów o zerowej wartości, a Google przesunęło budżet z kart produktowych na te śmieci. To nie jest kara, to alokacja.
Drugim krokiem była analiza logów serwera z 30 dni. Udział Googlebota w żądaniach kierowanych na adresy z parametrami skoczył z 11 procent do 63 procent. Karty produktowe dostawały średnio jedno pobranie na 26 dni, wcześniej jedno na 6 dni. Metodykę takiego przeglądu opisujemy szerzej w poradniku o tym, jak prowadzić analizę logów pod crawlery AI, a te same zapytania działają dla klasycznego Googlebota.
Rola paginacji, filtrów i parametrów
Źródło było jedno: aktualizacja wtyczki filtrów, wdrożona osiem tygodni wcześniej przez zespół deweloperski bez konsultacji z kimkolwiek od SEO. Zmiana wyglądała niewinnie, bo dotyczyła tylko sposobu budowania adresów.
- Filtry przestały działać na fragmencie URL, a zaczęły generować pełne adresy typu
/regaly/?kolor=czarny&wysokosc=180, indeksowalne i linkowane z widocznego menu bocznego. - Każdy zestaw filtrów miał własną paginację, więc jedna kategoria z 12 filtrami produkowała kilkaset kombinacji stron od 2 do 9.
- Strony od 2 wzwyż dostawały kanoniczny wskazujący na siebie, a nie na wersję bazową ani na własny adres w spójnej formie. Sortowanie po cenie tworzyło kolejny wymiar tej samej macierzy.
- Sitemapa nadal zawierała wyłącznie 4300 adresów bazowych, więc rozjazd między tym, co zgłaszaliśmy, a tym, co crawler znajdował w kodzie, urósł do ponad dwukrotności.
Warto podkreślić mechanikę, bo bywa źle rozumiana. Google nie usunęło kart produktowych, bo uznało je za słabe. Google przestało je odwiedzać wystarczająco często, żeby utrzymać je w indeksie, a przy braku odświeżenia adres wypada. Wypadanie było więc skutkiem, nie przyczyną. Sygnałów jakościowych nikt nie zmieniał.
Dokumentacja Google jest w tej sprawie jednoznaczna i sami się na nią powoływaliśmy w raporcie dla klienta: strony z paginacją należy traktować jako osobne, samodzielne adresy, a nie sklejać kanonicznym do pierwszej strony listingu, natomiast warianty filtrów i sortowania powinny być z indeksowania wykluczone. Szczegóły są w materiałach o paginacji w e-commerce oraz o konsolidacji zduplikowanych adresów.
Wdrożone zmiany w kolejności
Kolejność miała znaczenie, bo część działań daje efekt dopiero wtedy, gdy poprzednie zdążą się przecrawlować. Rozłożyliśmy wdrożenie na cztery tygodnie.
- Tydzień 1: odcięcie źródła. Kombinacje filtrów wróciły na parametry obsługiwane po stronie klienta, bez zmiany adresu. Linki do wariantów filtrów w menu bocznym dostały atrybut
rel="nofollow"i przestały być renderowane w HTML jako<a href>dla wariantów wielokrotnych. - Tydzień 1: reguła w robots.txt. Zablokowaliśmy wzorce
*?kolor=,*?wysokosc=,*?sort=i pochodne. Świadomie zrobiliśmy to dopiero po usunięciu linków, żeby nie zamrozić 3700 adresów w stanie „zablokowane, ale znane”. - Tydzień 2: naprawa paginacji. Strony listingów od 2 wzwyż zachowały indeksowalność i kanoniczny na samych siebie, w jednej spójnej formie adresu. Usunęliśmy paginację z wariantów filtrowanych całkowicie.
- Tydzień 2: sitemapy w podziale. Rozbiliśmy jedną sitemapę na cztery: produkty, kategorie, listingi paginowane, blog. Dzięki temu raport indeksowania dało się czytać per segment i mierzyć powrót osobno dla każdego z nich.
- Tydzień 3: linkowanie wewnętrzne do produktów. Karty, które wypadły najwcześniej, dostały linki z opisów kategorii i z pięciu artykułów poradnikowych. To był jedyny element treściowy w całym wdrożeniu.
- Tydzień 4: zgłoszenia ręczne. Zgłosiliśmy przez inspekcję adresu 40 reprezentatywnych kart z każdego segmentu, żeby mieć próbkę kontrolną z datą pobrania.
Nie ruszaliśmy tytułów, opisów meta ani struktury nagłówków. To była decyzja świadoma: przy tak wyraźnej hipotezie technicznej równoległa zmiana treści uniemożliwiłaby przypisanie efektu. Pełną listę punktów kontrolnych, z której korzystaliśmy przy tej diagnozie, spisaliśmy w opracowaniu Technical SEO audit 2026.
Tempo powrotu stron do indeksu
Powrót nie był liniowy i to jest najważniejsza rzecz do zapamiętania z tego case’u.
| Moment | Zaindeksowane | Adresy znane Google |
|---|---|---|
| Start wdrożenia | 3050 | 8900 |
| +14 dni | 3080 | 8100 |
| +30 dni | 3390 | 6400 |
| +60 dni | 3720 | 5100 |
| +90 dni | 3880 | 4700 |
Przez pierwsze dwa tygodnie nie działo się nic. Liczba zaindeksowanych stała w miejscu, spadała za to liczba adresów znanych, czyli crawler przede wszystkim sprzątał. Realny przyrost ruszył dopiero, gdy pula śmieciowych adresów zeszła poniżej mniej więcej 7000, a więc gdy budżet miał gdzie wrócić. Do 90 dnia odzyskaliśmy 830 z 900 utraconych podstron, czyli 92 procent. Reszta to karty produktów wycofanych ze sprzedaży, których i tak nie chcieliśmy przywracać.
Bardzo podobną dynamikę widzieliśmy przy innym projekcie z tej samej półki, opisanym w case o tym, jak wyglądała indeksacja 12 tysięcy SKU. Tam także pierwsze 3 tygodnie po naprawie wyglądały jak brak reakcji, a klient naciskał na kolejne zmiany.
Efekt na ruch po 3 miesiącach
Ruch organiczny wrócił wolniej niż indeks, co jest normalne: strona najpierw musi zostać pobrana, potem odzyskać pozycję, a dopiero potem wygenerować kliknięcia. Po 90 dniach kliknięcia organiczne były 6 procent powyżej poziomu sprzed awarii, wyświetlenia 4 procent poniżej, a średnia pozycja poprawiła się o 1,8 miejsca w segmencie kart produktowych. Kategorie odzyskały pozycje 4–8 na frazach, które utraciły, choć trzy najbardziej konkurencyjne wróciły dopiero na przełomie czwartego miesiąca.
Nadwyżka nad punktem wyjścia nie wzięła się z magii, tylko z tego, że sprzątanie parametrów rozwiązało przy okazji starszy problem kanibalizacji: warianty filtrów konkurowały wcześniej z kategoriami bazowymi na te same frazy, tylko w mniejszej skali i nikt tego nie łapał.
Czego zrobilibyśmy inaczej
Trzy rzeczy z perspektywy czasu wyglądają na błędy po naszej stronie.
Po pierwsze, blokada w robots.txt weszła zbyt szybko po odcięciu linków. Odstęp jednego tygodnia był za krótki, część adresów zawisła w stanie zablokowanych na dodatkowe kilka tygodni. Dziś odczekalibyśmy pełne 21 dni albo w ogóle zrezygnowali z robots.txt na rzecz samego noindex na wariantach filtrowanych.
Po drugie, za późno rozbiliśmy sitemapy. Gdyby podział na segmenty istniał od początku, spadek dałoby się zauważyć w drugim tygodniu, a nie w siódmym, bo krzywa produktów odjechałaby od krzywej bloga.
Po trzecie, zabrakło alertu. Serwis nie miał żadnego monitoringu liczby adresów znanych Google, a to jedyna metryka, która w tym przypadku ostrzegała z wyprzedzeniem. Cotygodniowy eksport z API Search Console i prosty próg zmiany o 10 procent wystarczyłby, żeby skrócić cały incydent z siedmiu tygodni do jednego.
FAQ
Czy paginacja sama w sobie szkodzi indeksowaniu?
Nie. Szkodzi paginacja pomnożona przez filtry i sortowanie, bo z jednego listingu robi setki kombinacji. Zwykła paginacja kategorii, z kanonicznym na samą siebie i spójnym adresem, jest bezpieczna i Google zaleca traktowanie takich stron jako samodzielnych.
Ile trwa powrót stron do indeksu po naprawie?
W tym projekcie 92 procent adresów wróciło w 90 dni, przy czym pierwsze 14 dni nie przyniosło żadnego przyrostu. Tempo zależy głównie od tego, jak szybko maleje pula bezwartościowych adresów, bo dopiero wtedy budżet crawlowania wraca do stron, na których nam zależy.
Czy zgłaszanie adresów ręcznie w Search Console przyspiesza proces?
Przy takiej skali nie. 40 zgłoszeń przy 900 utraconych podstronach to próbka kontrolna, a nie narzędzie naprawcze. Ręczna inspekcja jest przydatna do potwierdzenia, że strona po zmianach jest już pobierana i uznawana za kanoniczną, ale nie zastąpi naprawy architektury.
Blokować parametry w robots.txt czy dawać noindex?
Jeżeli adresy są już znane Google, lepiej działa noindex, bo pozwala crawlerowi wejść, odczytać dyrektywę i usunąć adres. Blokada w robots.txt uniemożliwia odczytanie czegokolwiek, więc adres potrafi wisieć w raporcie miesiącami. Robots.txt ma sens dopiero jako zabezpieczenie na przyszłość, po posprzątaniu.
Po czym poznać, że to problem budżetu crawlowania, a nie jakości treści?
Po dwóch liczbach naraz: rośnie liczba adresów znanych Google, a spada liczba zaindeksowanych. Jeżeli treść byłaby przyczyną, pula znanych adresów zostałaby mniej więcej stała. Potwierdzenie daje analiza logów: sprawdź, jaki procent żądań Googlebota trafia na adresy z parametrami.