Website problems
Missing viewport meta tag
The viewport meta tag tells a mobile browser how wide to consider the page. Without it, browsers fall back to an assumed desktop width — commonly 980 pixels — lay the page out at that width, and then scale the whole thing down to fit the screen. The result is a readable-looking miniature of a desktop site: text too small to read, links too small to tap, and every CSS media query evaluating against the wrong width, so responsive styles never apply.
What the tag actually does
`<meta name="viewport" content="width=device-width, initial-scale=1">` is the standard declaration. It says: treat the layout viewport as the device's own width, and start at 100% scale.
`width=device-width` is the part that matters most. It is what makes a CSS pixel correspond to a device-independent pixel, and therefore what makes `@media (max-width: 600px)` mean what the author intended.
`initial-scale=1` sets the starting zoom. Without it, some browsers apply their own initial scale and the page opens partially zoomed.
Without the tag, media queries still run — they just evaluate against the assumed desktop width, so the mobile breakpoints never match. This is why a site with complete responsive CSS can still render as a shrunken desktop page.
The values that cause harm
`user-scalable=no` disables pinch-to-zoom. It is a direct accessibility failure: anyone who needs to magnify text cannot. WCAG 2.2 Success Criterion 1.4.4 requires text to be resizable to 200%.
`maximum-scale=1` has the same effect by a different route, and is frequently copied from older templates written when mobile browsers handled zoom badly.
Modern browsers ignore both in many contexts precisely because of the harm, but not universally, and the declaration is still the site stating an intention it should not have.
A fixed `width=1024` or similar pins the layout to one width, which defeats responsive design entirely and produces horizontal scrolling on every phone.
The correct answer for almost every site is exactly `width=device-width, initial-scale=1`, with nothing else.
Why it survives so long
The page is usable. Pinch and zoom and everything is there, which is why it is reported as 'the mobile site looks small' rather than as a fault.
Desktop testing shows nothing at all — the tag has no effect there, so a developer resizing a browser window sees the responsive layout working perfectly.
Browser device emulation can also mislead: some tools apply a device width regardless of the tag, so the layout looks correct in the emulator and wrong on the phone.
The usual cause is a page or a template outside the main layout: a landing page built separately, an email-capture page, a legacy section, a print view. The main template has the tag and the outlier does not.
How to check it yourself
In the source, look in `<head>` for `name="viewport"`. In the console: `document.querySelector('meta[name=viewport]')?.content`.
On a real phone, load the page and see whether text is legible without zooming. That is the symptom, and it is unambiguous.
In Chrome device emulation, disable any device-width override so the tag's absence actually shows.
Check the pages that were built separately from the main template. The home page almost always has it; the campaign landing page from two years ago frequently does not.
How to fix it
Add the standard declaration to the base template's `<head>`, once: `<meta name="viewport" content="width=device-width, initial-scale=1">`.
Remove `user-scalable=no` and `maximum-scale` wherever they appear. If a layout breaks when zoomed, the layout is the defect.
Then check that responsive CSS actually exists. Adding the tag to a page with no media queries reveals a fixed-width layout rather than fixing it — the page stops being shrunk and starts overflowing sideways.
Audit the outliers rather than the main template, since the main template is rarely the problem.
On pages with fixed-width elements — a wide table, an embedded map, a large image — expect horizontal overflow to appear once the tag is added, and fix those elements rather than reverting the tag.
How VeriFixScan detects it
`mobile.viewport` reads the `<head>` of each crawled page, reports pages with no viewport declaration, and reports the declared value where one exists — including the scale restrictions that disable zoom.
`mobile.responsive` covers the adjacent question of whether the page carries responsive styles at all, which is what determines whether adding the tag will help or expose a fixed layout.
`mobile.content_width` and `mobile.horizontal_scrolling` report the overflow that usually appears once the viewport is declared correctly.
Frequently asked questions
- Does a missing viewport tag affect rankings?
- Indirectly. Google evaluates pages as a mobile user agent, and a page laid out at an assumed desktop width is assessed that way. The direct cost is that mobile visitors get a shrunken desktop page.
- Should I ever use user-scalable=no?
- No. It prevents people from magnifying text, which is a direct accessibility failure against WCAG 1.4.4. If a layout breaks when zoomed, fix the layout.
- I added the tag and now the page scrolls sideways. Why?
- The tag stopped the browser shrinking the page, so fixed-width content now overflows a narrow screen. That content was always too wide; the zoom was hiding it.
Sources
Related
VeriFixScan crawls a site and applies its checks to every page it reaches, keeping the evidence behind each finding. Scanning one website is free.
Scan a website