Teste de compatibilidade com dispositivos móveis: como verificar seu site agora que a ferramenta do Google acabou

Resumo: o Google aposentou o Teste de Compatibilidade com Dispositivos Móveis (Mobile-Friendly Test), a API do teste e o relatório de Usabilidade em dispositivos móveis do Search Console em 1º de dezembro de 2023. O mobile não perdeu importância: o Google rastreia e indexa sites apenas com o rastreador de smartphone, e o conteúdo que não pode ser acessado em um celular não é indexável. Para testar um site hoje, verifique o básico (tag viewport, imagens que se ajustam, texto legível, áreas de toque) com um verificador rápido e o Lighthouse, veja a página em celulares reais e confirme que a versão mobile tem o mesmo conteúdo que a desktop.

Por anos, "teste de compatibilidade com dispositivos móveis" significava uma coisa só: colar uma URL na ferramenta do Google e receber o aviso verde "A página está otimizada para dispositivos móveis". Essa ferramenta não existe mais, e muitos guias ainda linkam para ela. Este artigo explica o que aconteceu, o que o Google espera hoje das páginas mobile, como testá-las com ferramentas que ainda funcionam, incluindo nosso teste de site para celular gratuito, e como corrigir cada problema.

O que aconteceu com o Mobile-Friendly Test do Google

Em uma publicação de abril de 2023 sobre experiência da página, o Google anunciou: "Also starting December 1, 2023, we'll be retiring Search Console's 'Mobile Usability' report, the Mobile-Friendly Test tool and Mobile-Friendly Test API." O motivo apresentado não foi que o mobile deixou de importar. O Google observou que surgiram muitos recursos robustos para avaliar a usabilidade mobile, "including Lighthouse from Chrome".

Assim, desde dezembro de 2023 não existe um "aprovado ou reprovado" oficial do Google para compatibilidade com mobile. Verificadores de terceiros, o Lighthouse e seus próprios testes preenchem essa lacuna.

Por que o mobile ainda define como você é indexado

Dois anúncios importam mais do que a ferramenta aposentada:

1. A indexação mobile-first foi concluída. Em outubro de 2023, o Google escreveu que "the trek to Mobile First Indexing is now complete" (anúncio). A página de boas práticas define o que isso significa: "Google uses the mobile version of a site's content, crawled with the smartphone agent, for indexing and ranking."
2. O rastreamento desktop acabou na Busca. Em junho de 2024, o Google disse: "After July 5, 2024, we'll crawl and index these sites with only Googlebot Smartphone" e "If your site's content is not accessible at all with a mobile device, it will no longer be indexable" (anúncio).

A consequência prática: o que a sua versão mobile mostra é a sua página, no que diz respeito ao Google. Texto oculto no mobile, uma seção ausente ou um título diferente no template mobile é o que acaba indexado.

A experiência da página acrescenta uma segunda camada. As orientações de experiência da página do Google perguntam "Does your content display well on mobile devices?" e dizem que seus principais sistemas de ranqueamento "look to reward content that provides a good page experience", enfatizando que não existe um único sinal de experiência da página.

O que significa "compatível com mobile" na prática

Não há mais uma lista oficial, mas a documentação do Google e o web.dev cobrem o essencial:

O Google recomenda o design responsivo "because it's the easiest design pattern to implement and maintain". Uma URL, um documento HTML, CSS que se adapta: os problemas de paridade praticamente desaparecem.

Como testar a compatibilidade com mobile hoje

Use várias ferramentas, porque cada uma enxerga uma parte diferente do quadro:

1. Uma verificação rápida do básico. Nosso teste de site para celular gratuito verifica a tag viewport, imagens responsivas, favicon e idioma da página em cerca de 20 segundos (detalhes abaixo).
2. Lighthouse no Chrome. Execute-o pelo DevTools com a configuração mobile. Desde o Lighthouse 13 (outubro de 2025), a verificação de viewport fica no insight "Optimize viewport for mobile", e a antiga auditoria de tamanho de fonte legível foi removida sem substituto.
3. Modo de dispositivo do Chrome DevTools. Arraste a largura a partir de 320 px e observe barras de rolagem horizontais, elementos sobrepostos e texto que transborda da caixa.
4. Celulares reais. Use pelo menos um Android pequeno e um iPhone. Teste o menu, os formulários e o checkout com o polegar.
5. Inspeção de URL do Search Console. O teste ao vivo mostra uma captura da página como o Googlebot Smartphone a renderiza, além do HTML renderizado, para confirmar que o conteúdo importante está lá.
6. Dados de velocidade de usuários reais. Core Web Vitals de visitantes em celular, do Chrome User Experience Report. Nosso guia de Core Web Vitals explica como interpretá-los.

Como funciona o teste de site para celular da Searvia

O teste de site para celular gratuito executa nossa auditoria completa do site (38 verificações) e coloca as quatro verificações mobile no topo. Informe um domínio ou o endereço de uma página e ele busca essa página (a página inicial, se você informar só o domínio), seguindo redirecionamentos, e lê o HTML que seu servidor envia, sem executar JavaScript.

