naprawa-stron.pl Online 24/7 Zgłoś awarię

Strona zniknęła z Google albo ruch spadł o połowę: awaria, włamanie czy aktualizacja algorytmu?

Autor: Grzegorz Wojterzak. Aktualizacja: 25 listopada 2026. Czas czytania: około 12 minut.

$ diagnoza spadek ruchu z Google
Typowe objawy
Mniej zapytań i zamówień, strona nie wyświetla się na swoje frazy albo wcale
Najczęstsze przyczyny
Awaria serwera, noindex po migracji, włamanie ze spamem, aktualizacja algorytmu, sezon
Czas diagnozy
Zwykle 1–2 godziny z dostępem do Search Console i serwera
Czy zrobisz to sam?
Diagnozę tak. Naprawę awarii lub włamania często z pomocą

Szybka odpowiedź

Spadek ruchu z Google ma pięć typowych przyczyn: awarię techniczną (błędy 5xx, noindex, blokada w robots.txt, złe przekierowania), włamanie ze spamem, karę ręczną, aktualizację algorytmu albo sezonowy spadek popytu. Sprawdzaj je w tej kolejności, bo pierwsze trzy możesz i musisz naprawić od razu. Datę spadku porównaj z datami aktualizacji na stronie stanu wyszukiwarki Google, a w Search Console przejrzyj raporty Indeksowanie stron, Ręczne działania i Problemy dotyczące bezpieczeństwa.

Gdy telefon przestaje dzwonić, pierwsza myśl brzmi zwykle: „Google mnie ukarał”. Kara ręczna to jednak rzadkość. Dużo częściej przyczyna jest przyziemna: ktoś zostawił zaznaczone pole blokujące indeksowanie po przeniesieniu strony, serwer od tygodnia zwraca błędy albo włamywacz dopisał tysiące stron ze spamem.

Ten poradnik prowadzi przez sprawdzenie wszystkich możliwości po kolei, od najłatwiejszych do naprawienia. Stan na początek listopada 2026.

Najpierw upewnij się, że ruch naprawdę spadł

Zanim zaczniesz szukać winnych, sprawdź, czy spadek widzi sama wyszukiwarka, a nie tylko Twój licznik odwiedzin. Google Analytics może pokazywać spadek, bo po zmianie motywu zniknął kod pomiaru albo baner zgód na pliki cookie zaczął inaczej działać. Search Console, czyli bezpłatne narzędzie Google dla właścicieli stron, liczy kliknięcia po stronie wyszukiwarki, więc kod na stronie nie ma na nie wpływu.

  1. Otwórz raport skuteczności w Search Console

    Wybierz wyniki z wyszukiwarki Google i ustaw zakres 16 miesięcy. Tyle Search Console przechowuje danych, a dłuższy zakres pokaże, czy podobny spadek nie powtarza się co roku.

  2. Porównaj kliknięcia i wyświetlenia

    Wyświetlenia to liczba pokazań strony w wynikach, kliknięcia to wejścia. Jeśli spadły oba, szukaj przyczyny w tym poradniku. Jeśli wyświetlenia stoją, a spadły kliknięcia, problemem są raczej tytuły i opisy w wynikach albo konkurencja, która wyświetla się atrakcyjniej. Według Google tak właśnie należy czytać ten raport.

  3. Ustal dokładną datę i zasięg spadku

    Na wykresie znajdź dzień, od którego linia idzie w dół. Potem w zakładce stron posortuj podstrony po różnicy kliknięć. Spadek całej strony z dnia na dzień wskazuje na awarię, blokadę albo karę. Powolny spadek kilku podstron to częściej problem pojedynczych adresów albo zmiana algorytmu.

Drzewo diagnostyczne: co sprawdzić po kolei

Najpierw wykluczasz rzeczy, które zależą od Ciebie i blokują wszystko inne. Nie ma sensu analizować algorytmu, jeśli Google od tygodnia dostaje od serwera błąd.

