Fix Viewport Zoom Disabled (user-scalable=no)
Your viewport meta tag disables zoom, usually with user-scalable=no or a low maximum-scale value, so users can't pinch-zoom to enlarge text. This fails WCAG 2.1 success criterion 1.4.4 (Resize Text) and hurts anyone with low vision. The fix is to drop the zoom-blocking parameters and keep the tag as width=device-width, initial-scale=1 so pinch-to-zoom works again.
What this means
Your page has a viewport meta tag, but it's configured to prevent zooming. The audit flags viewport_zoom_disabled when it finds one of these in the tag's content attribute:
user-scalable=no(oruser-scalable=0), which turns off pinch-to-zoom entirelymaximum-scaleset below 5, which caps zoom so low that enlarging text is effectively blocked (Lighthouse fails the page whenmaximum-scaleis under 5)minimum-scale=1paired with a lockedmaximum-scale, pinning the page at 100%
A problem tag typically looks like this:
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
This is different from a missing viewport tag. The tag is present and your responsive layout still works. The one problem is that you (or your theme or builder) told mobile browsers not to let people zoom in.
Historically this was added to stop iOS from zooming when a user tapped a form field, or to make a web app feel more native. Both reasons are outdated. Modern browsers stop the form-field zoom once inputs use a 16px font, and blocking zoom trades a minor cosmetic gain for a real accessibility barrier. It's flagged as a warning rather than a hard error because the page still functions, but for users who rely on zoom it's a genuine wall.
Why it matters
Disabling zoom is a direct accessibility failure. It breaks WCAG 2.1 success criterion 1.4.4 (Resize Text), which requires that text can be resized up to 200% without loss of content or function. People with low vision, presbyopia, or a situational impairment (bright sunlight, a cracked screen, reading at arm's length) rely on pinch-to-zoom to make text legible. user-scalable=no takes that away.
There's a partial reprieve on Apple devices: Safari has ignored user-scalable=no since iOS 10, so it lets people zoom regardless. But you can't lean on that. Many Android browsers and in-app webviews still honor the attribute, so a real share of your visitors are locked out. Leaving the parameter in place is a bug that happens to be masked on one platform.
For classic Google ranking, accessibility isn't a named ranking factor, but page experience and mobile usability are, and Lighthouse and PageSpeed Insights explicitly fail the page under Accessibility when user-scalable="no" is present or maximum-scale is under 5. A low accessibility score is a quality signal you'd rather not carry, and blocked zoom means a worse mobile experience for the majority of your traffic.
The answer-engine angle is indirect but real. Crawlers behind ChatGPT, Perplexity, and Google's AI Overviews read your raw HTML, so a blocked-zoom viewport tag doesn't stop them from extracting content. What it does is drag on the same page-experience and accessibility signals Google uses to judge overall page quality, and quality is one of the inputs to whether a page is a strong candidate to be surfaced or cited. Clearing this flag removes a small, easy quality ding.
How to fix it
- 1
Simplify the viewport tag to the accessible default
Replace whatever you have with
<meta name="viewport" content="width=device-width, initial-scale=1">. That's the complete, correct tag for the overwhelming majority of sites. It sets the layout to the device width and starts at 100% zoom while leaving pinch-to-zoom fully enabled. Deleteuser-scalable=no,user-scalable=0, and anymaximum-scaleorminimum-scalevalues. There's no accessibility reason to specify a maximum scale at all. - 2
Find where the tag is generated
The tag usually lives in one shared place, not on every page. In hand-coded sites it's in a base template or layout include. In frameworks it may be a config export. In a CMS it's often baked into the theme header or injected by the platform or a plugin. Search your codebase for
user-scalableandmaximum-scaleto locate every occurrence, because a stray copy in a second template keeps the warning alive. Fix the source, not each page. - 3
Fix the real reason zoom was disabled
If zoom was blocked to stop iOS auto-zooming when users tap an input, solve that properly instead: set a font size of at least 16px on your
input,select, andtextareaelements. iOS only auto-zooms when the focused field's font is smaller than 16px, sofont-size: 16pxremoves the trigger without disabling zoom for everyone. If it was disabled to mimic a native-app feel, that tradeoff isn't worth an accessibility barrier on a public website. - 4
Re-test zoom on a real device or emulator
Load the page on an Android phone or in Chrome's device toolbar and try to pinch-zoom. It should enlarge smoothly. Then re-run Lighthouse or your accessibility audit and confirm the
[user-scalable="no"]finding is gone. View the page source (Ctrl+U) and confirm exactly one viewport tag remains with no scale restrictions. Because iOS already permits zoom, don't verify on an iPhone alone. Test on Android, where the attribute was actually being honored.
Example
<!-- Broken: blocks pinch-to-zoom, fails WCAG 1.4.4 -->
<meta name="viewport"
content="width=device-width, initial-scale=1, maximum-scale=1, user-scalable=no">
<!-- Fixed: accessible default, zoom allowed -->
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- Stop iOS auto-zoom on inputs the correct way (CSS), not by disabling zoom -->
<style>
input, select, textarea { font-size: 16px; }
</style>
<!-- Next.js App Router (app/layout.tsx) -->
<!--
export const viewport = {
width: 'device-width',
initialScale: 1,
// Do NOT add: maximumScale: 1 or userScalable: false
};
-->Remove the zoom-blocking parameters and keep the simple viewport tag. Fix iOS form auto-zoom with a 16px input font, not by disabling zoom.
Platform-specific steps
Most themes output the viewport tag through wp_head() in header.php, so search the active theme (and any child theme) for user-scalable and maximum-scale. If your theme hard-codes them, edit the tag in a child theme so an update won't overwrite it. Some older mobile or AMP-style plugins inject a zoom-locked viewport tag, so deactivate or reconfigure those. Yoast and Rank Math don't control the viewport tag, so this is a theme or plugin fix, not an SEO-plugin setting.
Open layout/theme.liquid in the code editor (Online Store > Themes > Edit code) and look in the <head> for the viewport meta tag. Some themes include maximum-scale=1 or user-scalable=no. Change the line to <meta name="viewport" content="width=device-width, initial-scale=1">, then save. If a third-party app injects its own viewport tag, check the app's settings.
Both platforms generate the viewport tag automatically and don't expose it for editing, so a genuine zoom-disabled tag from the platform itself is rare. If the audit flags it, the culprit is almost always custom code you added through header or code injection. Search your custom code and custom CSS blocks for user-scalable or maximum-scale and remove them. If nothing there matches, a crawler may be reading a cached or injected tag rather than a real issue.
For static HTML, edit the single viewport tag in each page's <head> (or the shared include) down to width=device-width, initial-scale=1. In the Next.js App Router, export a viewport object and omit the zoom-blocking fields: export const viewport = { width: 'device-width', initialScale: 1 } and do not set maximumScale or userScalable: false. In the Pages Router, fix the <meta> tag inside next/head or _document.
Frequently asked
For a public web page, no. It fails WCAG 1.4.4 and locks out users who need to enlarge text. The only defensible cases are full-screen interactive surfaces like a map canvas or a drawing or game area, where native pinch gestures would conflict with the app's own controls. Even then it's better to disable zoom on just that element with the CSS touch-action property rather than on the whole page. For normal content and marketing pages, always allow zoom.
Safari has deliberately ignored user-scalable=no since iOS 10 to protect accessibility, so zoom works on iPhone regardless of the attribute. But the attribute is still in your HTML, and other browsers, especially some Android browsers and in-app webviews, still honor it. Lighthouse flags the source markup, not the behavior on one browser, because those other users really are blocked. Remove it so every platform behaves correctly.
No. The viewport tag controls layout width and initial zoom separately from whether users can manually zoom. Keeping width=device-width, initial-scale=1 preserves your responsive layout exactly as it is. All you're changing is re-enabling the pinch-to-zoom gesture. Your breakpoints, fluid widths, and design won't shift.
That's the wrong fix. iOS zooms in only when a focused input has a font size below 16px. Set font-size: 16px (or larger) on your input, textarea, and select elements and the auto-zoom stops, with pinch-to-zoom still available for everyone. Disabling user scaling to solve a form-field annoyance trades a minor UX quirk for a genuine accessibility barrier.
A missing viewport tag means mobile browsers render your page at desktop width and shrink it, so it isn't mobile-friendly at all. That's a more severe, layout-level problem. Viewport zoom disabled means the tag is present and your layout is fine, but it explicitly forbids zooming. This one is an accessibility issue rather than a mobile-rendering issue, and the fix is to delete the zoom-blocking parameters, not to add the tag.
Does your site have this issue?
Run a free, AI-powered audit and we’ll flag this and 150+ other checks in about a minute. No signup.