Como testar se um site é mobile friendly agora que o Teste de Compatibilidade com Dispositivos Móveis do Google acabou
Para verificar se um site é mobile friendly agora que o Mobile-Friendly Test do Google acabou, combine quatro métodos: Lighthouse (no Chrome DevTools ou pelo PageSpeed Insights) para uma auditoria detalhada com emulação de celular, modo dispositivo do DevTools para ver a página com 360–430 px de largura, um celular de verdade para pegar o que a emulação deixa passar, e nosso Mobile-Friendly Test para uma verificação rápida, sem cadastro, do código da página (meta viewport, media queries, larguras fixas, texto pequeno e áreas de toque), junto com uma captura de tela em iPhone.
A seguir: o que exatamente o Google desativou, o que usar no lugar, um checklist de 15 minutos e correções prontas para copiar e colar para os problemas mais comuns.
O que aconteceu com o Mobile-Friendly Test do Google
Em dezembro de 2023, o Google desativou três coisas de uma vez: o próprio Mobile-Friendly Test, sua API e o relatório de Usabilidade em dispositivos móveis do Search Console. O endereço antigo search.google.com/test/mobile-friendly agora redireciona para a visão geral do Lighthouse, a indicação do Google para o substituto.
A ferramenta saiu, mas a exigência continua. O Google ainda indexa os sites com seu rastreador para smartphones, então a usabilidade em dispositivos móveis importa tanto quanto antes. Só que o Google não oferece mais um veredito pronto de "a página é mobile friendly", então você precisa verificar por conta própria.
Comparação de alternativas ao Mobile-Friendly Test do Google
| Método | O que mostra | Executa JavaScript | Use para |
|---|---|---|---|
| Lighthouse no Chrome DevTools | Auditoria com emulação de celular: desempenho, acessibilidade, SEO, boas práticas, incluindo meta viewport ausente | Sim, um navegador real | Análise detalhada de uma página, inclusive páginas atrás de login ou em localhost |
| PageSpeed Insights | O mesmo Lighthouse na nuvem, mais dados de usuários reais do Chrome (LCP, INP, CLS) quando o Google tem dados suficientes | Sim | Velocidade no celular e Core Web Vitals |
| Modo dispositivo do DevTools | A página em uma largura de tela escolhida, com limitação opcional de rede e CPU | Sim | Identificar overflow, sobreposições e elementos em que não dá para tocar |
| Um celular de verdade | Toque real, teclado, fontes do sistema e barras do navegador | Sim | Verificação final de formulários, menus e pop-ups |
| Nosso Mobile-Friendly Test | 8 verificações de HTML e CSS com pesos transparentes, nota de 0 a 100 e captura de tela em iPhone | Não | Verificação rápida de qualquer URL, sem instalar nada |
O modo dispositivo é o ícone de celular e tablet no DevTools, ou Ctrl+Shift+M (Cmd+Shift+M no Mac). Veja a documentação do Chrome para mais detalhes.
Como verificar se um site é mobile friendly: passo a passo
- Comece pelo código. Passe a página pelo Mobile-Friendly Test. Viewport ausente, um wrapper de 960–1200 px ou zoom desativado aparecem imediatamente, antes mesmo de você abrir um navegador.
- Veja no DevTools. Ative o modo dispositivo e teste 360 px (celulares Android estreitos comuns) e 390–430 px (iPhones recentes). Role a página inteira: há barra de rolagem horizontal, texto cortado, blocos sobrepostos?
- Execute o Lighthouse no modo móvel. Aba Lighthouse → Dispositivo: Móvel → Analisar carregamento da página. Leia cada achado com as referências de elementos, não apenas as notas.
- Verifique a velocidade no PageSpeed Insights. Se o relatório mostrar no topo uma seção de dados de usuários reais, é isso que o Google enxerga. Se não mostrar, o site tem pouco tráfego no Chrome, e os números de laboratório são seu guia.
- Abra a página em um celular de verdade. Preencha um formulário, abra o menu, feche o pop-up, gire a tela. A emulação não vai avisar que o polegar erra o botão de fechar ou que o teclado cobre o campo de entrada.
- Teste vários tipos de página. As home pages costumam ser bem cuidadas; os problemas se escondem em páginas de produto, artigos antigos com tabelas largas e templates de blog.
- Compare o conteúdo do celular e do desktop. Texto, títulos, links, dados estruturados e atributos alt devem estar presentes em ambos.
Problemas comuns e como corrigi-los
Sem meta viewport
Sem essa tag, o celular monta a página com cerca de 980 px de largura e a reduz, deixando todo o texto minúsculo. Adicione isto ao <head>:
<meta name="viewport" content="width=device-width, initial-scale=1">Não use user-scalable=no nem maximum-scale=1: bloquear o zoom prejudica pessoas com baixa visão, e nossa ferramenta desconta pontos por isso.
Layouts de largura fixa
O clássico dos templates antigos é width: 960px no wrapper: uma barra de rolagem horizontal garantida no celular. Limite a largura:
.container { max-width: 1200px; width: 100%; margin: 0 auto; padding: 0 16px; box-sizing: border-box; }
img, video, iframe { max-width: 100%; height: auto; }Tabelas largas
Uma tabela de seis colunas nunca vai caber em 360 px. A solução mais simples é deixá-la rolar dentro da própria caixa, em vez de quebrar a página inteira:
<div class="table-wrap"><table>…</table></div>
.table-wrap { overflow-x: auto; -webkit-overflow-scrolling: touch; }Se houver muitas colunas e os dados forem importantes, transforme as linhas em cards em telas estreitas usando uma media query.
Texto pequeno e áreas de toque pequenas
Use texto do corpo em torno de 16 px e unidades rem. Para áreas de toque, o critério de sucesso 2.5.8 do WCAG 2.2 pede pelo menos 24×24 px CSS, e o Material Design recomenda cerca de 48×48 com espaçamento entre links vizinhos:
html { font-size: 100%; } /* 16px by default */
body { font-size: 1rem; line-height: 1.5; }
.nav a, button { min-height: 48px; padding: 12px 16px; display: inline-flex; align-items: center; }Media queries para telas estreitas
Layouts com várias colunas devem se reduzir a uma única coluna no celular:
.grid { display: grid; grid-template-columns: repeat(3, 1fr); gap: 24px; }
@media (max-width: 768px) {
.grid { grid-template-columns: 1fr; }
}Pop-ups em tela cheia
As orientações do Google dizem para não cobrir a página inteira com um interstitial, a menos que seja exigido por lei (consentimento de cookies, verificação de idade). Mostre avisos de newsletter ou de instalação de app como um banner pequeno que não bloqueie a leitura.
Tecnologias legadas
Flash, applets Java e framesets não funcionam em celulares. Substitua-os por vídeo HTML5, layout normal e páginas separadas.
Por que isso importa: indexação mobile-first
O Google usa a versão mobile do conteúdo de um site, rastreada com o agente de smartphone, para indexação e ranqueamento. Isso não significa que um site sem layout responsivo desaparece da busca: o Google diz que uma versão mobile não é obrigatória, mas é muito fortemente recomendada. A conclusão prática é outra: o que o celular vê é o que é indexado. Se a versão mobile corta texto, esconde links ou remove dados estruturados, a busca também não os recebe. Saiba mais no nosso artigo sobre indexação mobile-first.
Core Web Vitals no mobile
Usabilidade inclui velocidade. O Google recomenda um LCP (carregamento do conteúdo principal) em até 2,5 segundos, um INP (capacidade de resposta) abaixo de 200 milissegundos e um CLS (mudança de layout) abaixo de 0,1. Em celulares, esses números quase sempre são piores do que no desktop: CPUs mais lentas, redes mais lentas. Confira a aba mobile no PageSpeed Insights e o relatório Core Web Vitals no Search Console, que separa URLs mobile e desktop. O significado de cada métrica é explicado em Core Web Vitals; por onde começar para acelerar o site, em velocidade de carregamento da página.
Como executar a verificação no nosso Teste de otimização para dispositivos móveis
Digite uma URL no Teste de otimização para dispositivos móveis. A ferramenta carrega o HTML com um user agent de celular Android, lê até seis folhas de estilo do seu próprio domínio e executa oito verificações. Cada uma vale um número fixo de pontos, e os pesos são exibidos na página:
| Verificação | Pontos | O que ela analisa |
|---|---|---|
| Meta viewport | 30 | Se a tag existe e usa width=device-width |
| CSS responsivo | 20 | Media queries baseadas em largura; flex, grid ou clamp sem elas recebem pontos parciais |
| Larguras fixas | 10 | Regras de CSS e estilos inline com width acima de 480 px |
| Risco de rolagem horizontal | 10 | Atributos de largura grandes, imagens sem max-width, layouts com tabelas aninhadas |
| Tamanho da fonte | 10 | Fonte base abaixo de 12 px, muitas regras abaixo de 11 px |
| Áreas de toque | 10 | Links e botões com fonte minúscula ou tamanho abaixo de 24 px em estilos inline |
| Zoom | 5 | user-scalable=no ou maximum-scale abaixo de 2 |
| Plugins legados | 5 | Flash, Java, frames |
Junto com os resultados, você recebe uma captura de tela em emulação de iPhone. Se ela mostrar texto cortado ou uma barra de rolagem, confie na captura e não na pontuação. Sinais de pop-up e peso da página aparecem como dicas e não afetam a pontuação. Sem conta, você tem 15 verificações por dia, 45 com uma conta gratuita e sem limite no Pro.
Outras ferramentas que ajudam
- Captura de tela do site: capturas mobile e desktop para mostrar o problema a um desenvolvedor ou comparar antes e depois. Como interpretá-las: captura de tela de site online.
- Analisador de velocidade da página: peso de HTML, imagens, CSS e JS, além do tempo de carregamento. Imagens pesadas são um motivo frequente de lentidão em páginas mobile.
- Search Console: o relatório de Core Web Vitals com dados separados para mobile e desktop.
