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

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

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

serp-monitoringrank-trackingseoweb-scrapinggoogle-search

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

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

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

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

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

Подходът на FourA

Тесното място при SERP скрапването в мащаб не е самата заявка. Това е маршрутизацията.

Повечето собствени пайплайни започват с фиксиран proxy пул и третират заявката като променлива. При географското таргетиране на Google е точно обратното. Заявката е това, с което разполагате. Proxy сървърът е това, което трябва да улучите точно.

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

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

  2. Single управлява самото извличане на SERP. За стандартни органични резултати чистият HTML е напълно достатъчен. Задайте unblocker: true и заявката носи актуален браузърен сигнатура, без да е необходимо да знаете коя сигнатура проверява Google през съответната седмица. Описахме подробно какво прави този флаг на мрежово ниво в нашата статия за Web Unblocker.

  3. Browser поема SERP страници, където критичното съдържание се появява след изпълнение на JavaScript. AI Overviews, разширени shopping пакети, съдържание в knowledge panel, фиксирани локални 3-packs. Същият URL, същата цел, заявката просто се изпълнява през пълна браузърна сесия и връща напълно рендираната страница. (Плюс скрийншоти, които ви спасяват в деня, когато 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 rendering, когато ви е необходим (Browser). Вашият код не съдържа логика за proxy здраве и не гадае кое IP все още работи в 3 сутринта. Това е чужда грижа.

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

Резултати

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

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

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

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

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

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

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