Idiomas

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
Idiomas
AIEscrito porAI v2

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 — A meta tag de viewport — <meta name="viewport" content="width=device-width, initial-scale=1"> — indica ao navegador que dimensione o layout viewport para a largura do dispositivo em pixels CSS em vez de um fallback legado de ~980px que alguns navegadores móveis usam, o que é o que permite que as media queries CSS responsivas sejam avaliadas em relação à largura real do dispositivo no celular. Ausente ou mal configurada, é uma falha clássica de usabilidade móvel (texto minúsculo, rolagem horizontal). Não é um fator de ranqueamento — o Google documenta sua presença como uma das coisas que sua avaliação de compatibilidade com dispositivos móveis verifica, e nada mais do que isso. Nunca force user-scalable=no / maximum-scale restritivo: isso falha na regra de acessibilidade ACT do W3C para zoom, embora existam overrides de navegador (iOS 10+ ignora isso por padrão). Google e Bing recomendam a tag idêntica. Teste com Lighthouse / PageSpeed Insights — o relatório de Usabilidade Mobile do Search Console e o Teste de Compatibilidade com Dispositivos Móveis foram aposentados em 1º de dezembro de 2023.

Evidence for this claim The viewport meta tag lets authors control viewport width and scaling so responsive layouts render at device width. Scope: Browser viewport behavior. Confidence: high · Verified: MDN: Viewport meta tag Evidence for this claim Pages should not disable browser zoom because users must be able to enlarge content for accessibility. Scope: WCAG resize-text requirement and viewport guidance. Confidence: high · Verified: W3C WAI: Understanding Resize Text

O problema que ela resolve: o viewport virtual de ~980px

Para entender a tag, você precisa entender o que ela está substituindo. Quando os navegadores móveis eram novos, a falta de uma tag de viewport significava que alguns deles recorreriam a uma largura de layout fixa de aproximadamente 980px e renderizariam nesse tamanho — uma acomodação deliberada para que sites desktop, pré-responsivos, não quebrassem completamente nos primeiros smartphones. O navegador então reduzia o resultado para caber na tela física. A própria estrutura do MDN: “Se o site não for projetado para funcionar bem em viewports pequenos e esta tag for omitida, alguns navegadores móveis renderizam o site usando uma largura fixa do bloco de contenção inicial, tipicamente 980px.” — é um fallback específico do navegador, não uma constante universal da especificação.

A consequência, nas próprias palavras do Google: “Sem uma meta tag de viewport, dispositivos móveis renderizam páginas em larguras típicas de tela de desktop e depois reduzem as páginas, dificultando a leitura.” Você obtém texto ilegível, zoom por pinça forçado e rolagem horizontal — os sintomas clássicos de uma página marcada como “não compatível com dispositivos móveis”.

Definir a tag “permite que você controle a largura e o dimensionamento do viewport para que ele seja dimensionado corretamente em todos os dispositivos.”

Layout viewport vs. visual viewport (por baixo dos panos)

Dois “viewports” estão em jogo, e vale a pena mantê-los distintos:

  • O layout viewport é a área na qual a página é disposta e à qual elementos de posição fixa se anexam. width=device-width define isso para a largura da tela do dispositivo em pixels CSS.
  • O visual viewport é o que o usuário está vendo no momento — que muda quando ele dá zoom com pinça. O zoom altera o visual viewport sem alterar o layout viewport.

A razão pela qual isso importa para SEO e CSS: suas media queries responsivas (@media (max-width: 600px) e afins) são avaliadas em relação ao layout viewport. Se o layout viewport estiver preso a um fallback legado de ~980px porque não há tag de viewport, um telefone pode corresponder aos seus breakpoints de desktop em vez dos estreitos. O MDN coloca isso claramente: “Sem ela, seu design responsivo com breakpoints e media queries pode não funcionar como pretendido em navegadores móveis.” A tag é o que faz device-width ser o layout viewport para que seus breakpoints pretendidos sejam avaliados corretamente.

Evidence for this claim 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. Scope: production HTML and HTTP responses Confidence: high · Verified: Responsive web design

A tag correta e onde ela vai

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

Coloque-a no início do <head>, perto de charset, antes de tags dependentes de conteúdo. Este é o valor que Google, Bing e Lighthouse recomendam — literalmente, é a correção que o próprio Lighthouse sugere. Não pense demais no valor: width=device-width, initial-scale=1 é a resposta para praticamente todo site responsivo.

Referência de atributos

O atributo content é uma lista de diretivas separadas por vírgula. O MDN é a referência canônica atributo por atributo; aqui está o que cada um faz:

