Bingbot splits traffic between two subsystems. Only one of them executes JavaScript.

I expected one Bingbot.

I got two.

In the first eight days of JS SEO Lab data, bingbot made 126 requests to the Next.js test bed at next.jsseo.dev. 110 of those requests came from one user-agent string. 16 came from a different one. The two populations had different behaviour, hit different paths in different patterns, and — most importantly — only one of them executed JavaScript.

Most bot trackers, including the one I built before I noticed this, classify both as the same bingbot class. The split is structurally invisible from the classifier alone. You have to look at the raw UA string to see it.

On this domain, in this window, desktop Bingbot never ran JavaScript. Smartphone Bingbot did.

That phrasing matters. I am not saying Bing’s desktop crawler can’t render JavaScript. I am saying that in 110 observed requests, it didn’t.

The Data

The test bed is next.jsseo.dev, a 55-cell matrix built to measure which JavaScript content patterns survive in bot HTTP responses. Every request is logged into track.jsseo.dev through three layers: Next.js middleware for dynamic routes, a Cloudflare GraphQL Analytics ingester for static routes, and a JS-execution beacon that records whether a bot’s renderer actually ran JavaScript on the page.

For the window 2026-05-18 through 2026-05-26, the tracker recorded 126 bingbot hits across 56 distinct source IPs. Every single IP resolved through reverse DNS to msnbot-*.search.msn.com, every one mapped to ASN 8075 (Microsoft Azure US). One infrastructure pool, by every external indicator.

But the UA strings split:

Both strings end with bingbot/2.0 and link back to Microsoft’s bot documentation. Most regex-based bot classifiers, including the one in this project, match both with a single rule like /bingbot/i and assign them the same class. The split only shows up when you GROUP BY user_agent and look.

That split is the entire finding.

Two Bingbots, Two Behaviours

Desktop and smartphone bingbot behave nothing alike in our data.

Desktop bingbot: continuous, long-tail crawling. The same source IP returns over multiple days to the same one or two URLs. One IP made four hits on /ssr/clean/homepage spread across six days (May 20 to May 26). Another returned across five days. The pattern looks like a classical index-maintenance crawler doing low-frequency revisits.

Smartphone bingbot: single-shot burst. Each source IP is used once. It fetches between one and four URLs inside a one-to-two-second window. It never comes back from that IP. Five distinct sessions over eight days, each with the same shape.

If a classifier merges these two into one bingbot bucket, the aggregate looks like the union of these patterns and tells you neither story cleanly.

Only Smartphone Bingbot Ran JavaScript

This is the load-bearing observation.

The Layer 3 JS-execution beacon fires when a bot’s renderer actually executes a small inline script or a React-mounted client component on the page. Beacon hits land in a separate js_executions table. Pre-registered hypothesis H3 says batch AI crawlers don’t execute JavaScript. The same beacon logic applies to traditional search crawlers.

In the window:

Zero. In 110 observed desktop hits, the beacon never fired. Across the same period, smartphone bingbot fired the beacon in 7 of 16 hits, or 44% of the time.

Pre-empting the obvious counter-question: most of the desktop URLs were SSR cells with content already in the initial HTML. A non-rendering crawler doesn’t need to execute JavaScript to harvest text from those pages. So the “zero JS execution” observation could mean either “desktop bingbot never renders” or “desktop bingbot never needed to render in the URLs it picked.” We can’t distinguish those two on this sample alone.

What we can say is narrower and useful:

In our data, desktop bingbot consistently delivered behaviour indistinguishable from a no-JS batch crawler, while smartphone bingbot consistently delivered behaviour indistinguishable from a full-pipeline renderer.

The 7 beacon firings included both delivery mechanisms our tracker uses (legacy inline script and a newer React-mounted client component). Smartphone Bingbot, when it shows up on a URL, runs the page like a real Chromium-class headless browser. Desktop Bingbot, when it shows up, looks like the textbook description of a no-JS crawler that just slurps SSR HTML.

