Mobile-first indexing: implicações práticas

O que indexação mobile-first realmente significa

Por décadas, o Google rastreou sites com o Googlebot Desktop e usou a versão para computador como referência. Em 2016, anunciou a transição para indexação mobile-first. Em 2019, novos sites passaram a entrar diretamente no índice mobile-first, e em 2023 o processo foi concluído para todos os sites elegíveis. Hoje, o Googlebot Smartphone é o rastreador primário — a versão mobile da página define o que entra no índice e como a página classifica.

Isso não é uma "preferência" do Google por sites mobile. É uma mudança de qual versão da página o rastreador lê. Se a sua versão mobile tem menos conteúdo, metadados diferentes ou ausência de dados estruturados, é essa versão reduzida que o Google indexa. A versão desktop pode até existir e ser elegante, mas ela não é mais a referência. Para sites responsivos modernos, isso geralmente não muda nada — o HTML servido é o mesmo. Para sites com versão m. separada, conteúdo dinâmico em accordions ou imagens diferentes entre versões, mobile-first revela problemas que o índice desktop antigo escondia.

Responsivo, dinâmico ou versão separada

O Google reconhece três padrões de site mobile, com implicações distintas para mobile-first:

Design responsivo. O mesmo HTML é servido a todos os dispositivos, e o CSS adapta a apresentação por largura de tela (breakpoints). É o padrão recomendado pelo Google e o que minimiza risco em mobile-first, porque conteúdo, metadados e dados estruturados são, por construção, idênticos entre versões. A grande maioria dos sites modernos usa essa abordagem.

Veiculação dinâmica. O servidor identifica o agente do usuário (User-Agent) e serve HTML diferente para mobile e desktop, na mesma URL. Funciona, mas exige cuidado: o Googlebot Smartphone precisa receber a versão mobile completa, e a paridade de conteúdo precisa ser monitorada. Caiu em desuso fora de casos muito específicos.

URLs separadas. A versão mobile vive em outro endereço — tipicamente m.empresa.com.br — e o desktop em www.empresa.com.br. As versões são ligadas por rel="canonical" e rel="alternate". É a configuração mais frágil em mobile-first: qualquer diferença de conteúdo, ausência de metadados na versão mobile, ou redirecionamento mal feito gera perda de classificação. Sites legados com m. separada têm projetos formais de consolidação para responsivo.

Paridade: o que precisa ser igual entre versões

Mobile-first não exige que a versão mobile seja idêntica em aparência à desktop — exige paridade de substância. O conjunto abaixo precisa ser igual ou equivalente:

Conteúdo textual. Texto principal, parágrafos, listas, títulos e subtítulos precisam estar presentes na versão mobile. "Versão mobile resumida" com 30% do texto desktop é um anti-padrão. Se o desktop tem 1.500 palavras de conteúdo, o mobile precisa ter as mesmas 1.500 palavras — pode estar em accordions ou abas, desde que o HTML seja renderizado.

Imagens. As mesmas imagens (ou equivalentes responsivas via srcset) precisam estar presentes, com atributos alt idênticos. Imagem que aparece só no desktop deixa de ser indexada.

Vídeos. Mesma marcação de vídeo (tag video ou incorporação) e mesmos metadados (legenda, transcrição).

Links internos. Estrutura de navegação e links contextuais idênticos. Menu hamburger é OK, desde que o HTML dos links esteja presente.

Metadados. title, meta description, meta robots, canonical, hreflang, Open Graph e Twitter Cards precisam ser idênticos entre versões.

Dados estruturados. Schema.org marcado em JSON-LD ou microdata precisa estar presente na versão mobile com os mesmos campos. Ausência de dados estruturados na mobile é um dos erros mais comuns em sites com versão separada.

Desempenho mobile e os indicadores principais de web

Mobile-first não é só sobre conteúdo — desempenho mobile virou fator de classificação direto através dos Core Web Vitals (indicadores principais de web). São três métricas que medem experiência percebida:

