← Wszystkie wpisy

Monitoring SERP na dużą skalę po wycofaniu num=100

Śledzenie pozycji w Google na dużą skalę stało się trudniejsze po wycofaniu parametru num=100. Oto jak zespoły inżynieryjne SEO odbudowują infrastrukturę do monitorowania SERP na rok 2026.

Wyzwanie

Jeśli Twój zespół tworzy narzędzia do monitorowania pozycji, dashboardy SEO lub systemy competitive intelligence, rok 2026 uderzył w Waszą ekonomię skali. Google po cichu wycofało w tym roku parametr URL num=100 z Google Search, czyli sztuczkę używaną przez każdy scraper SERP do pobierania 100 wyników w jednym zapytaniu. Teraz to samo pokrycie wymaga dziesięciu requestów zamiast jednego.

To jest ten oczywisty koszt. Ukryte koszty są znacznie gorsze.

Monitorowanie pozycji działa tylko wtedy, gdy widzisz dokładnie taki SERP, jaki zobaczyłby prawdziwy użytkownik w odpowiednim kraju, regionie i mieście. Słowo kluczowe na 4. pozycji w Londynie może zajmować 11. pozycję w Edynburgu i 19. w Belfaście. Lokalne 3-packi, karuzele produktowe, sekcje z wiadomościami, panele wiedzy, AI Overviews. Każdy element SERP zmienia się w zależności od lokalizacji geograficznej i urządzenia. (Scrape.do oszacowało, że na początku 2026 roku AI Overview pojawiało się w około 36% zapytań.) Jeśli Twój scraper przechodzi przez proxy w złym mieście, Twoje dane o rankingach to tylko fikcja podana z pełnym przekonaniem.

Dlatego stabilny produkt SERP w 2026 roku wymaga trzech współpracujących elementów: requestu wyglądającego na poziomie sieciowym jak prawdziwa przeglądarka, proxy zlokalizowanego dokładnie w monitorowanym mieście oraz możliwości renderowania JavaScriptu, gdy Google ładuje połowę wyników po stronie klienta. Pomiń dowolny z nich, a jakość Twoich danych po cichu spadnie.

Podejście FourA

Wąskim gardłem w scrapowaniu SERP na dużą skalę nie jest sam request. Jest nim routing.

Większość własnych pipeline'ów zaczyna ze stałą pulą proxy i traktuje zapytanie jako zmienną. Przy targetowaniu geograficznym Google jest dokładnie odwrotnie. Zapytanie to stała, którą dysponujesz. To proxy jest zmienną, którą musisz precyzyjnie dobrać.

Obserwujemy, że zespoły budujące architekturę na FourA stosują zazwyczaj następujący wzorzec:

  1. Proxy Finder utrzymuje aktywną pulę proxy weryfikowanych świeżymi testami liveness i otagowanych krajem, regionem, miastem oraz ASN. Gdy request musi pochodzić z Manchesteru, Bostonu lub São Paulo, Proxy Finder wybiera węzeł rzeczywiście tam zlokalizowany i aktywny w ostatnim teście. Wybór następuje przed pobraniem, a nie w jego trakcie. Więcej informacji o tym, dlaczego ta warstwa routingu ma znaczenie, znajdziesz w naszym artykule o Smart Proxy Routing.

  2. Single odpowiada za samo pobieranie SERP. W przypadku standardowych wyników organicznych surowy HTML jest w zupełności wystarczający. Ustaw parametr unblocker: true, a request zyska aktualną sygnaturę przeglądarki bez konieczności sprawdzania, którą z nich Google weryfikuje w danym tygodniu. Działanie tej flagi na poziomie sieciowym opisaliśmy w naszym wpisie o Web Unblockerze.

  3. Browser obsługuje te strony SERP, na których kluczowa zawartość pojawia się po wykonaniu kodu JavaScript. AI Overviews, rozszerzone moduły produktowe, zawartość paneli wiedzy, przypięte lokalne 3-packi. Ten sam URL, ten sam cel, ale request przechodzi przez pełną sesję przeglądarki i zwraca w pełni wyrenderowaną stronę. (Do tego dochodzą zrzuty ekranu, które ratują sytuację, gdy SEO lead pyta, dlaczego dashboard wskazuje pozycję #3, a w swojej przeglądarce widzi #6.)

Pojedyncze wywołanie API z routingiem proxy:

curl -X POST "https://api.foura.ai/api/proxy" \
  -H "x-api-key: YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "maxTries": 3,
    "timeout_ms": 20000,
    "request": {
      "method": "GET",
      "url": "https://www.google.co.uk/search?q=plumber+manchester&hl=en-GB",
      "unblocker": true,
      "validate": {
        "status": { "accept": [200] },
        "data": { "fail": ["unusual traffic", "/sorry/", "captcha"] }
      }
    }
  }'

