The viewport meta tag on 27 homepages: 26 set width=device-width, two still block zoom
The viewport meta tag is on all 27 homepages we crawled on 2026-08-24, and 12 distinct content strings cover the whole panel. Twenty-six declare width=device-width, three stop there, and two still ship maximum-scale=1 — a value iOS has ignored by default since iOS 10.
FIELD TEST · 2026-08-24 · 27 homepages · single crawl · head tags only
Sample and method: the same 30-site panel in use since 2026-08-15, each homepage fetched once on 2026-08-24 with a browser user agent. We read the <head> of the delivered HTML and recorded the raw content string of every <meta name="viewport">. No rendering, no second request.
Every one of the 27 homepages we could read carries a viewport meta tag, and 12 distinct content strings cover all of them. Twenty-six declare width=device-width. Two still ship maximum-scale=1, a value iOS has ignored by default since iOS 10, and one of those two also sets user-scalable=0.
How we measured it
One HTTP request per site, no rendering, no retries. Inclusion was fixed before the run: status 200, body at least 10,000 bytes, body containing <body. Three of the 30 failed — stackoverflow.com and medium.com returned 403, www.reddit.com returned an 8,393-byte shell — leaving 27, the same three exclusions as previous batches.
We parsed the served HTML only. A tag injected by a script after load would not appear in our count, and none of these numbers say anything about how the page actually renders on a phone. We measured a declaration, not a layout.
Every homepage ships a viewport meta tag, and 12 strings cover all 27
There is no spread here worth arguing about: 27 of 27 declare one, and no site declared two. Thirteen of the 27 use the exact same string, width=device-width, initial-scale=1, which is also the string Google's own developer pages serve.
| content string | Sites |
|---|---|
width=device-width, initial-scale=1 | 13 |
width=device-width | 3 |
width=device-width, initial-scale=1.0 | 2 |
width=device-width,initial-scale=1 (no space) | 1 |
with viewport-fit=cover added | 3 |
with maximum-scale or user-scalable | 2 |
with shrink-to-fit=no | 1 |
with interactive-widget=resizes-content | 1 |
no width at all | 1 |
The odd one out is www.wikipedia.org, whose portal page declares initial-scale=1,user-scalable=yes and never mentions width. That is the only site in the panel where the layout viewport width is left to the browser's default, which on a narrow screen is typically 980 CSS pixels rather than the device width.
Two homepages still try to switch pinch-zoom off
vercel.com serves width=device-width, initial-scale=1, maximum-scale=1. substack.com goes further with maximum-scale=1, user-scalable=0, viewport-fit=cover. Both are attempts to stop a reader zooming, and on current iOS neither works.
MDN's viewport reference, read on 2026-08-24, says the same thing under three separate keywords: for maximum-scale, minimum-scale and user-scalable alike, "Browser settings can ignore this rule, and iOS10+ ignores it by default." The same page carries a warning: "Disabling zooming capabilities by setting user-scalable to a value of no prevents people experiencing low vision conditions from being able to read and understand page content. Additionally, WCAG requires a minimum of 2× scaling; however, the best practice is to enable a 5× zoom."
A zoom-blocking viewport is not a setting any more. It is a record of what someone once wanted.
Three sites stop at width=device-width
github.com, www.framer.com and www.netlify.com declare the width and nothing else. This is a smaller decision than it looks. initial-scale sets the zoom level at first paint; without it, a browser that has already been told the layout width has little reason to scale anything, so the practical result on a modern phone is usually the same as initial-scale=1.
We did not test this. Confirming it would need real devices and screenshots, and this run was a single HTML fetch per site.
The rare keywords, and one that is no longer documented
Four sites add viewport-fit=cover: stripe.com, linear.app, www.cloudflare.com and substack.com. It is the keyword that lets a page paint into the area around a notch. linear.app is alone in also declaring height=device-height, and www.canva.com is alone in declaring interactive-widget=resizes-content, which tells the browser to resize the layout when a virtual keyboard opens instead of only resizing the visual viewport.
www.theverge.com ships shrink-to-fit=no. MDN's current viewport reference does not document that keyword at all — we searched the page on 2026-08-24 and the only occurrence of "shrink" is in the prose describing how narrow-screen browsers shrink a virtual viewport down. It is a leftover from an old iOS quirk, and it costs nothing to leave in, which is presumably why it is still there.
What this means for you
Google uses the mobile version of a page for indexing and ranking, so the tag that decides what "mobile version" means is worth thirty seconds of attention. Google's mobile-first indexing guidance, read on 2026-08-24, states it directly: "Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking."
- Ship
width=device-width, initial-scale=1and stop there — it is what 13 of 27 already do. - Add
viewport-fit=coveronly if you are painting into the notch area on purpose. - Don't set
maximum-scale=1oruser-scalable=no. Current iOS overrides it, and WCAG asks for at least 2× zoom. - Don't omit
width. It is the one part of the string that changes the layout viewport.
If you want to see what a crawler receives from your own <head> before you start editing it, check whether AI crawlers can read your page first — a viewport declaration is irrelevant on a page nothing can fetch.
Common questions
How did you measure this?
One request per homepage on 2026-08-24, browser user agent, no JavaScript execution. We recorded the content attribute of every <meta name="viewport"> in the delivered HTML and compared the strings verbatim, including whitespace.
Does the viewport meta tag affect SEO directly?
Not as a ranking input we can point to in any documentation. It matters because indexing happens on the mobile rendering, and a page that lays out at 980px on a phone is a worse mobile page than the same page at device width. That is an indirect route, and we would rather say so than dress it up.
Is user-scalable=no ever acceptable?
For a map or a drawing canvas that implements its own pinch gesture, there is a real argument. For a page of text there is not, and the accessibility cost is documented while the benefit is not.
Why did three homepages not appear?
Two returned 403 to our user agent and one returned an 8,393-byte shell with no content. The inclusion rule was written before the crawl, and the same three sites have been excluded in every batch on this panel. See what AI crawlers actually see on your site for what a 200 does and does not prove, and the html lang attribute across the same panel for the other head declaration we counted this way.