LCP (Largest Contentful Paint). Tempo para o maior elemento visível na tela carregar. Meta: menos de 2,5 segundos em mobile. Causas comuns de LCP ruim: imagem hero não otimizada, fontes que bloqueiam renderização, servidor lento.

INP (Interaction to Next Paint). Substituiu o FID em 2024. Mede o tempo entre uma interação do usuário (clique, toque) e a próxima resposta visual. Meta: menos de 200 milissegundos. Causas comuns: JavaScript pesado que trava a thread principal.

CLS (Cumulative Layout Shift). Mede deslocamentos visuais inesperados durante o carregamento. Meta: menos de 0,1. Causas comuns: imagens sem dimensões declaradas, banners injetados após renderização inicial.

Os Core Web Vitals são medidos com dados de usuários reais (CrUX) e ficam disponíveis no Search Console. Sites com bom desempenho mobile em CWV têm classificação mais consistente do que sites com desempenho ruim, especialmente em consultas competitivas.

Experiência mobile que o Google avalia

Além de CWV, o Google considera fatores básicos de usabilidade mobile:

Viewport configurado. A tag meta viewport precisa estar presente com width=device-width. Sem ela, o navegador mobile renderiza a página como se fosse uma tela desktop encolhida — usuários veem texto microscópico e precisam dar zoom.

Tamanho de fonte legível. Texto principal com pelo menos 16px (com proporção adequada via rem). Fonte pequena obriga zoom.

Alvos de toque adequados. Botões e links com pelo menos 48 por 48 pixels de área tocável e espaçamento entre eles. Alvos pequenos geram cliques errados — frustração e taxa de rejeição alta.

Sem conteúdo lateral. Página inteira cabe na largura da tela sem rolagem horizontal. Tabelas largas e imagens fixas em pixel são causas comuns de transbordamento.

Sem interstícios intrusivos. Pop-ups que cobrem o conteúdo principal logo após a entrada do usuário são penalizados. Banners de consentimento de cookies (LGPD) são uma exceção formal documentada pelo Google, mas precisam permitir interação fluida.

AMP: estado atual

AMP (Accelerated Mobile Pages) foi lançado pelo Google em 2015 como framework para páginas mobile ultrarrápidas, com requisitos técnicos restritos e CDN do próprio Google. Por anos, AMP foi pré-requisito para aparecer no carrossel de notícias mobile (Top Stories).

Em 2021, o Google removeu o requisito de AMP para Top Stories. Hoje, AMP não é mais necessário para nenhum benefício de classificação ou destaque mobile — qualquer página com bom desempenho mobile e CWV satisfatórios pode classificar igual. Muitos publishers descontinuaram AMP nos últimos anos, dado o custo de manter duas versões da mesma página. AMP ainda funciona, mas não há razão estratégica para adotá-lo agora se a versão mobile do site já tem desempenho bom.

Erros mais comuns em mobile-first

Conteúdo escondido sem renderização. Accordions, abas e dropdowns mobile podem ser indexados normalmente — desde que o HTML do conteúdo esteja presente no DOM. Quando o conteúdo é injetado via JavaScript apenas após o clique do usuário, o Googlebot pode não vê-lo. Use a inspeção de URL no Search Console para confirmar que o HTML renderizado contém o texto que você espera indexar.

Imagens diferentes entre mobile e desktop. Versão desktop com imagem ilustrativa, versão mobile com placeholder ou imagem reduzida. O Google indexa o que vê na versão mobile — imagens que aparecem só no desktop deixam de existir para o índice.

Dados estruturados ausentes na versão mobile. Schema.org de produto, artigo, FAQ, evento marcado só na versão desktop. Em sites com versão m. separada, é o erro mais frequente — e custa rich results (resultados ricos) inteiros nas pesquisas mobile.

robots.txt ou meta robots divergentes. Versão mobile bloqueia robôs ou tem noindex que não existe na desktop. Acontece especialmente em ambientes onde mobile foi tratado como projeto separado.

Redirecionamentos quebrados em m. Versão mobile redireciona desktop usuários para a home em vez de para a página equivalente, ou loops de redirecionamento. Mata indexação.