One Year Without the Official Bing Search API: Your Real Options in 2026

One year ago this month, Microsoft quietly retired every official Bing Search API. No dramatic shutdown screen — the endpoints just started returning errors, and thousands of pipelines around the world had to find answers fast.

I work on a SERP data API (TalorData), so I watched this from an unusual seat: our inbox was the place where the breakage showed up. This post is the summary I wish someone had published back then — what actually broke, which migration paths work, and which ones don't. It's written from that experience, so yes, there's a bias toward structured APIs at the end. I'll try to keep the trade-offs honest.

TL;DR

Path	Verdict
Do nothing	Your pipeline is already broken (or silently degraded)
Scrape Bing yourself	Works for a demo, collapses at scale
Drop Bing entirely	Legitimate for some products, expensive for others
Structured SERP API	The pragmatic default for most teams

What exactly happened

Microsoft announced the retirement of the Bing Search APIs (v7) in mid-2025 and pulled the plug in August 2025. Everything under api.bing.microsoft.com went away: Web Search, News, Image Search, all of it.

Two things made this messier than a normal deprecation:

1. No official replacement. Google's Custom Search JSON API exists for Google, but Microsoft left no successor for Bing. If your product needed Bing specifically — not "a search engine" — you were on your own.
2. Silent dependencies. A lot of teams didn't have "we depend on Bing Search API v7" written anywhere. It was one HTTP call buried in a service. Some only noticed weeks later, when reports looked odd or agents started citing stale results.

Who got hit hardest

From what we saw, three archetypes:

• Rank-tracking tools — Bing positions vanished from dashboards overnight.
• AI agents and RAG pipelines — anything using Bing as its "fresh information" tool call lost its live-data source. Ironically, many teams didn't build these until after the retirement, and inherited the problem without knowing it ever existed.
• Price/news monitors — anything polling Bing News or shopping results on a schedule.

If you're reading this in 2026 and your pipeline still shows "Bing results," it's worth asking where those results come from now. There is no official feed anymore. Someone is maintaining that data by hand — maybe you, maybe a vendor.

Path 1: Scrape Bing yourself

This is the first idea everyone has, so let me save you the week: it works great until it doesn't.

Here's the naive version, which runs fine on your laptop:

import requests
from bs4 import BeautifulSoup

resp = requests.get(
    "https://www.bing.com/search",
    params={"q": "best serp api", "count": 10},
    headers={"User-Agent": "Mozilla/5.0"},
)
soup = BeautifulSoup(resp.text, "html.parser")
results = [
    {"title": li.h2.a.text, "url": li.h2.a["href"]}
    for li in soup.select("li.b_algo")[:10]
]

Run this five times and you're a hero. Run it 5,000 times and you'll discover:

• Fingerprinting. Bing is aggressive about bot detection. Plain requests gets CAPTCHA walls or empty pages quickly; even rotating user agents stops working fast.
• Markup drift. li.b_algo is not an API contract. Selectors change without notice, and your parser fails silently — you get fewer results, not errors.
• Hidden cost. Between proxy rotation, CAPTCHA solving, and maintenance, DIY scraping at volume typically costs more than paying for structured results — and that's before counting the engineer-hours.

Verdict: fine for a one-off research task. Not a foundation for a product.

Path 2: Just drop Bing

Honest option, and sometimes the right one. Ask yourself why you needed Bing:

• If it was "any search engine will do" — switch to whatever you already have and move on. Bing's global share is small.
• If Bing matters for your users — SEO agencies tracking Bing because clients rank there, regional markets where Bing's share is meaningful, enterprise contexts (Windows defaults, Edge) — then dropping it means losing a feature someone is paying you for.

Only you know which side you're on. But make the decision consciously; don't let a dead API make it for you.

Path 3: Structured SERP APIs

This is the path most production systems landed on: a provider maintains the scraping infrastructure (proxies, CAPTCHA handling, parsers) and returns clean JSON per query.

The nice surprise: migration is usually smaller than expected, because the concept maps almost 1:1 from the old Bing API. Here's the shape of it.

Before (Bing Search API v7):

import requests

resp = requests.get(
    "https://api.bing.microsoft.com/v7.0/search",
    params={"q": "best serp api", "count": 10},
    headers={"Ocp-Apim-Subscription-Key": KEY},
)
for item in resp.json()["webPages"]["value"]:
    print(item["name"], item["url"])

After (generic modern SERP API — same mental model):

import requests

resp = requests.post(
    "https://api.your-serp-provider.com/v1/search",  # [替换为你们文档中的真实端点]
    json={"query": "best serp api", "engine": "bing", "count": 10},
    headers={"Authorization": f"Bearer {API_KEY}"},
)
for item in resp.json()["organic_results"]:          # [核对响应字段名]
    print(item["title"], item["url"])

Field mapping cheat sheet:

Bing v7	Typical modern SERP API
webPages.value[].name	organic_results[].title
webPages.value[].url	organic_results[].url
webPages.value[].snippet	organic_results[].description
webPages.totalEstimatedMatches	total_results (or similar)

A bonus you didn't have before: once you're on a multi-engine provider, adding Google/Yandex/DuckDuckGo coverage is often just changing one parameter — useful if your product ever needs cross-engine comparison.

What to check when picking a provider

• Billing model. Pay-per-success (you're only charged for delivered results) vs monthly quotas that expire unused. For spiky workloads, pay-per-success is usually kinder.
• Latency profile. If results feed a live agent loop, sub-second responses matter; batch rank-checking can tolerate queues. These are different products wearing similar names — check the numbers, not the marketing. (For reference: we run P90 under 0.8s, which is the tier you want for agent loops.)
• Engine coverage beyond Google. If you came here because of Bing, pick a provider that treats Bing as a first-class engine, not a checkbox.
• Structured extras. People Also Ask, knowledge panels, local packs — cheap to include now, painful to retrofit.

When you don't need any of this

Full honesty section, because every article like this is secretly an ad for something:

• You need one page of one site? Use requests + a parser, or a headless browser. Done in an afternoon.
• You need cached/archival search data for research? Public datasets may beat any API.
• Your LLM just needs "some" fresh context occasionally and precision doesn't matter? A general-purpose search integration might be enough.

SERP infrastructure earns its cost at the point where correctness, freshness, and scale intersect. Below that line, it's overkill — and pretending otherwise is how vendors lose trust.

Wrapping up

The Bing API retirement was a quiet event with loud consequences: it turned "search results as an input" from something you could take for granted into something you have to source deliberately.

If you're evaluating providers right now — or checking what your current tool is actually doing behind the scenes — you can try ours at talordata.com. Free responses come with signup, no subscription attached; you only pay for successful results after that.

Either way: go look at what your pipeline calls for search results, and make sure the answer isn't a dead endpoint.

---

What did your team do after the retirement? I'm curious whether other folks saw the same patterns in the comments.