Recovery po Google Core Update — case study 6 miesięcy

Google Core Update w marcu uderzył w nasz kliencki content site z nisz technologicznej niemal bez ostrzeżenia. W ciągu dziewięciu dni ruch organiczny spadł o 62%, przychody z reklam o 71%, a zaufanie zespołu — o wartość, której nie da się łatwo policzyć. Pół roku później ten sam serwis notował ruch +14% względem stanu sprzed Core Update, wyższe pozycje na zapytaniach komercyjnych i trzy razy wyższy CTR w Search Console. Ten case study rozkłada tę drogę na czynniki pierwsze — krok po kroku, z liczbami, tabelą i frameworkiem, który możesz zaadaptować u siebie.

Zanim przejdziemy do szczegółów, jedno zastrzeżenie: nazwa klienta jest zanonimizowana, a metryki zostały lekko przeskalowane, żeby uniknąć identyfikacji. Struktura działań, kolejność decyzji i proporcje wyników pochodzą natomiast wprost z prawdziwego projektu realizowanego w latach 2023 — 2024. Wszystko, co opisuję poniżej, da się wykonać w zespole dwuosobowym bez budżetu na drogie narzędzia enterprise.

Profil serwisu i punkt wyjścia

Serwis, o którym mowa, to polskojęzyczny content hub z branży SaaS / productivity — recenzje narzędzi, porównania, poradniki i tutoriale. Przed Core Update miał około 620 opublikowanych artykułów, 94% treści po polsku, resztę w wersji angielskiej na subdomenie. Miesięcznie generował około 380 tysięcy sesji organicznych, z czego 68% przychodziło z zapytań informacyjnych, a 32% z komercyjnych (modyfikatory typu „najlepszy”, „ranking”, „alternatywy dla”). Dochód z programów partnerskich i reklam display stanowił około 85% całkowitego przychodu biznesu — dlatego spadek po aktualizacji był egzystencjalnym zagrożeniem, a nie kosmetyczną niedogodnością.

Zespół liczył cztery osoby: redaktor naczelny, dwóch copywriterów (każdy prowadził po dwie kategorie tematyczne) i jeden specjalista SEO na pół etatu. Ja dołączyłem jako konsultant dziewiątego dnia po aktualizacji, kiedy spadek się ustabilizował na poziomie -62% widoczności w Ahrefs i -58% sesji w Google Analytics 4. Technicznie strona stała na WordPressie z motywem GeneratePress, była zoptymalizowana pod Core Web Vitals (LCP 1,8 s, INP 130 ms, CLS 0,02), miała poprawny sitemap i aktywny plugin RankMath. Czyli — nie była to klasyczna wtopa techniczna.

Diagnoza — co tak naprawdę się stało

Pierwsze 72 godziny poświęciłem wyłącznie na diagnozę. Bez cięć, bez publikacji, bez paniki. W recovery po Core Update największym wrogiem jest pośpiech — usunięcie niewłaściwego artykułu albo przerobienie dobrych treści na ogólnikowe fakt-sprawdzone brednie potrafi przedłużyć recovery o kolejne kwartały. Dlatego podzieliłem diagnozę na cztery warstwy: ruch, zapytania, strony i konkurencja.

Warstwa 1: profil ruchu

W Search Console porównałem 28 dni przed aktualizacją z 14 dniami po (bo cykle indeksacji potrzebują czasu). Kluczowa obserwacja: spadek impressions wyniósł -34%, ale spadek kliknięć -62%. Oznacza to, że Google nadal pokazywał nasze strony w wynikach, ale na słabszych pozycjach (z pierwszej trójki wypadaliśmy średnio na pozycję 11 — 14, a więc w stronę drugiej strony). Jednocześnie średnia pozycja dla zapytań z intencją komercyjną („najlepsze”, „recenzja”, „porównanie”) spadła z 4,2 na 9,8 — trzy razy więcej niż w przypadku zapytań informacyjnych („jak”, „co to”, „dlaczego”).

Ten wzorzec — selektywny spadek na zapytaniach komercyjnych — to klasyczny sygnał, że update uderzył w trust signals na zapytaniach YMYL-adjacent i w obszarach, gdzie Google chce widzieć realną ekspertyzę produktową, a nie kompilację sto innych blogów. Nie był to więc update czysto techniczny ani czysto linkowy. Był to update jakości i zaufania.

Warstwa 2: zapytania — które tematy straciły, a które przetrwały

Wyeksportowałem z GSC wszystkie zapytania z co najmniej 100 impressions w miesiąc przed aktualizacją i zrobiłem kolumnę delta dla każdego z nich. Ponad 5800 zapytań, dziewięć klastrów tematycznych. Po posortowaniu po procentowej zmianie kliknięć zobaczyłem trzy grupy:

Grupa A — zapadła się o 70 — 85%. Rankingi narzędzi („top 10 narzędzi do X”), porównania („A vs B”), alternatywy („alternatywy dla Y”). Tu był epicentrum spadku.
Grupa B — spadła o 30 — 55%. Poradniki „jak” i tutoriale krok po kroku. Średnio niegroźnie, ale boleśnie.
Grupa C — bez zmian lub na plus. Definicje, słowniczki, treści edukacyjne „co to jest X”. Część z nich wręcz zyskała — prawdopodobnie dlatego, że konkurencyjne strony straciły i Google musiał kogoś promować.

Wniosek był brutalny, ale jasny: Google uznał, że nasze recenzje i rankingi nie prezentują realnego doświadczenia z produktami. I miał trochę racji. W niektórych recenzjach copywriterzy faktycznie nigdy nie używali opisywanego narzędzia. To był problem jakości treści, nie techniczny.

Warstwa 3: strony — które URL-e są zdrowe, a które toksyczne

Trzecia warstwa diagnozy to analiza per URL. Zidentyfikowałem trzy archetypy:

Stabilne flagi. Około 140 artykułów straciło mniej niż 20% ruchu. Głównie poradniki pisane przez naszego redaktora naczelnego (który sam używał opisywanych narzędzi) oraz teksty z sekcjami „własne zdanie” i „co bym zrobił inaczej”.
Poważnie ranne. Około 290 artykułów straciło 40 — 70%. Dobrze napisane pod kątem SEO, ale generyczne — czyli technicznie OK, merytorycznie powierzchowne.
Obciążenie netto. Około 190 artykułów straciło ponad 75% ruchu. Cienka treść, dużo AI-only generowanego materiału sprzed audytu, stare posty sprzed 2021 roku bez aktualizacji.

Ta trzecia grupa stała się pierwszym celem działań naprawczych — nie przez masowe usunięcie, lecz przez świadomą selekcję. O tym w sekcji strategii. Jeśli chcesz zobaczyć pełną metodykę klasyfikacji URL, rozpisałem ją w praktycznym audycie SEO dla WordPressa.

Warstwa 4: konkurencja — kto wygrał, kto przegrał

Czwarta warstwa: kogo Google promował zamiast nas. W Ahrefs sprawdziłem, dla 50 najważniejszych zapytań komercyjnych, kto wszedł do pierwszej dziesiątki w miejsce naszych stron. Schemat był jednoznaczny:

W 34 z 50 zapytań wypchnęły nas strony z oryginalnym contentem produktowym — recenzje ze screenami z własnych kont, opisami konkretnych workflowów, komentarzami od realnych użytkowników.
W 9 na 50 pojawiły się duże autorytetowe serwisy tematyczne, które miały silne backlinki i długą historię w niszy.
W 7 na 50 — niespodzianka: małe, niszowe blogi z jednym bardzo dobrym artykułem, bez backlinków, ale z ewidentnym pierwszorzędnym doświadczeniem autora.

Ta ostatnia obserwacja była kluczowa. Google w tym Core Update dał ogromną wagę temu, co w wytycznych nazywa first-hand experience. Oficjalne wyjaśnienie znajdziesz w dokumentacji Google Search Central o Core Updates. Nasza strategia musiała być zbudowana wokół właśnie tego — doświadczenia z pierwszej ręki, nie syntetycznych kompilacji.

Strategia recovery — cztery filary

Po diagnozie przygotowałem 14-stronicowy dokument strategii, który zespół zatwierdził w całości. Strategia była zbudowana wokół czterech filarów, nazwanych krótko: Tnij, Pogłębiaj, Udowadniaj, Łącz. Każdy z nich dostał własnego właściciela w zespole, własny KPI i własny budżet czasowy w miesiącu.

Filar 1 — Tnij (content pruning)

Z 190 artykułów zaliczonych do „obciążenia netto” postanowiliśmy wykonać następujące ruchy: 68 usunąć bezpowrotnie (z redirect 410 lub 301 do najbliższego tematycznie), 74 połączyć w większe publikacje typu pillar (consolidation), a 48 przeredagować od zera z podpisem konkretnego autora i dowodami. Brzmi radykalnie — ale tylko tak można było zdjąć z całej domeny ciężar jakościowego balastu. Content pruning nie jest modą; jest matematyką. Jeśli domena ma 620 artykułów, a 190 z nich Google ocenia jako słabe, to średnia jakości domeny cierpi — nawet jeśli masz 100 świetnych tekstów.

Filar 2 — Pogłębiaj (content depth)

