Google vs scrapery. Chronologia polityki anty-scrapowej Google

W ciągu 12 miesięcy Google wykonało serię ruchów, które z perspektywy czasu wyglądają jak skoordynowana kampania:

1. Wymóg JavaScriptu w wyszukiwarce
2. Wdrożenie SearchGuard
3. Wyłączenie parametru &num=100
4. Oferta pracy na stanowisko wprost nazwane „anty-scrapingowym”
5. Pozew sądowy – pierwszy tego rodzaju, oparty na przepisach prawa autorskiego skrojonych pierwotnie pod piractwo płyt DVD.

Staram się zrekonstruować chronologię na podstawie publicznie dostępnych źródeł.

Tabela chronologiczna

Google wymaga JavaScriptu (15 stycznia 2025)

Google zaczęło wymagać włączonego JavaScriptu w wyszukiwarce 15 stycznia 2025 roku. Po wyłączeniu JavaScript, Google wyświetla informacje jak na tej stronie: https://www.google.com/httpservice/retry/enablejs.

Chociaż moje testy pokazują, że jest możliwe wyświetlanie wyników wyszukiwania z wyłączonym JavaScript 🙂

W e-mailu do TechCrunch rzecznik Google napisał¹

Włączenie JavaScriptu pozwala nam lepiej chronić nasze usługi i użytkowników przed botami oraz rozwijającymi się formami nadużyć i spamem

Chociaż osobiście uważam, że głównym powodem była chęć zablokowania botów oraz scraperów, które pobierających dane z wyników wyszukiwania. Wymóg ten zwiększył też ogólny poziom bezpieczeństwa wyszukiwarki.

Wymuszenie JavaScript spowodowała potrzebę przebudowy wielu zewnętrznych narzędzi SEO i API analitycznych, które do tej pory pobierały dane z Google za pomocą szybkich, statycznych zapytań HTML bez uruchamiania JS.

Google wdraża SearchGuard (styczeń 2025)

W tym samym miesiącu Google wdrożyło dla wyszukiwarki system znany jako „SearchGuard”, który jest bezpośrednią ewolucją rozwiązania „BotGuard” przeniesioną z ochrony logowań i YouTube do wyszukiwarki. System zaczął wysyłać do zapytań pochodzących z nierozpoznanych źródeł tzw. „JavaScript challenges”².

W okresie styczeń-grudzień 2025 firmy takie jak SerpApi na bieżąco modyfikowały swoje narzędzia żeby udawać ruch ludzki. Wolumen ruchu SerpApi na serwerach Google wzrósł w tym okresie o 25000% w skali 2 lat³.

Google wyłącza parametr &num=100 (wrzesień 2025)

Parametr &num=100 Google wyłączyło w połowie września 2025 roku. Pierwsze anomalie i testowe wyłączenia specjaliści SEO zaobserwowali 11-12 września, a globalne zablokowanie parametru nastąpiło ok. 14-15 września 2025. Google wprowadziło tę zmianę po cichu, bez wcześniejszych oficjalnych zapowiedzi.

Parametr pozwalał wymusić wyświetlanie 100 wyników na jednej stronie SERP jednym zapytaniem. Dlatego było tak bardzo pożądane przez scraperów. Od kiedy Google wyświetla 10 wyników, to scraperzy muszą wykonać 10x więcej pracy.

Przy okazji usunięcie parametru &num=100 pokazało jak bardzo wiele botów nabijało puste wyświetlenia, dzięki czemu statystyk w Google Search Console chociaż przez chwile były bardziej realne.

Google ogłasza rekrutację analityka anty-scrapingowego (wrzesień 2025)

We wrześniu 2025 roku w Google Careers została opublikowana oferta pracy na stanowisko „Senior Engineering Analyst, Search, Anti-scraper” czyli w bezpośrednim sąsiedztwie czasowym wyłączenia parametru &num=100.

Już wtedy zadawałem pytanie czy „Google oficjalnie idzie na wojne ze scrapingiem?!„

Najciekawsze fragmenty z oferty pracy to:

• Doświadczenie w zakresie analizy zagrożeń, zapobiegania nadużyciom, bezpieczeństwa, analizy sieci, wykrywania oszustw i SEO
• Mierzenie wpływu scraperów na wyniki i skuteczności obrony przed nimi
• Projektowanie, testowanie i wdrażanie nowych reguł i modeli antyscraperskich
• Tworzenie bazy wiedzy o scraperach i taktykach

