Pozycje i widoczność nagle lecą w dół, a Ty nie wiesz, co się dzieje ani jak temu zaradzić? Ja zawsze działam według konkretnego schematu. Najpierw ustalam, co właściwie spadło, później szukam momentu, w którym zaczęło dziać się coś niepokojącego, a dopiero na końcu zastanawiam się, co z tym zrobić. Pokazuję, jak u mnie wygląda taka akcja ratunkowa.
Spis treści:
- Zanim przejdę dalej – szybki kontakt z klientem
- Pierwszy przystanek: Google Search Console
- A może roboty Google w ogóle nie mogą wejść na stronę?
- Jak próbuję zaradzić spadkom i odzyskać pozycje?
- Aktualizacja adresów docelowych 301
- Weryfikacja tagów kanonicznych – canonicale też potrafią namieszać
- Audyt linkowania wewnętrznego
- Content na stronie i brainstorming z zespołem
- Przywracanie usuniętych ofert
- Thin content – gdy serwis ma za dużo bezwartościowych podstron
- Kategoria bez produktów i popytu niewiele daje
- Title i H1 też mogą wymagać uporządkowania
- Kiedy strona nagle leci w dół w Google – podsumowanie
- Podsumowanie w punktach
Zanim przejdę dalej – szybki kontakt z klientem
Spadek widoczności, zwłaszcza gdy jest nagły, ZAWSZE podnosi ciśnienie. I nikt mnie nie przekona, że jest inaczej.
Oczywiście z perspektywy specjalisty od pozycjonowania warto zachować chłodną głowę i szybko sprawdzić, co się właściwie dzieje – nagłe tąpnięcie w wynikach może mieć przecież bardzo różne przyczyny.
Czasami problem jest banalny i wystarczy cofnąć jedną rzecz na stronie. Innym razem trzeba przekopać się przez Google Search Console, indeksowanie, błędy techniczne, linkowanie wewnętrzne i historię poważniejszych zmian w serwisie.
Z pewnością jednak chowanie głowy w piasek to nie jest dobry pomysł. Kiedy widzę nagły spadek, od razu kontaktuję się z klientem. Muszę mu powiedzieć, co się stało, ale przede wszystkim chcę się upewnić, czy problem nie powstał właśnie przez jego działania.
Przebudowa struktury, wdrożenie dyrektywy no index, całkowita zmiana szablonu czy nawet usunięcie ponad połowy serwisu – to tylko kilka przykładów, z którymi dotychczas się spotkałem. O wielu z nich dowiadywałem się przypadkiem, wchodząc na stronę i zastanawiając się, dlaczego nagle zniknęła połowa adresów URL.
Niestety, wielu klientów nie traktuje SEO jako istotnego elementu biznesu i nie informuje nas o zmianach, które mogą mieć na nie bezpośredni wpływ.
I ja to rozumiem. Dla osoby, która zajmuje się sprzedażą, rozwojem produktu czy obsługą klienta, zmiana szablonu strony może być… po prostu zmianą szablonu strony. Teoretycznie nic wielkiego.
Tymczasem dla mnie to może być początek kilkutygodniowego problemu z gorszymi wynikami w wyszukiwarce.
Dlatego przy nagłym spadku zawsze pytam: co ostatnio było zmieniane w obrębie witryny?
- Czy wdrażany był nowy szablon?
- Czy ktoś zmieniał URL-e?
- Czy usunięto jakieś produkty albo kategorie?
- Czy wykonano migrację albo przekierowania adresów?
- Czy programista dłubał coś w pliku robots.txt?
Czasami odpowiedź na te pytania już na wstępie rozwiązuje połowę zagadki.
Pierwszy przystanek: Google Search Console
Google Search Console to bardzo ważne, jeśli nie najważniejsze narzędzie dla właściciela strony internetowej. Przede wszystkim jest darmowe – a jak za darmo, to i sól słodka.
Powiązanie strony z GSC to podstawa, więc zakładam, że jest to już zrobione.
W przypadku spadku widoczności właśnie tutaj zaczynam szukać odpowiedzi. Nie dlatego, że Search Console pokaże mi wielką czerwoną strzałkę z napisem „Tu jest problem”, ale da mi dane, dzięki którym będę mógł zawęzić obszar poszukiwań.
Kara od Google?
Pierwsze miejsce, do którego zaglądam, to Bezpieczeństwo i ręczne działania → Ręczne działania.
Kara ręczna albo problemy związane z bezpieczeństwem, np. zhakowaniem strony, mogą być przyczyną gwałtownego „dzwonu” w dół. Sprawdzenie tego zajmuje zaledwie kilka sekund. Dopiero gdy upewnię się, że tutaj jest czysto, przechodzę dalej.
Nie chcę spędzić dwóch godzin np. na analizowaniu canonicali, jeśli problem wynika z czegoś, co Google już jasno komunikuje w Search Console.
Problemem może być sezonowość biznesu
Potem weryfikuję, czy nie mam przypadkiem do czynienia z naturalnym, sezonowym spadkiem, którego po prostu należało się spodziewać.
Jeśli prowadzisz sklep z produktami sezonowymi albo stronę hotelu, spadek ruchu w konkretnym miesiącu nie musi oznaczać problemu z SEO. Podobnie w przypadku fraz związanych z wydarzeniami, świętami czy okresowymi potrzebami użytkowników.
Same 7 czy 28 dni nie wystarczą mi do wykluczenia sezonowości. Ustawiam najszerszy dostępny zakres dat i szukam regularności w ujęciu rocznym.
Porównuję też ostatnie 3/6 miesięcy z analogicznym okresem zeszłego roku. Chodzi mi o odpowiedź na proste pytanie: czy rzeczywiście mam problem, czy po prostu wykres zachowuje się podobnie jak wcześniej?
Weryfikuję również dane w Senuto. Sprawdzam, czy spadek widoczności w GSC pokrywa się z tym, co widać w zewnętrznym narzędziu.
To dla mnie ważne rozróżnienie. Search Console pokazuje dane dotyczące rzeczywistych kliknięć, wyświetleń i pozycji w wynikach Google, natomiast narzędzia takie jak Senuto opierają się na własnych bazach fraz i modelach widoczności.
Nie traktuję ich jako dwóch identycznych źródeł danych, ale jako dwa różne punkty widzenia.
Te sposoby sprawdzają mi się zarówno w nagłych spadkach, jak i w tendencji trwającej już jakiś czas.
Sprawdzam, czy strony nie wypadły z indeksu
Kolejny krok to przeanalizowanie wykresu prezentującego liczbę stron zindeksowanych oraz niezindeksowanych.
Jeśli w tym samym momencie, w którym spadła widoczność, widzę gwałtowny spadek liczby podstron zindeksowanych, to mam już bardzo wyraźną wskazówkę, że problem dotyczy właśnie indeksowania.
Jeżeli strony nadal są w indeksie, będę szukał innej przyczyny spadku pozycji. Jeżeli natomiast duża część URL-i nagle przestała być indeksowana, najpierw muszę zrozumieć, dlaczego Google przestało je uwzględniać.
Cyklicznie wykonuję audyt indeksowania w Google Search Console. Raport Indeksowanie → Strony to dla mnie centrum informacji na temat stanu indeksowania, ale niestety bardzo często jest źle rozumiany.
Przede wszystkim informacje tam zawarte to nie są po prostu błędy, a raczej powiadomienia. To, czy konkretna sytuacja rzeczywiście stanowi problem, wymaga indywidualnej weryfikacji.
Zwracam szczególną uwagę na takie komunikaty:
- Strona wykluczona za pomocą tagu noindex
Sprawdzam, czy ten wykres nie zaczął nagle rosnąć.
Jeżeli pojawia się bardzo dużo adresów oznaczonych jako wykluczone przez noindex, zastanawiam się, skąd się wzięły. Czy ktoś celowo je wykluczył? Czy może podczas wdrożenia zmieniono ustawienia całego szablonu?
W przypadku dużej liczby podstron eksportuję je do pliku i etapami usuwam adresy, które na pewno nie powinny być indeksowane, np. adresy dynamiczne.
Nie zakładam przy tym automatycznie, że każdy noindex jest błędem. Jeżeli mamy setki stron filtrów, parametrów czy innych technicznych URL-i, część z nich może być wykluczona całkowicie prawidłowo. Interesuje mnie przede wszystkim nagła zmiana i jej skala. - Błędy 404
Jeśli nagle spora część podstron zaczyna zwracać kod 404, robot natrafia na informację, że dana strona nie istnieje, i z czasem usuwa ją z wyników.
Jeśli np. produkt w sklepie ma adres URL zależny od kategorii, jedna zmiana struktury tej nadrzędnej kategorii może uruchomić efekt domina. Zmieniają się adresy produktów, pojawiają się 404, trzeba przygotować przekierowania, inne będą linki wewnętrzne i nagle niby niewielka modyfikacja staje się sporym problemem dla całego serwisu.
Między innymi dlatego jestem zwolennikiem prostych adresów URL produktów. - Strona zeskanowana, obecnie niezaindeksowana / Wykryta – obecnie niezaindeksowana
Te komunikaty bardzo często łączą się z problemem thin content, czyli treściami niskiej jakości, albo brakiem unikalności.
Google wie o istnieniu strony, ale nie zdecydowało się jej umieścić w indeksie. Powodów może być oczywiście więcej i nie zakładam z góry, że na pewno winna jest treść. Patrzę na konkretny przypadek, typ strony i skalę zjawiska.
Spotkałem się już z sytuacją, w której podane były adresy zwracające kod 200 (czyli ok), ale po wejściu na nie następowało przekierowanie 301 po kilku sekundach.
Z pozoru mamy więc poprawny kod odpowiedzi. Po głębszym sprawdzeniu okazuje się jednak, że zachowanie strony jest zupełnie inne. - Strona zawiera przekierowanie
Tutaj weryfikuję, czy adresy docelowe są poprawne.
Sprawdzam przede wszystkim, czy nie kierują masowo na stronę główną albo jakąś przypadkową kategorię, oraz czy adres docelowy rzeczywiście zwraca kod 200.
Samo przekierowanie nie jest przecież problemem. Kłopoty zaczynają się wtedy, gdy jest ono wykonane źle.
A może roboty Google w ogóle nie mogą wejść na stronę?
Co w sytuacji, gdy strony są w indeksie, a raport skuteczności nie wskazuje jednoznacznie na problem z konkretną treścią?
Wtedy zaczynam patrzeć na witrynę z trochę innej perspektywy. Robot Google mógł po prostu odbić się od ściany, próbując wejść na stronę.
Ten krok jest nieco ukryty i czasami jest pomijany, ale zdecydowanie polecam tam zajrzeć.
Wchodzę w Ustawienia w GSC, następnie w Statystyki indeksowania i otwieram raport.
Pokazuje on, jak intensywnie roboty Google odwiedzają witrynę. Mnie interesuje przede wszystkim sekcja Stan hosta, dostępna na samej górze albo po kliknięciu w szczegóły.
Jeśli w okresie, w którym zaczął się spadek, pojawia się tam czerwony wykrzyknik lub ostrzeżenie, sprawdzam to bardziej szczegółowo. Szukam informacji o problemach technicznych, które mogły utrudnić Googlebotowi dostęp do witryny. To mogą być:
- Błędy połączenia z serwerem, czyli błędy 5xx – może to oznaczać, że hosting nie wytrzymał obciążenia, serwer zaliczał mikroprzerwy w działaniu albo w jakiś sposób blokował ruch botów.
- Problemy z plikiem robots.txt – jeżeli serwer w trakcie wizyty Googlebota nie był w stanie poprawnie zwrócić pliku robots.txt, np. zwrócił błąd serwera zamiast poprawnego statusu lub oczekiwanego 404, robot ze względów bezpieczeństwa może ograniczyć albo przerwać skanowanie witryny.
Jeśli więc wykresy w tym raporcie pikują w dół albo widzę nagły skok błędów serwerowych, wiem już, że problemu nie rozwiąże nowy tekst czy kilka dodatkowych linków. W pierwszej kolejności trzeba zgłosić się do administratora hostingu.
Trzymam się tu prostej zasady: nie próbuję leczyć problemu SEO, który w rzeczywistości jest problemem infrastruktury serwera.
Jak próbuję zaradzić spadkom i odzyskać pozycje?
Punktem wyjścia powinno być naprawienie problemów wykrytych w GSC.
Mówiąc o problemach, mam na myśli między innymi nieprawidłowe przekierowania, błędy 404 czy niechciane tagi noindex, jeżeli rzeczywiście pojawiły się przez pomyłkę.
Ja idę jednak o krok dalej i analizuję błędy wewnętrzne także w Screaming Frog.
Masowe usuwanie treści z pewnością może spowodować wysyp takich błędów. Dlatego sprawdzam, co dokładnie stało się ze strukturą serwisu i jak te zmiany wpłynęły na pozostałe podstrony.
Aktualizacja adresów docelowych 301
Sprawdzam i poprawiam przekierowania, które masowo kierują na stronę główną lub strony kategorii. Staram się przy tym, żeby przekierowanie prowadziło na możliwie najbardziej powiązaną tematycznie podstronę.
Przykładowo, usunięty artykuł o motylach wolę skierować na artykuł o biosferze na łące niż na stronę główną bloga.
Brzmi banalnie, ale przy dużych migracjach można bardzo łatwo wpaść w pułapkę „wszystko przekierujemy na homepage i będzie dobrze”. Nie będzie.
Jeżeli stara podstrona miała konkretną funkcję w serwisie i odpowiadała na konkretne zapytania, jej przekierowanie powinno mieć sens zarówno dla Google, jak i użytkownika.
Weryfikacja tagów kanonicznych – canonicale też potrafią namieszać
Kolejna rzecz to canonicale.
Zdarza mi się wykryć błędne tagi kanoniczne. Jeżeli adres jest kanonizowany, sprawdzam, czy wskazuje na stronę ze statusem 200 – nieraz widziałem przypadki, że docelowa strona kanoniczna po prostu nie istniała.
Przy większych serwisach takie rzeczy potrafią się przemnożyć przez setki czy tysiące URL-i, dlatego automatyczne sprawdzenie tego w Screaming Frog jest bardzo pomocne.
Audyt linkowania wewnętrznego
Sprawdzam, ile podstron linkuje do danego adresu, czy ten sam anchor (tekst zakotwiczenia) nie kieruje do różnych podstron oraz czy same anchory nie są zbyt ogólne.
Dużo informacji pobieram znowu ze Screaming Froga, ale korzystam również z AI.
Nie chodzi mi o to, żeby wrzucić cały eksport do modelu i zapytać „co jest nie tak?”. Przy większej ilości danych taki prompt raczej nie rozwiąże problemu.
AI wykorzystuję jako dodatkową parę oczu. Przy odpowiednio przygotowanym prompcie może pomóc mi znaleźć bardziej zagmatwane zależności, wskazać nietypowe wzorce w danych albo zasugerować miejsca, które warto sprawdzić ręcznie.
Content na stronie i brainstorming z zespołem
Konsekwentnie tworzę opisy na strony, które ich nie mają. Trudno wypozycjonować podstronę bez treści, chociaż oczywiście zdarzają się wyjątki. W takich przypadkach zwykle jest to zasługa doskonałej kondycji całej domeny i silnego brandu.
Nie traktuję jednak dodawania treści jako magicznego lekarstwa na każdy spadek. Jeżeli problemem jest noindex, 404 albo niedziałający serwer, napisanie kolejnych 50 tekstów niewiele pomoże.
Jeżeli natomiast technicznie wszystko działa, a widzę duże braki w contentowej warstwie serwisu, to po prostu z tym działam.
Nie boję się również poprosić o radę chłopaków z naszej agencji SEO i zainicjować burzy mózgów.
Czasami sam siedzę nad wykresem przez godzinę i widzę tylko kilka możliwych scenariuszy. Wystarczy, że pokażę problem komuś z zespołu i po pięciu minutach pada pytanie: „A sprawdzałeś to?”.
I nagle zapala się lampka. Może nie od razu wiem, gdzie dokładnie leży problem, ale sugestie innych specjalistów od pozycjonowania często nakierowują mnie na właściwy trop.
Przywracanie usuniętych ofert
Jedną z częstszych przyczyn spadku lub stagnacji widzę w przypadku usuwania ofert. Najczęściej spotykam się z tym w e-commerce – produkt, który został wycofany z asortimentu, jest po prostu wyłączany.
Tym samym powstaje błąd 404. Robot natrafia na taką stronę i dostaje sygnał, że strona nie istnieje, więc z czasem usuwa ją z indeksu razem z wypracowaną pozycją.
Ale problem nie dotyczy wyłącznie produktów.
Jeżeli oferty zostały usunięte, sugeruję ich przywrócenie, jeżeli z biznesowego i technicznego punktu widzenia ma to sens.
Dobrym przykładem jest branża hotelarska.
Mamy ofertę sezonową, która świetnie pozycjonuje się na konkretne zapytanie. Kiedy sezon się kończy, ktoś wyłącza podstronę.
Oferta znika z linkowania wewnętrznego, a po jakimś czasie zostaje całkowicie usunięta. Następnie robi się przekierowanie na stronę główną, podstronę /oferta, a czasem nawet na dedykowaną stronę w stylu /ale-to-juz-bylo.
Dla Googlebota to ogromna zmiana.
Jeżeli dany hotel świetnie pozycjonował się na frazę „sylwester w Pobierowie”, to po usunięciu podstrony i wykonaniu przekierowania robot natrafia na zupełnie inny, niezwiązany z ofertą content. I w efekcie pozycje mogą zostać ucięte.
Warto wiedzieć
W wielu podobnych przypadkach wolę zachować stronę pod tym samym adresem URL. Oferta może nie być aktualnie dostępna, ale podstrona nadal może istnieć. Można wyłączyć ją z głównego linkowania, jasno poinformować użytkownika, że oferta jest nieaktywna, a jednocześnie zachować cały kontekst URL-a.
Z perspektywy klienta nic złego się tu nie dzieje – kiedy trafi na taką nieistniejącą podstronę, prawdopodobnie kliknie wynik wyżej, ale nie opuści witryny.
To często znacznie lepsze rozwiązanie niż całkowite usuwanie podstrony.
Thin content – gdy serwis ma za dużo bezwartościowych podstron
Thin content to podstrony, które nie wnoszą dla użytkownika wystarczającej wartości. Mowa tu m.in. o:
- setkach wygenerowanych automatycznie stron tagów,
- pustych kategoriach produktowych,
- podstronach z jednym nagłówkiem bez sensownej treści,
- powielanych stronach filtrów w katalogach.
Problem staje się szczególnie istotny w przypadku większych serwisów i sklepów składających się z tysięcy, czy nawet milionów URL-i – no i tu wchodzi temat crawl budgetu, czyli budżetu indeksowania Google.
To w dużym uproszczeniu zasoby, które Google przeznacza na odwiedzanie i przetwarzanie konkretnej witryny.
Nie jest to sztywny „limit stron”, po którego przekroczeniu Google przestaje indeksować serwis. To bardziej kwestia tego, jak efektywnie robot może wykorzystywać swoje zasoby podczas crawlowania dużej domeny.
Jeśli bot musi przechodzić przez setki pustych, śmieciowych adresów URL (marnując ten budżet), może w ogóle nie dotrzeć do podstron, które dla mnie są najważniejsze, a dla użytkowników – najbardziej wartościowe.
W efekcie algorytm zaczyna usuwać takie podstrony z indeksu, a cała domena traci swój autorytet.
Dlatego przy dużych serwisach nie patrzę wyłącznie na to, ile mamy podstron, tylko skupiam się na tym, po co one właściwie są.
Warto wiedzieć
Jeżeli mam 100 tysięcy URL-i, ale 60 tysięcy z nich nie odpowiada na żadne realne potrzeby użytkowników, to niekoniecznie mam świetnie rozbudowaną stronę. Mogę mieć po prostu bardzo duży problem.
Kategoria bez produktów i popytu niewiele daje
Duża liczba kategorii ma sens, jeżeli w tych kategoriach jest wystarczająco dużo produktów, a samych kategorii ktoś szuka. Tworzenie kategorii tylko po to, żeby rozbudować stronę, mija się z celem.
Przede wszystkim kategorie bez produktów nie wypozycjonują się łatwo, a bez potencjału nie wygenerują żadnego ruchu, a tym bardziej konwersji.
Nie potrzeba jednak robić wielkiej rewolucji. Ten sam produkt może przecież znajdować się w wielu kategoriach, pod warunkiem, że jego URL się nie zmieni.
Im częściej robot znajdzie link do produktu w logicznych miejscach serwisu, tym łatwiej może do niego dotrzeć. Nie oznacza to jednak, że zaczynam tworzyć setki kategorii bez potencjału tylko po to, żeby zwiększyć liczbę stron w serwisie – wręcz przeciwnie.
Jeżeli kategoria nie ma produktów, nie ma popytu i nie ma sensownego zastosowania dla użytkownika, najpierw zastanawiam się, czy w ogóle powinna istnieć.
Title i H1 też mogą wymagać uporządkowania
Chociaż samo niedopasowanie meta title czy H1 raczej nie będzie bezpośrednią przyczyną nagłego spadku widoczności (chyba że zostałyby nagle przywrócone np. z kopii bazy danych), to i tak warto to sprawdzić.
Meta title i H1 są ważnymi elementami strony. Często jednak są niedopasowane, nie zawierają istotnego słowa kluczowego albo przeciwnie – próbują upchnąć w sobie zbyt wiele fraz. Mogą się też duplikować i występować wielokrotnie w serwisie.
Dlatego weryfikuję je, zaczynając od najważniejszych kategorii i podstron, które wcześniej generowały ruch.
Nie traktuję przy tym title czy H1 jako magicznych pól, do których wystarczy wpisać frazę i czekać na wzrosty. Bardziej interesuje mnie spójność całej podstrony.
Jeżeli użytkownik wpisuje konkretne zapytanie i trafia na stronę, a title, H1, treść i oferta mówią o zupełnie różnych rzeczach, to mam problem, który wypada jak najszybciej rozwiązać.
Kiedy strona nagle leci w dół w Google – podsumowanie
Spadki widoczności zdarzają się najlepszym. Nawet dobrze prowadzone strony potrafią nagle zaliczyć mocny zjazd.
Najgorsze, co można zrobić, to działać po omacku albo wierzyć w niesprawdzone teorie.
Dla mnie najważniejsze jest ustalenie, co faktycznie się zmieniło. Czy strony wypadły z indeksu? Czy nadal są w indeksie, ale straciły pozycje? Czy problem dotyczy całej domeny, konkretnej grupy URL-i, a może tylko kilku najważniejszych fraz?
Dopiero kiedy mam odpowiedź na te pytania, przechodzę do naprawy.
Warto wiedzieć
Jeżeli spadły wszystkie frazy, szukam problemu na poziomie całej domeny.
Jeżeli spadła jedna grupa kategorii, patrzę właśnie na nią.
Jeżeli pozycje straciły przede wszystkim artykuły, analizuję content.
Jeżeli z indeksu zniknęły całe grupy URL-i, wracam do technicznej strony indeksowania.
Podsumowanie w punktach
- Nagły spadek widoczności zawsze zaczynam od sprawdzenia, czy na stronie nie wprowadzono ostatnio zmian, o których nie zostałem poinformowany.
- W Google Search Console najpierw weryfikuję ręczne działania, bezpieczeństwo, sezonowość oraz skalę zmian w indeksowaniu.
- Sprawdzam, czy strony całkowicie wypadły z indeksu, czy tylko straciły pozycje, analizując m.in. raport „Indeksowanie – Strony”.
- Szczególną uwagę zwracam na nagłe wzrosty liczby stron z tagiem noindex, błędy 404, niezindeksowane URL-e oraz nieprawidłowe przekierowania.
- Sprawdzam statystyki indeksowania i stan hosta, szukając m.in. błędów serwera 5xx oraz problemów z robots.txt.
- Po znalezieniu przyczyny naprawiam problemy techniczne, analizuję przekierowania, canonicale i linkowanie wewnętrzne, a następnie zajmuję się brakującym lub słabym contentem.
- Przy dużych serwisach zwracam szczególną uwagę na usunięte oferty, thin content i masowo tworzone kategorie bez potencjału, bo mogą one negatywnie wpływać na jakość i efektywność indeksowania.
- Przy spadkach nie działam na ślepo – najpierw ustalam, co dokładnie się zmieniło i gdzie leży problem, a dopiero później wdrażam konkretne działania.