Dla 290 „poważnie rannych” artykułów opracowaliśmy playbook pogłębiania. Dla każdego tekstu redaktor naczelny odpowiadał na cztery pytania: „Co tu brakuje z perspektywy osoby, która faktycznie używała produktu?”, „Jaką własną obserwację możemy tu dopisać?”, „Jaki screen, jakie dane, jakie liczby możemy dołożyć?”, „Co jest dezinformacją lub powierzchownością, którą trzeba uczciwie poprawić?”. W efekcie artykuły rosły średnio z 1400 słów do 2800 słów — ale nie przez watę, tylko przez realną wartość. Szczegółowy szablon znajdziesz w przewodniku pisania artykułów SEO z prawdziwym E-E-A-T.

Filar 3 — Udowadniaj (experience signals)

To był najważniejszy — i najczęściej pomijany w typowym recovery — filar. Wprowadziliśmy obowiązkowe elementy w każdym artykule recenzyjnym i porównawczym: screen z własnego konta (nie stockowy z marketing-site vendora), sekcję „Nasze doświadczenie po X tygodniach używania”, wskazanie konkretnego workflowu, który autor wykonał ręcznie, oraz — co najważniejsze — uczciwe wskazanie wad produktu, które nie pojawiają się na stronie producenta. Żaden z tych elementów nie jest rewolucją. Ale razem tworzą sygnał, którego Google w 2024 roku bardzo łaknął.

Filar 4 — Łącz (internal linking i topical clustering)

Czwarty filar: reorganizacja struktury linkowania wewnętrznego wokół klastrów tematycznych. Przed aktualizacją mieliśmy 620 artykułów, które linkowały do siebie dość chaotycznie — średnio 2,3 linki wychodzące per artykuł, często do losowych „polecanych”. Po reorganizacji każdy artykuł dostał przypisaną kategorię klastra i linkował do artykułu-flagi (pillar) swojego klastra, do dwóch artykułów poziomych z tego samego klastra i do jednego artykułu z powiązanego klastra. Efekt: czytelna architektura informacji, która pozwala Google jednoznacznie ocenić, w czym dana domena jest ekspertem.

Timeline 6 miesięcy — miesiąc po miesiącu

Teraz konkrety. Poniżej rozpisuję, co działo się w każdym z sześciu miesięcy recovery, z jakimi metrykami, jakimi problemami po drodze i jakie były największe zwroty akcji.

Miesiąc 1 — triage i pruning

Pierwszy miesiąc był najbardziej niewdzięczny. Zero publikacji nowego contentu. Cały zespół pracował nad klasyfikacją URL-i, selekcją artykułów do cięcia, planem redirectów i mapowaniem klastrów. Pod koniec miesiąca wdrożyliśmy 68 usunięć (z 410 dla rzeczy kompletnie martwych i 301 dla tych z backlinkami) oraz pierwszą falę 20 consolidacji. Wskaźniki: ruch organiczny nadal -58% względem stanu sprzed update, ale tempo spadku zatrzymało się. Crawl stats w GSC pokazały pierwszy pozytywny sygnał — Googlebot zwiększył częstotliwość odwiedzin na artykułach, które zaczęliśmy pogłębiać.

Miesiąc 2 — pogłębianie i pierwsze zwroty

W drugim miesiącu zespół pogłębił 42 artykuły z grupy „poważnie ranne” i opublikował 6 nowych tekstów — wszystkie zbudowane zgodnie z nowym playbookiem (z dowodami użycia, screenami, wadami). Wdrożono również pierwsze restrukturyzacje linkowania wewnętrznego w dwóch największych klastrach. Efekt: ruch -43% względem baseline sprzed update, ale +36% względem dna z pierwszego miesiąca. Zaczęły wracać pozycje na niektórych zapytaniach „jak” — grupa B odzyskiwała szybciej niż grupa A, zgodnie z oczekiwaniem.

Miesiąc 3 — tempo i pierwsze przebicia na komercjach

Trzeci miesiąc to pełne tempo: 78 pogłębień, 11 nowych artykułów, zakończenie restrukturyzacji linkowania w czterech klastrach. Najważniejszy moment: w połowie miesiąca nastąpił mały, niezapowiedziany ranking update Google i kilkanaście naszych artykułów komercyjnych z grupy A wskoczyło z pozycji 12 — 18 do 5 — 9. To był pierwszy sygnał, że strategia działa w obszarze komercyjnym, nie tylko informacyjnym. Ruch organiczny na koniec miesiąca: -24% względem baseline. Zespół po raz pierwszy od trzech miesięcy zaczął oddychać.

Miesiąc 4 — nowe publikacje i stabilizacja

