Checklist de SEO para dispositivos móveis

TL;DR — SEO para dispositivos móveis agora é apenas SEO. O Google indexa e classifica seu site usando a versão móvel das suas páginas, então a lista de verificação se resume a três coisas: certifique-se de que suas páginas móveis tenham o mesmo conteúdo que as de desktop, certifique-se de que carreguem rápido e sejam responsivas no celular, e certifique-se de que sejam fáceis de usar com o polegar. E ignore o antigo Teste de Compatibilidade com Dispositivos Móveis — o Google o matou.

Evidence for this claim Google predominantly uses the mobile version of a site's content for indexing and ranking. Scope: Google mobile-first indexing behavior. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile-first indexing Evidence for this claim Google recommends responsive web design as the easiest mobile configuration to implement and maintain. Scope: Google's implementation recommendation; other supported configurations can work. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile site configurations

Por que o SEO para dispositivos móveis é o jogo todo agora

Por anos, “SEO para dispositivos móveis” foi um projeto paralelo — você otimizava para desktop e depois garantia que o site não parecia quebrado no celular. Isso acabou. Desde julho de 2024, o Google usa apenas a versão móvel da sua página para decidir como você ranqueia, para todos — inclusive para pessoas pesquisando em desktop. Se a versão para celular for pior que a versão para desktop, essa versão pior é a que o Google usa para avaliar você.

Então, a lista de verificação moderna de SEO para dispositivos móveis é curta de dizer e importante de acertar:

1. Mesmo conteúdo no celular e no desktop (“paridade de conteúdo”)

Esta é a grande. Tudo o que você quer que o Google veja — seus títulos, seu texto corpo, suas imagens e seus textos alternativos, seus links internos, seus dados estruturados — precisa estar presente na versão móvel da página. Se o seu template móvel silenciosamente remove uma seção, esconde um parágrafo removendo-o da página (não apenas recolhendo-o), ou corta seus links internos, o Google pode nunca ver esse conteúdo.

Esconder conteúdo dentro de abas ou acordeões no celular é ok — o Google ainda o lê contanto que esteja realmente no código da página. O problema é conteúdo que está verdadeiramente ausente.

2. Velocidade e responsividade no celular (Core Web Vitals)

O Google mede três “Core Web Vitals” separadamente para celular e desktop:

• LCP — quão rápido o maior elemento na tela carrega (mire em 2,5 segundos ou menos).
• INP — quão rapidamente a página reage quando você toca (mire em 200 milissegundos ou menos).
• CLS — o quanto a página pula enquanto carrega (mire em 0,1 ou menos).

O celular geralmente pontua pior que o desktop porque os celulares têm redes mais lentas e chips mais lentos. O erro mais comum e mais prejudicial: carregamento preguiçoso da sua imagem hero principal. Não faça isso. Carregue preguiçosamente imagens abaixo da dobra, nunca a grande no topo.

3. Fácil de usar com o polegar

• Uma tag viewport correta para a página caber na tela: <meta name="viewport" content="width=device-width, initial-scale=1">.
• Alvos de toque grandes o suficiente para acertar — cerca de 48×48 pixels, com um pouco de espaço entre eles.
• Texto do corpo com pelo menos 16px para ninguém precisar dar zoom com pinça.
• Nenhum pop-up gigante cobrindo a página no momento em que alguém chega da busca.

As ferramentas que você conhece se foram

Se um guia diz para você “executar o Teste de Compatibilidade com Dispositivos Móveis do Google”, ele está desatualizado. O Google aposentou essa ferramenta e o relatório de Usabilidade em Dispositivos Móveis no Search Console em dezembro de 2023. Use estes em vez disso: PageSpeed Insights (pagespeed.web.dev), Lighthouse no Chrome, a ferramenta Inspeção de URL no Search Console e o relatório Core Web Vitals.

Quer a versão completa da auditoria — casos extremos de paridade de conteúdo, a armadilha de carregamento preguiçoso do LCP com a própria admissão do Google, INP vs. a antiga métrica FID, isenções de intersticiais, a realidade do AMP e como o Bing difere? Mude para a aba Avançado.