Drzewo diagnostyczne spadku ruchu z Google Pięć pytań w kolejności. Pierwsze: czy strona działa i zwraca kod 200; jeśli nie, to awaria techniczna. Drugie: czy jest blokada noindex, Disallow w robots.txt albo błędne przekierowania; jeśli tak, to błąd konfiguracji. Trzecie: czy w wynikach site: są obce podstrony albo wpis w raporcie Problemy dotyczące bezpieczeństwa; jeśli tak, to włamanie. Czwarte: czy jest wpis w raporcie Ręczne działania; jeśli tak, to kara ręczna. Piąte: czy data spadku pokrywa się z aktualizacją Google; jeśli tak, to aktualizacja algorytmu, a jeśli nie, to sezonowość, popyt lub problem pojedynczych podstron. Ruch z Google spadł 1 Strona działa i zwraca kod 200? curl -I, narzędzie do sprawdzania adresów URL 2 Jest noindex, Disallow lub złe przekierowania? Ustawienia → Czytanie, robots.txt, adresy po migracji 3 Obce podstrony lub wpis o bezpieczeństwie? site:twojadomena.pl, Problemy dotyczące bezpieczeństwa 4 Wpis w raporcie Ręczne działania? Search Console, raport Ręczne działania 5 Data spadku pasuje do aktualizacji Google? status.search.google.com, historia aktualizacji Sezon, popyt albo pojedyncze podstrony Google Trends, porównanie rok do roku, zmienione adresy Awaria techniczna 5xx, DNS, SSL, limit hostingu Błąd konfiguracji napraw od razu, poproś o indeksację Włamanie czyszczenie, potem prośba o sprawdzenie Kara ręczna usuń naruszenie, prośba o sprawdzenie Aktualizacja algorytmu czekaj na koniec, oceń treść, bez paniki tak nie nie nie nie nie tak tak tak tak
Czerwone pola naprawiasz od razu. Przy żółtych liczy się cierpliwość i porządna analiza. Kilka przyczyn może wystąpić naraz: włamanie potrafi zbiec się w czasie z aktualizacją algorytmu.

Krok 1 i 2: awaria techniczna i blokady indeksowania

Czy serwer odpowiada poprawnie

To, że Ty widzisz stronę, nie znaczy, że widzi ją Google: wtyczka zabezpieczająca może blokować jego robota, hosting zwracać błąd 503 przy przeciążeniu, a certyfikat SSL mógł na kilka dni wygasnąć. Kod odpowiedzi to trzycyfrowa liczba, którą serwer dołącza do każdej strony: 200 znaczy „w porządku”, 301 „przeniesiono na stałe”, 404 „nie ma”, 5xx „błąd serwera”.

Kod sprawdzisz w terminalu poleceniem, które pobiera same nagłówki odpowiedzi:

curl -I https://twojadomena.pl/

Prawdziwy wynik z testowej instalacji sklepu (fragment):

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8

Bez terminala użyj w Search Console narzędzia do sprawdzania adresów URL: wpisz adres strony głównej i uruchom test na żywo. Zobaczysz, czy Google może pobrać stronę i czy wolno mu ją zaindeksować. Raport Statystyki indeksowania (w ustawieniach Search Console) pokaże, czy w ostatnich tygodniach robot Google dostawał błędy serwera.

Według dokumentacji Google błędy 5xx i kod 429 (zbyt wiele żądań) najpierw spowalniają odwiedziny robota. Zaindeksowane strony na razie zostają w wynikach, ale adresy, które uporczywie zwracają błąd serwera, w końcu z nich wypadają. Dlatego kilkudniowa, niezauważona awaria potrafi zabrać ruch na tygodnie. Jeśli serwer zwalniają automaty, zajrzyj do poradnika Boty AI przeciążają stronę.

Noindex: jedno pole w ustawieniach WordPressa

Noindex to informacja dla wyszukiwarek „nie pokazuj tej strony w wynikach”. W WordPressie włącza ją jedno pole w ustawieniach czytania (Ustawienia → Czytanie, pole Proś wyszukiwarki o nieindeksowanie witryny; w wersji angielskiej Settings → Reading). Zaznacza się je na czas budowy strony i zapomina odznaczyć po przeniesieniu na właściwą domenę. To najczęstsza przyczyna sytuacji „po wdrożeniu nowej strony zniknęliśmy z Google”.