Google pozywa SerpApi (19 grudnia 2025)

Google złożyło pozew przeciwko SerpApi 19 grudnia 2025 roku w Sądzie Okręgowym dla Północnego Okręgu Kalifornii (sygn. 5:25-cv-10826)⁴.

Google oparło pozew o Sekcję 1201 ustawy DMCA. Przepis stworzony pierwotnie do walki z łamaniem zabezpieczeń DRM na płytach DVD. Google argumentowało, że SerpApi nielegalnie obchodzi SearchGuard, który chroni „dzieła objęte prawem autorskim” takie jak licencjonowane zdjęcia wyświetlane w panelu wiedzy.

To właśnie ten pozew sprawił, że istnienie i nazwa systemu SearchGuard stały się jawne dla opinii publicznej – wcześniej funkcjonował on wyłącznie jako wewnętrzna technologia Google.

Google argumentowało, że ruch generowany przez SerpApi w celu obejścia zabezpieczeń wzrósł o 25 000% w ciągu 2 lat – o czym wcześniej wspominałem – a firma miała wykorzystywać „fałszywe wyszukiwania” do masowego pobierania treści z wyników.

Google zatrudnia analityka ds. anty-scrapingu (styczeń 2026)

4 miesiące po zamknięciu oferty pracy z września 2025 roku, proces rekrutacyjny doczekał się finału. Zrobiłem research na ten temat i okazuje się, że gdzieś blisko 20 stycznia 2026 roku Google na stanowisku „Staff Anti-Scraper Engineering Analyst” zatrudniło Davida Carlo.

Zwracam uwagę, że nazwa stanowiska („Staff Anti-Scraper Engineering Analyst”) różni się od nazwy z ogłoszenia o pracę („Senior Engineering Analyst, Search, Anti-scraper”). Dlatego nie zakładam z całkowitą pewnością, że to dokładnie ta sama oferta pracy ale korelacja czasu wprost może wskazywać, że w Google jednak zatrudnili osobę – de facto – na wyższym stanowisku niż pierwotnie szukali.

Deobfuskacja BotGuard v41 (styczeń 2026)

W styczniu 2026 roku w obiegu publicznym pojawiły się analizy skryptu BotGuard.

Analizy techniczne opisały szczegóły działania systemu: analizę zachowania użytkownika, fingerprinting środowiska przeglądarki, generowanie tokenów kryptograficznych oraz rotację parametrów zabezpieczających jako mechanizm utrudniający stałe obejścia.

To jeden z nielicznych elementów tej chronologii oparty na bezpośredniej analizie technicznej, a nie na oświadczeniach Google czy dokumentach sądowych. Poziom pewności co do szczegółów technicznych jest wysoki ale wciąż brakuje oficjalnego potwierdzenia ze strony Google.

SerpApi składa wniosek o oddalenie pozwu (20 lutego 2026)

20 lutego 2026 roku SerpApi złożyło formalny wniosek o oddalenie pozwu Google, tzw. „Motion to Dismiss”.

Argument SerpApi był taki, że dane wyświetlane w wynikach wyszukiwania są publicznie dostępne oraz SearchGuard nie wykorzystuje kluczy szyfrujących ani haseł w rozumieniu przepisów DMCA dotyczących obchodzenia zabezpieczeń, a Google próbuje wykorzystać prawo autorskie do zmonopolizowania ogólnodostępnych i niechronionych informacji.

Sąd oddala pozew Google (20 lipca 2026)

20 lipca 2026 roku federalna sędzia – Yvonne Gonzalez Rogers – oddaliła pozew Google przeciwko SerpApi.

Wyrok miał dwuczęściową strukturę. Sąd uznał, że DMCA nie chroni narzędzi blokujących dostęp do zwykłych, publicznych danych. Roszczenia dotyczące wyszukiwań z grafikami (np. w panelu wiedzy) zostały odrzucone ale z możliwością poprawienia pozwu przez Google w ciągu 21 dni – pod warunkiem wykazania, że twórcy tych zdjęć rzeczywiście upoważnili Google do wdrożenia SearchGuard w celu ich ochrony.

Najnowsze odkrycie: Google testuje mechanizm /goto?url= (10 lipca 2026)

