What breaks when you load 1,000 popular websites on a phone

1. A quarter of the popular web is closed to cloud browsers

213 sites answered with a bot wall: a 403, a "Just a moment…" challenge, a captcha or a "press and hold" check. 39 more sent the HTML but refused the stylesheets, scripts or fonts, so the page rendered unstyled. 35 showed something other than the site (parked domains, consent-only gates, region blocks, maintenance pages) and 42 never finished loading. That left 671 sites to check.

Which service served the bot walls, identified from the response headers:

If you build AI agents that browse from a data center, plan for this: about one popular site in four will refuse your agent, whatever it is trying to do. Blocking is the site owner's choice. For agents, that means using a site's API or feeds where one exists, or running the browser on the user's own connection.

2. Sideways scrolling is mostly solved, and what's left is the old classics

Of the 657 homepages with a mobile viewport tag, 21 are wider than the screen, so the page moves sideways when you swipe. 15 of them overflow by 32px or less, a wobble rather than a broken page. The causes, labelled by hand from the elements the check found and the screenshots:

How to fix the common ones. A Bootstrap .row has negative side margins that only a .container (or .container-fluid) parent cancels, so a row placed directly in the page sticks out by 12–15px. A carousel or horizontal menu needs overflow: hidden (or overflow-x: clip) on its own wrapper. And overflow-x: hidden on body alone doesn't fix overflow on phones: mobile Chrome still lets you pan to the hidden part. Put it on both html and body, or better, on a wrapper around the content.

3. 14 sites still have no mobile viewport tag

Without <meta name="viewport" content="width=device-width, initial-scale=1">, phones lay the page out 980px wide and shrink it to fit, so text shows at about 40% of its intended size. These sites still do that:

www.ncbi.nlm.nih.gov, www.nhc.noaa.gov, fast.com, www.dafont.com, m.tabor.ru, skyward.iscorp.com, www.rakuten-sec.co.jp, www.tjk.org, goal7.co, www.choiceadvantage.com, www.minhngoc.net.vn, www.orange.fr, cdn-f.adsmoloco.com, app.powerbi.com

They include the NIH's National Center for Biotechnology Information (home of PubMed), the National Hurricane Center, Netflix's fast.com speed test, Orange's French homepage and Microsoft Power BI's sign-in page.

4. React hydration fails on 10 big sites

React apps render HTML on the server, then the browser "hydrates" it into a live page. When the two renders disagree, React logs a minified error (#418, #421, #423 or #425), throws the server's work away and rebuilds the page in the browser. Visitors then wait longer for an interactive page, and on a phone that wait is noticeable. These sites failed hydration on both loads:

fortune.com, kakuyomu.jp, wise.com, www.aol.com, www.cnnbrasil.com.br, www.coursera.org, www.instacart.com, www.jio.com, www.newsweek.com, www.spotify.com

Seven of them (Spotify, Coursera, Wise, Instacart, Fortune, Newsweek and AOL) failed again on a third load set to New York time, so the browser's timezone isn't the cause. The usual causes: dates and times formatted differently on the server and in the browser, locale-dependent numbers, random IDs, and code that reads window or localStorage while rendering. My browser was in Germany with an English locale, the same as many real visitors. samsclub.com failed on two loads and then passed four times in a row, so it isn't listed.

5. Chrome is removing the Topics API, and ad code on 9 sites still calls it

Google is retiring its Privacy Sandbox Topics API: it was deprecated in Chrome 144, and Chrome is removing it in stages (intent to deprecate and remove). In Chromium 156, which I tested with, it's already gone, and calling it throws. On these sites, ad code calls document.browsingTopics() without checking that it exists, and the promise rejection goes uncaught:

az24.vn, deadline.com, dnd5e.wikidot.com, variety.com, www.billboard.com, www.hollywoodreporter.com, www.ojogodobicho.com, www.vlr.gg, xsmn.mobi

I traced each error's stack to the script that made the call: BlogHer Ads on Variety, Billboard, Deadline and The Hollywood Reporter; NitroPay on dnd5e.wikidot.com and vlr.gg; AnyMind on az24.vn and xsmn.mobi; and The Moneytizer on ojogodobicho.com. The site owners didn't write this code, and they'll get the errors anyway. The error won't hurt readers much, but it fills error monitoring with noise and shows the ad code isn't checking for the API. As the rollout reaches more Chrome users, they'll get it too. The fix is a feature check ('browsingTopics' in document) plus a .catch(), or an update to the ad library.

6. Smaller findings

• Small text. On 19 sites (2.8%), more than 40% of the text is under 12px, the threshold Lighthouse uses. This counts every character on the page, footers and fine print included. The shopping grids of m.shein.com and trendyol.com are clear cases. Others: imgsrc.ru (100%), thenkiri.com (81%), m.shein.com (79%), m.klikbca.com (79%), www.primevideo.com (78%), www.windy.com (71%), my.medu.ir (68%), czbooks.net (66%).
• Broken images. 8 sites showed a visible image that failed to load on both loads: www.cdc.gov, www.usps.com, skyward.iscorp.com, www.indianrail.gov.in, tiktokio.com, all.accor.com, www.capitalone.com, client.schwab.com. Tracking pixels and hidden images don't count.
• Everything else. 83 sites threw at least one uncaught JavaScript error on the first load. Besides hydration and Topics, the most common were scripts loading before jQuery ($ is not defined) and ad and recommendation widgets failing.
• Clean pages. 535 of 671 sites (79.7%) passed every check.

Every site

Sorted by Tranco rank, showing the sites with a finding first; use the buttons for the rest. "Blocked" means a bot wall or something other than the site; "assets withheld" means the page loaded but its CSS, scripts or fonts were refused.

Method and limits

• Sites. Domains from the Tranco top list (October 19, 2026) that also have an origin in the Chrome UX Report's top 10,000 (crux-top-lists), so every site is both popular and visited by real Chrome users. One origin per brand (google.de and google.com count once); adult and malware domains removed using Cloudflare's 1.1.1.3 family resolver; file and CDN hosts removed. The first 1,000 in Tranco order.
• Browser. Shotlane's /v1/check with devices=iphone: Chromium 156 in mobile mode at 393×852, English locale, run from a data center in Germany on October 20, 2026. Cookie banners are hidden before measuring, as the check does by default. Only homepages.
• Two loads. Every site with a finding was loaded a second time, and only findings seen both times are reported. 2 small text, 2 broken images, 4 hydration, 1 topics finding(s) didn't hold up and aren't counted. The overall JavaScript error rate is from the first load.
• Exclusions checked by hand. I read every short or suspicious page title for block pages in any language, looked at the screenshot of every page without a title (10 of 11 were walls or blank) and every page wider than the screen. That's how I found Zillow's "press and hold" overlay, which sits under a normal title, and three sites that rendered without their CSS. Overlay walls like Zillow's can still hide under a normal title elsewhere.
• Sideways scrolling counts when the page is wider than the screen and a person could pan to the extra width. Content clipped by overflow: hidden on html and body, or on a wrapper, doesn't count.
• Vendors come from response headers and cookies (for example cf-ray, AkamaiGHost, x-datadome), fetched again from the same server. A site served by one CDN may block with another product.

Raw data: mobile-2026-10.json (CC BY 4.0: reuse it with a link back).