Ustawienia czytania WordPressa: zaznaczone pole Proś wyszukiwarki o nieindeksowanie witryny w sekcji Widoczność w wyszukiwarkach, w czerwonej ramce
Zrzut ekranuUstawienia → Czytanie: „Widoczność w wyszukiwarkach” z zaznaczonym polem „Proś wyszukiwarki o nieindeksowanie witryny” (czerwona ramka). Tak wygląda problem: na produkcyjnej stronie to pole musi być odznaczone. Testowa instalacja WordPressa 7.1.4 po polsku, dane fikcyjne.

Sprawdziłem w kodzie WordPressa 7.1.4, co robi to pole. Nie blokuje strony w pliku robots.txt, tylko dodaje do każdej podstrony znacznik w kodzie HTML. Oto prawdziwy wynik funkcji WordPressa na instalacji testowej, najpierw z zaznaczonym polem (wymuszonym tylko na czas polecenia), potem w normalnym stanie:

# pole zaznaczone: wyszukiwarki mają nie indeksować strony
<meta name='robots' content='noindex, nofollow' />
# pole odznaczone: stan prawidłowy
<meta name='robots' content='max-image-preview:large' />

Możesz to sprawdzić sam: otwórz swoją stronę, naciśnij Ctrl+U (podgląd źródła) i wyszukaj name='robots'. Jeśli widzisz noindex, a nie chcesz go mieć, odznacz pole i zapisz. noindex mogą też dodawać wtyczki SEO, osobno dla pojedynczych stron, kategorii albo produktów. O zaznaczonym polu WordPress ostrzega w Narzędzia → Stan witryny komunikatem Wyszukiwarki są proszone o nieindeksowanie tej witryny. (w wersji angielskiej Search engines are discouraged from indexing this site).

Stan witryny w WordPressie: ostrzeżenie Wyszukiwarki są proszone o nieindeksowanie tej witryny w czerwonej ramce
Zrzut ekranuTak WordPress ostrzega o zaznaczonym polu w Narzędzia → Stan witryny: „Wyszukiwarki są proszone o nieindeksowanie tej witryny.” (czerwona ramka), z linkiem do ustawień widoczności. Raport nic nie instaluje, więc to najszybszy przegląd techniczny strony. Testowa instalacja WordPressa 7.1.4 po polsku, dane fikcyjne.

robots.txt

Plik robots.txt pod adresem twojadomena.pl/robots.txt mówi robotom, gdzie nie wolno im wchodzić. Jedna linia Disallow: / pod User-agent: * zamyka całą stronę. Taki plik bywa przenoszony z wersji testowej. Uwaga na dwie pułapki opisane w dokumentacji Google:

  • Blokada w robots.txt nie usuwa strony z wyników. Robot nie wchodzi na podstronę, więc nie widzi też jej znacznika noindex. Jeśli chcesz coś usunąć z Google, użyj noindex i nie blokuj adresu w robots.txt.
  • Błąd serwera przy robots.txt wstrzymuje indeksowanie. Gdy plik zwraca błąd 5xx, Google przez pierwsze 12 godzin przestaje odwiedzać stronę, potem przez 30 dni korzysta z ostatniej dobrej wersji pliku. Błąd 404 przy robots.txt jest niegroźny: Google uznaje wtedy, że ograniczeń nie ma.

W Search Console, w ustawieniach, jest raport dotyczący pliku robots.txt. Pokaże, którą wersję pliku Google pobrał i czy wystąpiły błędy.

Przekierowania po migracji i przejściu na HTTPS

Po przeniesieniu strony na nowy serwer, nową domenę albo z http:// na https:// stare adresy muszą prowadzić przekierowaniem 301 (stałym) do nowych. Dla Google przekierowanie 301 to silny sygnał, że nowa wersja ma zastąpić starą, a 302 tylko słaby. Najczęstsze błędy to pętla przekierowań, przekierowanie wszystkich starych adresów na stronę główną i adresy w ustawieniach WordPressa, które wciąż wskazują starą wersję.

Ustawienia ogólne WordPressa: pola Adres WordPressa (URL) i Adres witryny (URL) z adresem http:// w czerwonych ramkach
Zrzut ekranuUstawienia → Ogólne: „Adres WordPressa (URL)” i „Adres witryny (URL)” (czerwone ramki). Po przejściu na HTTPS oba adresy muszą zaczynać się od https:// i wskazywać tę samą domenę co przekierowania. Na zrzucie widać jeszcze http://, czyli stan, którego po przejściu na HTTPS być nie powinno. Testowa instalacja WordPressa 7.1.4 po polsku, dane fikcyjne.