Alguns detalhes sobre como ele avalia:

• A verificação de viewport falha em vez de apenas alertar porque uma página sem tag viewport fica quebrada em qualquer celular, não só um pouco pior.
• Para favicons, o /favicon.ico de reserva só conta se retornar um arquivo de verdade, não uma página de erro em HTML.
• A verificação de idioma mostra as duas primeiras letras do código, então en-GB aparece como "en".

O relatório completo também inclui a seção de velocidade, em que a verificação de Core Web Vitals lê o LCP, INP e CLS no percentil 75 para visitantes em celular, a partir dos dados de usuários reais do Chrome: para a página informada, quando o Chrome tem dados suficientes, ou para o site inteiro, caso contrário.

O que ele não faz: não renderiza a página em um navegador do tamanho de um celular, então não enxerga overflow horizontal, tamanhos de fonte, espaçamento de áreas de toque nem pop-ups. Para isso servem o Lighthouse, o modo de dispositivo e os celulares reais. Pense no verificador como a triagem de cinco minutos e nos testes manuais como a inspeção.

Como interpretar os resultados

• Viewport com falha: corrija primeiro; nada mais na página importa até o layout caber na tela.
• Alerta de imagens responsivas: os celulares estão baixando imagens do tamanho do desktop. Não está quebrado, mas é mais lento, especialmente em redes móveis.
• Alertas de favicon ou idioma: correções pequenas e rápidas que melhoram como você aparece nos resultados do Google e como leitores de tela tratam a página.
• "Too few images to judge": neutro. Com menos de três imagens, a proporção diz pouco.

Como corrigir cada problema

"The page has no mobile viewport tag."

1. Adicione esta linha dentro do <head> de todos os templates:

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

1. Não adicione user-scalable=no nem um maximum-scale baixo. O web.dev desaconselha ambos "because they can prevent the user from zooming."
2. Confira se há apenas uma tag viewport. Um tema e um plugin podem imprimir uma cada; a segunda pode sobrescrever a primeira.
3. Recarregue em um celular. Se a página agora mostra um layout de desktop apertado em vez de minúsculo, a viewport funciona e o CSS precisa de regras responsivas (veja abaixo).

Tornando o layout responsivo

A tag viewport apenas diz ao navegador para usar a largura da tela. O CSS ainda precisa se adaptar:

• Dê às imagens e vídeos max-width: 100%; height: auto; para que nunca transbordem.
• Use larguras flexíveis (porcentagens, fr, min()) em vez de larguras fixas em pixels para os contêineres.
• Adicione media queries onde o design quebra, não em larguras de dispositivos específicos. web.dev: "Design the content to fit on a small screen size first, then expand the screen until a breakpoint becomes necessary."
• Envolva tabelas largas em um contêiner com rolagem em vez de deixar a página rolar para o lado.

"N of M images use srcset."

Ofereça vários tamanhos e deixe o navegador escolher, como descrito na MDN:

<img
  src="/img/boots-800.jpg"
  srcset="/img/boots-480.jpg 480w, /img/boots-800.jpg 800w, /img/boots-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 50vw"
  alt="Brown leather hiking boots on a wet rock"
  width="800" height="600">

srcset lista os arquivos e suas larguras; sizes diz ao navegador qual será a largura da imagem na tela. Para imagens de tamanho fixo, como logotipos, use descritores x (logo.png, logo@2x.png 2x). O WordPress adiciona srcset automaticamente às imagens inseridas pelo editor; a maioria das CDNs de imagem gera os tamanhos para você. Adicione também width e height, para que o navegador reserve espaço e o layout não dê saltos.

"No favicon was found."

1. Crie um ícone quadrado. O Google exige proporção 1:1, no mínimo 8 × 8 px, e recomenda mais de 48 × 48 px (diretrizes de favicon).
2. Adicione-o ao head da página inicial:

<link rel="icon" href="/favicon.ico" sizes="48x48">
<link rel="icon" href="/favicon.svg" type="image/svg+xml">
<link rel="apple-touch-icon" href="/apple-touch-icon.png">

1. Mantenha a URL estável e garanta que o robots.txt não bloqueie o arquivo; o Google precisa rastrear tanto a página inicial quanto o ícone. O Google aceita um favicon por hostname.

"The page does not declare its language."

Defina o idioma no elemento raiz:

<html lang="en">

Use um código BCP 47 válido, como en, en-GB, pt-BR ou tr. O atributo lang permite que leitores de tela pronunciem o texto corretamente e é exigido pelo critério "Language of Page" da WCAG (MDN). Um esclarecimento: o Google diz que detecta o idioma da página pelo próprio texto, não pelo lang, então isso é mais uma correção de acessibilidade e de navegador do que de ranqueamento.

Além das quatro verificações