Podczas gdy sprawa SerpApi toczyła się w sądzie, Google testowało równolegle coś zupełnie innego – nową warstwę ukrywania adresów docelowych w wynikach wyszukiwania.

Mechanizm /goto?url= ukrywa adres docelowy przez co korelacja url=pozycja jest znacznie utrudniona. Dla zwykłego użytkownika nie ma kompletnie żadnej różnicy, bo przekierowanie następuje. Dla scraperów, botów i narzędzi SEO, to następna warstwa do przełamania bezpieczeństwa SERP.

Pierwsze ślady mechanizmu /goto?url= widoczne są w danych Ahrefs już od 5 grudnia 2025 roku, czyli 2 tygodnie przed złożeniem pozwu przeciwko SerpApi.

Mechanizm nie zastąpił istniejącego systemu przekierowań /url? ale został w nim zagnieżdżony jako dodatkowa warstwa. Wygląda mi to na typowy wzorzec ostrożnego wdrażania, które w razie problemów można wycofać bez przebudowy całej infrastruktury.

Postanowiłem przeanalizować mechanizm „goto”. Pozyskałem próbkę 380 linków za pomocą operatora site: i 10 lipca 2026 roku opublikowałem artykuł, w którym rozbieram na czynniki pierwsze mechanizm /goto?url=. Ustaliłem m.in że:

• jest to poprawna struktura Protocol Buffers
• format zaszyfrowanych danych odpowiada wyjściu biblioteki kryptograficznej Tink – wewnętrznego narzędzia Google do szyfrowania z uwierzytelnianiem integralności
• token okazał się deterministyczny, tzn. że ten sam adres zawsze daje identyczny wynik i jest odporny na modyfikacje
• analiza matematycznej zależności między długością tokenu a długością adresu docelowego potwierdziła też, że sam URL jest przed zaszyfrowaniem zapisywany jako ustrukturyzowane pole Protobuf

Oczywiście wprost przyznaję, że wiele elementów mechanizmu pozostaje niewyjaśnionych. Jedynym obszarem wymagającym uwagi jest ruch płatny, w którym /goto pojawia się już w skali milionów wyświetleń.

Skala wdrożenia rosła jednak szybko i w sposób, który wpisuje się w ten sam wzorzec co pozostałe działania opisane w tej chronologii – cicho i bez zapowiedzi.

• W dniu publikacji mojego artykułu z analizą parametru /goto?url= zaindeksowanch było 380 linków
• Do 19 lipca 2026 roku plik robots.txt na google.com nie zawierał informacji związanych z mechanizmem „goto”
• 21 lipca 2026 roku – czyli dzień po wyroku oddalającym pozew przeciwko SerpApi – Google dodało do robots.txt regułę Disallow: /goto?
• Liczba zaindeksowanych linków wzrosła do 3750 w ciągu kolejnych dni (stan na 25 lipca 2026)
• Na czas publikacji tej chronologii, czyli 27.07.2026 operator site:google.com/goto?url= wskazuje już 4120 zaindeksowanych linków z /goto?url=. To daje 370 nowych linków w 2 dni!

Podsumowując chronologię

SearchGuard działa. Wymóg JavaScriptu obowiązuje. Parametru &num=100 już nie ma. Stanowisko Staff Anti-Scraper Engineering Analyst istnieje i jest obsadzone. W tle całkowicie i prawie niezauważony rozwija się kolejny mechanizm „goto” ukrywający adresy URL, którego pełne przeznaczenie na razie znają chyba tylko inżynierowie Google. Opisana tu sekwencja wydarzeń pokazuje, że Google zrobi wiele w celu ochrony SERP.

Pewne rzeczy widać dopiero po czasie, łącząc ze sobą wiele kropek 🙂

1. Artykuł TechCrunch z wypowiedzią rzecznika Google [źródło] ↩︎
2. System zaczął wysyłać do zapytań pochodzących z nierozpoznanych źródeł tzw. „JavaScript challenges” [źródło] ↩︎
3. Google szacuje, że SerpApi wysyła setki milionów zautomatyzowanych żądań dziennie, a ich liczba wzrosła o 25000% w ciągu ostatnich 2 lat [źródło] ↩︎
4. Pozew Google przeciwko SerpApi [źródło] ↩︎