Całą procedurę przejścia na HTTPS opisałem w poradniku Chrome ostrzega przed wejściem na Twoją stronę. Według Google po zmianie adresów średniej wielkości strona może potrzebować kilku tygodni, zanim wyniki się ustabilizują.

Krok 3: włamanie i spam w indeksie

Włamanie potrafi zabrać ruch na dwa sposoby. Przy złośliwym oprogramowaniu Google pokazuje przed wejściem na stronę czerwone ostrzeżenie i ludzie po prostu nie wchodzą. Przy spamie atakujący dopisuje tysiące podstron z obcymi treściami, a Google zaczyna traktować całą domenę jako źródło spamu.

Wpisz w Google site:twojadomena.pl. Operator site: pokazuje przykładowe podstrony z indeksu Twojej domeny (nie pełną listę). Szukaj:

  • tytułów po japońsku lub chińsku, ofert podróbek, leków, kasyn,
  • adresów w katalogach, których nie tworzyłeś, np. z losowymi ciągami znaków,
  • opisów innych niż treść strony, co bywa objawem maskowania (cloakingu): robot Google dostaje spam, a Ty widzisz zwykłą stronę.

Maskowanie sprawdzisz w narzędziu do sprawdzania adresów URL: po teście na żywo obejrzyj kod strony, który pobrał Google, i porównaj go z tym, co widzisz w przeglądarce. W Search Console otwórz też raport Problemy dotyczące bezpieczeństwa oraz Ustawienia → Użytkownicy i uprawnienia. Obcy właściciel usługi, którego nikt w firmie nie dodawał, to częsty ślad ataku japońskimi słowami kluczowymi.

Co dalej przy włamaniu, opisałem osobno: japońskie znaki w Google, ostrzeżenie „strona zawiera szkodliwe programy” i jak sprawdzić, czy strona jest zhakowana. Jeśli spam wraca po usunięciu, przeczytaj dlaczego wirus wraca po wyczyszczeniu strony.

Najpierw czyszczenie, potem Google

Nie wysyłaj prośby o sprawdzenie, dopóki strona nie jest naprawdę czysta i nie załatałeś luki, przez którą weszli atakujący. Według Google weryfikacja spamu po włamaniu może trwać nawet kilka tygodni, a odrzucona prośba tylko wydłuża czekanie.

Krok 4: kara ręczna

Ręczne działanie (popularnie „kara od Google”) nakłada pracownik Google, gdy uzna, że strona narusza zasady dotyczące spamu. Nie trzeba go zgadywać: zawsze widać je w Search Console w raporcie Ręczne działania, a Google wysyła o nim wiadomość. Pusty raport oznacza, że kary ręcznej nie ma.

Typowe powody to spam tworzony przez użytkowników (np. w komentarzach), spam osób trzecich na Twojej stronie, maskowanie i podstępne przekierowania, ukryty tekst, nienaturalne linki. Raport podaje rodzaj naruszenia i przykładowe adresy.

Gdy usuniesz problem na wszystkich wskazanych stronach, w tym samym raporcie wyślij prośbę o sprawdzenie (w wersji angielskiej Request Review) i opisz konkretnie, co zrobiłeś. Według pomocy Search Console rozpatrzenie trwa zwykle od kilku dni do kilku tygodni, a o wyniku Google informuje mailem.

Krok 5: aktualizacja algorytmu Google

Kilka razy w roku Google wprowadza duże zmiany w sposobie oceniania stron. Aktualizacje podstawowe (core updates) zmieniają ocenę jakości i przydatności treści w całej wyszukiwarce. Aktualizacje spamowe (spam updates) ulepszają automatyczne wykrywanie spamu. Każda trwa od kilku godzin do kilku tygodni i Google ogłasza ją na stronie stanu wyszukiwarki: status.search.google.com.

