SERP API: зачем парсить поисковую выдачу в JSON

Идея лежит на поверхности: выдача — это же обычная веб-страница, скачаю её curl'ом, распаршу регуляркой, и никакой SERP API мне не нужен. Идея живёт ровно до первой капчи. Обычно это происходит где-то между двадцатым и сотым запросом с одного IP.

Ниже разберём, почему самодельный парсер выдачи почти всегда дороже готового API по 0.01 ₽ за страницу, и что именно приходит в JSON вместо горы HTML.

Проблема номер ноль: вы видите не ту выдачу

Даже если скачивание удалось, встаёт вопрос: что вы скачали? Выдача Google и Яндекса персонализирована: на неё влияют история запросов, куки, регион по IP, тип устройства. Позиции, снятые с рабочего ноутбука, где вы неделю гуглили сайт клиента, показывают выдачу для вас лично, а не для его покупателей. Для честного замера нужен чистый запрос без истории и с явно заданным регионом. У Google регион задаётся числовым ID или параметром uule (про это есть отдельный разбор), у Яндекса кодом lr.

Проблемы с первой по третью: капча, блокировки, вёрстка

Поисковики зарабатывают на рекламе в выдаче и совершенно не хотят отдавать её роботам. Скрипт, качающий страницы поиска, довольно быстро упирается в капчу, потом в блокировку IP. Дальше начинается гонка: пул прокси, ротация user-agent, паузы между запросами, прогретые куки. Это отдельный проект с бюджетом на прокси и постоянной поддержкой, а не «скрипт на вечер».

И даже победив антибот, вы получаете HTML, который поисковик не обещал держать стабильным. Классы обфусцированы, вёрстка меняется без предупреждения, и парсер, писанный под сегодняшнюю разметку, через месяц молча начинает отдавать пустоту. Регулярки по выдаче — расходный материал. Хуже всего, что ломается это тихо: скрипт отработал, отчёт сформирован, а внутри нули или мусор. Замечают такое обычно не по логам, а по возмущённому письму клиента, который открыл отчёт и не поверил ни одной цифре.

Что отдаёт SERP API вместо этого

Вся эта борьба уезжает на сторону сервиса, а вам приходит JSON с готовыми полями. Для каждого результата: url, domain, title, passage (сниппет) и breadcrumbs. Запрос помещается в одну строку:

https://jsonseo.ru/api/google?key=ВАШ_КЛЮЧ&q=купить+ноутбук&region=1011969&pages=2

Регион, язык (hl), страна (gl), глубина в страницах, отключение автоисправления запроса (nfpr): всё это задаётся параметрами, полный список в документации. Для Яндекса есть /api/yandex с text и lr, для Bing /api/bing с координатами ll.

С таким ответом позиция сайта считается циклом в пять строк: идёте по массиву, сравниваете domain со своим, индекс плюс один, вот и позиция. Никаких DOM-деревьев, XPath и ночных падений из-за того, что Google переименовал класс у ссылки. Формат ответа входит в контракт сервиса: когда поисковик в очередной раз перекраивает вёрстку, адаптация происходит на нашей стороне, а ваш код продолжает читать те же поля.

Отдельно про деньги при съёме позиций. Когда нужна не вся выдача, а строчка конкретного сайта, передайте break_domain: парсер остановится на странице, где домен нашёлся, и оплатите вы только пройденные страницы, а не все десять.

Считаем на пальцах

1000 страниц выдачи стоят 10 ₽. Это меньше, чем час аренды приличного пула прокси. Тарифы целиком лежат на странице цен, при регистрации на баланс начисляются 10 ₽, то есть первая тысяча страниц бесплатная. Этого хватает, чтобы прогнать свою семантику и посмотреть на JSON вживую, а не на словах.

Если у вас уже стоит Key Collector или другой софт под Яндекс XML, переписывать ничего не нужно: те же данные отдаются и в XML-формате, совместимом с привычными программами. Как переехать за пять минут, расписано в статье про аналог XMLRiver и XMLStock.

Когда свой парсер всё-таки оправдан

Честности ради: если вам нужны специфические блоки выдачи, которых нет в структуре ответа, или объёмы такие, что своя инфраструктура окупается, пишите свой. В остальных случаях (съём позиций, мониторинг конкурентов, сбор топов под кластеризацию) задача давно сведена к одному HTTP-запросу. А если позиции нужно спрашивать голосом у ассистента, есть и MCP-сервер: инструменты google_search и google_position принимают тот же region и работают прямо из Claude.