Straciliśmy 95% ruchu z Google w jedną noc. Bing wciąż pokazuje nas w top 3.

W nocy z 16 na 17 kwietnia 2026 r. nasz ruch organiczny z Google spadł o około 95% — praktycznie z dnia na dzień. Bez kary, bez ostrzeżenia. A najdziwniejsze było to, że Bing nadal utrzymywał dokładnie te same strony w pierwszej trójce wyników. To jest szczery post-mortem — co się zepsuło (to był nasz własny kod), jak prześledziliśmy to co do godziny i co do dziś się nie odbudowało.

Zawodowo budujemy moduły SEO, wydajności i bezpieczeństwa dla PrestaShop. To, że załamanie ruchu przydarzyło się naszemu własnemu sklepowi, było upokarzające, a ostatecznie — otrzeźwiające. Dlatego opisujemy to porządnie — łącznie z tym, czego jeszcze nie naprawiliśmy.

Czym to NIE było (fałszywe tropy, które wykluczyliśmy)

Większość porad o „załamaniu ruchu” wysyła najpierw właśnie tam. My też tam poszliśmy — i wykluczyliśmy:

• To nie była kara. Żadnych ręcznych działań w Search Console, żadnego powiadomienia o nienaturalnych linkach. API inspekcji URL wciąż pokazywało nasze kluczowe strony jako „Przesłano i zindeksowano”. To była degradacja pozycji, a nie usunięcie z indeksu.
• To nie była (wyłącznie) aktualizacja algorytmu. Marcowy core update 2026 rzeczywiście zakończył się około 8 kwietnia — osiem dni przed naszym urwiskiem — i nie będziemy udawać, że ten kontekst ponownego przetwarzania nie miał znaczenia. Ale core update rozkładany na tygodnie nie tłumaczy, dlaczego dzienne wyświetlenia zapadają się między dwoma sąsiednimi dniami. Coś naszego pokrywało się z tym co do godziny.
• To nie był przede wszystkim „thin content” — choć to zarzut po części słuszny. Jeśli już, mieliśmy więcej treści, niż uzasadniał nasz autorytet: ~150 stron modułów w sześciu językach, do tego blog, dokumentacja, FAQ. Uważamy, że ten rozmiar utrudnił odbudowę, i traktujemy „postrzeganie treści jako masowej i niskowartościowej” jako żywą, nierozstrzygniętą hipotezę, a nie coś, co można zbyć machnięciem ręki.
• To nie były oczywiste sprawy techniczne. robots.txt był czysty, mapa witryny działała, canonicale i hreflang (sześć wersji językowych + x-default) były poprawne.

Trop, który wszystko przestawił: Bing pokazywał dokładnie te same treści w swoim top 3 — przy tak chudym profilu domen linkujących, że nasz zewnętrzny wskaźnik „autorytetu” jest praktycznie zerowy. Te same strony, dwie wyszukiwarki, przeciwne wyniki. To odcisk palca werdyktu zaufania i autorytetu, który uruchomiła usterka techniczna — a nie samodzielnego problemu z jakością treści czy szybkością.

Prawdziwa przyczyna: sami wypuściliśmy tego buga (pewność około 80%)

A oto część, którą większość firmowych post-mortemów by pogrzebała. Wyzwalaczem był nasz własny deploy.

Między 13 a 18 kwietnia przerabialiśmy nasz moduł produktów cyfrowych — nowy kontroler pobierania, poprawka „duplicate slug on install”, renderowany po stronie serwera przycisk pobierania. Gdzieś w tej pracy generowanie adresów URL produktów zaczęło rzucać wyjątkiem PrestaShop Invalid product vars (w classes/Link.php). Nasze logi wyjątków pokazują korelację co do godziny:

Timing był brutalny. Właśnie wystrzeliliśmy w „miesiąc miodowy” młodej witryny — około 4,000–5,400 wyświetleń dziennie przy mniej więcej pozycji 10 na początku kwietnia. To dokładnie ten moment, w którym Google oceniał nas najsurowiej. I właśnie w tym oknie Googlebot trafiał dziennie na ~1,000 zepsutych wewnętrznych linków do produktów. Dla crawlera graf linków wewnętrznych, który w szczycie oceny nagle wskazuje na zepsute adresy produktów, to mocny sygnał: „ta witryna właśnie się popsuła”.