DiretivaO que fazObservações
widthControla a largura (mínima) em pixels da viewportUm número inteiro de 1 a 10000, ou o valor especial device-width (a largura da tela em pixels CSS). Use device-width.
initial-scaleA proporção de zoom entre a largura do dispositivo e a viewport no carregamentoUm número 0.0–10.0. Use 1.
minimum-scaleO nível mínimo de zoom permitidoDeve ser ≤ maximum-scale. O iOS 10+ o ignora por padrão.
maximum-scaleO zoom máximo permitidoDeve ser ≥ minimum-scale. O iOS 10+ o ignora por padrão. Não o restrinja.
user-scalableSe o usuário pode aplicar zoom (yes/no, padrão yes)O iOS 10+ o ignora por padrão. Definir no é um antipadrão de acessibilidade — deixe como está.
interactive-widgetComo a interface interativa (ex.: teclados virtuais) afeta a viewportValores: resizes-visual (padrão), resizes-content, overlays-content. Mais recente; a maioria do conteúdo de SEO o omite.
viewport-fitComo a viewport lida com recortes de exibição (notches)Valores: auto (padrão), contain (cabe dentro do maior retângulo que evita o recorte), cover (preenche a tela — combine com as variáveis CSS env() de safe-area-inset para que o conteúdo não fique sob o recorte).

viewport-fit e interactive-widget são ambos casos extremos de layout do navegador — manipulação de recortes de exibição e teclados virtuais, respectivamente — não diretivas de SEO; a maioria dos guias focados em SEO os omite completamente.

Uma pegadinha pequena, mas real, da própria documentação do Lighthouse: definir initial-scale abaixo de 1 pode acionar um comportamento legado de toque duplo para zoom que adiciona atraso de interação — outra razão para manter initial-scale=1 em vez de tentar ser esperto.

Nunca desative o zoom: user-scalable=no é um antipadrão

Você ainda encontrará user-scalable=no (ou maximum-scale=1) copiado e colado em modelos antigos de temas, geralmente de um desenvolvedor que não queria que o pinch-zoom “estragasse” seu layout. Está errado por dois motivos:

  1. Falha no próprio teste de conformidade de acessibilidade da web para zoom e vai contra a intenção do WCAG. A regra ACT do W3C “Meta viewport allows for zoom” (regra b4f0c3) se aplica a qualquer tag viewport que defina user-scalable ou maximum-scale, e sua expectativa é explícita: a tag não deve definir user-scalable=no, e maximum-scale não deve ser definido abaixo de 2. (A regra traz suposições declaradas — ela não se aplica se a página não tiver conteúdo visível, oferecer outra forma de redimensionar texto ou nunca precisar refluir além de uma área de 320×256 pixels CSS — mas uma página responsiva típica não atende a essas exceções.) Segundo o 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.” (tradução) «Desabilitar os recursos de zoom definindo user-scalable como no impede pessoas com condições de baixa visão de ler e entender o conteúdo da página. Além disso, o WCAG exige um mínimo de 2× de escala; no entanto, a melhor prática é habilitar um zoom de 5×.» Bloquear o zoom exclui exatamente os usuários que mais precisam dele.
  2. Também é específico do navegador, não universal. O Safari do iOS 10 e versões posteriores ignoram user-scalable=no e maximum-scale restritivo por padrão — isso é uma substituição do iOS, não uma mudança na regra ACT ou na intenção do WCAG. Portanto, em uma grande parcela do tráfego móvel, a configuração não realiza nada, enquanto em navegadores que ainda a honram (WebViews Android mais antigas, alguns navegadores em aplicativos) ela falha ativamente no teste de acessibilidade acima. Zero benefício, desvantagem real — e não trate “o iOS ignora isso” como prova de que o markup é acessível em todos os lugares.