The Smartphone Sessions Map Cleanly To URL Inspection — In Our Sample

Here is where the framing gets careful.

I cross-referenced the timestamps and URLs of the 6 smartphone bingbot sessions in the tracker against my own Bing URL Inspection history in Bing Webmaster Tools.

Five out of six smartphone sessions had a one-second lag from a manual URL Inspection live test. The sixth session — May 19 — predates a Layer 3 beacon fix, and I am excluding it as an early-deploy artifact. The 18-05 /rsc/homepage inspection produced no tracker record at all; that URL is a legacy v0.3 path that 404s on the current deployment, so Bing likely did not trigger a live test.

What the alignment looks like, then, is striking: every smartphone bingbot session in clean tracker data corresponded one-to-one to a URL Inspection live test I had clicked seconds earlier in Bing Webmaster Tools.

That is the temptation: declare that “Bing uses smartphone bingbot for URL Inspection live tests, desktop bingbot for organic indexing, full stop.” That phrasing would make a much better headline.

It would also be a generalization from five sessions, in one tool, on one cold-start domain, by one operator.

So I am holding the claim to its narrow form:

In our data, in this window, smartphone bingbot hits correlated one-to-one with my own URL Inspection live tests.

The correlation is striking. Five sessions is a small sample. Both statements are true.

How This Differs From Google

Google distinguishes URL Inspection from organic crawl at the user-agent level. The UA strings are different:

• Organic Googlebot: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
• GSC URL Inspection: includes Google-InspectionTool/1.0

A classifier that splits these into separate classes correctly attributes “Search Console activity” versus “production indexing crawl.” Tools like Cloudflare’s bot dashboard, paid log analyzers, and open-source crawler classifiers handle this distinction out of the box.

Bing does not provide that level of UA separation. The token bingbot/2.0 appears in both desktop and smartphone strings. The distinction is buried inside the device-family fragment of the User-Agent header, not in the bot identifier itself.

A tool that treats bingbot as one class — which most do — silently merges two operationally different subsystems. Anyone reporting “Bingbot crawled my site 126 times this week” without breaking that down by desktop versus smartphone has lost the most useful signal in the data: that one of those subsystems renders JavaScript and the other one almost certainly doesn’t.

Why Site Owners Should Care

The practical advice is short and boring, the way useful crawler advice usually is.

First, when you grep logs for bingbot, also group by the full User-Agent header. If your distribution looks roughly like ours — most of the volume in the desktop string, a much smaller share in the smartphone Nexus 5X string — you may be looking at two different subsystems with different goals.

Second, when you assess whether Bing can see content that depends on JavaScript execution, weigh smartphone bingbot hits much more heavily than desktop bingbot hits. In our data, only the smartphone subsystem ran JS at all. If your site has client-side-rendered patterns and you want Bing to index that content, the operational question is whether smartphone bingbot reached it, not whether bingbot generally did.

Third, treat unusual bursts of smartphone bingbot activity as candidate URL Inspection live tests, especially if the URL was recently touched in Bing Webmaster Tools or recently shared by a user on Bing. The correlation in our data was tight enough to be diagnostic.

A crawler policy is not real until traffic confirms it. A crawl-stats summary is not useful until you split the populations the operator actually wants to count.

What Would Falsify This

This is a single-domain, eight-day, low-volume finding. Several things would weaken it.

Desktop bingbot may execute JavaScript on URLs that demand it. Most of the desktop sessions in our window landed on SSR cells, where there was nothing JS-dependent to render. A test on a deliberately client-only cell, in a later window, would tell us whether the zero-execution count is a property of the subsystem or a property of the URL mix.

Smartphone bingbot may show up on this domain without a triggering URL Inspection. If it does, the one-to-one correlation we observed in N=5 collapses, and “smartphone = inspection” becomes obviously wrong. We already saw one excluded session that hinted at organic mobile-first activity, so this falsifier may show up sooner rather than later.

