Pages fail for smartphone Chrome
In the reportPages fail for the smartphone crawler but return 200 on desktop
mobile_ua_status_mismatch · Issue
This appears when both smartphone observations fail in the same class while both desktop observations return usable 200 HTML. Check device-specific server, CDN or firewall handling and restore the intended smartphone response.
Severity: High. Fix it soon: the observed smartphone requests cannot obtain the page even though desktop requests can.
Why it matters
A device-specific error prevents people using that response from accessing the page. Search engines also recommend consistent mobile and desktop error handling; this browser comparison does not establish what their crawlers receive.
What to do
- Compare the four saved status and error observations. Retained redirect evidence is bounded and may not show the complete route.
- Check server, CDN, firewall and mobile routing rules for different treatment of the smartphone browser profile.
- Run another audit to obtain a sufficient comparison of the same page.
What we read
We compare smartphone Chrome with desktop Chrome using two observations of each request profile. The smartphone crawl response supplies the first observation; we then collect a desktop response and a confirmation for each profile. These are browser request profiles, not observations of Googlebot.
The audit freezes a sample before comparison. Its size is the smaller of the eligible page count and the square root of the admitted representative page count, rounded up and limited to 10–100. Selection prioritises an eligible homepage, unresolved rechecks including dismissed findings, then pages from different sections. This does not guarantee every section or template.
A blocked request, cancellation, exhausted comparison budget, incomplete required artifact or challenge leaves the comparison unknown. The content and directive checks require four usable 200 HTML responses. A confirmed smartphone-only status failure belongs to the separate status check and leaves the other three checks unknown.
Both desktop observations must be usable 200 HTML. Both smartphone observations must fail in the same class: 4xx, 5xx or redirect loop. Different smartphone failure classes, an unusable desktop response, a challenge or incomplete required status evidence leave the result unknown.
Example & evidence
Illustrative example — repeated status differences for one page, not a live audit.
Both desktop observations receive:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8Both smartphone observations receive:
HTTP/1.1 500 Internal Server ErrorThe smartphone failures share the 5xx class while desktop receives usable HTML, so the page is reported.
A possible correction: fix the smartphone route so both observations receive the intended 200 HTML response.
Confirm & check again
Check for yourself: Repeat requests for the page with smartphone Chrome and desktop Chrome and compare HTTP status, redirects and response bodies. Browser display alone does not show which response the audit retained.
Check again: Full audit — Run another audit after correcting the response. The finding closes only when sufficient retained evidence gives a clean result for the same requested page and native final-URL identity. An unread or unselected comparison does not establish a fix. Moving to another final URL, or serving the old final URL through another page, does not fix the original finding. Dismissal is separate from technical state and does not remove the page from recheck consideration.
Limits & sources
The reported sample N of M describes the frozen selection among admitted representative pages in this audit, not every page on the website. Selected pages with incomplete evidence remain in N. An unavailable sample has an explicit reason; it is not a zero-page success.
These requests do not establish what a search crawler received or how it indexed the page. Responses can differ by time, location or other request properties. Missing evidence never counts as a pass.
This check identifies a repeated profile difference, not its cause. A failure in only one smartphone observation or different failure classes cannot establish this finding. It does not test Googlebot identity or network access.
Confidence: Medium because the browser-profile failure repeats, but the comparison does not establish its cause or what a search crawler receives.
Sources
- Google, Mobile site and mobile-first indexing best practices — asks for the same error status on desktop and mobile, and warns that a page serving an error only on mobile can be missing from the index. Checked 25 September 2026.
- Google, Mobile-indexing-vLast-final-final.doc — says that after July 5, 2024 Google crawls and indexes sites only with Googlebot Smartphone, and that content not accessible with a mobile device is no longer indexable. Checked 25 September 2026.
Editorial review: 3 November 2026