TL;DR — A indexação mobile-first está concluída (finalizada em 5 de julho de 2024) — o Google usa seu HTML mobile para ranquear você em todas as consultas e em todos os dispositivos. Portanto, o checklist é: (1) paridade de conteúdo — mesmo texto do corpo, títulos/descrições, cabeçalhos, imagens, texto alternativo, links internos e dados estruturados no mobile e no desktop; (2) Core Web Vitals no mobile — LCP ≤ 2,5 s (nunca use lazy-load na imagem LCP), INP ≤ 200 ms (o INP substituiu o FID em 12 de março de 2024), CLS ≤ 0,1; (3) usabilidade — viewport correto, alvos de toque de 48×48 px, fonte ≥16 px, sem intersticiais intrusivos (com isenções reais); (4) auditoria com ferramentas atuais — Lighthouse, PageSpeed Insights, URL Inspection e o relatório CWV, porque o Mobile-Friendly Test e o relatório de usabilidade mobile do GSC foram descontinuados em dezembro de 2023. O design responsivo é a configuração recomendada pelo Google. O AMP não oferece vantagem de ranqueamento desde junho de 2021. O Bing não usa indexação mobile-first.

Evidence for this claim Google predominantly uses the mobile version of a site's content for indexing and ranking. Scope: Google mobile-first indexing behavior. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile-first indexing Evidence for this claim Google recommends responsive web design as the easiest mobile configuration to implement and maintain. Scope: Google's implementation recommendation; other supported configurations can work. Confidence: high · Verified: 2026-07-14 Google Search Central: Mobile site configurations

A base: a indexação mobile-first está concluída

Este é o contexto que faz todo o resto fazer sentido. O Google anunciou a conclusão da maior parte da indexação mobile-first em outubro de 2023, e a aplicação final ocorreu em 5 de julho de 2024: qualquer site que não estivesse acessível ao Googlebot Smartphone simplesmente deixou de ser indexado. Não existe mais rastreamento desktop-first.

A implicação é a que as pessoas ainda subestimam: a versão mobile da sua página é a versão que determina seus ranqueamentos para todas as consultas, em todos os dispositivos — incluindo pesquisas no desktop. Você não está otimizando “uma experiência mobile” à parte; você está otimizando a versão canônica do seu site.

1. Paridade de conteúdo — o requisito técnico nº 1

Se você corrigir uma coisa nesta lista, corrija esta. A orientação do Google é explícita: “Make sure that your mobile site contains the same content as your desktop site.” (tradução) «Garanta que seu site mobile contenha o mesmo conteúdo que seu site desktop.» Isso significa que cabeçalhos, texto do corpo, imagens, texto alternativo e links internos precisam corresponder entre as versões, e “Make sure that the title element and the meta description are equivalent across both versions.” (tradução) «Garanta que o elemento de título e a meta description sejam equivalentes em ambas as versões.»

Verificações práticas de paridade:

• Conteúdo do corpo presente no mobile, não removido por um template mobile mais enxuto.
• Títulos e meta descriptions equivalentes entre as versões.
• Cabeçalhos (a mesma estrutura H1/H2) presentes no HTML mobile.
• Imagens com o mesmo texto alternativo descritivo, legendas e nomes de arquivo que no desktop.
• Links internos presentes no mobile — não remova seu grafo de links em uma navegação mobile “simplificada”.
• Não faça “lazy-load primary content upon user interaction” (tradução) «lazy-load de conteúdo primário mediante interação do usuário» — se o conteúdo só aparecer após um toque, o Google pode não vê-lo.

Duas nuances de paridade que valem a pena internalizar: abas e accordions são aceitáveis. Conteúdo reorganizado em UI recolhível ainda é indexado desde que esteja no DOM — o mito de que esconder conteúdo em accordions prejudica o SEO é apenas isso. O modo real de falha é conteúdo removido completamente da marcação no mobile. E as meta tags robots devem corresponder — “Use the same robots meta tags on the mobile and desktop site” (tradução) «Use as mesmas meta tags robots no site mobile e no desktop» — ou você pode acidentalmente noindex a versão que o Google realmente usa.

2. Paridade de dados estruturados

Mesma regra, aplicada ao schema. A orientação do Google de dezembro de 2018: “If you use structured data on the desktop versions of your pages, you should have the same structured data on the mobile versions of the pages, since with mobile-first indexing, we’ll only use the mobile version of your page for indexing.” (tradução) «Se você usa dados estruturados nas versões desktop das suas páginas, você deve ter os mesmos dados estruturados nas versões mobile das páginas, pois com a indexação mobile-first, usaremos apenas a versão mobile da sua página para indexação.» Valide-os com o Rich Results Test (ainda ativo — não descontinuado). Para configurações de URL separada (m-dot), as URLs dentro dos seus dados estruturados devem referenciar as URLs mobile corretas.

3. Rastreabilidade e robots

• Não bloqueie recursos (CSS, JS) em robots.txt que sejam necessários para renderizar a página móvel — se o Google não conseguir renderizá-la, ele não verá sua paridade.
• Meta tags de robots idênticas entre as versões (acima).
• Para URLs separadas, acerte a canonicalização: a canonical de desktop nas duas versões, rel="alternate" no desktop apontando para a URL móvel.

