Bing Search API закрыт: чем заменить Bing Web Search в 2026 году

История с Bing Search API закончилась не внезапно, но всё равно для многих разработчиков она стала неприятным сюрпризом. Вроде бы был понятный инструмент: отправляешь запрос, получаешь поисковые результаты, встраиваешь их в продукт, аналитику или внутренний сервис. Работает? Работает.

А потом — всё. Старый сценарий больше не живёт.

Microsoft официально закрыла Bing Search APIs. В объявлении Microsoft указано, что сервисы Bing Search APIs были retired 11 августа 2025 года, а существующие instances decommissioned. Иными словами, привычного Bing Web Search API, к которому многие успели привыкнуть, больше нет.

На замену Microsoft предлагает другой подход — Grounding with Bing, а также web search tools внутри Microsoft Foundry и Azure AI Agents. Это не плохо. Просто это другое.

И вот тут начинается самое интересное: если вам нужен AI-агент, который сам ходит в веб и подтягивает свежие источники для ответа, новый Microsoft-подход может оказаться удобным. Но если вы раньше использовали Bing Search API как источник структурированной выдачи — для SEO, мониторинга, аналитики, проверки позиций, внутреннего поиска или своего retrieval pipeline — то прямая замена не такая очевидная.

Разбираемся спокойно. Без паники, но и без иллюзий.

Что именно закрылось

Раньше Bing Search API был понятным способом получить поисковую выдачу Bing программно. Его использовали не только для классического поиска. Через него строили самые разные штуки:

• внутренний поиск по вебу;
• SEO-мониторинг;
• сбор новостей;
• анализ конкурентов;
• проверку позиций;
• research-инструменты;
• контекст для AI-моделей;
• альтернативные поисковые интерфейсы;
• автоматические отчёты по рынку.

То есть Bing Search API был не просто «поиском». Для многих команд это был кусок инфраструктуры.

После закрытия всё стало менее прямолинейно. Microsoft больше не предлагает старый Bing Web Search API как универсальный способ получать список результатов поиска в удобном формате. Вместо него компания развивает инструменты для AI-grounding: поиск становится частью агентской системы, а не отдельным источником raw search results.

Звучит похоже, но на практике разница большая.

Что Microsoft предлагает вместо Bing Web Search API

Главная замена — Grounding with Bing и веб-поиск внутри Microsoft Foundry Agent Service.

Если совсем коротко: Bing теперь чаще предлагается использовать как источник свежего контекста для AI-агента. Модель получает доступ к актуальной информации из веба, формирует ответ и может указывать источники.

Для AI-ассистента это удобно. Например, пользователь спрашивает: «Что изменилось в регулировании рекламы за последние месяцы?» Агент идёт в веб, находит свежие материалы, подтягивает контекст и отвечает уже не из своей «памяти», а с опорой на новые источники.

Нормальный сценарий. Даже хороший.

Но есть нюанс. Старый Bing Web Search API был про данные. Новый grounding-подход — скорее про ответ.

А если продукту нужны не красивые фразы модели, а сами результаты поиска? Ссылки, позиции, сниппеты, заголовки, регионы, языки, новости, shopping-блоки, локальная выдача, изменения во времени? Тут уже начинается другая история.

Grounding with Bing и SERP API — не одно и то же

Иногда эти вещи смешивают. Мол, раз Bing теперь доступен для grounding, значит, всё нормально, замена есть. Ну… не совсем.

Grounding with Bing отвечает на вопрос:

Как дать AI-модели свежую информацию из интернета, чтобы она лучше ответила пользователю?

SERP API отвечает на другой вопрос:

Как получить поисковую выдачу в структурированном виде и использовать её в своём продукте?

Это разные задачи. Примерно как спросить у таксиста дорогу и самому получить карту с координатами, маршрутами, пробками и всеми поворотами. И там, и там вы вроде бы «добираетесь», но контроль совершенно разный.

Вот в этом и суть. Grounding помогает модели отвечать. SERP API помогает продукту работать с поисковыми данными.

Когда Grounding with Bing вполне достаточно

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

Grounding with Bing или Web Search tool in Microsoft Foundry Agent Service может подойти, если:

• вы уже используете Azure или Microsoft Foundry;
• у вас есть AI-агент, которому нужно ходить в веб;
• вам важен готовый ответ, а не полный список результатов;
• вы не строите собственный SERP-интерфейс;
• вам не нужно хранить поисковую выдачу;
• вы не сравниваете позиции день к дню;
• вы готовы жить внутри агентской архитектуры Microsoft.

Например, у вас корпоративный ассистент. Его спрашивают: «Какие новости по этой компании появились за неделю?» Он ищет источники, собирает ответ, прикладывает ссылки. Всё нормально.