Aktualizacje wyszukiwarki Google w 2026 roku na osi czasu Oś od stycznia do listopada 2026. Aktualizacje podstawowe: marcowa od 27 marca do 8 kwietnia, majowa od 21 maja do 2 czerwca. Aktualizacje spamowe: marcowa 24–25 marca i wrześniowa od 24 września do 8 października; czerwcowa i sierpniowa trwały od dwóch do trzech dni. Lutowa aktualizacja Discover dotyczyła według Google tylko użytkowników anglojęzycznych w USA, więc dla polskiej strony zwykle nie ma znaczenia. Spadek, który zaczął się w trakcie trwania aktualizacji lub tuż po niej, może mieć z nią związek. Aktualizacje podstawowe (core) 27.03–8.04 21.05–2.06 Aktualizacje spamowe (czerwcowa i sierpniowa trwały ok. 2–3 doby) 24–25.03 24.09–8.10 Aktualizacja podstawowa Discover 5–27.02 2.11 stylut markwi majcze lipsie wrzpaź lis Spadek w trakcie paska lub kilka dni po nim: sprawdź związek z aktualizacją. Spadek z dnia na dzień poza paskami częściej oznacza awarię, blokadę albo włamanie.
Daty według historii aktualizacji na stronie stanu wyszukiwarki Google, w zapisie serwisów branżowych; stan na 2 listopada 2026. Przed wnioskami sprawdź aktualną listę na status.search.google.com, bo Google dopisuje tam kolejne zmiany.

Wrześniowa aktualizacja spamowa 2026

Ostatnia duża zmiana przed sezonem świątecznym to aktualizacja spamowa z września 2026. Według komunikatu Google zacytowanego przez serwisy branżowe ruszyła 24 września, objęła wszystkie języki i kraje, a zakończyła się 8 października, po około 14 dniach. Google nazwał ją „zwykłą aktualizacją spamową” i nie podał szczegółów. Według relacji branżowych nie dotyczyła spamu linkowego.

Jeśli Twój ruch spadł między 24 września a połową października, a kroki 1–4 niczego nie wykazały, przejrzyj zasady Google dotyczące spamu. Najczęstsze naruszenia na małych stronach to masowo generowane podstrony bez wartości (np. setki stron „usługa + miasto” różniących się tylko nazwą miasta), ukryty tekst, przejęte stare domeny i spam dopisany przez włamywacza, o którym właściciel nie wie. Google pisze, że po usunięciu naruszeń poprawa może przyjść dopiero po kilku miesiącach, gdy jego systemy uznają, że strona przestrzega zasad.

Co robić po aktualizacji podstawowej

Google wprost zaznacza, że spadek po aktualizacji podstawowej nie musi znaczyć, że z Twoją stroną jest coś nie tak: inne strony mogły po prostu zostać ocenione wyżej. Zalecenia z dokumentacji Google są proste:

  1. Poczekaj, aż aktualizacja się zakończy, i odczekaj jeszcze co najmniej tydzień.
  2. Porównaj ten tydzień z tygodniem sprzed rozpoczęcia aktualizacji.
  3. Przy niewielkim spadku pozycji nie rób gwałtownych zmian.
  4. Przy dużym, trwałym spadku oceń całą stronę uczciwie: czy treść jest przydatna, napisana przez kogoś, kto zna temat, i lepsza niż u konkurencji. Usuwanie treści traktuj jako ostateczność.

Poprawa po zmianach w treści może przyjść po kilku dniach, ale równie dobrze dopiero przy następnej aktualizacji podstawowej.

Sezonowość, popyt i pojedyncze podstrony

Jeśli nic z powyższego się nie potwierdziło, sprawdź, czy ludzie po prostu rzadziej szukają tego, co oferujesz. W Google Trends wpisz swoje główne frazy i porównaj ostatnie miesiące z tym samym okresem rok wcześniej. W Search Console użyj porównania okresu rok do roku zamiast miesiąca do miesiąca.

Spadek kilku konkretnych podstron ma zwykle konkretną przyczynę: zmieniony adres bez przekierowania, usunięty produkt, nowy wpis, który konkuruje z tym samym tematem, albo pole wyników, w którym Google zaczął pokazywać inne elementy. Sprawdź te adresy pojedynczo w narzędziu do sprawdzania adresów URL i w raporcie Indeksowanie stron.

Typowy scenariusz