Mówimy o ~80% pewności, a nie o stuprocentowej, bo wszystko wydarzyło się w naprawdę zaszumionym oknie — zakończony core update, spam update, koniec miesiąca miodowego i nawracające awarie serwera i bazy u nas samych (połowa marca, 14–16 kwietnia i znowu w czerwcu). Każdy z tych czynników pogłębia uszczerbek na zaufaniu. Ale tylko liczba błędów Link.php pokrywa się z urwiskiem dzień w dzień. Szczery werdykt: techniczny wyzwalacz na własne życzenie, który zdetonował w kontekście młodej witryny o niskim autorytecie, tuż po core update.

Kategoria, która naprawdę tłumaczy −95%: „zeskanowana, ale obecnie niezindeksowana”

Jeśli masz z tej historii wynieść jedną lekcję diagnostyczną, weź właśnie tę. W raporcie stanu indeksowania w Search Console kategorią, która się liczy, nie jest „404” ani „5xx”. Jest nią „zeskanowana, ale obecnie niezindeksowana” — mniej więcej 22,800 adresów URL.

Uczciwe zastrzeżenie, bo sprawdziliśmy własną historię: ta kategoria nie „spuchła” w noc krachu. Po raz pierwszy zobaczyliśmy ją już w lutym 2025, szczyt osiągnęła w okolicach 60k i od tego czasu powoli opada do ~22.8k. Samo nocne urwisko było degradacją pozycji stron, które pozostały w indeksie — dzienne wyświetlenia ~5,400 przy pozycji ~10 spadły następnego dnia do 161, przy pozycji 27. Kategoria „zeskanowane, niezindeksowane” nie jest mechanizmem nocnego spadku; to miejsce, w którym widać długoterminowy werdykt zaufania. Zweryfikowaliśmy próbkę z tych 22.8k stron: 200, index,follow, self-canonical, bogate w treść. Google zeskanował dziesiątki tysięcy technicznie czystych stron i zdecydował, że ich nie zindeksuje.

Odbudowa, część 1: naprawdę czysta strona techniczna

Nie można prosić Google o ponowną ocenę witryny, która wciąż potyka się o błędy. Faza pierwsza to więc bezwzględna higiena — każda możliwa do naprawienia usterka techniczna naprawiona i zweryfikowana na żywo, a nie tylko „wdrożona” (kategoria zaufania z następnej sekcji to osobny, nietechniczny problem):

• Wyzwalacz w Link.php: naprawiony w pierwszej kolejności — 0 błędów od maja, produkty renderują pełny HTML z kodem 200.
• Błędy 404: rozdzielone prawdziwe 404 i zmienione slugi; stare slugi przekierowane 301 na aktualne canonicale (jeden skok, z lokalizacją).
• Adresy z filtrów fasetowych: poprawne kombinacje jako 200 + noindex,follow, nieaktualne jako 301 — ludzie filtrują, crawlery nie toną.
• Błędy 5xx: międzyjęzykowy błąd krytyczny autoloadu przez rozjazd wielkości liter, naprawiony z zabezpieczeniem awaryjnym.
• Łańcuchy przekierowań: zwinięte do jednego skoku, rozwiązywane w momencie generowania linku.
• Dane strukturalne: dokładnie jeden brand na produkt i ograniczona długość opisu (dwa błędy, które realnie kosztowały nas wyniki rozszerzone).
• Zasoby: usunięty per-plikowy cache-busting ?v=, żeby działało natywne łączenie i minifikacja PrestaShop.
• Hierarchia nagłówków: jeden <h1> na stronę, czyste H1 → H2 → H3.

Odbudowa, część 2: nie wpuszczaj crawlera w bałagan — „freeze gate”

Oto dyscyplina, którą większość historii o odbudowie pomija. Zanim cokolwiek ponownie zgłosimy do Google, traktujemy mapę witryny i pipeline indeksowania jak bramkę: nic nie trafia do zgłoszenia, jeśli nie jest dowodnie czyste.

• Mapa witryny jest generowana od nowa, a każdy URL niezależnie weryfikowany — 200, index,follow, self-canonical, poprawny hreflang, poprawna schema. Nasza ustabilizowała się na 4,952 adresach URL w sześciu językach.
• Kolejka indeksowania zgłasza wyłącznie adresy, które są w tej chwili indeksowalnymi canonicalami, z osobną kontrolą każdego adresu w momencie zgłoszenia — bez ślepego wysyłania wszystkiego jak leci.

