Meta Tag de Viewport

O que a meta tag de viewport faz, por que ela faz o design responsivo funcionar em dispositivos móveis, a configuração correta, a referência de atributos e erros comuns.

Publicado pela primeira vez: 2 de jul. de 2026 · Última atualização: 3 de ago. de 2026 · Avançado

A meta tag de viewport — <meta name="viewport" content="width=device-width, initial-scale=1"> — indica ao navegador para dimensionar o viewport de layout para a largura do dispositivo em pixels CSS, em vez do fallback legado de ~980px que alguns navegadores móveis usam. Sem ela, os telefones podem renderizar a página nesse fallback mais largo e encolhê-la, produzindo texto minúsculo, rolagem horizontal e breakpoints responsivos que podem não se aplicar como pretendido. Não é um fator de ranqueamento em si, mas sua presença é uma das coisas que o Google documenta como indicativo de compatibilidade com dispositivos móveis, e sua ausência é uma falha clássica de usabilidade móvel. Nunca force user-scalable=no ou um maximum-scale restritivo — isso falha na regra de conformidade de acessibilidade do W3C para zoom e pode bloquear usuários com baixa visão, embora os navegadores possam substituir isso (iOS 10+ ignora por padrão). Teste com Lighthouse ou PageSpeed Insights: o relatório de Usabilidade Móvel do Search Console e o Teste de Compatibilidade com Dispositivos Móveis foram aposentados em 1º de dezembro de 2023.

«> TL;DR — The viewport meta tag —