Firma usługowa uruchamia nową stronę przygotowaną przez wykonawcę na serwerze testowym. Po kilku tygodniach telefonów jest coraz mniej. Właściciel podejrzewa wrześniową aktualizację spamową Google, ale wykres w Search Console spada od dnia wdrożenia, a nie od daty aktualizacji. W kodzie strony jest noindex, nofollow, bo w ustawieniach czytania zostało zaznaczone pole z czasów budowy. Do tego część starych adresów nie ma przekierowań. Po odznaczeniu pola, dodaniu przekierowań 301 i zgłoszeniu najważniejszych podstron do zindeksowania ruch wraca w ciągu kilku tygodni.

Kiedy nie robić tego samemu

Sprawdzenie ustawień czytania, raportów w Search Console i wyników site: zajmie Ci kwadrans. Pomoc przyda się, gdy:

  • serwer zwraca błędy 5xx albo strona działa tylko czasami, a hosting twierdzi, że wszystko jest w porządku,
  • w indeksie widać obce podstrony albo robot Google dostaje inną treść niż Ty, czyli doszło do włamania,
  • po migracji lub przejściu na HTTPS przekierowania tworzą pętle albo prowadzą w złe miejsca,
  • nie masz dostępu do Search Console, bo konto założył dawny wykonawca (zobacz jak odzyskać dostęp do strony),
  • spadek zbiegł się z aktualizacją WordPressa lub wtyczek i coś przestało działać (zobacz strona nie działa po aktualizacji).

Ruch z Google spadł i nie wiesz dlaczego?

Sprawdzę serwer, ustawienia indeksowania, przekierowania i Search Console, ustalę przyczynę spadku i naprawię awarię techniczną. Szybka Interwencja: 299 zł netto, 7 dni gwarancji na naprawę. Jeśli przyczyną okaże się włamanie, powiem to od razu i zaproponuję odwirusowanie.

Najczęstsze pytania

Czy spadek po aktualizacji algorytmu Google to kara?

Nie. Kara, czyli ręczne działanie, nakłada pracownik Google i zawsze widzisz ją w raporcie Ręczne działania w Search Console. Aktualizacja algorytmu zmienia ocenę wielu stron naraz. Google pisze wprost, że spadek po aktualizacji podstawowej nie musi oznaczać, że z Twoją stroną jest coś nie tak.

Ile trwa powrót ruchu po naprawieniu awarii lub usunięciu noindex?

Zależy od tego, jak szybko Google ponownie odwiedzi Twoje podstrony. Najważniejsze adresy zgłoś w narzędziu do sprawdzania adresów URL w Search Console. Często wracają po kilku dniach, ale według dokumentacji Google ponowna wizyta na rzadko odwiedzanej podstronie może potrwać nawet miesiące.

Google Analytics pokazuje spadek, a Search Console nie. Co to znaczy?

Najczęściej problem jest w pomiarze, nie w Google: zniknął kod Analytics po zmianie motywu, zmienił się baner zgód na pliki cookie albo ustawienia trybu zgody. Kliknięcia w raporcie skuteczności Search Console nie zależą od kodu na stronie, więc to one pokazują, czy ruch z wyszukiwarki naprawdę spadł.

Czy mam coś zmieniać na stronie w trakcie aktualizacji Google?

Awarie, noindex, przekierowania i włamania naprawiaj od razu, bez czekania. Treści nie przerabiaj w pośpiechu: Google radzi poczekać, aż aktualizacja się zakończy, odczekać jeszcze tydzień i dopiero wtedy porównać dane z okresem sprzed aktualizacji.

Jak sprawdzić, czy ktoś obcy ma dostęp do mojej Search Console?

W Search Console otwórz Ustawienia, a potem Użytkownicy i uprawnienia. Nieznany właściciel, którego nikt w firmie nie dodawał, to typowy ślad włamania: atakujący weryfikuje się jako właściciel, żeby zarządzać zaindeksowanym spamem. Usuń go, a potem jego plik weryfikacyjny lub rekord DNS, i sprawdź stronę pod kątem infekcji.

Grzegorz Wojterzak naprawia strony internetowe po awariach i włamaniach: WordPress, WooCommerce, PHP i Node.js. Od ponad dekady pracuje przy stronach i sklepach internetowych polskich firm.