Поиск Google для партнёров: миграция с Custom Search JSON API без слепых зон

Google указывает 1 января 2027 года как дату прекращения работы Custom Search JSON API. Одновременно в обновлённой 9 сентября документации появился Web Search Service API: он ищет по всему вебу, но доступен только программным партнёрам Google и требует клиентский идентификатор, привязанный к партнёрскому соглашению.

Для платформ аналитики соцсетей, мониторинга бренда и контент-маркетинга это не рядовая техническая замена. Если поиск Google участвует в сборе упоминаний, проверке источников, поиске копий публикаций или обогащении карточек контента, к 2027 году может измениться не только адрес API, но и сам порядок доступа к полному индексу.

Почему Google Web Search API меняет план миграции

Custom Search JSON API долго был понятным вариантом для команд, которым нужно было получать поисковую выдачу в собственном интерфейсе. Новый Web Search Service API описан иначе. Google называет его сервисом для программных партнёров: одного проекта в Google Cloud и API-ключа недостаточно.

В каждом запросе должны присутствовать три обязательных элемента:

• клиентский идентификатор, связанный с партнёрским соглашением;
• IP-адрес пользователя;
• поисковый запрос.

IP-адрес нужен для региональной маршрутизации и защиты от злоупотреблений. Для продуктовой команды это означает, что география выдачи перестаёт быть второстепенной деталью реализации. Если сервис показывает результаты для России, Казахстана, Германии или другой аудитории, правила передачи и хранения сетевых данных нужно заранее проверить вместе с юристами и специалистами по безопасности.

Документация описывает один основной метод — Search. Он выполняет поиск по всему вебу и возвращает результат в JSON через REST или gRPC. В ответе доступны заголовок, URL, сниппет, MIME-тип, формат файла, оценочное число результатов и исправленный запрос, если Google предлагает его. Можно задать язык, страну, диапазон дат, SafeSearch и сортировку по дате.

На один запрос сервис возвращает до 20 результатов, по умолчанию — 10. Следующие страницы запрашиваются через токен. Эта деталь важна для аналитики соцсетей: алгоритм, который раньше собирал широкий пул публикаций одним проходом, придётся проверить на ограничения глубины и на то, не теряются ли релевантные упоминания после первой или второй страницы.

Главная неопределённость миграции сейчас не в формате JSON, а в доступе: Google пока не раскрыла критерии партнёрства, стоимость и лимиты запросов.

Где маркетинговая платформа может потерять данные

Полный веб-поиск часто встроен в продукт незаметнее, чем кажется. Он не обязательно называется «поиск Google» в интерфейсе. Иногда это фоновый шаг, который дополняет мониторинг бренда внешними публикациями, находит первоисточник изображения или собирает ссылки для отчёта по кампании.

Проверку стоит начать с четырёх пользовательских сценариев.

Поиск упоминаний за пределами собственных площадок

Мониторинг бренда редко ограничивается постами и комментариями в подключённых соцсетях. Веб-поиск помогает находить статьи, обзоры, каталоги, публичные обсуждения и перепечатки. Если этот слой исчезнет без замены, отчёт сохранит привычные графики, но потеряет часть внешнего контекста.

Для PR и SMM это риск ложного спокойствия. Вовлечённость в собственных каналах может выглядеть стабильно, пока заметное обсуждение развивается на стороннем ресурсе, который больше не попадает в сбор.

Проверка источника и копий контента

Поисковая выдача может быть одним из сигналов в задачах Smart Search: она помогает сопоставить публикацию с внешними страницами, подтвердить первичный источник или обнаружить распространение материала. Здесь нельзя обещать, что новый партнёрский сервис автоматически повторит поведение старого API: доступные поля описаны, но условия подключения и фактические лимиты ещё не опубликованы.

Поэтому полезно разделить процесс на две части: собственный алгоритм сопоставления и внешний поисковый источник. Тогда смена провайдера не превратится в переписывание всего контура поиска копий.

Обогащение отчётов по конкурентам

Digital-маркетинг опирается не только на прямые метрики каналов. Для оценки контентной активности конкурента командам часто нужны найденные публикации, даты, ссылки и заголовки. Параметры языка, страны и даты в новом сервисе потенциально полезны для таких задач, но их недостаточно считать гарантией полноценной замены до получения доступа и тестов на реальных запросах.

Контроль поисковых запросов пользователей