<meta name="viewport" content="width=device-width, initial-scale=1"> — hints the browser to size the layout viewport to the device’s width in CSS pixels instead of a legacy ~980px fallback some mobile browsers use, which is what lets responsive CSS media queries evaluate against the device’s real width on mobile. Missing or misconfigured, it’s a classic mobile usability failure (tiny text, horizontal scroll). It is not a ranking factor — Google documents its presence as one thing its mobile-friendliness evaluation checks for, and no more than that. Never force user-scalable=no / restrictive maximum-scale: it fails the W3C’s ACT accessibility rule for zoom, though browser overrides exist (iOS 10+ ignores it by default). Google and Bing recommend the identical tag. Test with Lighthouse / PageSpeed Insights — Search Console’s Mobile Usability report and the Mobile-Friendly Test were retired December 1, 2023. » (Tradução) (Síntese localizada do trecho vinte e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

« Evidência desta afirmação The viewport meta tag lets authors control viewport width and scaling so responsive layouts render at device width. Escopo: Browser viewport behavior. Confiança: alta · Verificado: MDN: Viewport meta tag Evidência desta afirmação Pages should not disable browser zoom because users must be able to enlarge content for accessibility. Escopo: WCAG resize-text requirement and viewport guidance. Confiança: alta · Verificado: W3C WAI: Understanding Resize Text » (Tradução) (Síntese localizada do trecho vinte e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## The problem it solves: the ~980px virtual viewport » (Tradução) (Síntese localizada do trecho vinte e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«To understand the tag you have to understand what it’s overriding. When mobile browsers were new, the lack of a viewport tag meant some of them would fall back to a fixed layout width of roughly 980px and render at that size — a deliberate accommodation so desktop-sized, pre-responsive sites wouldn’t completely break on early smartphones. The browser then scaled the result down to the physical screen. MDN’s own framing: “If the site isn’t designed to work well on small viewports and this tag is omitted, some mobile browsers render the site using a fixed initial containing block width, typically 980px.” — it’s a browser-specific fallback, not a universal spec constant. » (Tradução) (Síntese localizada do trecho vinte e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«The consequence, in Google’s own words: “Without a viewport meta tag, mobile devices render pages at typical desktop screen widths and then scale the pages down, making them difficult to read.” You get unreadable text, forced pinch-zooming, and horizontal scrolling — the textbook symptoms of a page flagged “not mobile-friendly.” » (Tradução) (Síntese localizada do trecho vinte e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Setting the tag “lets you control the width and scaling of the viewport so that it’s sized correctly on all devices.” » (Tradução) (Síntese localizada do trecho vinte e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Layout viewport vs. visual viewport (under the hood) » (Tradução) (Síntese localizada do trecho vinte e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Two “viewports” are in play, and it’s worth keeping them straight: » (Tradução) (Síntese localizada do trecho vinte e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- The layout viewport is the area the page lays out into and that fixed-position elements attach to. width=device-width sets this to the device’s screen width in CSS pixels.

  • The visual viewport is what the user is currently looking at — which changes when they pinch-zoom. Zooming changes the visual viewport without changing the layout viewport. » (Tradução) (Síntese localizada do trecho vinte e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«The reason this matters for SEO and CSS: your responsive media queries (@media (max-width: 600px) and friends) are evaluated against the layout viewport. If the layout viewport is stuck at a legacy ~980px fallback because there’s no viewport tag, a phone may match your desktop breakpoints instead of your narrow ones. MDN puts it plainly: “Without it, your responsive design with breakpoints and media queries may not work as intended on mobile browsers.” The tag is what makes device-width the layout viewport so your intended breakpoints evaluate correctly.

Evidência desta afirmação Without an appropriate viewport hint, narrow responsive breakpoints may not match as intended against the wider virtual layout viewport; it is too absolute to say CSS media queries never fire. Escopo: production HTML and HTTP responses Confiança: alta · Verificado: Responsive web design

» (Tradução) (Síntese localizada do trecho trinta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## The correct tag, and where it goes » (Tradução) (Síntese localizada do trecho trinta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <!-- ...the rest of your head... -->
</head>

«Put it high in the <head>, near charset, before content-dependent tags. This is the value Google, Bing, and Lighthouse all recommend — verbatim, it’s the fix Lighthouse itself suggests. Don’t overthink the value: width=device-width, initial-scale=1 is the answer for essentially every responsive site. » (Tradução) (Síntese localizada do trecho trinta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Attribute reference » (Tradução) (Síntese localizada do trecho trinta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«The content attribute is a comma-separated list of directives. MDN is the canonical attribute-by-attribute reference; here’s what each one does: » (Tradução) (Síntese localizada do trecho trinta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«| Directive | What it does | Notes | | --- | --- | --- | | width | Controls the (minimum) pixel width of the viewport | A whole number 1–10000, or the special value device-width (the screen width in CSS pixels). Use device-width. | | initial-scale | The zoom ratio between device width and viewport on load | A number 0.0–10.0. Use 1. | | minimum-scale | The minimum zoom level allowed | Must be ≤ maximum-scale. iOS 10+ ignores it by default. | | maximum-scale | The maximum zoom-in allowed | Must be ≥ minimum-scale. iOS 10+ ignores it by default. Don’t restrict it. | | user-scalable | Whether the user can zoom (yes/no, default yes) | iOS 10+ ignores it by default. Setting no is an accessibility anti-pattern — leave it. | | interactive-widget | How interactive UI (e.g. virtual keyboards) affect the viewport | Values: resizes-visual (default), resizes-content, overlays-content. Newer; most SEO content omits it. | | viewport-fit | How the viewport handles display cutouts (notches) | Values: auto (default), contain (fits inside the largest rectangle that avoids the cutout), cover (fills the display — pair with CSS env() safe-area-inset variables so content doesn’t land under the cutout). | » (Tradução) (Síntese localizada do trecho trinta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«viewport-fit and interactive-widget are both browser-layout edge cases — display-cutout and virtual-keyboard handling, respectively — not SEO directives; most SEO-focused guides skip them entirely. » (Tradução) (Síntese localizada do trecho trinta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«A small but real gotcha from Lighthouse’s own docs: setting initial-scale below 1 can trigger a legacy double-tap-to-zoom behavior that adds interaction delay — another reason to stick with initial-scale=1 rather than getting clever. » (Tradução) (Síntese localizada do trecho trinta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Never disable zoom: user-scalable=no is an anti-pattern » (Tradução) (Síntese localizada do trecho trinta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«You’ll still find user-scalable=no (or maximum-scale=1) copy-pasted into old theme boilerplate, usually from a developer who didn’t want pinch-zoom “messing up” their layout. It’s wrong on two counts: » (Tradução) (Síntese localizada do trecho quarenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«1. It fails the web’s own accessibility conformance test for zoom, and it works against WCAG’s intent. The W3C’s ACT rule “Meta viewport allows for zoom” (rule b4f0c3) applies to any viewport tag that sets user-scalable or maximum-scale, and its expectation is explicit: the tag must not set user-scalable=no, and maximum-scale must not be set below 2. (The rule carries stated assumptions — it doesn’t apply if the page has no visible content, offers another way to resize text, or never needs to reflow past a 320×256 CSS-pixel area — but a typical responsive page doesn’t meet those exceptions.) Per MDN: “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.” Blocking zoom locks out the exact users who need it most. 2. It’s also browser-specific, not universal. iOS Safari 10 and later ignore user-scalable=no and restrictive maximum-scale by default — that’s an iOS override, not a change to the ACT rule or to WCAG’s intent. So on a large share of mobile traffic the setting accomplishes nothing, while on browsers that do still honor it (older Android WebViews, some in-app browsers) it actively fails the accessibility test above. Zero upside, real downside — and don’t treat “iOS » (Tradução) (Síntese localizada do trecho quarenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.) « ignores it” as proof the markup is accessible everywhere.

Evidência desta afirmação `user-scalable=no` and `maximum-scale` below 2 fail the cited ACT rule's expectation under its assumptions, and disabling zoom harms low-vision users; an automated ACT failure is not by itself a complete universal WCAG conformance determination. Escopo: production HTML and HTTP responses Confiança: alta · Verificado: Viewport meta tag

» (Tradução) (Síntese localizada do trecho quarenta e um, parte dois: o texto-fonte foi preservado para conferência na revisão nativa.)

«The rule is simple: don’t touch zoom. width=device-width, initial-scale=1 and nothing else. » (Tradução) (Síntese localizada do trecho quarenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Is it a ranking factor? » (Tradução) (Síntese localizada do trecho quarenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Be precise here, because a lot of SEO content overstates it. Here’s exactly what Google documents, and where the line to industry inference sits. » (Tradução) (Síntese localizada do trecho quarenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«What Google documents: the viewport tag is not a direct ranking factor. Google’s own supported-meta-tags doc says plainly that “presence of this tag indicates to Google that the page is mobile friendly” — that’s the whole documented claim: presence signals mobile-friendliness. Google doesn’t document the tag as scored, as a rendering guarantee, or as proof a page’s responsive design is actually good.

Evidência desta afirmação Google documents that viewport-meta presence indicates a page is mobile friendly, but that statement does not establish that the tag itself is a ranking factor, a display guarantee or sufficient evidence of responsive quality. Escopo: production HTML and HTTP responses Confiança: alta · Verificado: Meta tags and attributes that Google supports

» (Tradução) (Síntese localizada do trecho quarenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Where practitioners connect the dots (industry inference, not a Google citation): a missing or misconfigured viewport tag is a common root cause of the mobile-usability failures (tiny text, horizontal scroll, unusable tap targets) that SEOs generally understand to degrade mobile page experience. That connection is reasonable and widely held in the industry, but it’s a practitioner inference about why the tag matters — not something Google’s docs state as a ranking chain. » (Tradução) (Síntese localizada do trecho quarenta e seis, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«So the honest framing: the tag itself isn’t scored, and fix it because a page without it renders badly on phones — not because Google documents it as a ranking lever, direct or indirect. Keep this separate from mobile-first indexing too: that’s a distinct Google Search concept about which version of your page Google primarily uses for indexing and ranking; the viewport tag is about how that mobile HTML renders in a browser, full stop.

Evidência desta afirmação Mobile-first indexing means Google primarily uses the mobile content for indexing and ranking; it is a separate Google Search concept from the browser's viewport rendering contract. Escopo: production HTML and HTTP responses Confiança: alta · Verificado: Mobile-first indexing best practices

» (Tradução) (Síntese localizada do trecho quarenta e sete, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## How to test it — the tooling changed in 2023 » (Tradução) (Síntese localizada do trecho quarenta e oito, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«This is where most older guides are stale. On December 1, 2023, Google retired Search Console’s Mobile Usability report, the Mobile-Friendly Test tool, and the Mobile-Friendly Test API (announced April 2023, confirmed complete that December). Google’s reasoning was that other tools had matured — “many other robust resources for evaluating mobile usability have emerged, including Lighthouse from Chrome.” So if a tutorial tells you to open Search Console → Mobile Usability to check your viewport, that report no longer exists. » (Tradução) (Síntese localizada do trecho quarenta e nove, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Layer these checks rather than relying on one tool: confirm the tag exists in the raw served HTML (not just after JavaScript runs), confirm your responsive breakpoints actually apply at phone widths, test zooming to 200% without the layout breaking (the resize behavior WCAG’s intent is built around), and spot-check in more than one browser — an iOS Safari-only check can hide a zoom-restriction bug that Android or in-app browsers still enforce. » (Tradução) (Síntese localizada do trecho cinquenta, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«Your current toolkit: » (Tradução) (Síntese localizada do trecho cinquenta e um, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- Lighthouse (in Chrome DevTools). The relevant audit historically read “Does not have a <meta name="viewport"> tag with width or initial-scale” — it fails unless the <head> has a meta name="viewport" whose content includes width=. As of Lighthouse 13 it’s folded into the “Optimize viewport for mobile” insight.

  • PageSpeed Insights — runs Lighthouse plus field Core Web Vitals data.
  • Chrome DevTools device toolbar — emulate phone dimensions and eyeball it.
  • Bing’s Mobile Friendliness Test Tool — Bing checks viewport and zoom-control configuration too, and recommends the same tag Google does.
  • View source / real-device check — sometimes the fastest test is to just look at the <head> on your phone. » (Tradução) (Síntese localizada do trecho cinquenta e dois, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«## Common mistakes » (Tradução) (Síntese localizada do trecho cinquenta e três, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«- No tag at all (“viewport not set”) — the page renders at the legacy desktop-ish width and shrinks.

  • A hardcoded pixel width like width=1024 instead of device-width — a tag exists, but it still doesn’t match the page to the device. Lighthouse and real mobile-friendliness both want a usable width= value, not just any tag.
  • initial-scale below 1 — can trigger the legacy double-tap-zoom delay.
  • user-scalable=no / restrictive maximum-scale — copy-pasted from old boilerplate; accessibility anti-pattern, ignored on iOS anyway. » (Tradução) (Síntese localizada do trecho cinquenta e quatro, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

«For where this sits in the broader mobile work — configuration, content parity, speed — see the mobile SEO hub, the mobile SEO checklist, and mobile-first indexing. For the tag itself as part of the wider on-page tag family, the meta tags cluster is the map. » (Tradução) (Síntese localizada do trecho cinquenta e cinco, parte um: o texto-fonte foi preservado para conferência na revisão nativa.)

Adicionar uma nota de especialista

Fixar uma citação de especialista

É uma pessoa nova? Crie o perfil não reivindicado dela em /admin/experts/ → Fixar uma citação de especialista primeiro.