Google Spam Update sierpień 2026 - analiza

Jak przeprowadziłem analizę spadków widoczności?

Zacząłem od wątków z Google Search Central Help Community, w których właściciele serwisów zgłaszali duże spadki widoczności w oknie sierpnia 2026. Każdy nazwany przypadek, dla którego udało się odzyskać publiczny serwis, sprawdziłem niezależnie od treści dyskusji na forum.

1. Struktura URL-i: jaki wzorzec adresów wykorzystuje serwis i ile realnie różniących się wariantów zawiera.
2. Próbka stron: ręczny przegląd reprezentatywnych URL-i z różnych warstw serwisu, nie tylko strony głównej.
3. Timing: czy zgłoszony spadek pokrywa się z 18-21 sierpnia, czy zaczął się wcześniej albo później.
4. Kontrprzypadki: porównanie z serwisami o podobnej geometrii URL-i, które obecnie mają widoczne strony w Google.
5. Manual actions: oddzielenie przypadków ręcznej interwencji Google od przypadków bez potwierdzonej akcji ręcznej.
6. Stan historyczny: sprawdzenie, czy obecny stan serwisu może być już po samodzielnym cleanupie właściciela.

Information / decision delta per URL - najczęstszy powtarzający się wzorzec

Macierz programmatic to zestaw stron, które serwis generuje automatycznie, krzyżując dwa zmienne elementy - np. miasto z usługą albo trasę początkową z docelową. Cały taki zestaw stron nazywam w tekście inventory serwisu. Pojedynczy wzorzec zapisuję jako „miasto x usługa” albo „origin x destination”: każda kombinacja po obu stronach „x” tworzy osobny, indeksowalny adres URL. Information / decision delta per URL sprawdza, co realnie zmienia się dla użytkownika, gdy zmieni się jeden z tych dwóch elementów.

W praktyce podstawiam: Warszawa zamienione na Kraków, kardiolog Warszawa zamienione na kardiolog Kraków, brow lift Turkey zamienione na brow lift Istanbul - i sprawdzam, co się zmienia poza samą nazwą: dane, dostępne opcje, ceny, providerzy, wynik czy decyzja użytkownika. To pytanie o funkcjonalną unikalność (functional uniqueness) - czy strona robi coś innego - a nie o unikalność samego tekstu (textual uniqueness). Strona może mieć 1500 słów osobno napisanego tekstu i nadal pełnić praktycznie tę samą funkcję co dwieście innych adresów.

Google definiuje scaled content abuse jako tworzenie wielu stron przede wszystkim po to, by manipulować rankingiem, a nie pomagać użytkownikom - i wprost dopuszcza, że metodą może być generatywne AI, scraping, automatyczne tłumaczenie albo inna masowa produkcja. Doorway abuse definiuje osobno, jako strony tworzone pod konkretne, podobne zapytania, które prowadzą użytkownika do pośredniej strony mniej użytecznej niż cel docelowy - tu Google nie przypisuje konkretnej metody produkcji. W mojej próbce te dwie kategorie nakładały się najczęściej na jeden wspólny mianownik: liczba indeksowalnych adresów URL rosła szybciej niż informacja przypadająca na każdy kolejny adres.

Dlaczego unikalny tekst nie oznacza unikalnej strony?

Unikalny tekst nie eliminuje functional redundancy, bo tekst i funkcja strony to dwa osobne wymiary: można napisać dla każdej strony osobny akapit, a mimo to prowadzić użytkownika do tej samej usługi i tego samego punktu konwersji. ConsigueMásClientes, chilijska agencja web design, to najlepszy przykład tego rozjazdu w mojej próbce - serwis publikuje wiele landing pages typu web design x gmina: strony są długie, mają osobne copy, obrazy i tytuły, więc nie są klasycznie „thin” w sensie liczby słów.

Dwie strony ConsigueMásClientes mogą różnić się prawie każdym zdaniem i nadal odpowiadać na to samo pytanie decyzyjne użytkownika w ten sam sposób - to widać wprost w audycie, nie tylko w teorii.

Ta sama geometria URL-i, przeciwny wynik - trzy porównania

Ten sam kształt macierzy programmatic - origin x destination, city x specialty, procedure x destination - pojawia się wśród najmocniejszych przypadków spadku i wśród domen, które 31 sierpnia 2026 pozostają widoczne w kontrolnej próbce. W poniższych trzech porównaniach sprawdzam, co różni te grupy poza samą geometrią adresu.

Dlaczego realny produkt nie chroni słabej warstwy SEO wokół niego?