4. Core Web Vitals no mobile

O Google mede o CWV “segmentado entre dispositivos móveis e desktop” no 75º percentil, e “Core Web Vitals são usados pelos nossos sistemas de ranqueamento.” O mobile é onde a diferença aparece — redes e CPUs mais lentas significam que aproximadamente 48% das páginas móveis passam em os três vs. ~56% no desktop, com LCP e INP impulsionando a diferença.

Os limites (bom / precisa melhorar / ruim):

• LCP — ≤ 2,5 s / 2,5–4,0 s / > 4,0 s.
• INP — ≤ 200ms / 200–500ms / > 500ms.
• CLS — ≤ 0,1 / 0,1–0,25 / > 0,25.

LCP — nunca faça lazy-load da imagem hero. Este é o erro de performance mobile mais destrutivo, e está em toda parte. O web.dev é direto: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (tradução) «Nunca faça lazy-load da sua imagem LCP, pois isso sempre levará a um atraso desnecessário no carregamento de recursos e terá um impacto negativo no LCP.» Em vez disso, indique prioridade com fetchpriority="high" (um preload ou diretamente no <img>). O próprio Martin Splitt, do Google, admitiu que o Google enviou esse bug: o CMS deles “defaults all images to lazy loading, which is not great.” (tradução) «define todas as imagens como lazy loading, o que não é ótimo.» Se o Google pode fazer isso por acidente, você também pode.

INP — e por que não é FID. O INP (Interaction to Next Paint) substituiu o FID em 12 de março de 2024. O FID media apenas o atraso antes que o navegador pudesse começar a processar a primeira interação; o INP mede o pior atraso de interação ao longo de toda a vida útil da página. Isso o torna muito mais sensível a JavaScript lento no mobile, onde eventos de toque em CPUs fracas ultrapassam facilmente o limite de 200 ms. Se suas notas de auditoria mais antigas ainda falam sobre FID, elas estão desatualizadas.

CLS — reserve espaço. Defina width e height explícitos (ou aspect-ratio) em imagens e embeds, reserve espaço para anúncios e conteúdo de carregamento tardio, e não injete conteúdo acima da dobra após o carregamento.

5. Imagens e vídeos no mobile

• Use formatos modernos (WebP/AVIF) e apenas formatos suportados — um JPG dentro de SVG inline não será indexado.
• Imagens responsivas via srcset + sizes; width/height explícitos para evitar CLS.
• Não use imagens muito pequenas ou de baixa resolução, e evite URLs de imagem que mudam constantemente (a geração de URL por carregamento de página quebra a indexação de imagens).
• Texto alternativo, títulos, legendas e nomes de arquivo idênticos ao desktop.
• Vídeos: formatos suportados em tags HTML válidas (<video>, <embed>, <object>), URLs estáveis, dados estruturados de vídeo correspondentes, colocados em destaque para minimizar a rolagem.

6. Usabilidade mobile

• Viewport: <meta name="viewport" content="width=device-width, initial-scale=1">. width=device-width é obrigatório. Evite maximum-scale=1 ou user-scalable=no — eles bloqueiam o pinch-zoom e o Google os sinaliza como violações de acessibilidade. Sem nenhuma tag de viewport, os navegadores móveis renderizam em ~980px de largura de desktop e encolhem, o que é inutilizável.
• Alvos de toque: mínimo de 48×48 pixels CSS, com pelo menos 8px de espaçamento entre alvos adjacentes (padrão Lighthouse / Material Design).
• Tamanho da fonte: texto do corpo ≥16px para evitar a sinalização de “texto pequeno demais para ler”.
• Formulários: use tipos de entrada apropriados (tel, email, number) para que os celulares mostrem o teclado certo.

7. Intersticiais e anúncios — e as isenções

A ideia de que «qualquer popup vai derrubar seu ranqueamento» é exagerada. O que é penalizado é o tipo intrusivo: “Don’t obscure the entire page with interstitials” (tradução) «Não cubra a página inteira com intersticiais» e “Don’t redirect the user to a separate page for their consent or input” (tradução) «Não redirecione o usuário para uma página separada para obter consentimento ou informações» — popups de tela cheia antes do usuário interagir, páginas intersticiais independentes.

O que é explicitamente permitido: banners de consentimento de cookies exigidos por lei, diálogos de login para conteúdo genuinamente protegido por paywall, pequenos banners que usam espaço razoável da tela e gateways de idade exigidos por lei. E observe a nuance de ranqueamento — o sinal de intersticiais não é uma métrica do Core Web Vitals. Como o Google coloca, “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results. However, they can make your website more satisfying to use.” (tradução) «Além do Core Web Vitals, outros aspectos da experiência da página não ajudam diretamente seu site a ranquear mais alto nos resultados de busca. No entanto, eles podem tornar seu site mais satisfatório de usar.» Para anúncios, siga o Better Ads Standard.