Depois que o básico passar, trabalhe nos pontos que nenhum verificador automático cobre por completo:

• Paridade de conteúdo. Compare mobile e desktop para a mesma URL: texto principal, títulos, imagens com o mesmo texto alternativo, dados estruturados, title, meta description e meta tags robots. O Google lista tudo isso em suas boas práticas de mobile-first.
• Lazy loading. O Google alerta: "Don't lazy-load primary content upon user interaction." O Googlebot não toca em "Ler mais" nem desliza carrosséis.
• Áreas de toque. Botões e links de cerca de 48 × 48 px com espaço entre eles. O Lighthouse sinaliza áreas menores que 48 × 48 px quando se sobrepõem a vizinhas.
• Tamanho do texto. Texto do corpo legível sem zoom. O Lighthouse não audita mais o tamanho da fonte, então confira em um celular real.
• Pop-ups. Banners de cookies e formulários de newsletter que cobrem o conteúdo em tela pequena entram na questão dos intersticiais intrusivos do Google.
• Velocidade em celulares. CPUs e redes de celular são mais lentas; verifique os dados de campo de mobile separadamente dos de desktop.

Se você mantém um site mobile separado

Alguns sites mais antigos servem celulares a partir de outro endereço, como m.example.com, ou enviam HTML diferente para celulares na mesma URL (dynamic serving, ou veiculação dinâmica). O Google ainda aceita ambos, mas eles dificultam a paridade, e suas boas práticas acrescentam regras extras para URLs separadas:

• O status de erro deve ser o mesmo nas duas versões: uma página que retorna 404 no desktop não deve retornar 200 no mobile, e vice-versa.
• A versão mobile não deve usar fragmentos de URL (#) para o conteúdo.
• As regras do robots.txt devem coincidir, para que o Googlebot rastreie as mesmas seções nos dois hosts.
• As páginas desktop apontam para as versões mobile com rel="alternate", e as páginas mobile apontam de volta com rel="canonical".
• O hreflang precisa ser configurado separadamente para cada versão.

Se você já está planejando um redesign, migrar para um design responsivo em uma única URL elimina toda essa categoria de problemas. Nosso verificador gratuito lê a versão que seu servidor envia ao próprio rastreador, então, em um site com dynamic serving, teste a versão para celular separadamente com o Lighthouse ou a Inspeção de URL.

Exemplo prático (hipotético)

O exemplo a seguir é hipotético, não são dados reais. A Cobble & Crumb, uma padaria inventada com um site codificado à mão em 2016, vê a maioria das visitas chegar por celulares e poucos pedidos em seguida. O teste de site para celular informa:

• Viewport mobile, falha: sem tag viewport.
• Imagens responsivas: 1 de 14 imagens usa srcset.
• Favicon: aprovado.
• Idioma da página, alerta: sem atributo lang.

O dono adiciona a tag viewport e lang="en", e abre o site em um celular: o texto agora está em tamanho normal, mas o contêiner de largura fixa de 960 px força a rolagem lateral. Um desenvolvedor troca a largura fixa por max-width: 960px; width: 100%, adiciona max-width: 100% às imagens, empilha o menu de três colunas em uma coluna abaixo de 600 px e aumenta os botões de pedido para 48 px de altura. As fotos dos produtos ganham srcset com versões de 480, 800 e 1600 px. Uma segunda execução aprova viewport e idioma, as imagens responsivas agora passam com 13 de 14, e o insight de viewport do Lighthouse está limpo. O trabalho restante é de conteúdo: o layout mobile tinha escondido o horário de funcionamento, que volta para a página.

Um checklist mobile de 30 minutos

1. Execute o teste de site para celular e corrija primeiro uma tag viewport ausente.
2. Abra suas cinco principais páginas em um celular real. Procure rolagem lateral, texto minúsculo e botões difíceis de acertar.
3. Execute o Lighthouse em modo mobile nas mesmas páginas.
4. Compare o conteúdo mobile e desktop de cada template de página.
5. Adicione srcset às imagens grandes, um favicon e o atributo lang.
6. Confira as Core Web Vitals em celular e corrija o template mais lento.

Como a Searvia ajuda você a se manter pronto para mobile

O teste de site para celular gratuito verifica o básico na sua página inicial, ou em qualquer página que você informar, em cerca de 20 segundos, sem cadastro, junto com outras 34 verificações de aparência na busca, rastreamento, preparo para busca com IA, velocidade e segurança.

Para monitoramento contínuo, uma conta gratuita da Searvia adiciona o acompanhamento de velocidade de página: notas de laboratório e dados reais de usuários do Chrome para suas páginas mais visitadas, reavaliadas toda semana, com correções ordenadas pelo tempo estimado economizado. A auditoria do site rastreia todas as páginas em busca de problemas que prejudicam tanto o mobile quanto o desktop, como títulos ausentes, links quebrados e conteúdo raso. Para o restante da checklist técnica, veja nosso guia de auditoria de SEO técnico.