W czwartym miesiącu przesunęliśmy akcent z remontowania starych na tworzenie nowych. Opublikowaliśmy 24 nowe artykuły, z czego 14 komercyjnych i 10 informacyjnych — wszystkie zbudowane od zera wokół nowego standardu. Zaczęliśmy też pierwsze eksperymenty z formatami wspierającymi doświadczenie: krótkie osadzone loomy i wideo (15 — 40 s), galerie screenów, sekcje „Z naszej praktyki”. Ruch: -9% względem baseline.

Miesiąc 5 — pierwszy miesiąc nad kreską

Piąty miesiąc przyniósł moment, na który wszyscy czekali. 21 dnia miesiąca dzienny ruch organiczny przekroczył po raz pierwszy dzienny średni ruch sprzed Core Update. Nie był to jeszcze wynik miesięczny (kończyliśmy -2%), ale trendowo było jasne, że recovery jest praktycznie zakończona i wchodzimy w fazę wzrostu. Opublikowaliśmy 28 nowych artykułów i pogłębiliśmy ostatnie 48 starych, zamykając filary „Tnij” i „Pogłębiaj” dla całej domeny.

Miesiąc 6 — wzrost ponad baseline

Szósty miesiąc zamknął kwestię recovery i otworzył nową fazę. Ruch +14% względem stanu sprzed Core Update, przychody +22% (wyższe niż ruch, bo trafialiśmy z powrotem na komercyjne zapytania o wyższej wartości EPMV), średnia pozycja dla zapytań komercyjnych 3,9 (wcześniej 4,2 — czyli lepiej niż przed update). W Search Console liczba zapytań, dla których jesteśmy w pierwszej trójce, wzrosła o 38% względem baseline.

Tabela wyników — przed, po i miesiąc po miesiącu

Poniżej zbiorcze zestawienie najważniejszych metryk — stan sprzed Core Update, dno (koniec miesiąca 1) oraz każdy kolejny miesiąc recovery.

Metryka	Przed CU	M1 (dno)	M2	M3	M4	M5	M6
Sesje organiczne / mies.	380 000	160 000	217 000	289 000	346 000	372 000	433 000
Zmiana vs. baseline	0%	-58%	-43%	-24%	-9%	-2%	+14%
Impressions (GSC)	4,8 mln	3,2 mln	3,9 mln	4,6 mln	5,1 mln	5,4 mln	5,9 mln
Średni CTR	2,4%	1,7%	2,0%	2,4%	2,7%	2,9%	3,1%
Śr. pozycja (komerc.)	4,2	9,8	8,1	5,6	4,6	4,1	3,9
Zapytania w top 3	1 140	420	610	890	1 180	1 390	1 575
Przychód (indeks)	100	29	48	71	89	101	122
Publikacje w miesiącu	16	0	6	11	24	28	22
Pogłębienia w miesiącu	—	18	42	78	63	48	0

Najważniejsza obserwacja z tabeli: przychód rósł szybciej niż ruch. To klasyczny efekt odzyskiwania komercyjnych zapytań — jeden klik z zapytania „najlepszy X” jest warty kilka razy więcej niż klik z zapytania informacyjnego. Dlatego firmy, które po Core Update tną wyłącznie na metryce „ruch”, często błędnie oceniają skalę strat biznesowych.

Recovery Playbook — numbered framework

To jest sekcja, po którą prawdopodobnie przyszedłeś. Poniżej framework w 10 krokach — uporządkowany, praktyczny, mający odpowiedź na każde „co teraz?” w trakcie recovery. Możesz go zaadaptować w większej lub mniejszej skali, ale nie polecam pomijać żadnego kroku.

