← Wszystkie wpisy
Zastosowanie 5 min czytania

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.

serp-monitoringrank-trackingseoweb-scrapinggoogle-search

Wyzwanie

Jeśli Twój zespół tworzy narzędzia do śledzenia pozycji, dashboardy SEO lub oprogramowanie do analizy konkurencji, rok 2026 zepsuł Waszą ekonomię jednostkową. Google po cichu wycofało w tym roku parametr URL num=100 z wyszukiwarki Google, czyli trik, którego używał każdy scraper SERP, aby pobrać 100 wyników w jednym zapytaniu. Teraz uzyskanie tego samego pokrycia wymaga dziesięciu requestów zamiast jednego.

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

Śledzenie pozycji działa tylko wtedy, gdy widzisz taki SERP, jaki zobaczyłby prawdziwy użytkownik w konkretnym kraju, regionie i mieście. Słowo kluczowe, które zajmuje 4. pozycję w Londynie, może być na 11. miejscu w Edynburgu i na 19. w Belfaście. Lokalne 3-packi, karuzele zakupowe, sekcje z wiadomościami, panele wiedzy, AI Overviews. Każda funkcja SERP zmienia się w zależności od lokalizacji i urządzenia. (Scrape.do odnotowało, że tekst AI Overview pojawiał się w około 36% zapytań na początku 2026 roku.) Jeśli Twój scraper kieruje ruch przez proxy w złym mieście, Twoje dane o pozycjach to po prostu pewna siebie fikcja.

Więc solidny produkt do monitorowania SERP w 2026 roku wymaga współdziałania trzech elementów: requestu, który na poziomie sieciowym wygląda jak wysłany z prawdziwej przeglądarki, proxy zlokalizowanego dokładnie w monitorowanym mieście oraz możliwości renderowania JavaScript, gdy Google zdecyduje się załadować połowę wyników po stronie klienta. Jeśli zabraknie choćby jednego z nich, jakość Twoich danych po cichu spadnie.

Podejście FourA

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

Większość wewnętrznie budowanych procesów zaczyna się od stałej puli proxy i traktuje zapytanie jako zmienną. Przy targetowaniu geograficznym Google jest dokładnie na odwrót. Zapytanie to stała. To proxy musisz dobrać bezbłędnie.

Obserwowaliśmy, jak zespoły projektują to w oparciu o FourA mniej więcej tak:

  1. Proxy Finder utrzymuje aktywną pulę proxy zweryfikowanych pod kątem działania i otagowanych krajem, regionem, miastem oraz ASN. Gdy request musi pochodzić z Manchesteru, Bostonu lub São Paulo, Proxy Finder wybiera to, które rzeczywiście tam działa i przeszło ostatni test aktywności. Wybór następuje przed pobraniem danych, a nie w jego trakcie. Więcej o tym, dlaczego ta warstwa routingu ma znaczenie, przeczytasz w naszym artykule o Smart Proxy Routing.

  2. Single obsługuje samo pobieranie SERP. Dla standardowych wyników organicznych czysty HTML w zupełności wystarczy. Ustaw unblocker: true, a request przejdzie przez zabezpieczenia antybotowe na poziomie handshake, bez konieczności śledzenia, którą sygnaturę Google sprawdza w danym tygodniu. Szczegółowo opisaliśmy działanie tej flagi na poziomie sieciowym w naszym artykule o Web Unblocker.

  3. Browser obsługuje SERP-y, w których kluczowa zawartość pojawia się dopiero po uruchomieniu JavaScript. AI Overviews, rozszerzone pakiety zakupowe, panele wiedzy, przypięte lokalne 3-packi. Ten sam URL, ten sam cel, ale request przechodzi przez pełną sesję przeglądarki i zwraca całkowicie wyrenderowaną stronę. (Do tego zrzuty ekranu, które uratują Cię, gdy lider zespołu SEO zapyta, dlaczego Twój dashboard pokazuje pozycję 3., a on 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 czysty podział na trzy obszary: dopasowanie geograficzne proxy (Proxy Finder), sam request (Single) oraz renderowanie JavaScript w razie potrzeby (Browser). Twój kod nie musi zawierać logiki sprawdzania stanu proxy ani zgadywać, które IP wciąż działa o 3 rano. To już nie Twój problem.

Zapisuj też każdą odpowiedź z kluczem (keyword, location, device, timestamp). To jest prawdziwa jednostka prawdy w śledzeniu pozycji. Nie "mieliśmy dziś taką pozycję na to słowo kluczowe", ale "mieliśmy taką pozycję na to słowo kluczowe, z tego miasta, na tym urządzeniu, w tej minucie". Bez tak dokładnej atrybucji dane z dwóch dni mogą po cichu przeczyć sobie nawzajem, a Ty nie będziesz mieć pojęcia, które są poprawne. Zespoły SEO monitorujące wrażliwe branże już teraz muszą się z tym mierzyć. Pisaliśmy również o tym, jak detekcja botów stała się behawioralna, co dodaje czwartą oś (ciągłość sesji) dla witryn analizujących sekwencję requestów zamiast sygnałów z pojedynczych zapytań.

Wyniki

Narzędzie do śledzenia pozycji monitorujące 5 000 słów kluczowych w 12 miastach, dwa razy dziennie, generowało około 120 000 requestów na dobę przy starym parametrze num=100. Teraz, ze zwykłej matematyki stronicowania, jest to bliżej 1,2 miliona (przykładowy scenariusz oparty na benchmarkach branżowych).

Zespoły, które przeniosły ten model na stos oparty na trzech produktach, zazwyczaj zgłaszają:

  • 40-60% redukcji kosztów pojedynczego requestu w porównaniu do utrzymywania własnej puli proxy, głównie dlatego, że przestały płacić za rotację proxy, martwe IP oraz godziny pracy inżynierów poświęcone na utrzymanie rotacji.
  • Wzrost dokładności lokalizacji na poziomie miasta z ~70% do ponad 95%, ponieważ Proxy Finder filtruje wyniki według miast i weryfikuje aktywność przy ostatnim teście przed przekazaniem proxy.
  • Brak konieczności tworzenia osobnej ścieżki dla AI Overviews. Słowo kluczowe pobierane przez Single może zostać przeniesione do Browser bez przebudowywania całego procesu. Kontrakt jest identyczny: przekazujesz URL, otrzymujesz odpowiedź.

Nie potrzebujesz tego wszystkiego dla dziesięciu słów kluczowych i laptopa. Ale staje się to niezbędne, gdy Twój proces monitoruje dziesiątki tysięcy fraz w różnych krajach, Twoi klienci odświeżają dashboard w poniedziałek o 9:00 rano, a pozycje muszą być prawdziwe.

Kluczowe wnioski

Trudność w monitorowaniu SERP już dawno przestała dotyczyć samego requestu. Chodzi o routing. Z jakiego miasta pobierasz dane? Czy to IP działa? Czy Google zwróciło układ, który rzeczywiście zobaczyłby prawdziwy użytkownik w tej lokalizacji, czy puste wyniki, które serwuje, gdy wyczuje scrapera?

Jeśli jesteś zespołem SEO prowadzącym śledzenie pozycji na własnoręcznie zbudowanym stosie technologicznym, pytanie na rok 2026 nie brzmi, czy powinieneś scrapować Google. Już to robisz. Pytanie brzmi, czy Twoja infrastruktura poradzi sobie z dostarczaniem wiarygodnych wyników, gdy zasady zmienią się bez ostrzeżenia, i jak dużą część swojego zespołu inżynieryjnego chcesz poświęcić na jej ciągłe utrzymywanie.