Someone reading this may have larger logs that show desktop bingbot firing JS-execution side-channels on their site. I want to see that data. Specifically: hits to a script-injected endpoint, or any side-effect that requires JS to evaluate, paired with the desktop bingbot UA string — not the smartphone one. If you have it, send it. Not a screenshot of documentation. Actual path-level logs.

Microsoft may publish or clarify the relationship between desktop and smartphone Bingbot, the role of each in live URL Inspection, and the role of each in mobile-first indexing. If they do, this entire post may collapse into “yes, that is documented.” That outcome is fine; it just means SEO documentation about Bing infrastructure has improved.

What I Am Holding Back

I am not claiming:

• Bing uses smartphone bingbot exclusively for URL Inspection.
• Desktop bingbot is incapable of executing JavaScript.
• Bing’s mobile-first indexing pipeline is the same as its URL Inspection pipeline.
• All 16 smartphone hits in our data were URL Inspection. (One was excluded as artifact; one Inspection produced no record at all.)

Those would all be too strong for one domain and 126 rows.

What I am claiming:

• Bingbot fetched our test bed 126 times during the window.
• 110 of those hits came from the desktop UA string and did not execute JavaScript.
• 16 came from the smartphone UA string and executed JavaScript in 7 cases (44%).
• In a clean subset of 5 smartphone sessions, every one corresponded to a manually clicked URL Inspection live test in Bing Webmaster Tools, with about one second of lag.
• A regex classifier matching on bingbot alone collapses two operationally different populations into a single class.

That is enough to justify a better question:

When your bot tracker reports “bingbot,” which subsystem actually produced the traffic, and which capability are you allowed to infer from it?

Method Notes

The classifier matches bingbot|adidxbot in the User-Agent header and assigns the bingbot class. To recover the desktop/smartphone split shown above, the SQL grouped by the full user_agent column, not by user_agent_class. The relevant queries are visible in the public tracker source under tracker-server/src/lib/queries.js.

Reverse DNS verification for bingbot runs through the same worker used for Googlebot and Applebot: reverse lookup, suffix match against search.msn.com, forward confirmation against the originating IP. Every one of the 56 distinct IPs in the bingbot population passed that check. None of the hits in this finding are spoofs.

The Layer 3 beacon was deployed in two delivery variants during the observation window. The legacy variant is an inline <script> at the end of <body> that fires new Image().src on initial page parse. The newer variant is a React client component mounted from the root layout that fires fetch() after hydration. Smartphone bingbot fired both, in the cases where it fired. Desktop bingbot fired neither.

The robots file on next.jsseo.dev is permissive:

User-agent: *
Allow: /

So nothing in the desktop bingbot zero-execution count is explained by access denial.

What I Will Watch Next

Four things are now on the board.

First, whether desktop bingbot ever fires a beacon. If after another month of observation it remains at zero, the “desktop is no-JS by default” framing strengthens considerably. If it fires even once on a CSR cell, the framing weakens.

Second, whether smartphone bingbot ever appears on a URL I have never clicked in Bing URL Inspection. That would mean the smartphone subsystem also handles organic mobile-first indexing, and the URL-Inspection correlation in our small sample is partly coincidence.

Third, whether the classifier should split bingbot into bingbot-desktop and bingbot-mobile as separate classes. The case is strong; the open question is whether to do this only for Bingbot or as part of a broader mobile/desktop split across crawlers (Googlebot has the same desktop-vs-smartphone distinction in its UAs).

Fourth, whether Bing’s documented user-agent list will ever match the operational distinction. The current Bing docs describe bingbot as a single agent. The data describes two.

Until then, the lesson is simple:

If your bot tracker says “bingbot,” ask which one.

Data availability: JS SEO Lab publishes methodology, tracker code, and findings notes in the public repository at github.com/Qbeczek1/jsseo-dev. The live aggregate dashboard is at /dashboard/.

Bias disclosure: I run JS SEO Lab as an independent technical SEO research project. I also do paid technical SEO and AI visibility audits through FratreSEO. No framework vendor, crawler vendor, search engine, or AI company funds this work.