Или другой пример: внутренний AI-помощник для поддержки продаж. Ему нужно быстро понять, что происходит с клиентом или рынком. Тут grounding выглядит логично.

Но если вы делаете SEO-инструмент, мониторинг выдачи, аналитику конкурентов или свой AI-поиск с контролируемым retrieval-слоем, вам, скорее всего, нужно не это.

Когда нужен SERP API

SERP API нужен там, где поисковая выдача — это не побочный эффект ответа модели, а самостоятельный источник данных.

Например, вам нужно:

• отслеживать позиции сайта по ключевым словам;
• проверять, какие страницы попали в топ;
• собирать выдачу по разным регионам и языкам;
• сравнивать Google, Bing, DuckDuckGo и другие engines;
• анализировать title, snippet, URL и дополнительные блоки;
• мониторить конкурентов;
• смотреть, как меняется выдача после апдейтов;
• собирать новости по темам;
• передавать результаты в AI-модель уже после собственной фильтрации;
• строить дашборды и отчёты;
• проверять, какие источники появляются рядом с вашим брендом.

Тут нужен не просто «ответ». Нужны данные. Желательно в предсказуемом JSON, без плясок вокруг HTML, банов, капч и внезапных изменений верстки.

И вот тут появляется смысл смотреть в сторону поисковых API вроде Xylop, где можно работать с поисковыми engines через единый интерфейс и использовать результаты дальше в своём продукте, аналитике или AI-пайплайне.

Какие варианты есть после закрытия Bing Search API

Если ваш продукт раньше зависел от Bing Search API, вариантов не так уж много. Но они есть.

Вариант 1. Перейти на Microsoft Foundry Web Search

Это самый официальный путь.

Microsoft развивает web search tools для агентов, включая Web Search tool и Grounding with Bing Search tools. Если вы уже в Azure, используете Foundry и строите AI-агента, сначала стоит посмотреть именно туда.

Плюсы:

• официальный инструмент Microsoft;
• хорошо встраивается в Azure / Foundry;
• подходит для AI-агентов;
• можно получать ответы с опорой на свежие источники.

Минусы:

• это не старый Bing Web Search API;
• меньше контроля над raw-выдачей;
• не очень подходит для SEO-мониторинга;
• сложно использовать как универсальный источник SERP-данных;
• есть привязка к экосистеме Microsoft.

То есть для AI-ассистента — да. Для rank tracker или search intelligence платформы — уже вопрос.

Вариант 2. Использовать SERP API

SERP API — более близкая замена для тех, кто раньше хотел получать именно поисковые результаты.

Например, в Xylop базовая логика строится вокруг поискового endpoint. В документации можно посмотреть параметры и примеры запросов.

Пример запроса может выглядеть так:

curl "https://api.xylop.ru/search?engine=google&q=best+laptop&location=united_states&hl=en&api_key=YOUR_KEY"

Смысл не в конкретной строке curl, конечно. Смысл в подходе: вы отправляете запрос, задаёте параметры, получаете структурированный ответ и дальше сами решаете, что с ним делать.

Можно сохранить результаты. Можно отправить их в модель. Можно построить отчёт. Можно сравнить с предыдущим снимком выдачи. Можно собрать свои метрики.

Плюсы:

• структурированные данные;
• единая интеграция;
• проще строить аналитику;
• подходит для SEO, AI-продуктов и внутренних инструментов;
• не нужно поддерживать собственный парсер;
• можно работать с несколькими engines через один слой.

Минусы тоже есть:

• нужно учитывать тарифы и лимиты;
• нужно заранее проверить поддержку нужных engines и параметров;
• как и с любым API, лучше иметь обработку ошибок, кеширование и fallback.

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

Вариант 3. Написать свой парсер

Да, можно. Технически почти всё можно.

Но собственный парсер поисковой выдачи — это не «поставили библиотеку и забыли». Это инфраструктура. Причём капризная.

Придётся думать про:

• блокировки;
• изменения HTML;
• прокси;
• очереди;
• retries;
• геолокации;
• языки;
• нормализацию результатов;
• хранение снапшотов;
• мониторинг качества;
• юридические и продуктовые риски;
• поддержку всего этого добра.

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

Если нет, готовый SERP API обычно выигрывает просто потому, что экономит время. А время разработки, как выясняется каждый квартал, почему-то не бесплатное.

Вариант 4. Собрать гибрид из разных API

Ещё один путь — использовать несколько отдельных инструментов:

• один API для web search;
• другой для новостей;
• третий для карт;
• четвёртый для shopping;
• отдельный grounding-инструмент для AI-ответов.

На старте это может выглядеть гибко. Потом у каждого API появляются свои форматы, лимиты, ошибки, названия полей, pricing, странности и «а почему тут link, а там url?».