8. AMP: neutro, não morto, não obrigatório

O AMP perdeu sua vantagem de ranqueamento em junho de 2021, quando o Google removeu o requisito de AMP para elegibilidade no Top Stories. Qualquer página com bons Core Web Vitals pode aparecer no Top Stories agora. As páginas AMP ainda funcionam — elas apenas não oferecem benefício de SEO sobre uma página padrão bem otimizada. Se você está no AMP hoje, avalie o custo da migração em relação ao benefício; o incentivo de SEO para adotá-lo desapareceu.

9. Configuração do site: responsivo é o caminho recomendado

Três configurações, na ordem de preferência do Google:

1. Design responsivo (recomendado): mesmo HTML na mesma URL; o CSS cuida do layout. Uma URL, sem risco de duplicação, sem lacuna de paridade por construção.
2. Serviço dinâmico: mesma URL, HTML diferente por user-agent. Risco: servir acidentalmente HTML de desktop para usuários móveis.
3. URLs separadas (m-dot): HTML diferente em URLs diferentes. Exige canonicalização cuidadosa e a maior disciplina de paridade. O conselho de longa data de John Mueller: “At some point all of these sites with separate mobile URLs should just move to a responsive design.” (tradução) «Em algum momento, todos esses sites com URLs móveis separadas deveriam simplesmente migrar para um design responsivo.»

10. Audite com ferramentas atuais e não obsoletas

Esta é a verificação de credibilidade em qualquer checklist móvel da era 2025. O Google aposentou a ferramenta Mobile-Friendly Test, a API Mobile-Friendly Test e o relatório de Usabilidade Móvel do GSC no início de dezembro de 2023. A declaração foi: “Today we’re sunsetting Search Console’s Mobile Usability report, Mobile-Friendly Test tool and Mobile-Friendly Test API,” (tradução) «Hoje estamos descontinuando o relatório de Usabilidade Móvel do Search Console, a ferramenta Mobile-Friendly Test e a API Mobile-Friendly Test». A justificativa foi que “many other robust resources for evaluating mobile usability have emerged.” (tradução) «surgiram muitos outros recursos sólidos para avaliar a usabilidade em dispositivos móveis».

Use estes em vez disso:

• PageSpeed Insights (laboratório + campo, aba móvel).
• Lighthouse (Chrome DevTools, modo móvel).
• Relatório de Core Web Vitals do GSC (dados de campo, filtre para móvel).
• Inspeção de URL do GSC (como o Googlebot renderiza uma página específica).
• Teste de resultados avançados (valida dados estruturados).
• CrUX Vis (cruxvis.withgoogle.com) — o painel CrUX foi descontinuado; o CrUX Vis é a ferramenta atual de dados de campo históricos do Google para tendências de CWV móvel.

Bônus: Bing é diferente — desktop-first

Uma divergência genuína que a maioria dos guias ignora: o Bing não usa indexação mobile-first. O alvo principal de rastreamento do Bing continua sendo a versão desktop das suas páginas. A compatibilidade móvel é um sinal de ranqueamento do Bing desde 2015, mas não é a metodologia de indexação do Bing. Portanto, a paridade móvel ainda importa para o Bing — por razões de ranqueamento, não porque o Bing só vê seu HTML móvel. Use o Bing Webmaster Tools para monitorar erros de rastreamento relacionados a dispositivos móveis, enviar sitemaps e validar dados estruturados.

Resumo de IA

Uma visão condensada da versão Avançada:

• A indexação mobile-first está concluída (finalizada em 5 de julho de 2024). O Google ranqueia você com base no seu HTML mobile para todas as consultas em todos os dispositivos, incluindo pesquisas em desktop.
• A paridade de conteúdo é a regra nº 1. Mesmo texto do corpo, títulos/descrições meta, cabeçalhos, imagens + texto alternativo, links internos, meta tags robots e dados estruturados no mobile e no desktop. Abas/acordeões são aceitáveis; conteúdo ausente não é.
• Core Web Vitals, medidos separadamente para mobile: LCP ≤ 2,5 s, INP ≤ 200ms, CLS ≤ 0,1, no 75º percentil. O mobile fica atrás do desktop (~48% vs ~56% de aprovação).
• Nunca faça lazy-load da imagem LCP — o erro mobile mais comum e mais prejudicial; use fetchpriority="high". O Google admitiu ter enviado esse bug ele mesmo.
• O INP substituiu o FID em 12 de março de 2024 — ele mede todas as interações ao longo da vida da página, não apenas a primeira, então é mais rigoroso com JS mobile lento.
• Usabilidade: viewport correto (sem user-scalable=no), alvos de toque de 48×48 px, fonte ≥16 px, tipos de entrada de formulário apropriados para mobile.
• Intersticiais têm isenções: consentimento de cookies, logins de paywall, banners pequenos, portões de idade legais são permitidos; o sinal não é uma métrica de CWV.
• AMP é neutro — sem vantagem de ranqueamento desde junho de 2021; ainda funcional.
• Design responsivo é a configuração recomendada pelo Google (em vez de servir dinamicamente e m-dot).
• Ferramentas: Lighthouse, PageSpeed Insights, Inspeção de URL, relatório de CWV, Teste de resultados avançados, CrUX. O Teste de compatibilidade com dispositivos móveis e o relatório de usabilidade mobile do GSC foram aposentados em dezembro de 2023.
• O Bing NÃO usa indexação mobile-first — ele é desktop-first; a compatibilidade com dispositivos móveis é um sinal de ranqueamento, não seu método de indexação.

Documentação oficial

Documentação de fonte primária dos mecanismos de busca.

Google

• Práticas recomendadas de indexação mobile-first — paridade de conteúdo, viewport, imagens/vídeos, meta tags robots e as três opções de configuração do site.
• Indexação mobile-first — conclusão (junho de 2024) — o marco final de 5 de julho de 2024.
• Mobile-first está aqui (outubro de 2023) — o anúncio anterior de conclusão da maioria.
• Indexação mobile-first e dados estruturados (dezembro de 2018) — os dados estruturados devem corresponder entre as versões.
• Evite intersticiais e diálogos intrusivos — o que é penalizado e o que é isento.
• Entendendo a experiência da página na Pesquisa Google — como o CWV e outros aspectos da experiência da página se relacionam ao ranqueamento.
• Core Web Vitals e resultados da Pesquisa Google — CWV como um insumo de ranqueamento.
• web.dev — Web Vitals (limiares) — os limiares de LCP/INP/CLS, medidos no 75º percentil em mobile e desktop.
• web.dev — Otimize o Largest Contentful Paint — “nunca faça lazy-load da sua imagem LCP” e fetchpriority.

Bing / Microsoft

• Diretrizes para webmasters do Bing — compatibilidade com dispositivos móveis como um sinal de ranqueamento (o Bing permanece desktop-first para indexação).

Citações da fonte

Declarações oficiais do Google. Cada link é um link profundo ou a página de origem para a passagem citada.

Google — paridade de conteúdo

• “Make sure that your mobile site contains the same content as your desktop site.” (tradução) «Garanta que seu site móvel contenha o mesmo conteúdo que seu site para desktop.» — Documentação do Google Search Central. Ir para a citação
• “Make sure that the title element and the meta description are equivalent across both versions.” (tradução) «Garanta que o elemento de título e a meta descrição sejam equivalentes nas duas versões.» Ir para a citação
• “Don’t lazy-load primary content upon user interaction.” (tradução) «Não faça lazy-load do conteúdo principal mediante interação do usuário.» Ir para a citação

Google — paridade de dados estruturados

• “If you use structured data on the desktop versions of your pages, you should have the same structured data on the mobile versions of the pages, since with mobile-first indexing, we’ll only use the mobile version of your page for indexing.” (tradução) «Se você usa dados estruturados nas versões para desktop das suas páginas, você deve ter os mesmos dados estruturados nas versões para mobile das páginas, pois com a indexação mobile-first, usaremos apenas a versão mobile da sua página para indexação.» — Blog do Google Search Central, dezembro de 2018. Fonte

Google — intersticiais

• “Don’t obscure the entire page with interstitials” (tradução) «Não cubra a página inteira com intersticiais» e “Don’t redirect the user to a separate page for their consent or input.” (tradução) «Não redirecione o usuário para uma página separada para obter consentimento ou informações.» Fonte

Google — nuances da experiência de página

• “Beyond Core Web Vitals, other page experience aspects don’t directly help your website rank higher in search results. However, they can make your website more satisfying to use.” (tradução) «Além do Core Web Vitals, outros aspectos da experiência de página não ajudam diretamente seu site a ranquear mais alto nos resultados de busca. No entanto, eles podem tornar seu site mais satisfatório de usar.» Fonte

Google — Core Web Vitals

