Тихое отключение выдачи Google поиска по 100 результатов не прошло незамеченным. Несмотря на то, что корпорация никак не освещала и не комментировала событие прекращения поддержки оператора &num=100, отсутствие работы этого параметра было замечено практически сразу, ведь с поисковиком взаимодействует огромное количество SEO-программ, парсеров и специалистов разного профиля.
Как теперь с этим жить и работать? Как увеличить количество результатов поиска в Google до 100 и можно ли это вообще сделать? Подробно разбираемся с проблемой в этом материале.
Почему исчезновение &num=100 — это не мелочь
Многие SEO-специалисты назвали отключение параметра &num=100 в результатах поиска Google Гуглопокалипсисом. Дело в том, что теперь вместо топ-100 результатов поисковик всегда показывает не более 10 ссылок. Это не может на сказаться на профильных SEO-сервисах и парсерах, которые собирали данные из поисковой выдачи большими объёмами. Теперь сбор данных существенно усложняется и замедляется – буквально в 10 раз. Ведь раньше можно было получить сразу все 100 результатов одним запросом (на одной странице), а теперь к поисковику нужно отправить уже 10 последовательных запросов и распарсить 10 страниц для тех же 100 результатов.
Собственно, не работают и другие операторы: для выдачи топ-30 или топ-50. Теперь SERP-скрапинг Google возможен исключительно по 10 результатов.
Профильные сервисы, которые предоставляли API-интерфейсы для SERP-скрапинга, почти сразу объявили о росте цен на свои услуги, что совсем неудивительно и вполне логично.
Что именно изменилось и когда: краткая хронология
Примерно с 10-11 сентября 2025 года тихо началось A/B-тестирование, когда в отдельных браузерах и локациях в поиске Google num100-оператор работал, а в каких-то нет. Из более-менее авторитетных источников мы нашли только пост в соцсети X от пользователя SEOwner, который заметил проблему практически сразу и запустил обсуждение. Это его час славы 😉
14 сентября нововведение коснулось абсолютно всех пользователей поисковика – во всех регионах и для всех языков. Скорее всего результаты тестирования устроили команду разработчиков и руководство корпорации. Об этом уже написали авторитетные новостные и профильные SEO-ресурсы.
Проблема на самом деле существенная и во многом напоминает апокалипсис, по крайней мере для всех тех, кто плотно работает с SERP-скрапингом.
Тут стоит отметить, что параметр &num=100 никогда и нигде не заявлялся в документации поисковика, но не заметить его было невозможно. Дело в том, что после ввода пользовательского запроса в форме поиска все связанные операторы выводятся внутри URL-адреса возвращаемой страницы с результатами – их можно увидеть и уточнить вручную (при желании).
Отдельно стоит упомянуть, что некоторые крупные сайты заметили в консолях веб-мастеров, что после данного нововведения трафик существенно просел. Прямая связь налицо: если сайт не в топ-10, то до него буквально никто не доходит при просмотре выдачи. А SEO-скраперы точно давали определённую долю поисков и переходов.
Google тоже можно понять:
- Большинство пользователей не опускаются ниже топ-5 и даже топ-7. Никто не любит длинные списки. А ещё нужно тратить много времени на изучение большого количества информации с предложенных сайтов и страниц.
- На мобильных гаджетах, а они дают львиную долю трафика, топ-100 изучать предельно тяжело и неудобно.
- Чем меньше результатов на странице, тем больше внимания к дополнительным элементам выдачи: реклама, сопутствующие сервисы, виджеты и пр. А ведь именно на рекламе Google зарабатывает.
- А ещё Google в настоящее время активно смещает фокус к готовым ответам и своему ИИ-ассистенту. Соответственно, &num=100 мешает этому процессу.
В общем, Google-поиск по 100 результатов теперь только в истории…
Почему &num=100 был таким удобным
- Экономия времени. Если пользователь добавлял параметр num100 в конец URL, то даже при ручном изучении поисковой выдачи он экономил массу времени и сил. Ему требовалось сделать это действие только один раз, а затем он мог просматривать сразу большое количество результатов поиска без дополнительных кликов и переходов.
- Существенное ускорение парсинга. Автоматический сбор из выдачи Google Search топ-100 требовал всего одного обращения к сервису поиска. То есть это минимум ресурсов сервера или ПК, а также небольшое время на сбор результатов.
- Более полное и комплексное видение Google Поиска.100 результатов покрывали все возможные потребности: при изучении конкурентов, при сборе своих позиций, при парсинге вхождений ключевых слов и т.п.
- Это реально было удобно и просто. Многие SEO-специалисты, SMM-щики и другие пользовались параметром &num=100 на постоянной основе.
Как это повлияло на типичные сценарии парсинга
SERP скрапинг стал сложнее и далеко не такой очевидный, как был. Раньше можно было проследить чёткую линейную нумерацию от num1 до num100, был специальный слайдер «Результатов на страницу», а теперь в выдаче может быть произвольное количество результатов в зависимости от типа авторизации и самого запроса. Большую часть выдачи занимают разные блоки, такие как People Also Ask, видео, карты, AI-обзоры и пр. Почти все они имеют подгрузку по мере взаимодействия с ними. Как итог – позиции стали «плавающими».
Повысилась нагрузка на парсер и на сам сервис поиска. Теперь для сбора топ-100 в Google Поиске нужно обратиться к нему 10 раз вместо одного. Неудивительно, что существенно выросли показы капчи и расходы на её решение / обход. Как обойти CAPTCHA – список надёжных инструментов.
Время парсинга увеличилось. Теперь собирать позиции конкурентов и своих сайтов нужно дольше.
Усложнилась структура анализа конкурентов. Если раньше топ-100 был фактически «плоским», все домены можно было увидеть в едином списке, то теперь нужно дополнительно проверять – не повторяются ли результаты и целевые сайты от страницы к странице. При этом стоит помнить, что часть конкурентом может быть в органике, а часть в дополнительных блоках: реклама, видео, карты, ИИ-поиск, People Also Ask и пр.
Теперь длинный «хвост» выдачи фактически скрыт. SERP скрапинг стал дороже в себестоимости, что не могло не отразиться на ценах подписок профильных сервисов.
Читайте также: Как парсить Google People Also Ask.
Как теперь работают скрипты без &num=100
Многие разработчики парсеров задались вопросом: как получить 100 результатов поиска в Google? Мы не исключение. Показываем и рассказываем какие теперь остались варианты для сбора топ-100 результатов вместо параметра &num=100.
Одно можем сказать точно: прямой замены &num=100 больше не существует. Но это не повод опускать руки. Парсинг SERP Гугла по-прежнему возможен. Просто он стал сложнее.
Пагинация по 10 результатов через параметр &start=
Если кликать на разные страницы в строке пагинации в результатах выдачи Google, то можно заметить, что внутри URL-адреса передаётся специальный параметр: &start=10, &start=20, &start=30 и т.д.
То есть при переходе на следующую страницу, с результатами поиска вам «выдают» следующую порцию из 10 строк. А чтобы поисковик не забыл, на чём он остановился, он указывает позицию результата относительно первого (вообще-то он нулевой, как при нумерации элементов массива).
Технически вы можете получать результаты, начиная с любого произвольного числа, например, &start=99.
Но в своих скриптах парсинга можно создать цикл, где инкремент будет увеличиваться с шагом в 10, тогда через 10 итераций вы сможете получить заветные топ-100 позиций.
Вот так это может выглядеть в коде Python-парсера:
query = "ваш поисковый запрос" # Можете заменить на своё значение
max_pages = 10 # сколько нужно собрать страниц, каждая по 10 результатов
print("List of resulting URLs Google:\n")
for page in range(max_pages):
start = page * 10
params = f"q={query}&start={start}&hl=ru" # параметр hl отвечает за указание языка
url = f"https://www.google.com/search?{params}"
# Здесь должен быть вызов логики вашего парсера
# А пока просто печатаем в консоль результирующие URL-адреса.
print(f"Page {page+1:2d}: {url}")
Это самый простой и логичный подход. По крайней мере до тех пор, пока поддержку параметра &start= не удалят, как это было с &num=100.
Клики на страницах пагинации (при автоматизации в headless-браузерах)
Чуть ниже расскажем о проблемах SERP скрапинга Google, тут только упомянем, что результатов на одной странице может быть меньше, чем 10, например, если пользователь не авторизован, тогда ему может отдаваться по 5 строк на страницу, а ещё структура вёрстки сильно усложнилась и сами страницы загружают большой объём JavaScript-кода.
В общем, чтобы максимально приблизить поведение парсера к поведению реальных пользователей, желательно задействовать антидетект-браузеры или headless-браузеры. И тогда вы можете буквально «кликать» по нужным элементам страницы. Параллельно логично «очеловечить» перемещение курсора, параметры скроллинга, естественных задержек и проч. В качестве библиотек для подключения безголовых браузеров могут использоваться: Playwright, Puppeteer, Selenium, Nodriver и т.п.
Гайд: Как парсить без блокировок.
Пример реализации с кликом на ссылках в блоке с пагинацией:
import random
import time
from playwright.sync_api import sync_playwright
def human_sleep(a=0.6, b=1.8):
"""Случайная задержка"""
time.sleep(random.uniform(a, b))
def human_scroll(page):
"""Естественный скроллинг страницы"""
scroll_height = page.evaluate("document.body.scrollHeight")
current = 0
while current < scroll_height:
step = random.randint(200, 500)
current += step
page.mouse.wheel(0, step)
human_sleep(0.2, 0.6)
def extract_results(page):
"""
Извлекаем органические результаты со страницы.
Возвращаем список словарей.
"""
results = []
items = page.locator("div#search div.g") #Здесь конструкцию идентификации контейнеров со строками результатов поиска можно заменить на свою, если текущая потеряла актуальность
count = items.count()
for i in range(count):
item = items.nth(i)
link = item.locator("a").first
title = item.locator("h3").first
if link.count() == 0 or title.count() == 0:
continue
results.append({
"title": title.inner_text(), # Тут извлекаем тайтл
"url": link.get_attribute("href") # А тут ссылку
})
return results
def click_next_page(page):
"""
Реальный клик по кнопке пагинации "Следующая".
Возвращает False, если кнопки нет.
"""
next_button = page.locator("a#pnnext") # конструкция может измениться, при необходимости укажите актуальный код
if next_button.count() == 0:
return False
# Небольшая пауза перед кликом
human_sleep(1.0, 2.5)
next_button.click()
return True
def parse_google_top_100(query):
collected = []
with sync_playwright() as p:
browser = p.chromium.launch(
headless=True,
args=[
"--disable-blink-features=AutomationControlled"
]
)
context = browser.new_context(
viewport={"width": 1366, "height": 768},
user_agent=(
"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36"
)
)
page = context.new_page()
page.goto(
"https://www.google.com/search?q=" + query.replace(" ", "+"),
wait_until="domcontentloaded"
)
human_sleep(2, 4)
page_number = 1
while len(collected) < 100:
print(f"Parsing page {page_number}")
human_scroll(page)
results = extract_results(page)
for r in results:
if len(collected) >= 100:
break
collected.append(r)
print(f"Total found: {len(collected)}")
if not click_next_page(page):
print("The pagination is over ")
break
page_number += 1
page.wait_for_load_state("domcontentloaded")
human_sleep(2, 4)
browser.close()
return collected
if __name__ == "__main__":
data = parse_google_top_100("пример поискового запроса")
print("\nThe final list:")
for i, item in enumerate(data, start=1):
print(f"{i}. {item['title']} — {item['url']}")
Скрипт использует связку из Python + Playwright. В качестве headless-браузера вызывается Chromium. Парсер исходит из того, что результатов на странице может быть менее 10, поэтому он их принудительно считает и останавливается только на num100. Переход по страницам реализован через реальный клик на ссылке пагинации. Присутствуют «очеловеченные» задержки и скролл.
Не забудьте доустановить недостающие библиотеки и браузеры:
pip install playwright
playwright install chromium
А ещё позаботьтесь о работе через прокси, желательно через резидентные или через мобильные, по возможности с ротацией на основе короткого промежутка времени или при каждом запросе.
API Custom Search JSON
Это официальный API-интерфейс, который Google предоставлял разработчикам решений, которые опирались на программируемый пользовательский поиск. Сейчас подключение к API недоступно. Всем текущим клиентам нужно перейти на API Vertex AI Search до 1 января 2027 года.
Как можно догадаться из названия, API Custom Search JSON отдаёт результаты поиска в структурированной разметке – в виде JSON-файла, соответствующего спецификации OpenSearch 1.1.
Смысла приводить пример скрипта нет, так как Custom Search Google работает только для тех, кто успел к нему подключиться ранее.
Ссылка на официальную документацию для разработчиков.
Доступ к API платный. Бесплатно только первые 100 запросов в день.
Альтернативные сервисы, которые реализуют аналог API для SERP скрапинга Google
Провайдеров на рынке масса, но в любом случае стоит помнить, что эти сервисы – посредники. И они не гарантируют 100% релевантный результат. Технически это уже готовые базы данных, которые пропарсили заранее, или которые парсят поиск под ваш конкретный запрос.
У каждого сервиса свой синтаксис API, ограничения, технические возможности и расценки. Примеры: SerpAPI, DataForSEO, Zenserp и пр.
Именно им стало сложнее всего после того, как Google удалил поддержку num100.
Заключение и рекомендации
SERP скрапинг Google стал сложнее. И дело даже не только в отключении поддержки параметра &num=100. Теперь Google – это полноценное веб-приложение, написанное с большим объёмом JS-кода. Поэтому для доступа к результирующему HTML нужны специальные решения и подходы, такие как headless-браузеры, реалистичные цифровые отпечатки и профили пользователей, а также качественные прокси, чтобы обходить показ капчи и временные блокировки.
Как раз за прокси отвечает наш сервис. Froxy – это более 10 млн резидентных и мобильных IP с автоматической ротацией. Подключение к парсерам осуществляется буквально одной строкой кода, а все остальные процедуры управления реализуются через удобный дашборд или через API.