Site responsivo é o site que usa o mesmo endereço e o mesmo HTML em qualquer aparelho e reorganiza o layout conforme a largura da tela: três colunas no computador, uma no celular, sem rolagem para o lado e sem precisar ampliar para ler. Para saber se o seu funciona assim, não há mais o teste de um clique do Google. Hoje a conferência junta quatro coisas: a meta viewport no código, o modo de dispositivo do Chrome, o Lighthouse e o celular na sua mão.
O que é um site responsivo, e o que ele não é?
É uma técnica de layout, e não uma segunda versão do site. Quem batizou a técnica foi Ethan Marcotte, num texto da revista A List Apart, em maio de 2010. A página é uma só. O CSS traz regras que valem a partir de certa largura, as media queries, e são elas que decidem quando o menu vira um botão, quando as colunas empilham e quando a imagem encolhe.
O Google descreve três jeitos de atender quem chega pelo celular e recomenda o primeiro, por ser o mais fácil de implantar e de manter:
| Configuração | Como funciona | O trabalho que dá |
|---|---|---|
| Design responsivo | Mesmo endereço e mesmo HTML; o CSS adapta o layout à tela | Uma página só para cuidar |
| Exibição dinâmica | Mesmo endereço, mas o servidor manda um HTML diferente para cada tipo de aparelho | Detectar o aparelho sem errar e manter dois HTMLs em dia |
| Endereços separados | Uma cópia do site em m.seusite.com.br | Ligar cada página do m. à sua par no computador e manter as duas iguais |
Site em m. ou "modo mobile" ligado por plugin pode abrir bem no celular, mas não é responsivo. Funciona, só que dobra o trabalho: todo texto, título e dado estruturado precisa existir nas duas versões.
Por que a versão de celular é a que conta no Google?
Porque é a que o Google lê. A documentação do Search Central diz que o Google usa a versão de celular do conteúdo, rastreada com o robô de smartphone, para indexar e classificar as páginas. A troca começou em 2016 e foi dada por concluída em 31 de outubro de 2023.
Desde então, só um grupo pequeno de sites que não funcionam no celular de jeito nenhum continua sendo lido pelo robô antigo de computador, e o Google reavalia essa lista algumas vezes por ano.
Na prática, o que só existe na versão de computador pode não contar. A lista de boas práticas do Google pede que a versão de celular tenha:
- o mesmo conteúdo do computador (guardar um trecho em aba ou acordeão é aceito; cortar, não);
- os mesmos subtítulos, o mesmo
titlee uma meta description equivalente; - os mesmos dados estruturados e as mesmas tags de robots;
- as mesmas imagens, com o mesmo texto alternativo;
- conteúdo principal que carrega sem depender de toque ou clique, com os arquivos de que o robô precisa liberados.
Funcionar bem no celular também está entre as perguntas que o Google sugere para avaliar a experiência da página: "seu conteúdo é exibido bem em dispositivos móveis?". A velocidade no celular tem métricas próprias e fica para o roteiro que separa servidor lento de página pesada.
O que aconteceu com o teste de compatibilidade do Google?
Saiu do ar, e o substituto indicado não faz o mesmo trabalho. O aviso veio em 19 de abril de 2023, num post do Search Central sobre experiência na página. Ali o Google explicou que a usabilidade no celular continua importante, mas que, em quase dez anos, surgiram outros recursos para avaliá-la, e citou o Lighthouse, do Chrome.
Quem digita hoje o endereço antigo, search.google.com/test/mobile-friendly, cai na página de apresentação do Lighthouse: conferimos em 26 de outubro de 2026.
O teste antigo dava um veredito único: página compatível com celular ou não. O Lighthouse foi tirando da categoria de SEO justamente as checagens de celular:
- Lighthouse 12, de abril de 2024: a checagem de botões e links pequenos demais saiu de SEO e foi trocada pela de tamanho dos alvos de toque, em Acessibilidade. Viewport e tamanho de fonte passaram para Práticas recomendadas.
- Lighthouse 13, de outubro de 2025: a checagem de fonte pequena foi removida. A equipe escreveu que não há sinais de que ela ainda pese no SEO. A de viewport virou um "insight" de Desempenho, que não entra na nota.
Ou seja, um 100 em SEO no Lighthouse não diz nada sobre o celular. O que sobrou de útil está em três pontos do relatório: o insight de viewport, a checagem de zoom bloqueado e a de alvos de toque. O resto você confere olhando.
Para que serve a meta viewport?
Ela manda o navegador do celular desenhar a página na largura da tela, em vez de montar uma página de computador e encolher o resultado. É uma linha só, que vai dentro do <head>:
<meta name="viewport" content="width=device-width, initial-scale=1">
O width=device-width diz para usar a largura do aparelho, e o initial-scale=1 abre a página sem zoom. Sem essa linha, o navegador do celular imagina uma tela de computador, em geral com cerca de 980 pixels, monta a página nesse tamanho e encolhe tudo para caber. Fizemos a prova com uma página de teste no Chrome, simulando um celular de 360 pixels: sem a tag, a página ficou com 980 pixels de largura; com ela, 360. E o CSS responsivo não salva quem esqueceu a tag, porque as media queries passam a enxergar uma tela de computador.
Os defeitos que aparecem na tag são três:
- Ausente: o caso acima, com letra miúda e página inteira encolhida.
- Largura fixa, como
width=1024: a página fica presa nesse tamanho em qualquer aparelho. - Zoom travado, com
user-scalable=nooumaximum-scale=1: a pessoa não consegue ampliar com dois dedos. A MDN lembra que as diretrizes de acessibilidade WCAG exigem ampliação de pelo menos 2 vezes e que o recomendado é permitir 5. O Lighthouse reprovamaximum-scaleabaixo de 5. O iPhone ignora essas travas por padrão desde o iOS 10, mas não conte com isso nos outros navegadores.
Se a trava foi posta para a página não ampliar sozinha quando alguém toca num campo de formulário, o conserto é aumentar a letra dos campos, e não tirar o zoom de todo mundo.
Como testar se o site funciona no celular?
São seis passos, uns dez minutos por página, e nada para instalar além do Chrome. Os quatro primeiros acontecem no computador; os dois últimos, no seu celular e no Search Console.
-
Procure a viewport no código. No computador, com a página aberta, use Ctrl+U para ler o HTML e Ctrl+F para achar a palavra
viewport. Ela precisa aparecer uma vez, comwidth=device-width. A nossa verificação de meta tags faz essa leitura e também avisa se o zoom está travado. -
Ligue o modo de dispositivo. Aperte F12 e depois Ctrl+Shift+M (no Mac, Cmd+Shift+M). Deixe o tamanho em modo responsivo, recarregue a página e use a barra de larguras prontas, começando pela menor, de 320 pixels. Depois arraste a borda devagar e anote onde o layout quebra.
-
Descubra se algo passa da tela. Ainda no modo de dispositivo, vá até o Console, cole esta linha e aperte Enter:
document.documentElement.scrollWidth > document.documentElement.clientWidthSe a resposta for
false, nada passa da borda. Se fortrue, algum elemento está mais largo que a tela e vai obrigar a rolar para o lado. Na nossa página de teste, uma caixa de 600 pixels fez a largura total subir de 360 para 608 pixels, e a linha respondeutrue. Para achar o culpado, ligue o seletor de elementos (Ctrl+Shift+C) e passe o mouse pelo que encosta na borda direita. -
Rode o Lighthouse como celular. Na aba Lighthouse do DevTools, escolha o dispositivo móvel e marque Desempenho, Acessibilidade e Práticas recomendadas. Leia o insight da viewport, o aviso de zoom bloqueado e o de alvos de toque pequenos ou colados demais.
-
Pegue o celular de verdade. A própria documentação do Chrome chama o modo de dispositivo de aproximação: ele imita a tela, mas o código não roda num processador de celular. No aparelho, confira a lista abaixo.
-
Veja o que o Google recebeu. No Search Console, a Inspeção de URL faz um teste ao vivo do endereço publicado, e a captura de tela desse teste vem da versão de celular da página. Layout desmontado ali costuma indicar CSS que não carregou para o robô. O passo a passo dessa tela está no guia dos relatórios do Search Console.
No celular, em pé e deitado:
- o texto se lê sem ampliar;
- nenhuma tabela, imagem ou vídeo obriga a rolar para o lado;
- o menu abre, fecha e leva a todas as páginas que o menu do computador leva;
- dá para tocar em cada botão e link sem acertar o vizinho;
- o formulário funciona com o teclado aberto, sem campo escondido atrás dele;
- o aviso de cookies ou de cupom fecha com um toque e não cobre o conteúdo;
- o zoom de dois dedos funciona.
O que os 53 sites mostraram sobre a viewport?
A varredura que sustenta esta seção cobriu 53 sites .br e 302 páginas, entre iniciais e internas, lidas pelo Nota do Site de 20/10 a 22/10/2026. Sobre a viewport, o resultado foi este:
- Sem meta viewport: 1 das 53 páginas iniciais (1,9%); somando as internas, 8 das 302 páginas (2,6%), espalhadas por 4 sites.
- Viewport sem
width=device-width: 1 página inicial. - Zoom travado: 2 páginas iniciais; 14 páginas no total (4,6%).
A falta da tag é rara, porque quase todo tema, construtor e plataforma já a escreve sozinho. A armadilha está nas contas: só uma página inicial estava sem viewport, mas as 8 páginas sem ela ficaram em 4 sites. Logo, pelo menos 3 sites tinham a página inicial certa e alguma página interna sem a tag. Testar só a página inicial teria aprovado os três. Com o zoom, a distância entre a vitrine e o resto do site é maior: a trava aparece em 2 páginas iniciais e em 14 páginas no total.
Desconfie das páginas montadas fora do modelo principal do site, como landing pages de campanha, blogs antigos e sistemas de agendamento ou de pedido. Quando a página usa outro modelo, o <head> dela não recebe as correções feitas no modelo principal.
O que mais quebra no celular, mesmo com a viewport certa?
Com a tag no lugar, os problemas passam a ser de conteúdo e de CSS. Estes são os pontos para olhar com calma depois do teste no aparelho:
- Imagem, vídeo e tabela de largura fixa. A web.dev recomenda
max-width: 100%nas imagens e manter largura e altura no HTML, para reservar o espaço. Para tabela larga, coloque-a dentro de um bloco comoverflow-x: auto: só ela rola, e a página fica parada. A escolha do arquivo certo para cada tela, comsrcset, está no guia de formato e tamanho das imagens. - Menu do celular mais curto que o do computador. Se o menu do celular corta páginas, os links para elas somem da versão que o Google lê.
- Texto que some no celular. Em site com versão m. ou com HTML diferente por aparelho, a versão de celular pode sair sem as avaliações, sem a tabela de medidas ou com parágrafos a menos. Pelo que o Google pede, o conteúdo tem de ser o mesmo nas duas.
- Pop-up cobrindo a página. Evitar intersticiais invasivos é outra das perguntas de experiência da página do Google.
- Edição separada para o celular. No Wix, o recurso de ocultar elementos só no Editor mobile serve para enfeite, e não para texto ou links que você quer no Google.
Quais páginas abrir no celular primeiro?
Três por site bastam para começar. No Search Console, em Desempenho, filtre por dispositivo e pegue a página que mais recebe cliques de celular.
Some a ela a página que gera contato ou venda e uma página feita fora do modelo, como uma landing page de campanha. Nas três, faça a busca pela viewport, rode a linha do console no modo de dispositivo e passe pela lista no seu celular. Para conferir a viewport de várias páginas de uma vez, a análise gratuita lê até 10 páginas do site com uma conta grátis.