• “Core Web Vitals are used by our ranking systems. We recommend site owners achieve good Core Web Vitals for success with Search.” (tradução) «O Core Web Vitals é usado pelos nossos sistemas de ranqueamento. Recomendamos que os proprietários de sites alcancem bons Core Web Vitals para ter sucesso na Pesquisa.» Fonte
• “a good threshold to measure is the 75th percentile of page loads, segmented across mobile and desktop devices.” (tradução) «um bom limite para medir é o 75º percentil dos carregamentos de página, segmentado entre dispositivos móveis e desktop.» — web.dev. Ir para a citação

Google (web.dev) — LCP e lazy loading

• “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP.” (tradução) «Nunca faça lazy-load da sua imagem LCP, pois isso sempre levará a um atraso desnecessário no carregamento de recursos e terá um impacto negativo no LCP.» Fonte

Martin Splitt, Google (via Search Engine Journal)

• “If you are using lazy loading on an image that is immediately visible, that is most likely going to have an impact on your largest contentful paint.” (tradução) «Usar carregamento tardio em uma imagem visível de imediato provavelmente afetará a maior renderização de conteúdo.» — e, sobre o CMS do próprio Google: “defaults all images to lazy loading, which is not great.” (tradução) «configura por padrão o carregamento tardio de todas as imagens, o que não é bom». Leia a cobertura

Google — aposentando as ferramentas móveis

• “Today we’re sunsetting Search Console’s Mobile Usability report, Mobile-Friendly Test tool and Mobile-Friendly Test API.” (tradução) «Hoje estamos descontinuando o relatório de Usabilidade em dispositivos móveis do Search Console, a ferramenta Mobile-Friendly Test e a API Mobile-Friendly Test.» — e a justificativa: “In the nearly ten years since we initially launched this report, many other robust resources for evaluating mobile usability have emerged.” (tradução) «Nos quase dez anos desde o lançamento inicial desse relatório, surgiram muitos outros recursos sólidos para avaliar a usabilidade em dispositivos móveis.» Leia a cobertura

John Mueller, Google (via guia de SEO mobile da Ahrefs)

• “At some point all of these sites with separate mobile URLs should just move to a responsive design.” (tradução) «Em algum momento, todos esses sites com URLs móveis separadas devem simplesmente migrar para um design responsivo.» Fonte

A lista de verificação de SEO para mobile

Trabalhe de cima para baixo. O primeiro grupo é inegociável; o restante o aprimora. Marcar todas as caixas abaixo remove os bloqueadores técnicos que o Google nomeou — isso não garante ranqueamento, indexação ou tratamento idêntico nos resultados de pesquisa. A qualidade e a relevância do conteúdo ainda decidem o restante.

Paridade de conteúdo (o requisito nº 1)

• A página mobile contém o mesmo conteúdo do corpo que a versão desktop (nada removido por um template mobile mais enxuto).
• Título e meta description são equivalentes entre mobile e desktop.
• A mesma estrutura de cabeçalhos (H1/H2…) está presente no HTML mobile.
• As mesmas imagens com o mesmo texto alt descritivo, legendas e nomes de arquivo.
• Os mesmos links internos estão presentes no mobile.
• Dados estruturados correspondem ao desktop (valide com o Rich Results Test).
• Meta tags de robots idênticas entre as versões (sem noindex acidental no mobile).
• Nenhum conteúdo principal carregado de forma preguiçosa por interação do usuário (revelar ao tocar).

Configuração técnica

• A configuração é design responsivo quando possível (em vez de servir dinamicamente / m-dot).
• robots.txt não bloqueia CSS/JS necessários para renderizar a página mobile.
• Se usar m-dot: canônico desktop em ambas as versões, rel="alternate" no desktop → mobile, páginas de erro retornam códigos de status correspondentes, ambos verificados no GSC.

Desempenho / Core Web Vitals (dados de campo mobile)

• LCP ≤ 2,5s — e a imagem LCP NÃO é carregada de forma preguiçosa (use fetchpriority="high").
• INP ≤ 200ms — auditado como INP, não o FID aposentado.
• CLS ≤ 0,1 — width/height explícitos em imagens/embeds; espaço reservado para anúncios e conteúdo tardio.
• Formatos de imagem modernos (WebP/AVIF), srcset/sizes responsivos, URLs de imagem estáveis.

Usabilidade

• Tag de viewport presente: width=device-width, initial-scale=1.
• Sem maximum-scale=1 / user-scalable=no (zoom por pinça não bloqueado).
• Alvos de toque ≥ 48×48px com espaçamento ≥ 8px.
• Fonte do corpo ≥ 16px.
• Formulários usam tipos de entrada apropriados (tel, email, number).
• Sem intersticial intrusivo na transição da pesquisa para a página (exceções de cookie/idade/login à parte).

Ferramentas (use apenas as atuais)

