Fixing a Missing or Broken Viewport Tag

Why phones need to be told

When smartphones arrived, almost every website was built for a desktop screen. To avoid breaking them, mobile browsers adopted a compromise: unless a page says otherwise, lay it out on a virtual canvas roughly as wide as a desktop window, typically around 980 CSS pixels, and scale it down to fit the phone. That default is still in place today. It is the reason an old page appears as a tiny, complete desktop layout on a phone.

The viewport meta tag switches that compromise off. It tells the browser to make the layout width equal to the width of the device and to start at normal zoom. Only then do the media queries in a responsive stylesheet fire at the right sizes. This is the key point: a responsive stylesheet without a viewport tag does not behave responsively on phones, because the browser reports a desktop-sized width to the CSS.

<meta name="viewport" content="width=device-width, initial-scale=1">

Include both. Older advice suggested adding shrink-to-fit=no, which dealt with a behaviour in a Safari version from years ago; current browsers do not need it.

Why it matters for search

Google indexes and ranks pages using the version a smartphone crawler sees, so the phone experience is the one that counts. Google retired its standalone Mobile-Friendly Test and the Mobile Usability report in Search Console at the end of 2023, so those tools can no longer confirm the problem for you. Lighthouse and the Meta Tag Analyzer still check for the tag.

Viewport values that cause problems

A viewport tag that is present but wrong can be worse than one that is missing, because it looks correct at a glance. These are the settings found most often in audits:

Why blocking zoom is an accessibility failure

WCAG 2.2 success criterion 1.4.4, Resize Text, asks that text can be enlarged to 200% without losing content or function, and 1.4.10, Reflow, asks that content works at a width of 320 CSS pixels without scrolling in two directions. People with low vision rely on pinch zoom on phones. Automated checkers such as axe flag user-scalable=no and low maximum-scale values for this reason.

Safari on iPhone has ignored user-scalable=no by default for several years for exactly this reason, but Chrome on Android and other browsers still honour it. So a tag that blocks zoom may seem harmless when tested on an iPhone and still lock out Android users.

Diagnosing viewport problems

Three quick checks tell you almost everything.

1. Is the tag in the HTML? Fetch the raw page and search for it. If nothing comes back, the tag is missing from the template, or a script adds it later.

   curl -s https://example.co.uk/ | grep -i 'name="viewport"'

2. What width does the browser report? Open the page on a phone, or in the device toolbar of browser developer tools, and run window.innerWidth in the console. A value near 980 on a phone-sized screen means the viewport tag is not working.
3. Does the page scroll sideways? Swipe left on a phone. If the page moves, something is wider than the screen, even though the viewport is correct. That is a layout problem, covered below.

Test a sample of templates, not only the home page. Old landing pages, legacy blog layouts, embedded booking forms and pages built by a separate page-builder canvas often have their own head and their own copy of the tag, or none at all.

The fix, step by step

Content that is still wider than the screen

A correct viewport tag makes the layout width match the phone, but it does not shrink anything that has been given a fixed width. Those elements poke out past the right edge and the whole page scrolls sideways. This snippet, pasted into the console with a phone-sized window, outlines and lists the offenders:

const w = document.documentElement.clientWidth;
document.querySelectorAll('body *').forEach(el => {
  if (el.getBoundingClientRect().right > w + 1) {
    el.style.outline = '2px solid red';
    console.log(el);
  }
});

Common fixes, in the order they usually come up:

• Images and video. Add img, video { max-width: 100%; height: auto; } to the base stylesheet. Keep the width and height attributes in the HTML so the browser can reserve space.
• Tables. Wrap wide data tables in a container with overflow-x: auto, so the table scrolls inside its box rather than the page scrolling.
• Code and long addresses. Use overflow-wrap: anywhere on body text so long links break, and a scrolling container for code samples.
• Fixed widths. Replace width: 600px with max-width: 600px or a percentage.
• 100vw. On desktop browsers with visible scrollbars, 100vw is wider than the space available. Use 100% for full-width sections.
• Third-party embeds. Booking widgets, maps and social embeds often set their own width. Most offer a responsive option; if not, a wrapper with a maximum width helps.

Where the tag lives on common platforms

If your site uses a separate mobile address such as m.example.co.uk, the mobile pages need the tag as well. Separate mobile sites are harder to keep consistent, and a single responsive site with one viewport tag avoids a whole class of problems.

Stopping it coming back

• One owner for the head. Decide which file prints the viewport tag and make sure nothing else does. Duplicates usually return when a page builder or plugin is added.
• A layout check in testing. Automated accessibility tests catch zoom restrictions, and a visual test at 320 pixels wide catches horizontal overflow before release.
• Base styles that forgive. A small set of defaults, such as images with a maximum width of 100% and scrolling wrappers for tables, prevents most overflow before anyone writes page-specific CSS.
• Check new templates. Landing pages, campaign microsites and embedded forms are where a missing viewport tag most often reappears.

Once phones lay the page out correctly, layout stability and speed on mobile are the next things to look at; the mobile Core Web Vitals guide covers those. The Meta Analyzer Guide explains the other head checks.