Since mobile-first indexing became the default for essentially all sites Google crawls, Googlebot Smartphone (the mobile user agent) is the primary crawler used to index content, and it accounts for the large majority of crawl activity on most sites. Googlebot Desktop still exists and still crawls, but it runs at a comparatively lower relative frequency, mainly to catch desktop-specific differences and confirm that the desktop experience isn’t broken or radically divergent from what mobile users see. Google has not published a fixed ratio between the two, and the split is not static: it adapts based on how a given site serves content, how it responds to each user agent, and its mobile-first indexing status. When a site sends conflicting directives to the two user agents (different robots.txt rules, different canonical tags, different noindex behavior), the practical effect is ambiguity that Google’s indexing pipeline has to resolve on its own, and it resolves it by trusting the mobile signal, since mobile is what’s primarily used for indexing.
Why the split isn’t a fixed ratio
Googlebot’s crawl scheduling is demand-driven, not quota-driven in a simple sense. Google determines how often to crawl a site (and with which user agent) based on a mix of perceived need: how often content changes, how important the site’s pages appear to be, and how well the server handles the crawl load without degrading (this is the essence of what Google calls crawl budget or crawl capacity, tied to concepts like crawl rate limit and crawl demand). Layered on top of that general scheduling logic is the mobile-first indexing reality: because indexing is based on the mobile version of a page, Googlebot Smartphone needs to visit far more often, and more comprehensively, than Googlebot Desktop. Desktop crawling still happens because Google wants visibility into cases where desktop pages diverge from mobile in ways that matter (different content, different structured data, different linking), and because not every property is fully mobile-first-verified in the same way. But there is no published fixed split such as “90 percent mobile, 10 percent desktop.” Any specific ratio you see quoted publicly is an inference from log-file analysis on individual sites, not a documented Google policy, and it will vary by site based on how each site’s mobile and desktop versions are structured and served.
It’s also worth being precise about what “Googlebot-Desktop” means today. It isn’t a legacy leftover being phased out. Google’s documentation on its common crawlers explicitly lists both the mobile (smartphone) and desktop user agent strings as active, current crawlers. Desktop crawling has a real purpose, it isn’t a deprecated artifact you can safely ignore in log analysis.
Why conflicting directives create real ambiguity
The core assumption behind mobile-first indexing is that the mobile version of a page is a faithful, complete representation of the content, and in the ideal case identical in substance to desktop. When directives diverge between user agents, that assumption breaks in a way Google’s systems weren’t designed to gracefully resolve, because it isn’t supposed to happen on a well-configured site.
Consider a few concrete conflict scenarios:
Different robots.txt treatment by user agent. Robots.txt directives are technically matched by user-agent token, so it’s possible to write rules that block Googlebot-Desktop from a path while allowing Googlebot-Smartphone (or vice versa). If you do this, you’re not creating a balanced dual-track crawl, you’re effectively choosing which version of the page exists for indexing purposes, since the mobile-crawlable version is what will end up representing the page. Blocking mobile while allowing desktop is particularly dangerous under mobile-first indexing, since it can result in the page effectively not being indexable at all, or being indexed based on cached/stale signals if Google struggles to reconcile the state.
Divergent canonical tags between mobile and desktop versions. If your desktop page canonicalizes to itself and your mobile version (on a separate m-dot domain or distinct mobile template) canonicalizes somewhere else, or the reverse, you’re giving Google contradictory instructions about which URL is authoritative. Since indexing decisions are made primarily from the mobile crawl, a canonical mismatch risks having Google settle on a canonical URL you didn’t intend, or in messier cases, treat the signals as unreliable and fall back to its own clustering heuristics rather than fully trusting either tag.
Noindex present on one version but not the other. If desktop carries a noindex meta tag (perhaps left over from an old template) while mobile doesn’t, or vice versa, the mobile-first crawl is what determines indexing eligibility in the common case. A desktop-only noindex that isn’t mirrored on mobile is likely to be ignored for indexing purposes, meaning content you intended to keep out of the index may still get indexed, because the version Google actually indexes from didn’t carry the exclusion signal. The inverse (mobile noindex, no desktop noindex) risks the opposite failure: content disappearing from the index even though the desktop version looks fine to anyone checking it manually.
Structured data or metadata present only on desktop. Rich results, hreflang annotations, and other structured signals that exist only in the desktop DOM are at serious risk of simply not being picked up, since the mobile crawl is the primary source Google uses to build its understanding of the page’s content and markup.
In all of these cases, the underlying mechanism is the same: Google is not running two independent indexing pipelines and averaging or arbitrating between them in a transparent, predictable way. It has one primary path (mobile) it depends on for indexing, and desktop crawling exists as a supplementary check. Directives that only exist on the desktop side are structurally at risk of being invisible to the process that actually decides how the page is indexed.
What to do about it
The practical fix is consistency, not cleverness. Every directive that affects indexing (robots.txt rules, canonical tags, noindex/index meta or header directives, hreflang, structured data) should resolve identically regardless of which Googlebot user agent is making the request. If you’re on a responsive design serving identical HTML to both user agents, this is largely automatic and low-risk. If you’re running separate mobile and desktop templates, dynamic serving, or a separate mobile subdomain, you need to actively audit for parity rather than assume it.
Concretely:
Verify robots.txt doesn’t contain user-agent-specific blocks that differ between Googlebot and Googlebot-Smartphone unless you have a very deliberate reason (and even then, treat it as high-risk).
Confirm canonical tags resolve to the same target URL whether fetched as mobile or desktop, especially if you maintain separate mobile URLs.
Check that noindex/index status is identical across both versions. A discrepancy here is one of the more common silent causes of unexpected indexing behavior on sites that migrated from separate mobile templates without a full audit.
Make sure structured data, hreflang, and any other markup you rely on for search features is present in the mobile version, not just desktop, since that’s the version being used to evaluate eligibility for most rich result types.
Use URL Inspection in Search Console to check how Google is actually rendering and reading the page, since that tool reflects the mobile-first crawl’s view in the current indexing paradigm for most sites.
None of this requires guessing at Google’s internal crawl-frequency math. The scheduling ratio between mobile and desktop crawling is an implementation detail Google manages dynamically and hasn’t published a fixed formula for. What is fully within your control, and what actually matters for outcomes, is making sure the two user agents never see materially different instructions in the first place.
