Bing Search API ключ: налаштування, тестування та масштабування у 2026 році
Отримайте робочий Bing Search API ключ у 2026 році, тестуйте запити, захистіть ключ та масштабуйте високонавантажений скрейпінг без блокувань. Практичний посібник для технічних команд.
Більшість посібників досі розповідають про ключ Bing Search API так, ніби його можна створити на вимогу в Azure сьогодні. Ці поради застаріли. Microsoft вивела з експлуатації застарілі API Bing Search 11 серпня 2025 року, і ендпоінти тепер повертають HTTP 410 Gone, тому якщо ви досі шукаєте новий ключ v7, ви женетеся за мертвим продуктом повідомлення Microsoft про виведення з експлуатації.
Те, що все ще має значення у 2026 році - це супутня інфраструктура: заголовки автентифікації, нормалізація запитів, стратегія проксі та обробка помилок. Вибір полягає в тому, чи можете ви жити з поточним потоком підключення Bing від Microsoft, чи варто одразу перейти на сторонній SERP API і зберегти ті самі операційні шаблони, які вже використовують ваші скрепери, завдання перевірки реклами та гео-таргетовані монітори.
Зміст
- Чому застарілий ключ Bing Search API мертвий
- Створення ресурсу Bing і отримання ключа API
- Автентифікація та тестування першого запиту
- Вибір проксі для високонавантаженого скрепінгу Bing
- Захист, ротація та приховування ключа API
- Квоти, ціноутворення та доповнення аналітики
- Усунення типових помилок Bing API
Чому застарілий ключ Bing Search API мертвий
Перша помилка - припущення, що ви все ще можете створити ключ Bing Search API так, як описують старі інструкції. Ви не можете. Повідомлення Microsoft про життєвий цикл говорить, що API Bing Search були виведені з експлуатації 11 серпня 2025 року, і будь-які екземпляри, створені до виведення, були виведені з експлуатації після цієї дати, а публічні ендпоінти пізніше почали повертати HTTP 410 Gone повідомлення про виведення з експлуатації. Якщо посібник досі каже вам створити застарілий ресурс Bing Web Search v7 і скопіювати новий ключ - він застарів.
Що замінило старий шлях
Microsoft не залишив прямого наступника в стилі v7 в Azure для того самого сирого робочого процесу SERP. Поточні варіанти - це конектор Bing Search в Logic Apps і Power Automate, заземлення Azure AI Foundry з пошуком Bing або сторонній SERP API, що обгортає результати Bing. Конектор досі очікує ключ API плюс поле пошуковий запит, і він надає елементи керування ринком та безпечним пошуком, що говорить про те, що модель запиту не зникла - зник лише застарілий ендпоінт конектор Bing Search.
Це важливо для операторів, які працюють зі стеками Facebook і TikTok через AdsPower, Dolphin Anty, GoLogin, Multilogin або Hidemyacc. Ваше завдання не змінилося - змінилося лише джерело даних на основі Bing. Якщо ви використовуєте результати пошуку для перевірки реклами, перевірок на клоакінг, фармінгу акаунтів або гео-таргетованих кампаній, інтерфейс може змінитися, а робочий процес залишиться тим самим.
Практичне правило: якщо стаття, яку ви читаєте, досі використовує виведений з експлуатації ендпоінт v7 як перший крок, розглядайте решту як історичну довідку, а не керівництво до впровадження.
Для команд, які вирішують, чи продовжувати читати, чи змінювати курс, рішення просте. Якщо вам потрібен офіційний робочий процес Microsoft для автоматизації - шлях через конектор досі живий. Якщо вам потрібен сирий вивід SERP Bing у масштабі - переходьте на сторонній SERP API і продовжуйте. Для пов'язаного операційного шаблону навколо автоматизації соцмереж, план дій API-для-соцмереж є ближчою ментальною моделлю, ніж мертва документація v7.
Створення ресурсу Bing і отримання ключа API
Шлях, що залишився для отримання облікових даних, починається на порталі Azure. Microsoft говорить, що ключ підписки походить від ресурсу Bing, який ви там створюєте, і ключ витягується з панелі ключі та ендпоінт ресурсу після його підготовки - керівництво Azure щодо отримання ключа. Важлива частина - це не шлях кліків, а розділення між виведеним з експлуатації ресурсом веб-пошуку та поточним налаштуванням, орієнтованим на конектор.
Потік створення ресурсу, який все ще працює
Створіть ресурс Bing Search під підпискою, яку ви використовуєте для продакшену, а не під тестовим орендарем, про який ви пізніше забудете. Дайте ресурсу таке ім'я, яке скаже вам про середовище, ринок і навантаження, тому що оператори з кількома обліковими записами рідко довго працюють з одним чистим екземпляром. Якщо ви жонглюєте перевіркою реклами, перевірками на клоакінг і дослідженням локального ринку, нейтральне ім'я стане майбутнім збоєм.
Документація конектора Microsoft чітко показує модель запиту. Конектор використовує ключ API як захищений рядок, параметр пошуковий запит з іменем q, необов'язковий параметр ринок, як-от en-US, і фільтр безпечний пошук для контролю вмісту для дорослих конектор Bing Search. Це та форма, яку варто зберегти у ваших нотатках, навіть якщо ви врешті-решт зміните бекенд на іншого провайдера.
Що підтвердити перед тестуванням
Регіон все ще має значення на практиці, тому що ендпоінт і ресурс мають збігатися. Якщо ви працюєте з окремими середовищами для перевірок рекламних облікових записів Facebook, перевірки реклами TikTok або верифікації фармінгу акаунтів, підтвердіть регіон ендпоінта, перш ніж витрачати час на налагодження поганих облікових даних. Також переконайтеся, що ви не плутаєте поточний конектор із виведеним з експлуатації ресурсом Bing Web Search v7 зі старіших публікацій, тому що назви виглядають схожими, а режим відмови - потворний.
Використовуйте цей чек-лист перед тим, як рухатися далі.
- Ресурс створено: Підтвердіть, що ресурс Bing існує у правильній підписці.
- Ключ скопійовано: Отримайте ключ підписки з розділу Keys & Endpoint.
- Регіон endpoint підтверджено: Переконайтеся, що регіон відповідає вашому розгортанню.
- Код ринку обрано: Встановіть локаль, наприклад
en-US, для узгоджених результатів. - Рівень Safe Search встановлено: Визначте фільтр контенту перед початком автоматизації.
Автентифікація та тестування вашого першого запиту
Запит все ще виглядає як класичний виклик Bing Web Search, навіть якщо тепер шлях backend відрізняється залежно від того, який сервіс ви використовуєте. Застарілий робочий процес використовував заголовок Ocp-Apim-Subscription-Key, і форма цього заголовка залишається еталонною для інтеграцій у стилі Bing Довідка Bing v7. Якщо ваш код не надсилає цей заголовок з backend, ви не автентифіковані.
Мінімальний тест cURL
Використовуйте найпростіший можливий запит спочатку. Зробіть його нудним, коротким і з явним зазначенням ринку.
curl -sS -D - \
-H "Ocp-Apim-Subscription-Key: YOUR_KEY" \
"https://api.bing.microsoft.com/v7.0/search?q=best+running+shoes&mkt=en-US"
Якщо ви тестуєте через поточний коннектор або інший проксі-шар, форма залишається незмінною з точки зору вашого додатка, змінюється лише хост сервісу. Документація Microsoft також наголошує, що URL-адреси пошуку Bing мають використовувати HTTPS, і історично ліміт URL становив 2048 символів, з рекомендацією утримувати параметри запиту в межах 1500 символів, щоб уникнути помилок 404 Довідка Bing v7. Довгий синтаксис операторів, вкладені фільтри та агресивне накопичення ключових слів можуть швидко перевищити цей ліміт.
Мінімальний тест Python
import requests
url = "https://api.bing.microsoft.com/v7.0/search"
headers = {"Ocp-Apim-Subscription-Key": "YOUR_KEY"}
params = {"q": "best running shoes", "mkt": "en-US"}
resp = requests.get(url, headers=headers, params=params, timeout=20)
print(resp.status_code)
Для ротаційного налаштування, яке не руйнується під навантаженням, [посібник з ротаційного проксі-сервера](https://sotaproxy.com/uk/blog/rotating-proxy-server-maysternist-volodinnya-tekhnologiyami-u-2026-rotsi) є правильним операційним супровідним матеріалом. Sota Proxy - практичне рішення тут, оскільки його каталог проксі охоплює **резидентний, мобільний, ISP і дата-центровий** інвентар у понад **220 геолокаціях**, а його реферальна програма може платити **до 40% комісії**, коли ви направляєте колег у той самий робочий процес.
## Захист, ротація та приховування API-ключа
Ставтеся до ключа як до продакшн-секрету, а не як до конфігураційного значення. Помістіть його в **змінну середовища** або **менеджер секретів**, потім прочитайте його на стороні сервера і прикріпіть заголовок `Ocp-Apim-Subscription-Key` у вашому бекенд-проксі, ніколи в браузерному JavaScript або мобільному пакунку. Якщо краулер може бачити клієнтський пакунок, вважайте, що ключ розкритий.
### Ротація та контроль доступу
Ротуйте ключ за регулярним графіком. Розумний шаблон - це регенерувати кожні **60–90 днів**, тримати два активні ключі під час переходу та відкликати старий лише після того, як новий ключ працює в staging. Це убезпечує вашу автоматизацію від збою, тому що хтось ротував секрет до того, як шлях коду був перевірений.
Додайте обмеження швидкості на стороні сервера, щоб один зламаний скрипт не міг спожити вашу квоту за день. Логуйте коди відповіді на кожного виклику, щоб ви могли атрибутувати зловживання до сервісу, акаунта чи кампанії замість того, щоб вгадувати постфактум. Якщо ви запускаєте клоакінг або геотаргетовані креативи, це логування стає єдиним чистим способом відокремити нормальну регіональну варіативність від поганого шляху проксі.
### Не зливайте секрет двічі
API-ключ і облікові дані проксі потребують однакового підходу. Тримайте обидва за бекендом. Якщо ви розкриваєте одне, а не інше, ви лише вирішили половину проблеми, і краулер платформи все одно підбере слабку ланку.
> **Операційне правило:** якщо людина може інспектувати фронтенд і відновити авторизаційні матеріали, ці матеріали не захищені.
Внутрішній контроль, який часто упускають з уваги, - це білий список IP, тому що увага зазвичай зосереджена на ключі, тоді як шлях викликача ігнорується. Тримайте цю політику привʼязаною до бекенда та шару проксі, а не до клієнтського застосунку, і перегляньте [глосарійну примітку про IP-whitelisting](https://sotaproxy.com/en/glossary/ip-whitelisting), якщо ви посилюєте доступ для багатосередовищних розгортань.
## Квоти, ціноутворення та аналітична надбудова
Застаріле ціноутворення Bing корисне зараз лише як довідка для бюджетування, але воно все ще показує, як Microsoft очікував, що будуть думати важкі користувачі. Безкоштовний тір **F1** давав **1 000 транзакцій на місяць**, а старіші платні тіри врешті-решт опинились на рівні **$25/1 000** для **S1**, **$15/1 000** для **S2** і **$6/1 000** для **S3** після підвищення цін 2023 року, згідно з історичними ціновими примітками, вже процитованими в міграційних вказівках. Якщо ви шукаєте заміну SERP API, ці цифри є вашою старою точкою прив'язки, а не вашим поточним рахунком.
### Що насправді надавала аналітична надбудоваДодаток Microsoft Bing Statistics надавав дані про обсяг викликів, найпопулярніші пошукові запити, географічний розподіл, підсумки кодів відповідей та розподіл за ринками. Панель оновлювалася кожні 24 години і зберігала дані до 13 місяців, що давало командам достатнє вікно для аналізу трендів, перевірки сезонності та порівнянь місяць до місяця додаток Bing Statistics. Це саме та частина, яка була потрібна більшості операторів, а не лише чисті дані відповідей.
Ось практична таблиця для бюджетування та операцій.
| Рівень | Ліміт / Ціна | Примітки |
|---|---|---|
| F1 | 1 000 транзакцій на місяць | Безкоштовний рівень, корисний лише для легкого тестування |
| S1 | $25 за 1 000 | Історична довідка платного рівня |
| S2 | $15 за 1 000 | Історична довідка платного рівня |
| S3 | $6 за 1 000 | Історична довідка платного рівня |
| Додаток Statistics | Оновлення кожні 24 години, зберігання до 13 місяців | Використовується для аналізу трендів та перегляду кодів відповідей |
Як команди мають використовувати це вікно
Плануйте свій місячний бюджет викликів виходячи з пікового трафіку, а не середнього. Робочі навантаження верифікації на основі пошуку зростають під час запуску кампаній, виходу на нові ринки та оновлення креативів. Якщо ви переходите на сторонній SERP API, діє та сама логіка, бо дороговартісною помилкою є не окремий виклик, а тиха недооцінка, коли один ринок починає збоїти, і ніхто цього не помічає.
Встановіть сповіщення, коли денний обсяг викликів досягає 70 відсотків вашої квоти. Цей поріг дає вам час уповільнити трафік, посилити ротацію або перенести пакет на дешевший endpoint, перш ніж pipeline зупиниться. 13-місячне вікно також дозволяє побачити, чи є сплеск сезонним явищем, чи це просто один надто активний акаунт, що повторно надсилає той самий набір запитів.
Усунення поширених помилок Bing API
Помилки, які мають значення, зазвичай очевидні, коли ви зіставляєте їх з причиною. HTTP 410 Gone означає, що endpoint було виведено з експлуатації, тому виправлення - це міграція, а не повторні спроби. Якщо ви досі звертаєтесь до старого сервісу, проблема архітектурна, а не тимчасова.
Відповідність помилки до виправлення
- HTTP 401: Заголовок
Ocp-Apim-Subscription-Keyвідсутній, неправильно сформований або прив'язаний до неправильного ресурсу. Перевірте backend-секрет та ресурс, з якого ви його скопіювали. - HTTP 404 на довгих URL: Ваш рядок запиту перевищив історичний ліміт у 2 048 символів, або не було дотримано рекомендації Microsoft щодо збереження параметрів у межах 1 500 символів. Скоротіть, нормалізуйте та перевірте перед відправкою.
- HTTP 429: Ви досягли лімітів швидкості. Відступіть з випадковою затримкою, зменште паралелізм і припиніть атакувати той самий код ринку.
- 5xx помилки: Невідповідність endpoint з регіональною прив'язкою або нестабільність на боці провайдера. Переключіть регіон endpoint перш ніж припускати, що ключ зламано.
Якщо ваші результати пошуку порожні або непослідовні в різних країнах, зазвичай першою річчю для перевірки є шар проксі. Геотаргетинг, швидкість ротації та прилипання сесії впливають на те, що показує вам Bing, частіше ніж заголовок автентифікації. Правильна діагностична звичка - порівняти той самий запит через той самий ринок з тією самою політикою проксі, а потім виділити розбіжність.
Для практичного нагадування про те, як нестабільність провайдера проявляється в автоматизації, корисно прочитати суміжний посібник з кодів відповіді HTTP 503. Тримайте проксі та шар API окремо в логах, інакше ви витратите години, звинувачуючи не той компонент.
Якщо вам потрібна проксі-інфраструктура, яка добре працює під час верифікації реклами, роботи з кількома акаунтами та моніторингу на основі пошуку, Sota Proxy надає резидентне, мобільне, ISP та датацентрове покриття, створене для такого типу трафіку. Відвідайте Sota Proxy, якщо вам потрібен шар проксі, який підходить для скрейпінгу Bing, геотаргетованих кампаній та робочих процесів з великою кількістю акаунтів без перетворення вашого backend на гру у вгадування.
Схожі статті
7 кращих провайдерів проксі для арбітражу та скрейпінгу
Порівняння 7 кращих провайдерів проксі за типами IP, таргетингом, ротацією, аптаймом, ціновими сигналами та придатністю для скрейпінгу, рекламних акаунтів, фармінгу та арбітражу.
10 найкращих проксі-сервісів для реклами, скрейпінгу та автоматизації
Порівняйте найкращі проксі-сервіси для перевірки реклами, скрейпінгу, операцій з обліковими записами та гео-таргетингу за типом IP, ціною, аптаймом та можливостями керування.
10 альтернатив Smartproxy для технічних команд
Порівняйте 10 альтернатив Smartproxy за типом проксі, якістю IP, таргетингом, ротацією, швидкістю, ціноутворенням та сценаріями використання для технічних команд.
10 альтернатив IPRoyal для серйозних проксі-навантажень
Порівняйте 10 альтернатив IPRoyal для скрейпінгу, верифікації реклами, фармінгу акаунтів, антидетект-браузерів, гео-кампаній, ціноутворення, ротації та підтримки.
10 альтернатив Oxylabs для скрейпінгу та рекламних операцій
Порівняйте 10 альтернатив Oxylabs за типом проксі, географічним охопленням, часом безвідмовної роботи, ротацією, ціноутворенням та сценаріями використання для скрейпінгу, перевірки реклами та фармінгу акаунтів.
Найкращі альтернативи Brightdata для команд з проксі у 2026 році
Ознайомтеся з найкращими альтернативами brightdata для скрейпінгу, верифікації реклами та геотаргетованих кампаній у 2026 році, а також порадами щодо міграції.