Realny produkt nie chroni słabej warstwy SEO, bo to dwa osobne systemy: baza, katalog czy marketplace mogą być rzetelne, podczas gdy dobudowana wokół nich warstwa treści - blog, opisy, FAQ - powstaje innym procesem i ma inną kontrolę jakości. Z2Market to najlepszy przykład tego rozjazdu w mojej próbce: jest realnym marketplace'em cyfrowych dóbr - kontami, przedmiotami i gift cards - a mimo to w audycie bloga znalazłem obiektywne ślady zautomatyzowanego pipeline'u (procesu produkcji treści), nie tylko „styl AI”.

Doctar.in pokazuje ten sam problem w innej postaci - wprowadza koncept, który nazywam generated-support-layer quality debt. Baza lekarzy jest realna, ale warstwa statystyk, opisów profilu i FAQ generowana wokół niej zawiera sprzeczności, placeholdery i treść powielającą intencje już obsłużone przez stronę katalogową. MyMediTour dokłada trzeci wariant tego samego problemu: część category pages powtarza niemal identyczne sekcje, podczas gdy inne strony tej samej domeny zawierają realne dane partnerskich klinik. Serwisu nie da się uczciwie ocenić po trzech najlepszych ani po trzech najgorszych URL-ach - potrzebna jest ocena audytu treści dla całego inventory.

Dlaczego AI wygląda bardziej jak akcelerator niż wspólny mianownik?

W mojej próbce AI nie okazało się odizolowaną, samodzielną przyczyną spadków - mimo że Google oficjalnie klasyfikuje scaled content abuse niezależnie od metody produkcji i wymienia AI obok scrapingu, automatycznych tłumaczeń oraz masowej produkcji jako jedne z możliwych narzędzi.

Najmocniejsze przypadki tej analizy nie wymagają żadnej hipotezy o AI: Milazzo opiera się na historycznie indeksowalnych route wrapperach, a ConsigueMásClientes na functional redundancy mimo osobno napisanego tekstu. Z2Market jest z kolei najsilniejszym przypadkiem automatyzacji właśnie dlatego, że dowód nie opiera się na ocenie stylu pisania, tylko na obiektywnych artefaktach pipeline'u - powtarzalnych slugach i widocznych znacznikach generowania treści.

Jak locale mnoży bazowe inventory, zamiast być samodzielnym ryzykiem?

Locale mnoży bazowe inventory najprostszym możliwym sposobem: ten sam zestaw stron powiela się pod kolejnymi prefiksami językowymi, więc jeśli bazowa treść jest słaba, słabość rośnie proporcjonalnie do liczby wersji językowych. SmartMak, serwis publikujący duże ilości treści informacyjnych, dobrze to ilustruje - zgłosił ok. 93,8% spadku impressions do 21-22 sierpnia 2026, mimo że tysiące stron pozostawało nadal zindeksowanych, a ten sam strumień artykułów powtarza się w wielu katalogach językowych; część treści pod ścieżką językową, np. /da/blog/..., pozostaje przy tym po angielsku mimo lokalnego prefiksu w adresie.

Milazzo dostarcza ważnego kontrsygnału wobec hipotezy „multilingual samo w sobie szkodzi”: mimo ok. 98-99% spadku głównego hosta właściciel zgłosił, że zlokalizowane subdomeny pozostały relatywnie stabilne. Formalnie zapisuję ten mechanizm jako base inventory quality x locale scale - jeśli strony bazowe niosą realną wartość, z mojej próbki nie wynika analogiczne ryzyko replikacji w kolejnych językach.

Dlaczego agregacja i rewrite nie gwarantują information gain?

Agregacja i rewrite nie gwarantują information gain, bo duża liczba cudzych źródeł może zostać zagregowana, streszczona i przepisana bez utworzenia porównywalnej ilości nowej, niedostępnej gdzie indziej informacji - to zjawisko nazywam source-space compression. Briefed.ro dobrze to ilustruje w mojej próbce: agreguje wiele źródeł na dany temat, dodaje generowane przez AI podsumowania i kontekst, porządkuje oś czasu i porównanie źródeł - to nie jest klasyczny scraper kopiujący treść 1:1, dokłada własną warstwę organizacji informacji.

Serwis zgłosił gwałtowny spadek widoczności na starcie rolloutu, choć sama korelacja czasowa nie rozstrzyga przyczyny. Attribution i przepisanie źródła własnymi słowami mogą przy tym nadal zostawiać większość informacji w tekście pochodzącą z istniejących materiałów.

Jakie inne przypadki warto znać mimo niższej pewności?

Sprawdziłem też kolejnych siedem domen zgłoszonych w tym samym oknie czasowym. Struktura URL-i bywa w nich równie ciekawa jak w głównych case studies, ale timing, przyczyna albo dostępne dane są słabsze, dlatego nie buduję na nich głównej tezy artykułu.