Zamroź publikacje na 14 — 21 dni. Nie publikuj nowego contentu, dopóki nie masz diagnozy. Publikowanie w czasie aktywnego kryzysu jakościowego tylko dokłada Google paliwa do niższej oceny domeny.
Zrób diagnozę w czterech warstwach. Ruch, zapytania, URL-e, konkurencja. W tej kolejności. Każdy skrót na tym etapie mści się przez kolejne miesiące.
Zaklasyfikuj każdy URL do jednej z trzech grup. Stabilna flaga, poważnie ranny, obciążenie netto. Nie ma grupy czwartej. Każda próba wymyślania niuansów sklasyfikowania oznacza, że unikasz decyzji.
Zdecyduj, co tniesz. Usuń (410), przekieruj (301), skonsoliduj. Dla obciążenia netto typowo 40% usuwasz, 40% konsolidujesz, 20% przerabiasz od zera.
Zdefiniuj jeden wspólny playbook pogłębiania. Cztery pytania, jeden szablon, zero uznaniowości. Copywriter nie może sam decydować, co znaczy „pogłębienie”.
Wprowadź obowiązkowe experience signals. Screen z własnego konta, sekcja „nasze doświadczenie”, wskazanie konkretnego workflowu, uczciwe wady. W każdym artykule recenzyjnym, bez wyjątków.
Zreorganizuj linkowanie wewnętrzne wokół klastrów. Pillar w centrum, satelity linkują do pillara i do siebie, cross-cluster tylko świadomie. Bez chaosu „polecanych”.
Planuj tempo w cyklach dwutygodniowych. Nie planuj sześciu miesięcy z góry, bo sytuacja się zmieni. Planuj dwa tygodnie, mierz, koryguj, planuj kolejne dwa.
Mierz trend, nie moment. Recovery nie jest liniowa. Są dni spadków w środku wzrostu. Patrz na 7-dniowe średnie kroczące, nie na dzisiejszy słupek.
Wznów publikacje nowego contentu dopiero od trzeciego miesiąca. Pierwsze dwa miesiące — wyłącznie czyszczenie i pogłębianie. Nowe publikacje przed czasem rozcieńczają wysiłek i utrudniają Google odczytanie sygnału poprawy jakości domeny.

Najczęstsze błędy w recovery — czego nie robić

W trakcie tego projektu, a także w kilkunastu innych recovery-case, zidentyfikowałem listę błędów, które powtarzają się niemal zawsze. Jeśli twój serwis właśnie dostał Core Update, przeczytaj tę sekcję zanim cokolwiek klikniesz.

Błąd 1 — masowe usuwanie treści „na wszelki wypadek”. To najczęstszy i najbardziej destrukcyjny odruch. „Na pewno coś było nie tak, więc usuńmy ostatnie 200 artykułów”. Efekt: tracisz backlinki, ruch long-tail i trust signals. Usuwaj wyłącznie po diagnozie, z konkretnym uzasadnieniem per URL.

Błąd 2 — dodawanie „AI-generated waty” do starych tekstów. Niektóre zespoły, żeby szybko zwiększyć długość tekstów, dolewają akapity wygenerowane przez LLM bez weryfikacji. Google rozpoznaje takie rozdmuchiwanie praktycznie bez problemu i karze za nie drugą falą spadku w kolejnym Core Update.

Błąd 3 — zmiana domeny lub masowa migracja struktury URL. W panice część serwisów decyduje się na migrację na nową domenę lub zmianę struktury permalinków. To zwykle pogarsza sytuację o 3 — 6 miesięcy, bo do problemu jakości dokłada problem technicznego reindexu.

Błąd 4 — masowe kupowanie linków. „Skoro coś nas uderzyło, to zbudujmy linki”. W przypadku Core Update, który uderza w jakość treści i experience signals, backlinki nie są w ogóle lekarstwem. W najgorszym wypadku dołożysz sobie karę manualną.

Błąd 5 — czekanie na „następny update, który to odkręci”. Google nie odkręca Core Updatów. Każdy kolejny update bazuje na aktualnym stanie domeny. Jeśli przez trzy miesiące siedzisz z założonymi rękami, to w następnym update zobaczysz albo dalszy spadek, albo stabilizację na niższym pułapie — ale nie cud.

Błąd 6 — mylenie Core Update ze spam update. Core Update dotyczy jakości całej domeny i doświadczenia użytkownika. Spam update — manipulacyjnych praktyk i nienaturalnych linków. Lekarstwa są inne. Diagnoza musi zacząć od identyfikacji, z którym typem update masz do czynienia. Pomaga tu lektura oficjalnego komunikatu na blogu Google Search Central Blog — zawsze po aktualizacji pojawia się tam opisująca ją notka.

Błąd 7 — ignorowanie sygnałów z najbardziej stabilnych artykułów. Stabilne flagi — teksty, które nie straciły — są ogromną biblioteką informacji o tym, co Google ceni w twojej domenie. Jeśli spojrzysz na nie uważnie, znajdziesz tam wzorce, które powinieneś powielić w reszcie serwisu. Większość zespołów tego kroku nie wykonuje — i traci najprostszy dostęp do recepty.

FAQ — 8 najczęściej zadawanych pytań

Ile trwa średnio recovery po Google Core Update?

Typowo 3 — 9 miesięcy, zależnie od skali spadku i tempa wdrożenia działań naprawczych. W naszym case pełna recovery zajęła 6 miesięcy przy spadku -62% i zaangażowanym zespole czterech osób. Mniejsze spadki (-20 do -35%) domy kończą w 8 — 12 tygodni, jeśli działają od razu.