В ответе Web Search Service API может приходить исправленный запрос. Для продукта это сигнал о том, что пользовательская формулировка не совпала с тем, как Google интерпретирует потребность. В интерфейсах аналитики такой сигнал стоит хранить отдельно от исходного запроса: он может помочь улучшить подсказки, словари вариантов написания бренда и настройки мониторинга.

Переход с Custom Search JSON API: сначала инвентаризация, потом код

Самая дорогая ошибка — начать замену интеграции с технической библиотеки, не понимая, какие решения зависят от выдачи. У Web Search Service API пока нет публичного описания цены, квот и процесса получения партнёрского статуса. Значит, план должен предусматривать вариант, при котором доступ не будет выдан быстро или условия окажутся неподходящими для конкретного объёма запросов.

1. Зафиксировать все места использования поиска

Нужно найти не только прямые вызовы Custom Search JSON API, но и косвенные зависимости: очереди задач, фоновые джобы, экспорт отчётов, ручные инструменты аналитиков, правила дедупликации и подсказки в интерфейсе.

Для каждого вызова стоит записать:

• продуктовый сценарий и владельца процесса;
• запрос, параметры страны и языка;
• ожидаемое число результатов;
• частоту вызовов;
• обязательные поля ответа;
• допустимую задержку;
• последствия, если поиск временно недоступен.

Такой список покажет, где действительно нужен поиск по всему вебу, а где достаточно поиска по ограниченному набору сайтов или данных самой платформы.

2. Отделить полный веб-поиск от поиска по списку доменов

В январском сообщении Google уточнила направление развития Programmable Search Element: виджет поиска по сайту ориентируется на сценарии с 50 доменами или меньше. Пользователям, которые ищут более чем по 50 доменам или по всему вебу, нужно перейти на другое решение до 1 января 2027 года.

Это удобная развилка для архитектуры. Поиск по собственным документациям, базе знаний клиента или фиксированному списку медиа не требует того же контура, что мониторинг открытого веба. Если смешать их в одном сервисе, более сложный партнёрский доступ начнёт определять стоимость и надёжность даже простых сценариев.

3. Подать заявку и не строить план на предположениях

Google ранее направляла разработчиков, которым требуется весь индекс, к форме интереса для отдельного решения полного веб-поиска. Обновлённая документация Web Search Service API подтверждает существование партнёрского сервиса, но не объясняет, может ли текущий пользователь Custom Search JSON API перейти на него автоматически.

Заявку разумно подать заранее, приложив описание сценария, примерный объём запросов, страны и требования к данным. Но дорожная карта не должна исходить из того, что соглашение будет заключено или условия окажутся одинаковыми для всех клиентов.

4. Создать слой адаптера выдачи

Внешний поиск следует изолировать за внутренним контрактом. Остальная система должна получать нормализованный объект: запрос, список результатов, URL, заголовок, сниппет, дату получения, параметры региона и технический статус.

Тогда Web Search Service API, поиск по ограниченным доменам и резервный поставщик останутся взаимозаменяемыми на уровне интеграции. Для FollowPulse такой подход особенно важен в связке с мониторингом бренда и Smart Search: продуктовая логика должна работать с сигналами, а не быть жёстко привязана к одному методу получения ссылок.

5. Подготовить тестовый набор запросов

Тесты не стоит сводить к одному брендовому запросу. Набор должен включать варианты написания бренда, название продукта, запросы с опечатками, конкурентные сравнения, свежие публикации, разные страны и языки. Для каждого запроса нужно сохранить ожидаемую полезность результата, а не только факт ответа со статусом 200.

Важны и отрицательные сценарии: пустая выдача, исправленный запрос, недоступная следующая страница, медленный ответ, отсутствие нужного поля. Именно они чаще всего ломают автоматические отчёты и цепочки обработки контента.

Какие метрики нужны до и после миграции

Успех перехода нельзя измерять только тем, что новый API возвращает JSON. Для маркетинговой платформы полезнее контролировать качество данных и влияние на пользовательский сценарий.

Покрытие запросов. Какая доля запросов получила результат и какая доля завершилась технической ошибкой или пустой выдачей. Пустой ответ нужно отделять от отсутствия релевантных упоминаний: это разные причины и разные действия.

Полнота результатов. Сколько результатов в среднем попадает в обработку и сколько страниц требуется для типовых задач. Лимит до 20 результатов на запрос делает эту метрику особенно важной для широких тем и мониторинга репутационных всплесков.

Региональная согласованность. Совпадает ли страна, указанная в запросе, с тем, какой контекст нужен пользователю. Передача IP для маршрутизации добавляет ещё одну переменную, которую стоит логировать в безопасной, неидентифицирующей форме.

