← Всички публикации
Случай на употреба 6 мин. четене

SERP мониторинг в голям мащаб след num=100

Проследяването на позициите в Google в голям мащаб стана по-трудно след отпадането на num=100. Ето как инженерните екипи за SEO изграждат наново своята инфраструктура за SERP мониторинг за 2026 г.

serp-monitoringrank-trackingseoweb-scrapinggoogle-search

Предизвикателството

Ако вашият екип разработва rank trackers, SEO табла или инструменти за конкурентно разузнаване, 2026 г. съсипа вашата unit economics. Google тихомълком премахна URL параметъра num=100 от Google Search тази година (трикът, който всеки SERP scraper използваше, за да извлече 100 резултата с една request). Сега за същото покритие са необходими десет requests вместо една.

Това е очевидният разход. Скритите разходи са по-неприятни.

Проследяването на позиции (rank tracking) работи само когато виждате SERP, който реален потребител би видял в правилната държава, регион и град. Ключова дума, която се класира на #4 позиция в Лондон, може да бъде на #11 в Единбург и на #19 в Белфаст. Локални 3-packs, shopping carousels, новинарски карета, knowledge panels, AI Overviews. Всяка SERP функция се променя в зависимост от географията и устройството. (Scrape.do измери, че текст от AI Overview се появява в приблизително 36% от заявките в началото на 2026 г.) Ако вашият scraper се маршрутизира през proxy в грешния град, данните ви за класиране са просто уверено поднесена измислица.

Така че един конкурентоспособен SERP продукт през 2026 г. се нуждае от три неща, работещи в синхрон: request, който изглежда като реален браузър на ниво мрежов протокол (wire level), proxy, което се намира в точния град, който се опитвате да наблюдавате, и възможност за рендериране на JavaScript, когато Google реши да зареди половината резултат от страна на клиента (client-side). Пропуснете някое от трите и качеството на данните ви ще се влоши тихомълком.

Подходът на FourA

Тясното място при SERP scraping в голям мащаб не е самият request. Това е маршрутизацията (routing).

Повечето собствено разработени системи (pipelines) започват с фиксиран proxy pool и разглеждат заявката като променлива. При географското насочване на Google е точно обратното. Заявката е това, с което разполагате. Proxy е това, което трябва да уцелите точно.

Наблюдавахме как екипите изграждат този модел върху FourA приблизително по следния начин:

  1. Proxy Finder поддържа работещ пул от proxies, валидирани чрез скорошни проверки за активност (liveness checks) и маркирани с държава, регион, град и ASN. Когато даден request трябва да дойде от Манчестър, Бостън или Сао Пауло, Proxy Finder избира такъв, който действително се намира там и е бил активен при последната проверка. Изборът става преди извличането (fetch), а не по време на него. За повече информация защо този маршрутизиращ слой (routing layer) е важен, вижте нашата статия за Smart Proxy Routing.

  2. Single управлява самото извличане (fetch) на SERP. За стандартни органични резултати необработеният HTML е напълно достатъчен. Задайте unblocker: true и request преминава през защитите срещу ботове на ниво ръкостискане (handshake-level anti-bot), без да е необходимо да знаете кой подпис (signature) проверява Google тази седмица. Подробно описахме какво прави този флаг на мрежово ниво в нашата публикация за Web Unblocker.

  3. Browser се справя със SERP страници, при които критичното съдържание се появява след изпълнение на JavaScript. AI Overviews, разширени пакети за пазаруване, съдържание от knowledge-panel, фиксирани локални 3-packs. Същият URL, същата цел, просто request се изпълнява през пълна браузърна сесия и връща напълно рендерираната страница. (Плюс екранни снимки, които ви спасяват в деня, в който някой SEO мениджър попита защо вашето табло показва позиция #3, а те виждат #6 в своя браузър.)

Единично извикване към API с маршрутизиране на 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"] }
      }
    }
  }'

Това са три ясно разделени задачи: географски коректна работа с proxy (Proxy Finder), самият request (Single) и рендериране на JavaScript, когато ви е необходимо (Browser). Вашият код не съдържа логика за проверка на състоянието (health) на proxy и не гадае кой IP адрес е все още активен в 3 часа сутринта. Това е грижа на някой друг.

И съхранявайте всеки response с ключ (keyword, location, device, timestamp). Това е действителната единица за истинност при rank tracking. Не „днес се класирахме тук за тази ключова дума“, а „класирахме се тук за тази ключова дума, от този град, на това устройство, в тази минута“. Без такова ниво на атрибуция данните от два различни дни могат тихомълком да си противоречат и няма да има как да разберете кои са верните. SEO екипите, които наблюдават защитени вертикали, вече се сблъскват с това. Писали сме също за това как засичането на ботове стана поведенческо, което добавя четвърта ос (непрекъснатост на сесията) за сайтове, които анализират последователността на requests, а не сигналите за всеки отделен request.

Резултати

Инструмент за rank tracking, който наблюдава 5000 ключови думи в 12 града два пъти дневно, правеше около 120 000 requests на ден при стария режим с num=100. Сега те са близо 1,2 милиона по проста математика за странициране (примерен сценарий, базиран на индустриални бенчмаркове).

Екипите, които са прехвърлили тази структура към стек от три продукта, обикновено отчитат:

  • 40-60% намаление на разходите за всеки request в сравнение с поддържането на собствен proxy pool, най-вече защото са спрели да плащат за текучество на proxies (proxy churn), неактивни IP адреси и инженерни часове за поддръжка на ротацията.
  • Точност на локацията на ниво град, нарастваща от ~70% до над 95%, тъй като Proxy Finder филтрира по град и проверява активността при последната проверка, преди да предаде proxy.
  • Без специален път за AI Overviews. Ключова дума, която се извлича чрез Single, може да бъде прехвърлена към Browser без пренаписване на системата (pipeline). Договорът е идентичен: подава се URL, получава се response.

Не се нуждаете от нищо от това за десет ключови думи и лаптоп. Но то ви е необходимо, когато системата наблюдава десетки хиляди ключови думи в различни държави, клиентите ви обновяват таблото си в 9 часа сутринта в понеделник и класиранията трябва да бъдат реални.

Основен извод

Трудната част при SERP мониторинга отдавна спря да бъде самият request. Винаги е била маршрутизацията (routing). От чий град извличате данни? Активен ли е този IP адрес? Върна ли Google оформлението (layout), което реален потребител на това място действително би видял, или празното такова, което сервират, когато усетят scraper?

Ако сте SEO екип, който извършва rank tracking на разработен от вас стек, въпросът за 2026 г. не е дали да извличате данни от Google. Вие вече го правите. Въпросът е дали вашата инфраструктура може да продължи да предоставя надеждни класирания, когато правилата се променят без предупреждение, и колко от ресурса на инженерния си екип сте готови да отделите, за да я поддържате в това състояние.