• Auditado com Lighthouse (modo mobile) e PageSpeed Insights.
• Verificado o relatório de Core Web Vitals do GSC, filtrado para mobile.
• Renderização verificada com GSC URL Inspection.
• Não confiou no Mobile-Friendly Test aposentado ou no relatório de Usabilidade Mobile do GSC (removido desde dezembro de 2023).

Folha de referência rápida de SEO para mobile

O que verificar → ferramenta → aprovado/reprovado

Limiares do Core Web Vitals (mobile, 75º percentil)

Fatos rápidos

• Indexação mobile-first concluída em 5 de julho de 2024 — o HTML mobile ranqueia você em todos os lugares.
• INP substituiu o FID em 12 de março de 2024.
• Teste de compatibilidade com dispositivos móveis + relatório de usabilidade mobile do GSC aposentados em dezembro de 2023.
• AMP — sem vantagem de ranqueamento desde junho de 2021 (Top Stories não exige mais).
• Bing — desktop-first; a compatibilidade com dispositivos móveis é um sinal de ranqueamento, não seu índice.

Os modelos mentais

1. O mobile é a versão canônica. Pare de pensar “site desktop + uma experiência mobile”. Desde julho de 2024, o HTML mobile é a versão que o Google indexa e ranqueia para todos. Cada pergunta de auditoria se torna: “O que o Googlebot Smartphone realmente vê nesta página?”

2. Paridade → Performance → Usabilidade, nessa ordem. Se o conteúdo está ausente no mobile, nenhuma otimização de velocidade salva a página — o Google não pode ranquear conteúdo que nunca vê. Acertar a paridade primeiro, depois buscar o Core Web Vitals, depois polir a usabilidade ao nível do polegar. Gastar esforço em CWV em uma página com lacuna de paridade é otimizar a camada errada.

3. Dados de campo, não dados de laboratório, são o insumo de ranqueamento. O Lighthouse dá a você uma pontuação de laboratório em um ambiente controlado; CrUX/GSC dão a você os dados de campo de usuários reais no 75º percentil, e isso é o que os sistemas de ranqueamento usam. Use o laboratório para diagnosticar, o campo para julgar. Uma execução verde no Lighthouse com CWV de campo ruim ainda é um problema.

4. “Use X em vez de Y” — a regra da atualidade das ferramentas. O sinal mais rápido de falta de credibilidade em SEO mobile é se alguém ainda recomenda ferramentas mortas. Teste de compatibilidade com dispositivos móveis → Lighthouse / PageSpeed Insights. Relatório de usabilidade mobile do GSC → relatório de CWV + Inspeção de URL. FID → INP. Se o seu processo referencia o lado esquerdo de qualquer uma dessas setas, está desatualizado.

5. Penalidades têm isenções — leia a regra real. Intersticiais não derrubam ranqueamentos universalmente; a regra visa os intrusivos, e consentimento de cookies, logins de paywall, banners pequenos e portões de idade legais são isentos. Quando uma “regra” soa absoluta, verifique a fonte para as exceções antes de redesenhar em torno de um mito.

Verificação mensal de saúde do SEO mobile

1. Revise os dados de campo mobile. Abra o relatório de Core Web Vitals no Search Console e o PageSpeed Insights para templates representativos. Registre grupos de URL afetados e a métrica que mudou. Concluído significa que cada novo problema tem um responsável ou um motivo documentado para monitorar.
2. Amostre a paridade de conteúdo. Compare os rastreamentos mobile e desktop para títulos, robots, canônicos, cabeçalhos, texto principal, links internos, imagens e dados estruturados. Concluído significa que diferenças materiais são mudanças intencionais de layout ou tickets.
3. Inspecione templates alterados como Googlebot Smartphone. Use a Inspeção de URL para uma amostra de cada tipo de página lançado recentemente. Concluído significa que o conteúdo principal e os sinais aparecem no HTML renderizado sem interação.
4. Execute verificações práticas de usabilidade. Teste larguras comuns de telefone para zoom, overflow horizontal, alvos de toque, formulários, navegação e intersticiais. Concluído significa que defeitos bloqueadores são reproduzíveis e atribuídos.
5. Anote e compare o desempenho. Segmente o desempenho mobile do Search Console por template e registre lançamentos, migrações e campanhas. Concluído significa que anomalias têm uma investigação escopada em vez de uma conclusão abrangente sem qualificação.

Erros de auditoria mobile a evitar

Usar ferramentas aposentadas do Google como plano de auditoria

O Teste de compatibilidade com dispositivos móveis e o relatório de usabilidade mobile do Search Console não existem mais. Use Lighthouse, PageSpeed Insights, Inspeção de URL, o relatório de Core Web Vitals e testes diretos em dispositivos.

Verificar apenas o layout visual