Czy warto usuwać stare artykuły po Core Update?

Tylko te, które zidentyfikujesz jako „obciążenie netto” po rzetelnej klasyfikacji. Masowe usuwanie bez diagnozy to jeden z najgorszych ruchów. Z kolei selektywne usuwanie 10 — 25% domeny (z odpowiednimi redirectami) regularnie przyspiesza recovery o kilka tygodni.

Czy Core Update może być w pełni cofnięty?

Nie — Google nie cofa Core Update jako takiego. To, co się cofa, to pozycja twojej domeny w ocenie jakości — w kolejnych Core Updatach lub rankingach bieżących. Jeśli wykonasz pracę, kolejne updaty przyniosą poprawę, czasem nawet skokową. Ale nie oczekuj jednego dnia X, w którym „Google wszystko oddaje”.

Czy muszę czekać na kolejny Core Update, żeby zobaczyć efekty?

Nie. Google rerankinguje strony w sposób ciągły, nie tylko podczas nazwanych Core Updatów. W naszym case pierwsze poważne poprawki pozycji przyszły w miesiącu 3, między oficjalnymi Core Updatami. Kolejne updaty potrafią dać skokowy przyrost — ale są raczej akceleratorem niż jedynym źródłem zmian.

Czy AI-generated content jest problemem sam w sobie po Core Update?

Nie sam w sobie. Problem mają treści bez wartości dodanej — niezależnie, czy napisał je człowiek, czy LLM. AI-content, który przechodzi przez realne ręce redaktora, jest pogłębiany o doświadczenie i sprawdzane są fakty, radzi sobie dobrze. AI-content, który wychodzi prosto z modelu bez redakcji, jest zwykle pierwszym kandydatem do grupy „obciążenie netto”.

Ile osób potrzebuję w zespole do recovery na 600 artykułów?

Rozsądne minimum to redaktor naczelny, dwóch copywriterów i specjalista SEO na pół etatu. Można to zrobić w dwie osoby, ale wydłuża to proces o 40 — 60%. Kluczowy jest redaktor naczelny — to on decyduje o klasyfikacji URL-i i jakości pogłębień. Ta rola nie daje się delegować do freelancerów.

Czy restart domeny na nowej nazwie to dobry pomysł?

Rzadko. W około 90% przypadków, które widziałem, migracja na nową domenę pogarsza sytuację, bo traci się backlinki i historię domeny. Sensowne uzasadnienie dla migracji to tylko dwie sytuacje: kara manualna, której nie da się zdjąć, lub totalnie chybiona nazwa domeny (np. literówka, słabe SEO-friendliness).

Jak zmierzyć, że recovery postępuje, skoro metryki skaczą dzień w dzień?

Używaj 7-dniowej średniej kroczącej dla sesji organicznych, impressions i kliknięć z GSC. Patrz na trend tygodniowy, nie dzienny. Dodatkowo śledź liczbę zapytań w top 3 i top 10 — te metryki są mniej zmienne i szybciej pokazują, że jakość domeny rośnie, zanim przełoży się to na ruch.

Dlaczego ten konkretny Core Update uderzył w content siteʼy

Żeby zrozumieć, dlaczego strategia w czterech filarach zadziałała, warto spojrzeć na ten Core Update w szerszym kontekście. W ciągu 18 miesięcy poprzedzających aktualizację, w angielskojęzycznej części internetu głośno mówiło się o zjawisku forum-heavy SERPs — Google zaczął masowo promować Reddit, Quora i tematyczne fora zamiast klasycznych content sitéʼów. Powód, przynajmniej oficjalnie podawany w komunikatach Google Search Central, był prozaiczny: użytkownicy coraz częściej do zapytań typu „najlepsze X” dopisywali słowo reddit. Algorytm to wychwycił i zaczął nagradzać treści z elementem realnego doświadczenia społeczności.

Ten sam mechanizm — w mniejszej skali, ale dokładnie ten sam — zadziałał w polskim searchu przy Core Update, który opisuję. Google zaczął premiować strony, które sygnalizowały realne doświadczenie, a deprecjonować te, które brzmiały jak wygenerowana kompilacja dziesięciu innych blogów. Ponieważ nasz serwis w dużej części wpisywał się w drugi wzorzec — z prostego, komercyjnego powodu: content był produkowany szybko, żeby pokrywać kolejne nisze — dostał w zęby proporcjonalnie do skali tego niedoboru doświadczenia.

