Reading Bing Webmaster Tools from your own panel means pulling clicks, impressions, click-through rate and average position per query, plus the daily site totals, through the Bing API and rendering them alongside your Google numbers. Two properties of that data have to be understood before it is quoted. Bing buckets query data weekly and offers no date range at all, and its average position is weighted by impressions and taken from the impression position rather than the click position. Neither is a bug, and both change what the numbers mean.
Bing is worth reading because it is a different index from Google's with different answers, and because of what reads from it. A page can rank in Bing and appear nowhere in Search Console, or the reverse, and neither observation says anything about the other. That alone makes Bing a second opinion on the same site. The larger reason is that Bing's index is what Copilot's search reads, so Bing coverage is an answer-engine question rather than only a market-share question.
That framing changes which numbers matter. If Bing is being read as a small second search engine, low click totals make it easy to ignore. If Bing is being read as the retrieval layer behind an assistant, impressions on a query matter even when clicks do not follow, because an assistant that cites a page rarely sends a click. This is the same measurement gap that makes AI citation share hard to see from a traffic report.
Bing query figures will not line up with Search Console figures day by day, and the reason is structural rather than a synchronisation fault. Bing buckets its query data weekly and its API exposes no date range parameter, so the whole history comes back on every call. Any narrower window is applied by the caller after the fact, against buckets that were never daily to begin with. Comparing a Bing week against a Search Console day and calling the difference a discrepancy is comparing two different units.
The practical consequence is that a combined report needs to say which engine each figure came from and over what grain. A single chart plotting Bing and Google clicks on the same daily axis is drawing a line through data that has no daily resolution on one side. Weekly totals compared to weekly totals is the honest comparison, and even then the two indexes cover different pages and answer different queries.
Search Console has no language dimension. On a site in more than one language you separate the data by page or by country, which means the URL structure you chose for translations decides what you can measure.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Bing's average position is weighted by impressions and taken from the impression position, which is a deliberate choice with a specific alternative. The other available number is the click position, and it is unusable as an average: it is zero for every query nobody clicked, so averaging it across a query set drags the mean towards zero exactly for the queries performing least well. A report built on click position would show its weakest queries as sitting at position zero, which reads as a triumph.
Weighting by impressions matters just as much as the choice of field. An unweighted mean lets a query with three impressions at position two pull the average down as hard as a query with three thousand impressions at position eleven, which produces a number that describes the tail rather than the site. Weighting by impressions makes the average describe where a typical impression happened, which is the question somebody asking about average position is actually asking.
| Property | Bing Webmaster Tools | Google Search Console |
|---|---|---|
| Query data grain | Weekly buckets, whole history per call | Daily rows, with a requested date range |
| Date range in the API | Not accepted; filtering happens after the fetch | Requested as part of the query |
| Average position source | Impression position, weighted by impressions | Reported per row for the range requested |
| What reads the index | Copilot's search draws on it | Google's own surfaces, including AI Overviews |
| Credential | A key pasted by the site owner | An authorised property connection |
| Missing connection | Answers configured: false rather than erroring | No property selected means no data at all |
A missing Bing connection should be reported as a fact about your own setup, never as a fact about the customer's site. An app with no Bing key stored has no Bing data, and writing "no Bing traffic" for it states something about a search engine when the truth is something about a wiring gap. Market4's read answers with configured set to false when no key is stored, and with a plain problem sentence when Bing itself refused, and neither of those is an error worth retrying.
The same discipline applies to whether a connection is verified. A verification value of null means not checked, which is not the same as false, and collapsing the two turns an absent measurement into an accusation. For IndexNow the value is permanently null on purpose, because IndexNow verifies through a key file on the site owner's own server that can be removed without telling anybody, so the only honest live answer is a fresh check of that file.
The Bing key is pasted by the site owner in the panel and never handed to a tool. No tool in the MCP server accepts a Bing or Yandex credential, and that is a deliberate boundary rather than a gap waiting to be filled: a key typed into an assistant conversation lives in that transcript indefinitely, and a transcript is not a secret store. The same rule covers every provider credential the product touches.
The last item is the piece people most often miss when they start reading Bing seriously. IndexNow tells Bing, Yandex, Seznam, Naver and Yep that a URL changed, and Google does not participate in it at all, so a site relying on IndexNow alone has told everybody except the engine most of its traffic comes from. Keeping the two discovery paths separate in your head is what makes the Bing numbers actionable rather than confusing, and the two mechanisms compare directly.
Because the two are different indexes reporting at different grains. Bing buckets query data weekly and accepts no date range, so the whole history comes back and any narrower window is applied afterwards. Search Console reports daily rows for a range you request. Beyond the grain, the two indexes hold different pages and serve different queries, so a page can rank in one and be absent from the other. The gap is structural and is not evidence of a bug in either.
Partly because the rankings differ and partly because the averages are built differently. Bing's figure is weighted by impressions and taken from the impression position, so it describes where a typical impression happened. The alternative field, the click position, is zero for every query that received no clicks, which would drag an average towards zero precisely for the queries doing least well. Knowing which field a number came from matters more than the number itself.
Yes. Without a stored Webmaster Tools key there is no Bing data, and a well-behaved report says so rather than reporting zero. Zero clicks and no connection look identical in a chart and mean opposite things: one is a claim about the site, the other a claim about your wiring. Check the connection state before drawing any conclusion about Bing visibility, and pass the setup problem sentence through to whoever can fix it.
It matters for the assistants whose search draws on Bing's index, which includes Copilot. A page that Bing has not indexed cannot be retrieved by anything reading that index, regardless of how it performs in Google. This makes Bing coverage an answer-engine concern rather than only a question of search market share, and it is a reason to check Bing indexing on pages written to be cited rather than clicked.
No. Paste it into the panel that stores credentials and nowhere else. A key typed into a conversation stays in that transcript for as long as the transcript exists, and transcripts are copied, exported and fed back into models. Tools that read Bing data should use the stored credential without ever accepting one as an argument, which is why no tool in this server takes a Bing or Yandex key and none is planned.
Reading what Yandex says about a site needs a Yandex Webmaster OAuth token, stored per app in the vault rather than in an environment variable, because a token answers only for the hosts it was issued for.
A report that arrives every Monday whether or not anything happened teaches its reader to ignore it. Three constraints fix that: alert only above a severity floor, only on kinds worth interrupting somebody for, and only when the finding is new.