Гибридный подход нормален, если вы осознанно строите сложную архитектуру. Но если задача — быстро заменить Bing Search API и не расползтись по пяти интеграциям, единый SERP API обычно практичнее.

Почему это особенно важно для AI-продуктов

Есть забавный парадокс. В эпоху AI поисковые данные стали не менее важными, а более.

Модель может красиво писать, спору нет. Но если вопрос касается текущих событий, цен, вакансий, компаний, локального бизнеса, товаров или новостей, ей нужен свежий контекст. Без него получится уверенный текст на песке.

Есть два основных подхода.

Первый — дать модели встроенный web grounding. Она сама ищет, сама выбирает источники, сама формирует ответ.

Второй — сначала получить поисковые результаты через SERP API, затем обработать их своим backend: отфильтровать мусор, убрать дубли, выбрать источники, сохранить данные, а уже потом передать модели аккуратно подготовленный контекст.

Второй путь чуть сложнее. Зато он даёт контроль.

Вы видите, какие источники были найдены. Можете сохранять результаты. Можете повторить запрос. Можете объяснить, почему модель получила именно такой контекст. Для серьёзных AI-продуктов это важно, особенно если речь не о демо, а о рабочем сервисе.

Почему это важно для SEO

SEO-командам, честно говоря, и так скучать не приходится. AI Overview, новые SERP-фичи, локальные блоки, сниппеты, апдейты алгоритмов, разный SERP в разных регионах — весёлый парк аттракционов, только ремень безопасности иногда забыли выдать.

Закрытие Bing Search API — ещё один сигнал: прямой доступ к поисковым данным становится сложнее.

А выдача всё ещё нужна. Потому что именно SERP показывает:

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

Google Search Console и Bing Webmaster Tools полезны, но они показывают только часть картины. Они не заменяют живую выдачу. А если нужно видеть рынок, конкурентов и структуру SERP, без внешнего слоя поисковых данных сложно.

Как понять, что вам нужен именно SERP API

Можно пройтись по простому списку.

Вам, скорее всего, нужен SERP API, если:

• вам нужен список результатов, а не только AI-ответ;
• нужно хранить позиции;
• нужно сравнивать выдачу во времени;
• важны регион и язык;
• нужно мониторить конкурентов;
• нужно строить отчёты;
• нужно подключить несколько поисковых engines;
• результаты поиска надо передавать в свой backend;
• нужен стабильный JSON;
• вы хотите сами контролировать retrieval для AI-модели.

Если вы ответили «да» хотя бы на несколько пунктов, grounding-инструмента может не хватить. Не потому что он плохой. Просто он про другое.

Где здесь может помочь Xylop

Xylop — это поисковый API для продуктов, аналитики и внутренних инструментов. Его можно использовать как слой доступа к поисковым данным: отправляете запрос, получаете структурированный ответ, дальше используете его в своём коде.

Для команды, которая ищет замену Bing Web Search API, Xylop может быть полезен в нескольких сценариях.

Единый API вместо набора разрозненных интеграций

Сегодня вам нужен Bing. Завтра — Google. Потом DuckDuckGo, новости, карты, локальная выдача, shopping или что-то ещё.

Если каждый источник подключать отдельно, интеграции быстро начинают жить своей жизнью. Единый Search API помогает держать это в одном месте.

Данные в формате, пригодном для продукта

HTML-страница хороша для человека. Для backend она так себе.

Продукту обычно нужны поля: title, link, snippet, position, metadata, параметры запроса, дополнительные блоки. Всё это должно нормально парситься, сохраняться и передаваться дальше.

SERP API как раз закрывает эту задачу.

Контекст для AI-моделей

AI-агенту не обязательно самому бесконтрольно бегать по вебу. Иногда лучше сделать так:

1. backend запрашивает SERP API;
2. результаты фильтруются;
3. дубли убираются;
4. источники ранжируются;
5. нужный контекст передаётся модели;
6. исходные данные сохраняются для проверки.

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

SEO-мониторинг и search intelligence

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

AI-grounding для этого неудобен. SERP API — как раз тот инструмент.

SERP API не заменяет вообще всё

Тут стоит не перегибать.

SERP API не заменяет:

• Google Search Console;
• Bing Webmaster Tools;
• рекламные кабинеты;
• CRM;
• внутреннюю аналитику;
• first-party данные;
• официальные API платформ, если они подходят под задачу.

SERP API — это слой внешней поисковой видимости. Он показывает, что видно в поиске: какие страницы, какие конкуренты, какие блоки, какие изменения.

И уже вокруг этого можно строить продуктовую или аналитическую логику.

Мини-чеклист для миграции с Bing Search API

Если ваш сервис раньше использовал Bing Search API, не начинайте сразу с выбора новой платформы. Сначала разберите, что именно вам нужно.

1. Выпишите, какие данные вы получали

Не просто «мы использовали поиск», а конкретно:

• organic results;
• новости;
• изображения;
• snippets;
• ranking positions;
• локальные результаты;
• выдача по регионам;
• выдача по языкам;
• контекст для AI;
• related queries;
• shopping-данные.

От этого зависит, чем заменять старый API.

2. Разделите AI-ответы и поисковую выдачу

Если вам нужен готовый AI-ответ с источниками — смотрите в сторону Microsoft Foundry Web Search.

Если вам нужны сами результаты поиска — смотрите в сторону SERP API.

Это разные этажи архитектуры. Их лучше не путать.

3. Проверьте требования к контролю

Задайте себе несколько неприятных, но полезных вопросов:

• нужно ли повторять запросы регулярно;
• нужно ли сравнивать выдачу во времени;
• нужно ли хранить результаты;
• нужно ли контролировать регион и язык;
• нужно ли передавать данные в свой backend;
• нужен ли fallback;
• нужно ли подключать несколько engines.

Если да, вам нужен управляемый слой поисковых данных.

4. Сделайте внутреннюю абстракцию

Даже если вы выбрали конкретный API, не размазывайте его вызовы по всему коду. Лучше сделать внутренний слой:

SearchProvider
  -> search(query, engine, location, language)
  -> normalize(results)
  -> store(snapshot)
  -> passToAnalyticsOrLLM()

Потом будет проще менять провайдера, добавлять кеширование, делать fallback и не переписывать половину продукта.

5. Посчитайте реальную стоимость

Сравнивать API только по цене за тысячу запросов — ловушка.

Нужно учитывать:

• сколько запросов уходит на один пользовательский сценарий;
• нужны ли retries;
• сколько регионов проверяется;
• сколько engines используется;
• как часто обновляются данные;
• есть ли кеширование;
• сколько результатов нужно хранить;
• сколько стоит поддержка собственной инфраструктуры.

Иногда самый «дешёвый» вариант оказывается дорогим, потому что команда тратит недели на поддержку, исправления и костыли. Немного неприятно, но так бывает часто.

Что выбрать в итоге

Если вы строите AI-агента внутри Microsoft Foundry и вам нужен готовый ответ со свежими источниками, логично начать с Web Search tool или Grounding with Bing.

Если вы строите SEO-инструмент, мониторинг выдачи, search intelligence платформу, внутреннюю аналитику или AI-продукт с собственным retrieval pipeline, вам, скорее всего, нужен SERP API.

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

FAQ

Bing Search API действительно закрыт?

Да. Microsoft официально объявила, что Bing Search APIs были закрыты 11 августа 2025 года. Старые instances были decommissioned, а сервис больше не доступен в прежнем виде. Подробности есть в официальном объявлении Microsoft.

Grounding with Bing — это замена Bing Web Search API?

Частично, но не полностью. Grounding with Bing подходит для AI-агентов, которым нужен свежий web-контекст. Но если вам нужна структурированная поисковая выдача, позиции, URL, сниппеты и контроль над результатами, это уже задача SERP API.

Что лучше выбрать для AI-продукта?

Если вам нужен просто ответ модели с источниками, можно смотреть в сторону Microsoft Foundry Web Search.

Если вы хотите сами контролировать поиск, фильтровать источники, сохранять результаты и передавать модели подготовленный контекст, лучше использовать SERP API как отдельный retrieval-слой.

Что лучше для SEO-мониторинга?

Для SEO-мониторинга обычно нужен SERP API. Вам важно видеть позиции, сниппеты, URL, конкурентов, SERP-фичи, регионы и изменения во времени. Grounding-инструмент для этого не очень подходит, потому что он заточен под генерацию ответа, а не под анализ выдачи.

Можно ли написать свой парсер?

Можно. Но это отдельный технический проект: прокси, блокировки, очереди, retries, изменения HTML, нормализация данных, мониторинг качества. Если у вас нет команды, которая готова это постоянно поддерживать, готовый API чаще будет проще.

Короткий итог

Закрытие Bing Search API — не конец света. Но это заметный сдвиг.

Microsoft теперь ведёт разработчиков в сторону AI-grounding и агентских сценариев. Для части продуктов это хорошо. Для других — не совсем то, что нужно.

Если вам нужен AI-ответ со свежими источниками, смотрите в сторону Grounding with Bing и Microsoft Foundry Web Search.

Если вам нужны сами поисковые данные — выдача, позиции, сниппеты, URL, регионы, сравнение engines и контроль над результатами — вам нужен SERP API.

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

Полезные ссылки

• Официальное объявление Microsoft о закрытии Bing Search APIs
• Grounding with Bing
• Web Search tool in Microsoft Foundry Agent Service
• Grounding with Bing Search tools with the agents API
• Xylop — поисковый API для продуктов и аналитики
• Документация Xylop