Audyt każdego adresu z mapy witryny przez tę kontrolę wyłapał trzy błędy, które po cichu zmarnowałyby cały ponowny crawl: w naszym wewnętrznym rejestrze stron brakowało 918 adresów z mapy witryny — w tym całego zestawu dokumentacji liczącego 882 adresy; trzy strony FAQ były błędnie oznaczone noindex przez brakujący wiersz powiązania ze sklepem; a wpisy blogowe były błędnie kierowane na noindex przez klasyfikator dopasowujący supportowe słowa kluczowe przed regułą bloga. Zażądaliśmy wyniku zero zablokowanych — każdy z 4,952 adresów musi przejść kontrolę — zanim uznaliśmy bramkę za zamkniętą.

Lekcja: odzyskiwanie zaufania oznacza, że następna rzecz, którą zobaczy Google, musi być nieskazitelna. Kolejna runda „prosimy, zindeksujcie nasze zepsute strony” tylko pogłębia dół.

Na co teraz mamy alerty

Awaria była niewidzialna przez wiele dni, bo nic nie krzyczało. Co monitorujemy teraz:

• Alerty na wyjątki klasy krytycznej na Link.php i nietrafiony slug w dispatcherze — każdy skok budzi nas natychmiast, zamiast cotygodniowej lektury logów.
• Trend statystyk crawlowania GSC + Bing oglądany co tydzień, obok siebie — rozjazd Bing/Google to nasz najwcześniejszy sygnał zaufania.
• Watchdog dostępności na serwerze źródłowym — nasze awarie były częścią rany, więc uptime jest teraz pełnoprawną metryką SEO.
• Kontrola zgodności mapy witryny z rejestrem — zabezpieczenie, które znalazło brakujące 918, działa bez przerwy.

Co się uczciwie (jeszcze) NIE odbudowało

To tu większość wpisów „jak się odbudowałem” zaczyna mijać się z prawdą. My nie będziemy.

• Pozycje i ruch nie wróciły. Strona techniczna jest czysta i zweryfikowana, ale Google wciąż odmawia indeksowania większości tego, co skanuje, a pozycja dalej dryfuje, zamiast odbić.
• Prawdziwym sufitem jest off-page. Nasz profil domen linkujących jest chudy — te same treści, które Bing pokazuje w top 3, Google odrzuca. Czysta witryna ze słabą zewnętrzną walidacją to dokładnie to, jak wygląda „zeskanowane, niezindeksowane”.
• Nasze nieanglojęzyczne wersje to martwy balast. Zbierają wyświetlenia, ale prawie żadnych kliknięć; realnie konwertują tylko angielski i polski. Skalowanie maszynowo tłumaczonych stron było częścią przerośniętego rozmiaru witryny, a nie aktywem.
• Dalsza naprawa nie jest techniczna. To autorytet i czas: prawdziwe sygnały doświadczenia i eksperckości, linki wypracowane w ekosystemie PrestaShop i danie czystej witrynie szansy, by się obroniła, gdy ponownie otworzymy indeksowanie przez kontrolowaną kolejkę.

Publikujemy to teraz, w połowie odbudowy, właśnie dlatego, że post-mortem spisany po pełnym powrocie to bajka obciążona błędem przeżywalności. Tak to naprawdę wygląda od środka.

Jeśli to samo dzieje się w Twoim sklepie PrestaShop

• Sprawdź Bing. Jeśli Bing pokazuje Twoje treści, a Google nie — przestań obwiniać treść i szybkość. To kwestia zaufania, a uruchomiło ją najpewniej coś technicznego.
• Połóż własny dziennik wdrożeń obok wykresu ruchu. Naszym dowodem była liczba wyjątków pokrywająca się z urwiskiem co do dnia. Twoim może być to samo.
• Czytaj kategorie stanu indeksowania, nie tylko linię ruchu. „Zeskanowane — niezindeksowane” na dużą skalę to sygnał jakości, a nie błąd do naprawienia.
• Naprawiaj i weryfikuj na żywo — bezpośrednio na serwerze źródłowym, a nie „powinno już działać”.
• Nie wpuszczaj crawlera w bałagan. Udowodnij, że mapa witryny i zestaw zgłoszeń są nieskazitelne, zanim poprosisz Google, by spojrzał jeszcze raz.
• Potem uzbrój się w cierpliwość i buduj autorytet. Na zaufanie nie ma poprawki w kodzie.

Jeśli Twój sklep pokazuje ten sam wzorzec — czysty na powierzchni, ignorowany przez Google, w porządku w Bing — nasz PrestaShop SEO Audit precyzyjnie wskaże, który z tych scenariuszy awarii Cię dotyka, na stronie i poza nią. To ten sam proces śledczy, który powyżej zastosowaliśmy na sobie.