Свежесть. Как быстро в выдаче появляются новые материалы и как отрабатывает фильтр по датам. Для контент-маркетинга и реагирования на упоминания ценность часто определяется не общим числом ссылок, а временем до первого сигнала.

Доля полезных результатов. Аналитик или автоматическое правило может отмечать, какие найденные страницы действительно пригодились в отчёте, мониторинге или проверке источника. Такая обратная связь поможет сравнить старый и новый контур без выдуманных универсальных коэффициентов качества.

Безопасность и юридические вопросы нельзя оставить на потом

Требование передавать IP-адрес пользователя нужно рассматривать до запуска интеграции. В зависимости от того, как построена платформа, запрос может идти от сервера, от пользовательского устройства или через промежуточный сервис. Это влияет на состав передаваемых данных, текст политики конфиденциальности, логи и сроки хранения.

Минимальный набор решений выглядит так:

• определить, какой IP передаётся и зачем он нужен конкретному сценарию;
• не писать полный IP в продуктовые логи без необходимости;
• разделить технические журналы и данные аналитики;
• проверить требования законодательства стран, где работает сервис;
• описать пользователю, когда поиск обращается к Google.

Отдельно стоит проверить, не используют ли команды результаты поиска для автоматических выводов о тональности или репутации. Сниппет и заголовок помогают найти страницу, но не заменяют чтение материала и не доказывают контекст упоминания.

Что это значит для SMM и аналитики соцсетей

Миграция с Custom Search JSON API — повод перестроить не только интеграцию, но и отношение к внешней выдаче. Поисковый слой полезен для мониторинга бренда, но не должен быть единственной точкой правды. Собственные данные соцсетей и мессенджеров, история публикаций, реакции, охваты и контекст обсуждений должны сохранять самостоятельную ценность.

Следующий год имеет смысл использовать для аудита: какие сигналы приходят из веб-поиска, какие можно получить напрямую из платформ, а какие требуют отдельного партнёрского решения. Такой разбор снижает риск, что отключение API в 2027 году превратится в внезапное ухудшение аналитики.

Чеклист

1. Найти все прямые и косвенные вызовы Custom Search JSON API в продукте, отчётах и фоновых задачах.
2. Разметить сценарии: полный веб-поиск, поиск по ограниченному списку доменов и поиск по собственным данным.
3. Зафиксировать для каждого сценария запросы, географию, язык, глубину выдачи и обязательные поля.
4. Подать заявку на доступ к полному веб-поиску Google, не считая его гарантированным маршрутом миграции.
5. Вынести поставщика выдачи за внутренний адаптер и подготовить нормализованный формат результата.
6. Собрать тестовый набор запросов, включая опечатки, разные страны, свежие публикации и пустую выдачу.
7. Настроить метрики покрытия, полноты, свежести и полезности результатов до отключения старого API.

FAQ

Когда перестанет работать Custom Search JSON API?

Google указывает дату прекращения работы Custom Search JSON API — 1 января 2027 года. Сервис также закрыт для новых клиентов.

Можно ли подключить Google Web Search API только с API-ключом?

Нет. В документации указаны проект Google Cloud, API-ключ и клиентский идентификатор, связанный с партнёрским соглашением Google. Условия получения такого соглашения публично не раскрыты.

Сколько результатов возвращает Web Search Service API за запрос?

По документации сервис возвращает до 20 результатов за запрос, а по умолчанию — 10. Для получения следующих страниц используется токен.

Нужен ли Web Search Service API для поиска по собственному сайту?

Не обязательно. Google сообщала, что Programmable Search Element ориентирован на поиск по 50 доменам или меньше. Полный веб-поиск нужен для другого сценария и требует отдельного рассмотрения.

Какие данные можно получить в ответе Google Web Search API?

Документация перечисляет заголовок, URL, сниппет, MIME-тип, формат файла, оценочное число результатов и исправленный вариант запроса. Также доступны параметры языка, страны, даты, SafeSearch и сортировки по дате.

Как подготовить мониторинг бренда к смене API?

Нужно отделить внешний поиск от бизнес-логики мониторинга, сохранить тестовый набор запросов и сравнивать не только техническую доступность, но и полноту, свежесть и полезность найденных упоминаний.

FollowPulse помогает объединить аналитику соцсетей, Telegram Analytics и мониторинг бренда в одном рабочем контуре.

Пользуйся FollowPulse и получай:

• Аналитику соцсетей
• Умный поиск информации
• Рост своего бренда

Пробный доступ — от 10 рублей.

Попробовать FollowPulse