Как на самом деле работает парсинг SERP в 2026 году (после того, как Google убил num=100 и сделал обязательным JavaScript)
Два тихих изменения — обязательный JavaScript и отмена параметра num=100 — переписали экономику парсинга поиска. Вот что на самом деле изменилось, почему ваш трекер рангов сломался и как надежно собирать данные SERP в 2026 году.
Если ваш трекер рангов внезапно замолчал в конце 2025 года или ваш самодельный парсер Google начал возвращать пустые страницы, вы не воображали это. В течение девяти месяцев Google внес два изменения, которые по отдельности выглядели как незначительная уборка, а вместе тихо переписали экономику парсинга поиска. Это практическое руководство по тому, что на самом деле изменилось, почему это сломало так много инструментов сразу и как надежно собирать данные SERP в 2026 году, не сжигая вашу инфраструктуру — или ваши IP-адреса.
Изменение первое: Google сделал JavaScript обязательным
17 января 2025 года Google начал требовать JavaScript для использования Google Search. Выключите его, и вы получите короткое сообщение — "Включите JavaScript, чтобы продолжить поиск" — вместо результатов. Представитель компании сообщил TechCrunch, что цель заключалась в том, чтобы "лучше защитить наши сервисы и пользователей от ботов и развивающихся форм злоупотреблений и спама", и подтвердил, что менее 0,1% поисков поступает от пользователей с отключенным JavaScript.
Эта цифра в 0,1% — это подсказка. Приблизительно 8,5 миллиарда поисков в день, десятая часть процента — это все равно миллионы запросов, и непропорциональная их доля никогда не была от людей. Это были трекеры рангов, SEO-сканеры и дешевые парсеры, обращающиеся к легкой версии страницы результатов без JavaScript. Search Engine Journal подтвердил прочитанное напрямую: Google требует JavaScript, чтобы блокировать ботов и парсеров, включая SEO-инструменты.
Включение JavaScript позволяет нам лучше защищать наши сервисы и пользователей от ботов и развивающихся форм злоупотреблений и спама, а также предоставлять наиболее актуальную и актуализированную информацию.
Практическое следствие: эпоха парсинга Google путем получения URL и выполнения регулярного выражения по статическому HTML закончилась. Результаты теперь собираются на стороне клиента. Если ваш парсер не может выполнять JavaScript, он не видит ухудшенную страницу — он не видит никакой страницы.
Изменение второе: смерть num=100
Второе изменение было меньше по виду, но больше по влиянию. Около 11 сентября 2025 года Google отключил URL-параметр &num=100 — маленький флаг, который говорил Search возвращать 100 результатов на одной странице вместо стандартных 10. В течение десятилетия это было основой глубокого отслеживания рангов: один запрос, сто позиций.
Когда он исчез, математика перевернулась за одну ночь. Чтобы увидеть топ-100 результатов, теперь нужно до десяти запросов с пагинацией вместо одного. Keyword Insights выразил стоимость прямо в день, когда это произошло.
Google убил параметр n=100 SERP. Вместо 1 запроса для 100 результатов SERP теперь требуется 10 запросов (в 10 раз дороже). Это влияет на наш модуль ранжирования. Мы рассматриваем варианты и скоро обновим платформу.
Волна ударила и по Google Search Console. Начиная с 10 сентября, команды SEO заметили резкое падение показов на настольных компьютерах, в то время как средняя позиция, казалось, улучшилась. Теория аналитика Броди Кларка — широко обсуждаемая, но никогда не подтвержденная Google — заключается в том, что большая доля этих ранних показов никогда не была человеческой: это были боты, загружающие страницы с 100 результатами через num=100, каждая из которых регистрировала в десять раз больше показов, чем обычная страница. Уберите параметр, и фантомные показы исчезают вместе с ним. Это интерпретация сообщества, а не официальное объяснение, но она точно совпадает по времени.
Почему это сломало так много инструментов сразу
Большинство инструментов SERP были построены на двух предположениях, которые были верны годами и теперь оба ложны: что Google будет предоставлять пригодный для использования HTML без JavaScript и что можно получить 100 результатов за запрос. Уберите оба в одном году, и режимы отказа складываются:
- Статические фетчеры возвращают пустые или вызовные страницы вместо результатов.
- Коллекторы на основе пагинации нуждаются в 10 раз большем объеме запросов для того же охвата, что означает 10 раз больше пропускной способности прокси и 10 раз больше поверхности блокировки.
- Больше запросов из тех же диапазонов IP быстрее запускают антибот-системы, так что уровень успеха падает ровно тогда, когда объем нужно увеличивать.
- Базовые линии Search Console сместились, так что исторические панели больше не сравниваются как за равное.
Как сформулировал это инженер SEO Райан Джонс, агрессивная волна парсинга — большая часть которой теперь питает AI-продукты — именно то, что подтолкнуло Google к борьбе, ломая проверяющие ранги и парсеры SERP как побочный ущерб. Инструменты не провалились, потому что они были плохо написаны. Они провалились, потому что земля сдвинулась.
Как выглядит надежный парсинг SERP в 2026 году
Новая базовая линия имеет три непреложных условия. Пропустите любое из них, и ваш уровень успеха рухнет под нагрузкой.
1. Выполняйте JavaScript — но только когда это необходимо
Поскольку результаты собираются на стороне клиента, вам нужен клиент, который выполняет JavaScript для страниц, которые этого требуют. Но запуск безголового браузера для каждого запроса медленный и дорогой. Эффективная схема — сначала попробовать легкий фетч с реальным TLS-отпечатком и перейти к полному рендеру браузера только тогда, когда страница действительно бросает вам вызов. Большинство запросов никогда не нуждаются в браузере; те, которые нуждаются, получают его автоматически.
2. Поворачивайте резидентные выходы с реальными отпечатками браузера
IP-адреса дата-центров и стандартные отпечатки HTTP-клиентов — это самый быстрый путь к CAPTCHA. Запросы должны поступать с резидентных IP-адресов, неся TLS и заголовочный отпечаток настоящего браузера, такого как Chrome. Когда один выход помечается, переключение на новый обычно очищает блокировку без каких-либо изменений в самом запросе — именно так устойчивый коллектор восстанавливается после страницы "необычного трафика" вместо того, чтобы умирать на ней.
3. Парсите в структурированные данные, а не в сырой HTML
Разметка Google постоянно меняется, и после num=100 макет стал более фрагментированным, а не менее. Поддержка собственных селекторов против движущейся цели — это работа на полный рабочий день. Структурированный SERP-эндпоинт, возвращающий чистый JSON — органические результаты, реклама, покупки, панели знаний, People Also Ask, AI Overviews — изолирует ваш конвейер от каждого косметического изменения на стороне Google.
Паттерн на практике
Вместо того чтобы поддерживать браузеры, пулы прокси и парсеры самостоятельно, вы передаете запрос на эндпоинт, который делает все три и возвращает чистые структурированные результаты. С QuantumProxies SERP API один аутентифицированный запрос обрабатывает выполнение JavaScript, резидентную ротацию и парсинг за вас:
curl --location --request GET \
"https://app.quantumproxies.io/api/v1/serp/google/search?q=best+running+shoes&cc=us" \
--header "Authorization: Bearer YOUR_API_KEY"Ответ — это JSON, а не HTML — органические результаты с позициями, реклама, торговые блоки, граф знаний, People Also Ask и AI Overviews, где они есть. Нет безголового браузера, за которым нужно следить, нет селектора, который нужно чинить, когда Google перестраивает страницу, и пагинация обрабатывается так, что вам не нужно вручную восстанавливать то, что num=100 давал вам бесплатно. Когда один выход попадает на антибот-страницу, сервис автоматически повторяет попытку на новом резидентном IP — то же самое поведение ротации для восстановления, которое поддерживает конвейер в живом состоянии под реальной нагрузкой.
Если вы хотите увидеть полную форму запроса и ответа перед написанием кода, интерактивная документация SERP API на https://quantumproxies.io/serp-api/docs позволяет вам выполнить живой запрос и скопировать готовые фрагменты для cURL, Python, JavaScript, PHP, Go и Ruby.
Вывод
Парсинг SERP не стал сложнее в каком-то неопределенном, постепенном смысле — он изменился дважды за один год. JavaScript теперь обязателен, так что вам нужен настоящий клиент. num=100 исчез, так что глубокое покрытие стоит на порядок больше в запросах, что означает, что качество вашего прокси-слоя и интеллект вашей логики эскалации теперь важнее, чем когда-либо была сырая масса запросов. Команды, которые все еще собирают чистые данные SERP в большом масштабе в 2026 году, не те, кто отправляет больше запросов. Это те, кто отправляет более умные — способные на JavaScript, с резидентными отпечатками и структурированные с первого байта.