Ещё год назад спарсить выдачу Google можно было одним GET-запросом с параметром num=100 — сотня результатов приходила чистым HTML. В 2026-м так уже не работает: Google убил доступ без JavaScript, отрезал сотню результатов на страницу и добавил в выдачу блок AI Overviews, который рендерится асинхронно и виден не с каждого IP. Разбираемся, как собирать SERP в новых условиях, где скрытые ловушки и почему выбор типа прокси стал важнее самого парсера.
Для кого этот гайд
Парсинг поисковой выдачи (SERP scraping) — это не только про SEO-позиции. Сегодня его используют:
- SEO-специалисты и агентства — отслеживают органику, featured snippets, «Люди также спрашивают», локальную выдачу и то, попал ли сайт в AI Overviews.
- Аналитики рынка — мониторят, кого Google цитирует в AI-блоках по коммерческим запросам, и как меняется первая страница у конкурентов.
- AI- и data-команды — собирают SERP как источник данных для RAG-систем, обучения моделей и фактчекинга.
Всех объединяет одна проблема: Google в 2026 году активно отличает автоматический трафик от живого, и без правильной инфраструктуры сбор данных ломается на первых десятках запросов.
Что изменилось: три удара Google по скраперам
Чтобы гайд был честным, начнём с того, почему старые инструкции больше не работают.
Январь 2025 — SearchGuard. Google развернул систему JavaScript-челленджей: обычный HTTP-запрос через requests или httpx теперь получает не HTML, а challenge-страницу. Без исполнения JavaScript выдачу увидеть нельзя — прямой парсинг «в лоб» падает мгновенно.
Сентябрь 2025 — конец num=100. Google убрал параметр, который отдавал 100 результатов за один запрос. Теперь топ-100 — это десять отдельных запросов с пагинацией. Для глубокого мониторинга это буквально десятикратный рост числа обращений (и, соответственно, нагрузки на прокси и бюджета).
Декабрь 2025 — юридическое давление. 19 декабря 2025 года Google подал DMCA-жалобу против SerpApi, заявив, что SearchGuard — это «техническое средство защиты» (technological protection measure), а его обход подпадает под антиобходные нормы. Прецедент ещё не разрешён, но он задаёт тон: серый парсинг Google становится и технически, и юридически дороже.
Отдельно отметим: официальный Custom Search API Google сворачивают — существующим клиентам объявлен дедлайн миграции к 1 января 2027 года. То есть «легальная» альтернатива тоже сужается.
Главная новинка выдачи — AI Overviews
AI Overviews (в прошлом SGE) — это сгенерированная ИИ сводка вверху выдачи со ссылками на источники. Для скрапинга это самый сложный элемент 2026 года по трём причинам.
Их много. По данным Ahrefs, AI Overviews появляются примерно в 30% запросов; более поздние оценки (Olostep) дают до 48% всех запросов и до 80% информационных. Игнорировать этот блок — значит собирать заведомо неполную картину выдачи.
Они рендерятся асинхронно. Блок существует в трёх состояниях: приходит сразу в HTML (реже всего), догружается через JavaScript спустя секунды после основной страницы (самый частый случай) или не появляется вовсе. При отложенной загрузке сырой HTTP-ответ содержит пустой контейнер — контент подтягивается позже, и парсеру нужно ждать (на практике — около 8 секунд в браузерной автоматизации).
Их видно не с каждого IP. Вот ключевой момент, о котором молчат старые гайды: Google считает мобильных пользователей приоритетной аудиторией для AI-поиска. На практике это значит, что с датацентр-IP AI Overview часто не отдаётся вообще, тогда как тот же запрос через мобильного оператора возвращает полный блок. Даже топовые агрегаторы признают неполноту: SerpApi на начало 2026 года заявлял около 68% успешного детекта AI Overviews.
Пошаговый разбор: как собрать SERP в 2026
- Определитесь с объёмом. До ~100 запросов в день реально тянуть на собственной браузерной автоматизации. От 100 до 10 000 — уже нужен управляемый парсер или SERP-API. Свыше 10 000 в день без enterprise-инфраструктуры с батчами и вебхуками не обойтись. Это определяет весь дальнейший стек.
- Соберите правильный URL. Базовый эндпоинт — /search, ключевые параметры: q (запрос, URL-энкодинг), hl (язык интерфейса), gl (страна выдачи), start (пагинация: start=10 — вторая страница, start=20 — третья и так далее). Помните: num=100 больше не действует, глубину набираете только пагинацией.
- Используйте браузерный рендеринг. Поскольку без JavaScript выдачи нет, базовый стек — Playwright или Selenium с headless Chromium. Обязательно снимайте автоматизационные маркеры (флаг --disable-blink-features=AutomationControlled), иначе антибот вычислит управляемый браузер по navigator-свойствам.
- Дождитесь AI Overview. После загрузки страницы не хватайте DOM сразу: дайте networkidle устояться и подождите догрузки блока (ориентир — до 8 секунд). Наличие блока надёжнее определять по тексту заголовка «AI Overview», а не по CSS-классам — они у Google динамические и меняются (условные Kevs9, Y3BBE сегодня одни, завтра другие).
- Парсите по структуре, а не по классам. Органику берите по заголовочным тегам (h3) и семантике, а не по хрупким именам классов. Из выдачи в 2026 доступны: органические результаты, featured snippets, «Люди также спрашивают», связанные запросы, knowledge graph, локальный пак, реклама и цитаты внутри AI Overview.
- Ротируйте IP и притормаживайте. Ставьте реалистичные паузы между запросами (4–12 секунд) и меняйте IP примерно каждые 5 минут, варьируя город/оператора. Слишком ровный ритм и один IP — самый быстрый путь к капче.
Подводные камни
- «Пустой» AI Overview. Если вы забираете DOM сразу после загрузки, отложенный блок будет пуст — и вы решите, что его нет. Всегда закладывайте ожидание и повторную проверку.
- Одноразовые сессии на догрузку. У некоторых API ключ сессии для дозагрузки отложенного AI Overview одноразовый и живёт около 60 секунд — не рассчитывайте переиспользовать его позже.
- Ложная экономия на датацентре. Дешёвые датацентр-IP ловят капчу уже на 5–10 запросах и в придачу не показывают AI Overviews. Экономия оборачивается неполными данными и слитым временем.
- Хрупкие селекторы. Привязались к именам CSS-классов — парсер сломается на ближайшем редизайне выдачи. Держитесь текста и структуры.
- Ровный отпечаток запросов. Одинаковые User-Agent, тайминги и заголовки на всех потоках выдают ботнет. Разнообразьте фингерпринт так же, как и IP.
Какой тип прокси выбрать
В 2026-м именно прокси, а не парсер, определяет, увидите ли вы полную выдачу. Разложим по задачам.
Мобильные прокси — под AI Overviews и самые «тяжёлые» запросы. Раз Google отдаёт AI-блоки в первую очередь мобильной аудитории, реальные операторские IP (T-Mobile, Verizon, Vodafone и аналоги) стабильнее всего триггерят AI Overview и выдерживают заметно больше — по наблюдениям, 50–200 запросов до появления трения против 5–10 у датацентра. Плюс мобильный CGNAT-IP делит один адрес с сотнями живых абонентов, поэтому забанить его Google опасается. Если ваша задача — собирать именно AI Overviews или мониторить самые защищённые SERP, начинайте с мобильных прокси.
Резидентные прокси — рабочая лошадка для органики и объёма. Для сбора обычной выдачи, позиций, featured snippets и локального пака резидентные IP (адреса домашних провайдеров) дают лучшее соотношение цены и успеха. Их сложно отличить от реального пользователя, а ротация позволяет масштабировать сбор без залпа с одного адреса. Оптимальный вариант, когда AI Overview не в фокусе, а важны объём и география, — резидентные прокси с ротацией.
Датацентр — только для черновых прогонов. Быстро и дёшево, но против Google в 2026 году живёт считаные запросы и не видит AI-блоки. Подходит для отладки логики парсера, не для боевого сбора.
Не уверены, что взять под конкретную задачу, — начните с разбора резидентные против мобильных прокси в 2026: там подробно, где какой тип экономит деньги, а где — данные.
Вывод
Парсинг Google в 2026 году перестал быть задачей «написать парсер». SearchGuard заставил рендерить JavaScript, отмена num=100 удесятерила число запросов, а AI Overviews добавили блок, который виден в основном с мобильных IP и догружается с задержкой. Технически всё решаемо: браузерная автоматизация, парсинг по структуре, разумные паузы и ротация. Но фундамент, на котором держится полнота и стабильность сбора, — это правильные прокси: мобильные под AI Overviews и защищённые запросы, резидентные под органику и объём. Начните с типа прокси под свою задачу — и парсер перестанет спотыкаться о капчу.