Dlaczego nie każdy spadek z sierpnia 2026 pasuje do tego wzorca?

Trzy przypadki ograniczają tezę tego artykułu i celowo je tu zostawiam, zamiast wybierać wyłącznie potwierdzenia.

• MODNOOR.COM

  Realny producent bez widocznego klastra

  Modnoor to producent oświetlenia z osobnymi produktami WooCommerce, first-party portfolio realizacji i zwykłym blogiem branżowym. W audycie nie znalazłem wyraźnego klastra scaled ani doorway. Właściciel opisuje spadek jako stopniowy, rozpoczęty jeszcze przed update'em i kontynuowany po nim.

• WEBCOMEDIA.NET

  Kontrola techniczna, nie treściowa

  Middleware Clerk/Next.js kierował część żądań do odpowiedzi noindex/nofollow. Po naprawie technicznej, bez przepisania treści, widoczność wróciła szybko. Pokazuje to, że równoczesny z update'em spadek może mieć czysto techniczną przyczynę.

• NIPURN.COM

  Spadek sprzed startu rolloutu

  Nipurn zgłosił ok. 95% spadku impressions ok. 1 sierpnia, ponad dwa tygodnie przed startem 18 sierpnia. W tle był spór o rendering i zmiana wdrożenia z końca lipca. Krytyka AI-slop z forum nie może więc być dowodem, że to konkretnie August Spam Update ukarał ten rodzaj treści.

Jak sprawdzić własny serwis pod kątem information gain per URL?

Sprawdzasz to, porównując pary URL-i z tej samej macierzy programmatic i licząc, ile z poniższych dziewięciu pytań kończy się realną różnicą, a nie tylko podstawionym tokenem. Te pytania spisałem na podstawie przypadków z tej analizy - nie potwierdzają działania konkretnego classifiera Google, ale porządkują priorytet audytu: które części serwisu dokładają URL-e szybciej, niż dokładają im wartości.

Pełny audyt SEO krok po kroku łączy te pytania z danymi z crawla, Search Console i analizą logów serwera, żeby zamiast pojedynczych przykładów ocenić całe inventory.

Co można nazwać faktem, a co pozostaje hipotezą?

W tej analizie rozróżniam cztery poziomy pewności. Mieszanie ich - np. zamiana zgłoszenia właściciela w potwierdzony fakt o przyczynie - jest najczęstszym błędem przy interpretowaniu aktualizacji algorytmu na podstawie forum.

Co ustaliłem

• Google definiuje scaled content abuse i doorway abuse niezależnie od sposobu tworzenia stron.
• W badanej próbce macierz programmatic często rosła szybciej niż information gain przypadający na kolejny URL.
• Ten sam programmatic wzorzec adresu może tworzyć zarówno bardzo słabe, jak i bardzo użyteczne strony.
• Ani AI, ani multilingual nie zostały w tej próbce odizolowane jako samodzielna przyczyna spadku.
• Wartościowy produkt może współistnieć ze słabą warstwą SEO zbudowaną wokół niego.
• Nie każdy spadek widoczności z tego okresu daje się wyjaśnić scaled albo doorway contentem.

Co zostawiam jako hipotezę

• Udział URL-i o niskim zróżnicowaniu w całym hoście może wpływać na dotkliwość spadku w skali serwisu.
• Sprzeczności i placeholdery w warstwie generowanej mogą być sygnałem szerszego problemu jakości, nie potwierdzonym czynnikiem rankingowym.
• Locale może działać jako mnożnik bazowego inventory, przyspieszając ekspozycję jego jakości - dobrej albo złej.
• Doorway i scaled content mogą być praktycznie różnymi manifestacjami jednego problemu: liczba URL-i rośnie szybciej niż ich wartość.

Świadomie nie twierdzę, że August 2026 Spam Update celował w AI, w wielojęzyczność albo w programmatic SEO jako takie, że każda strona typu miasto plus usługa jest doorwayem, że Google mierzy information gain per URL dokładnie w opisany tu sposób, ani że odpowiedź Product Experta na forum jest oficjalnym potwierdzeniem przyczyny przez Google.

Z mojej analizy wynika model użyteczny niezależnie od kolejnych aktualizacji algorytmu. Programmatic stronę oceniam po tym, czy kolejny indeksowalny adres wnosi realnie nowe dane, funkcję albo decyzję. Sama liczba URL-i i unikalność tekstu do tego nie wystarczą. Problem skali potrafi się pojawić nie w samym produkcie, lecz w warstwie SEO dobudowanej wokół niego. AI, tłumaczenia, lokalizacje i agregacja zwiększają zarówno wartość, jak i redundancję information gain per URL - sama technologia nie rozstrzyga, po której stronie znajdzie się konkretny serwis.