To trzy czysto odseparowane kwestie: dobór proxy wedlug lokalizacji (Proxy Finder), samo zadanie (Single) oraz renderowanie JavaScriptu, gdy go potrzebujesz (Browser). Twoj kod nie obsluguje logiki sprawdzania stanu proxy ani nie zgaduje, ktore IP nadal dziala o 3 w nocy. To juz problem kogos innego.

Zapisuj kazda odpowiedz indeksowana wedlug (keyword, location, device, timestamp). To jedyne realne zrodlo prawdy przy sledzeniu pozycji. Nie "mielismy dzis taka pozycje na to slowo kluczowe", ale "mielismy taka pozycje na to slowo kluczowe, z tego miasta, na tym urzadzeniu, dokladnie w tej minucie". Bez takiego poziomu atrybucji dane z dwoch dni moga po cichu przeczyc sobie nawzajem, a Ty nie bedziesz w stanie stwierdzic, ktore sa poprawne. Zespoly SEO monitorujace chronione branze juz sie z tym mierza. Pisalismy rowniez o tym, jak wykrywanie botow przeszlo na analize behawioralna, co dodaje czwarty wymiar (ciaglosc sesji) dla witryn analizujacych sekwencjonowanie zadan zamiast pojedynczych sygnalow.

Wyniki

Monitorowanie 5000 slow kluczowych w 12 miastach, dwa razy dziennie, oznaczalo okolo 120 000 zadan na dobe przy starym schemacie num=100. Teraz, ze wzgledu na sama paginacje, jest to blizej 1,2 miliona (scenariusz pogladowy oparty na benchmarkach branzowych).

Zespoly, ktore przeniosly ten model na stos zlozony z trzech produktow, zglaszaja zazwyczaj:

  • Spadek kosztu pojedynczego zadania o 40-60% w porownaniu z utrzymywaniem wlasnej puli proxy, glownie dlatego, ze przestaly placic za rotacje proxy, martwe adresy IP oraz godziny pracy inzynierow potrzebne na utrzymanie rotacji.
  • Wzrost dokladnosci lokalizacji na poziomie miasta z ~70% do ponad 95%, poniewaz Proxy Finder filtruje wedlug miast i weryfikuje dzialanie proxy podczas ostatniego sprawdzenia przed jego przekazaniem.
  • Brak osobnej sciezki dla AI Overviews. Slowo kluczowe pobierane przez Single mozna bez zmian w calym pipeline przeniesc do Browser. Kontrakt pozostaje identyczny: podajesz URL, otrzymujesz odpowiedz.

Nie potrzebujesz tego wszystkiego dla dziesieciu slow kluczowych i pracy na laptopie. Jest to jednak niezbedne, gdy pipeline monitoruje dziesiatki tysiecy slow w wielu krajach, Twoi klienci odswiezaja dashboard w poniedzialek o 9 rano, a pozycje musza byc w pelni wiarygodne.

Podsumowanie

Trudnosc monitorowania SERP juz dawno przestala polegac na samym wysylaniu zadan. Caly problem tkwi w routingu. Z jakiego miasta wykonujesz zapytanie? Czy to IP wciaz dziala? Czy Google zwrocilo uklad, ktory zobaczylby prawdziwy uzytkownik w danej lokalizacji, czy pusta strone serwowana w momencie wykrycia bota?

Jesli jestes zespolem SEO prowadzacym rank tracking na wlasnym stosie technologicznym, pytanie na rok 2026 nie brzmi, czy scrapowac Google. Bo juz to robisz. Pytanie brzmi, czy Twoja infrastruktura jest w stanie generowac rzetelne dane o pozycjach, gdy reguly gry zmieniaja sie bez ostrzezenia, oraz jak duzo zasobow inzynieryjnych jestes w stanie poswiecic na jej biezace utrzymanie.