Evidence for this claim `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. Scope: production HTML and HTTP responses Confidence: high · Verified: Viewport meta tag

A regra é simples: não mexa no zoom. width=device-width, initial-scale=1 e nada mais.

É um fator de ranqueamento?

Seja preciso aqui, porque muito conteúdo de SEO exagera nisso. Aqui está exatamente o que o Google documenta, e onde está a linha para a inferência do setor.

O que o Google documenta: a tag viewport não é um fator de ranqueamento direto. O próprio documento de meta tags suportadas do Google afirma claramente que “a presença dessa tag indica ao Google que a página é compatível com dispositivos móveis” — essa é toda a afirmação documentada: a presença sinaliza compatibilidade com dispositivos móveis. O Google não documenta a tag como pontuada, como garantia de renderização ou como prova de que o design responsivo de uma página é realmente bom.

Evidence for this claim 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. Scope: production HTML and HTTP responses Confidence: high · Verified: Meta tags and attributes that Google supports

Onde os profissionais conectam os pontos (inferência do setor, não uma citação do Google): uma tag viewport ausente ou mal configurada é uma causa raiz comum das falhas de usabilidade em dispositivos móveis (texto pequeno, rolagem horizontal, alvos de toque inutilizáveis) que os profissionais de SEO geralmente entendem como degradação da experiência de página em dispositivos móveis. Essa conexão é razoável e amplamente aceita no setor, mas é uma inferência de profissionais sobre por que a tag importa — não algo que os documentos do Google afirmam como uma cadeia de ranqueamento.

Portanto, o enquadramento honesto: a tag em si não é pontuada, e corrija-a porque uma página sem ela renderiza mal em celulares — não porque o Google a documenta como uma alavanca de ranqueamento, direta ou indireta. Mantenha isso separado também da indexação mobile-first: esse é um conceito distinto do Google Search sobre qual versão da sua página o Google usa principalmente para indexação e ranqueamento; a tag viewport é sobre como esse HTML móvel renderiza em um navegador, ponto final.

Evidence for this claim 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. Scope: production HTML and HTTP responses Confidence: high · Verified: Mobile-first indexing best practices

Como testar — as ferramentas mudaram em 2023

É aqui que a maioria dos guias antigos está desatualizada. Em 1º de dezembro de 2023, o Google aposentou o relatório de Usabilidade em dispositivos móveis do Search Console, a ferramenta Mobile-Friendly Test e a API Mobile-Friendly Test (anunciado em abril de 2023, confirmado como concluído naquele dezembro). A justificativa do Google foi que outras ferramentas amadureceram — “muitos outros recursos robustos para avaliar a usabilidade em dispositivos móveis surgiram, incluindo o Lighthouse do Chrome.” Portanto, se um tutorial diz para você abrir Search Console → Usabilidade em dispositivos móveis para verificar sua viewport, esse relatório não existe mais.

Combine essas verificações em vez de confiar em uma única ferramenta: confirme se a tag existe no HTML bruto servido (não apenas após a execução do JavaScript), confirme se seus breakpoints responsivos realmente se aplicam em larguras de celular, teste o zoom para 200% sem que o layout quebre (o comportamento de redimensionamento em torno do qual a intenção do WCAG é construída) e faça uma verificação pontual em mais de um navegador — uma verificação apenas no Safari do iOS pode esconder um bug de restrição de zoom que o Android ou navegadores em aplicativos ainda aplicam.

Seu kit de ferramentas atual:

  • Lighthouse (no Chrome DevTools). A auditoria relevante historicamente lia “Não tem uma tag <meta name="viewport"> com width ou initial-scale” — ela falha a menos que o <head> tenha uma meta name="viewport" cujo content inclua width=. A partir do Lighthouse 13, ela está incorporada ao insight “Otimizar viewport para dispositivos móveis”.
  • PageSpeed Insights — executa o Lighthouse mais dados de campo do Core Web Vitals.
  • Barra de ferramentas de dispositivos do Chrome DevTools — emule dimensões de celular e avalie visualmente.
  • Ferramenta de teste de compatibilidade com dispositivos móveis do Bing — o Bing verifica a configuração de viewport e controle de zoom também, e recomenda a mesma tag que o Google.
  • Ver código-fonte / verificação em dispositivo real — às vezes o teste mais rápido é apenas olhar o <head> no seu celular.

Erros comuns

  • Nenhuma tag (“viewport não definido”) — a página renderiza na largura legada semelhante à de desktop e encolhe.
  • Uma largura de pixel fixa como width=1024 em vez de device-width — uma tag existe, mas ainda não corresponde a página ao dispositivo. O Lighthouse e a compatibilidade real com dispositivos móveis querem um valor width= utilizável, não apenas qualquer tag.
  • initial-scale abaixo de 1 — pode acionar o atraso legado de zoom com duplo toque.
  • user-scalable=no / maximum-scale restritivo — copiado de boilerplate antigo; antipadrão de acessibilidade, ignorado no iOS de qualquer forma.

Para saber onde isso se encaixa no trabalho mobile mais amplo — configuração, paridade de conteúdo, velocidade — veja o hub de SEO mobile, o checklist de SEO mobile e a indexação mobile-first. Para a tag em si como parte da família mais ampla de tags on-page, o cluster de meta tags é o mapa.

Add an expert note

Pin an expert quote

New person? Create their unclaimed profile at /admin/experts/ → Pin a quote first.