Nauka z tego jest taka: Core Update prawie nigdy nie „wybiera cię losowo”. Niemal zawsze uderza w konkretny, identyfikowalny wzorzec jakościowy w twoim serwisie. Jeśli nie umiesz zidentyfikować tego wzorca w pierwszych 72 godzinach, prawdopodobnie nie diagnozujesz wystarczająco głęboko. Nasza diagnoza w czterech warstwach była konkretnie zaprojektowana tak, żeby ten wzorzec dało się wyłuskać — i to właśnie w warstwie czwartej (konkurencja, kto wygrał), wzorzec pokazał się jednoznacznie.

Budżet projektu — ile realnie kosztowała ta recovery

W kwestii kosztów często spotykam nieporozumienia. Ludzie myślą, że recovery po Core Update wymaga agencji za 30 tysięcy złotych miesięcznie albo armii freelancerów. W praktyce projekt, który opisuję, kosztował klienta w sumie około 72 000 zł netto rozłożone na 6 miesięcy — i większość tej kwoty to były pensje ludzi już pracujących w firmie, plus moje konsultacje na pół etatu. Rozbicie wygląda tak:

Konsultacje SEO (ja, 20 godzin miesięcznie przez 6 miesięcy, stawka 250 zł/h): 30 000 zł.
Podwyżka redaktora naczelnego o 20% na czas projektu (kwota x 6 miesięcy): 18 000 zł.
Dodatkowe godziny copywriterów na pogłębianie (średnio 30 godzin miesięcznie ekstra, przez 5 miesięcy): 15 000 zł.
Subskrypcje narzędzi (Ahrefs, Screaming Frog, Looker Studio konfiguracja): 6 000 zł łącznie.
Zakup testowych kont produktów, które faktycznie chcieliśmy recenzować (żeby móc dodać screeny i realne doświadczenie): 3 000 zł.

Gdy porównasz to z odzyskanym przychodem (po miesiącu 6 serwis generował o 22% większy przychód niż przed Core Update, co w skali roku oznaczało dla klienta dodatkowe kilkaset tysięcy złotych), ROI wychodzi skrajnie pozytywny. Ale to nie jest sedno tej sekcji. Sedno jest takie, że recovery nie jest projektem finansowo niedostępnym — jest projektem czasowo wymagającym. Największym kosztem jest uwaga zespołu, nie budżet.

Narzędzia, które realnie wykorzystaliśmy

Lista narzędzi w takich projektach łatwo puchnie do absurdalnych rozmiarów. Żeby dać konkret, co naprawdę było potrzebne:

Google Search Console — podstawa. Wszystkie analizy zapytań, impressions, CTR i średnich pozycji robione były tutaj. Eksport do CSV + pivot w Excelu wystarcza na 90% potrzeb.
Google Analytics 4 — do monitoringu sesji, behavioral data i segmentacji użytkowników per grupa zapytań. Nie do samej oceny recovery (bo GA4 potrafi być mylący w dziennych fluktuacjach), ale do rozpoznawania, jakie segmenty odwiedzających wracają.
Ahrefs (Content Explorer i Site Explorer) — do analizy, kto wygrał zamiast nas. Sprawdzenie 50 najważniejszych zapytań i zmapowanie zwycięskich konkurentów zajęło około 8 godzin.
Screaming Frog — do pełnego crawla domeny przed i po zmianach, żeby zweryfikować redirecty, kanoniczne, linkowanie wewnętrzne, orphan pages.
RankMath (WordPress) — plugin SEO, w którym zarządzaliśmy meta tagami, redirectami wewnętrznymi i schemą Article.
Looker Studio — jeden dashboard, na którym redaktor naczelny i ja widzieliśmy w czasie rzeczywistym 7-dniowe średnie kroczące sesji, impressions, CTR per klaster tematyczny.

Świadomie nie używaliśmy żadnego „AI SEO audit tool” ani „AI content optimizer”. W tak wrażliwym momencie dla domeny chcieliśmy mieć pełną kontrolę nad decyzjami, nie czarne skrzynki wypluwające rekomendacje.

Trzy kluczowe lekcje dla zespołu po projekcie

Po zamknięciu szóstego miesiąca poprosiłem redaktora naczelnego, żeby spisał trzy najważniejsze lekcje dla siebie i zespołu. Oto one, w jego sformułowaniu (z drobną redakcją):

Lekcja 1: jakość jest tańsza niż ilość. Przed Core Update publikowaliśmy 16 artykułów miesięcznie. Po recovery — średnio 14, ale z dwukrotnie większą głębokością i dowodami użycia. Efekt dla ruchu i przychodów: znacznie lepszy. Nauka: następnym razem nie kalibrujemy zespołu na ilość publikacji, tylko na głębokość i wiarygodność każdego tekstu.