Uma página pode parecer responsiva enquanto o HTML mobile omite texto, links, diretivas, imagens ou dados estruturados. Compare a saída indexável, não apenas capturas de tela.

Lazy-loading da imagem LCP

Adiar o recurso visual principal atrasa o recurso que define o LCP. Mantenha-o detectável no markup inicial e priorize-o em vez disso.

Tratar conteúdo em acordeão como conteúdo ausente

Conteúdo recolhido não é o problema quando permanece no DOM. Concentre-se no conteúdo que o template mobile remove ou carrega somente após interação.

Aplicar uma pontuação de laboratório ao site inteiro

Uma execução do Lighthouse é diagnóstica, não representa o desempenho real no campo. Amostre tipos de página e combine achados de laboratório com dados de campo mobile.

Falhas comuns em auditorias de SEO mobile

O HTML mobile não tem conteúdo do desktop

Sintoma: Uma diferença de rastreamento mostra menos headings, links, imagens ou itens de schema no mobile. Causa provável: Templates separados ou regras de user-agent divergiram. Correção: Restaure os elementos da fonte de conteúdo compartilhada e confirme-os com um fetch mobile mais a Inspeção de URLs.

Lighthouse parece bom, mas os dados de campo são ruins

Sintoma: Uma execução de laboratório controlada passa enquanto os grupos de Core Web Vitals mobile falham. Causa provável: Dispositivos, redes, interações ou templates reais diferem do teste único. Correção: Identifique grupos de URLs afetados e distribuições de métricas, reproduza em dispositivos representativos e otimize o gargalo compartilhado em vez da URL de amostra isolada.

Páginas transbordam horizontalmente em alguns celulares

Sintoma: Os usuários precisam deslizar lateralmente apesar da meta tag viewport. Causa provável: Um filho de largura fixa, valor longo sem quebra, tabela, incorporação de mídia ou elemento transformado excede seu contêiner. Correção: Inspecione o nó que transborda na largura com falha, restrinja mídias responsivas e reteste zoom e layouts paisagem.

Prompts para auditoria de SEO mobile

Triagem de uma diferença de rastreamento mobile/desktop

Review this crawl comparison with mobile and desktop columns for status, title,
robots, canonical, H1, word count, internal-link count, image count, and structured
data types. Identify material content-parity exceptions, separate likely layout-only
differences, group issues by template, and give a direct verification step for each
group. Do not infer missing content from count differences alone.

[paste CSV]

Converter achados de dados de campo em tickets

Turn these mobile Core Web Vitals findings into implementation tickets. For each URL
group, preserve the observed metric and evidence, distinguish field data from lab
diagnostics, list the most likely shared template causes as hypotheses, and define a
pass/fail validation step. Do not invent a cause or promise a ranking change.

[paste findings]

Teste-se: SEO mobile

Cinco perguntas rápidas sobre auditoria de SEO mobile em um mundo mobile-first. Escolha uma resposta para cada uma e depois confira.

Recursos que valem seu tempo

Meus escritos relacionados

• The Beginner’s Guide to Technical SEO — onde o mobile se encaixa no panorama técnico maior.
• Mobile SEO (blog da Ahrefs, Jamie Grant) — o mergulho profundo complementar, incluindo a frase de Mueller sobre “mover para responsivo”.
• Core Web Vitals — o hub de métricas: LCP, INP, CLS, limites e dados de campo vs. laboratório.
• Largest Contentful Paint — o mergulho profundo no LCP, incluindo a armadilha do lazy loading.
• Interaction to Next Paint — o que o INP mede e por que o mobile sofre com ele.
• Mobile-First Indexing — o conceito de indexação e a linha do tempo verificada.

Oficial

• Google — Mobile-First Indexing Best Practices.
• web.dev — Web Vitals e Optimize LCP.
• Bing Webmaster Guidelines.

Do setor

• Google encerra oficialmente o Relatório de Usabilidade Mobile, a Ferramenta e a API do Teste de Compatibilidade com Dispositivos Móveis (Search Engine Land, dez 2023) — a descontinuação, com a declaração do Google.
• Google: por que o lazy loading pode atrasar o Largest Contentful Paint (LCP) (Search Engine Journal) — Martin Splitt sobre a armadilha do lazy loading no LCP, incluindo o erro do próprio CMS do Google.
• SEO para dispositivos móveis (Ahrefs, Jamie Grant) — guia completo de SEO para dispositivos móveis.
• Sua lista de verificação de SEO para dispositivos móveis (Nostra.ai) — referência em formato de lista de verificação com contexto de tráfego móvel.
• r/TechSEO — a comunidade para depuração de rastreamento, renderização e paridade em dispositivos móveis.

Registro de alterações