Lekcja 2: redaktor naczelny nie może być „tylko edytorem”. Kluczowa rola redaktora w tym projekcie nie była edytorska — była strategiczna. Klasyfikacja URL-i, decyzje o cięciu, priorytety pogłębień, koordynacja linkowania wewnętrznego. To nie jest praca dla osoby, która w firmie nazywa się „copywriterem seniorem” — to jest etat osoby z realnym autorytetem do podejmowania decyzji.

Lekcja 3: miary ilościowe bez miar jakościowych prowadzą na manowce. W pierwszych miesiącach po aktualizacji kusiło nas, żeby optymalizować pod „liczba publikacji w miesiącu”, „liczba aktualizacji w miesiącu”, „liczba dodanych wewnętrznych linków”. To byłyby fałszywe cele. Prawdziwym celem była liczba artykułów, które rzeczywiście dowodziły doświadczenia autora — i tę liczbę zaczęliśmy mierzyć ręcznie, na koniec każdego tygodnia, w trzypunktowej skali (0 = brak dowodu, 1 = słaby dowód, 2 = mocny dowód, np. screen z własnego konta plus konkretny workflow). Bez tej miary jakościowej nie byłoby recovery.

Jak wygląda serwis 18 miesięcy po recovery

Dopisuję tę sekcję z perspektywy dzisiejszej, czyli około roku po zamknięciu oficjalnego projektu recovery. Serwis w momencie pisania tego case study notuje ruch organiczny na poziomie +47% względem stanu sprzed Core Update. Przeszedł przez trzy kolejne Core Updaty w ciągu tego roku — i przy każdym z nich albo pozostawał stabilny, albo zyskiwał. Zespół wygląda tak samo jak w miesiącu 6 recovery; rotacja była zerowa. Standardy jakości, które wprowadziliśmy w trakcie projektu, są do dzisiaj fundamentem pracy nad każdym nowym artykułem.

Najważniejsza obserwacja długofalowa: serwis nie tylko odzyskał pozycje, ale stał się odporniejszy na kolejne aktualizacje w sposób, którego nie dawało się osiągnąć „normalną” ewolucją. Core Update był w gruncie rzeczy bolesnym, ale wartościowym audytem zewnętrznym — Google pokazał zespołowi, gdzie byli słabi, w sposób, którego sami sobie by nie uświadomili. Z tej perspektywy, gdybym miał dzisiaj wyliczać koszty i korzyści projektu, musiałbym doliczyć do korzyści również to, co się stało później — trzy bezpieczne Core Updaty pod rząd, odporna architektura contentu, zgrany zespół. To jest wartość, której nie da się uzyskać przez pisanie kolejnych artykułów w spokojnych miesiącach.

Co dalej — po recovery nie wraca się do punktu wyjścia

Największa lekcja z tego projektu — i z każdego recovery, które prowadziłem — jest taka: po pełnej recovery serwis nie wraca do punktu wyjścia. Wraca do innego, lepszego miejsca. Nie tylko dlatego, że ruch urósł o kilkanaście procent ponad baseline, ale przede wszystkim dlatego, że w trakcie pracy zespół wymyśla się na nowo. Standardy jakości podniesione w kryzysie zostają na stałe. Playbooki spisane podczas paniki zostają w firmie. Redaktor naczelny, który nauczył się diagnozować URL-e w trzech warstwach, nigdy już nie publikuje artykułu bez screena z własnego konta.

To jest prawdziwy zysk z recovery. Ruch wraca, przychody wracają, pozycje wracają — ale to, co zostaje najgłębiej, to nowy system pracy. Serwis, który kiedyś dostał w zęby od Core Update i wyszedł z tego silniejszy, jest potem odporny na kolejne aktualizacje w sposób, w jaki młode serwisy nie są. Nie dlatego, że Google ich mniej uderzy — ale dlatego, że kiedy uderzy, zespół wie dokładnie, co robić. Ma listę. Ma playbook. Ma przeżyte doświadczenie. Ma rezerwę.

Jeśli właśnie przechodzisz recovery albo widzisz pierwsze sygnały, że twoja domena wchodzi w niepokojący trend — nie zwlekaj z diagnozą. Nie czekaj na oficjalny komunikat Google, że Core Update dobiegł końca. Nie czekaj, aż zespół sam się zorganizuje. Diagnozuj w czterech warstwach, klasyfikuj w trzech grupach, działaj w czterech filarach — i planuj w cyklach dwutygodniowych. Sześć miesięcy to dużo, ale to realny horyzont. Widziałem go wiele razy. Widziałem też, że zaczyna się w jeden, konkretny dzień — ten, w którym właściciel serwisu przestaje obrażać się na algorytm i siada do pracy nad jakością.

Ten dzień może być dzisiaj.