Uma posição não é um número único. Pergunte ao mesmo site, pela mesma consulta, nos mesmos 90 dias, e mobile e desktop vão discordar. Nos nossos próprios dados do Search Console, a diferença chegou a 11,4 posições em uma consulta, e a direção se invertia conforme a consulta: às vezes o mobile ficava melhor, às vezes o desktop.
Isso não é falha nos dados nem motivo para comprar um rastreador de posições mobile. É uma propriedade de como o Google monta uma página de resultados, e permanece invisível enquanto você lê uma média misturada.
Este artigo trata do que realmente causa a separação, de como ficaram os nossos próprios números e de um fluxo de trabalho curto no Claude Code que separa os dois para você parar de tomar decisões de desktop sobre tráfego mobile.
O equívoco
A suposição que a maioria das equipes carrega, normalmente sem verbalizar, é que a posição é uma propriedade da página. Você está em 8º numa consulta, então está em 8º. Os rastreadores de posição reforçam essa suposição porque, por padrão, trabalham com um único dispositivo e imprimem um número por palavra-chave.
A consequência prática é um hábito de relatório: alguém confere a posição no desktop, anota numa planilha, e tudo o que vem depois trata aquilo como a verdade sobre visibilidade.
A realidade mais útil
Dois fatos, ambos documentados pelo próprio Google, quebram o modelo do número único.
Fato um: o que é ranqueado é a sua página mobile. A documentação do Search Central do Google diz isso diretamente: "O Google usa a versão mobile do conteúdo de um site, rastreada com o agente de smartphone, para indexação e ranqueamento." Seu HTML de desktop não é a entrada principal, mesmo quando quem pesquisa está num notebook.
Fato dois: a página de resultados é construída para o dispositivo que está na frente dela. A própria documentação de ajuda do Search Console diz isso sem rodeios, e vale ler duas vezes: "Os resultados da pesquisa são específicos para o horário, o local, o dispositivo e o histórico recente de quem pesquisa."
Junte os dois e a posição que você anotou é uma amostra de uma distribuição que se desloca por dispositivo. O número não está errado. Ele só é bem mais estreito do que o uso que se faz dele.
Por que o mito se espalha tão facilmente
Quatro coisas comuns mantêm vivo o modelo do número único.
- Os rastreadores vêm com desktop por padrão. Buscar a SERP de desktop é mais barato e mais simples de armazenar, então ela vira a coluna padrão. A troca de dispositivo existe em muitos planos, o que é diferente de vir ligada por padrão.
- O Search Console mistura os dispositivos. O relatório de Desempenho padrão faz a média entre mobile, desktop e tablet. É preciso abrir a aba "Dispositivos", ou chamar a API com device como dimensão, para ver a separação. Nada na visualização padrão avisa que uma mistura está acontecendo.
- O rastreamento de posições mobile é vendido como adicional. Quando um fornecedor lista "rastreador de posições mobile" como recurso, a implicação é que o relatório padrão já cobre tudo. Ele cobre uma fatia.
- O efeito é invisível em amostras pequenas. Se você olhar dez consultas e todas concordarem, o problema parece teórico. Ele fica visível no nível da consulta, em consultas com impressões suficientes para tirar média.
O que os nossos próprios 90 dias mostraram
Puxamos a nossa própria propriedade do Search Console, 90 dias terminando em 11 de setembro de 2026, com query e device como dimensões.
Dispositivo | Impressões | Cliques | CTR | Posição média |
|---|---|---|---|---|
Desktop | 34.028 | 375 | 1,10% | 34,4 |
Mobile | 7.147 | 69 | 0,97% | 30,8 |
Tablet | 156 | 0 | 0,00% | 40,8 |
Mesma propriedade, mesma janela, três histórias diferentes. Repare que a posição média no mobile é melhor enquanto o CTR no mobile é pior.
Há dois pontos nesta tabela que merecem atenção.
O primeiro é o sinal invertido. A posição média no mobile era melhor que no desktop (30,8 contra 34,4), e ainda assim o CTR no mobile era pior (0,97% contra 1,10%). Posição melhor com taxa de cliques pior é normal no mobile: as páginas de resultados são mais altas, o layout é diferente e o topo da página fica cheio de recursos. Quem relatasse apenas a posição teria chamado o mobile de superfície mais forte e perdido a lacuna de cliques por completo.
O segundo é a armadilha de ler médias do site inteiro. Essas duas linhas resumem misturas de consultas diferentes. O desktop carrega 82% das nossas impressões porque nosso público é de profissionais de SEO em suas mesas, e o mobile carrega um conjunto diferente e menor de consultas. As médias do site inteiro escondem isso. É a junção por consulta que torna o número acionável.
Então fizemos a junção. Das 130 consultas com pelo menos 20 impressões, 85 tinham dados nos dois dispositivos. Aqui estão as seis maiores divergências.
Consulta | Posição no mobile | Posição no desktop | Diferença |
|---|---|---|---|
auditoria seo on page | 64,5 | 53,1 | 11,4 (desktop melhor) |
perplexity seo checking tool | 20,5 | 31,1 | 10,6 (mobile melhor) |
geo seo | 92,9 | 85,4 | 7,5 (desktop melhor) |
auspia | 5,4 | 1,6 | 3,8 (desktop melhor) |
perplexity referral traffic | 11,2 | 12,0 | 0,9 (desktop melhor) |
amazon echo keywords | 13,9 | 13,8 | 0,1 (empate) |
A lacuna corre nos dois sentidos. "O mobile ranqueia pior" é tão errado quanto "posição é posição".
A direção se inverte. Essa é a descoberta que deve mudar seu hábito operacional: você não consegue corrigir a divergência entre dispositivos com uma regra de bolso, porque não existe uma direção consistente a corrigir. Você precisa medir por consulta.
O que fazer em vez disso: separar, juntar, definir limite, decidir
Quatro passos, cerca de 20 minutos depois que o fluxo de trabalho existe.
Passo 1: puxe query e device juntos. No Search Console, abra Desempenho, adicione a aba "Dispositivos" ao lado de "Consultas" e exporte em 90 dias. Pela API, peça as dimensões ["query","device"] com um limite de linhas alto o suficiente para caber o seu conjunto de consultas. A API aceita um limite de linhas bem acima do que um site de porte médio precisa, então peça alto e corte localmente.
Se você já produz um relatório semanal de posições, isso vira uma dimensão extra em algo que você já tem, e não uma planilha nova. O contrato de relatório do nosso fluxo de trabalho de relatório semanal de posições tem um espaço reservado para isso.
Passo 2: junte pela chave da consulta. Uma linha por consulta, com uma coluna de mobile e uma de desktop. Linhas que existem em apenas um dispositivo são uma descoberta por si só: significam que a consulta recebe impressões numa superfície e não na outra.
Passo 3: aplique um limite antes de olhar. Cinco posições é um limite inicial utilizável. Abaixo disso, você está lendo ruído. Acima disso, você tem uma consulta em que as duas superfícies realmente discordam.
Passo 4: decida por classe de consulta, não por consulta. Consultas de dinheiro são corrigidas primeiro. Consultas de comparação costumam divergir porque o layout da SERP é diferente, não porque sua página é fraca. Consultas de marca que divergem quase nunca são problema de SEO. Consultas informacionais podem esperar.
O fluxo de trabalho no Claude Code que faz a separação
A parte repetível é mecânica: puxar, juntar, aplicar limite, resumir. É exatamente o formato de tarefa que pertence a um agente, não à sua semana.
Salve isto como um arquivo de instruções que o Claude Code consiga ler e aponte-o para a propriedade que você possui:
Puxe os dados do Search Console da propriedade <property> dos últimos 90 dias.
Use as dimensões: query, device. Mantenha apenas consultas com pelo menos 20 impressões.
Junte mobile contra desktop pela chave da consulta.
Para cada consulta presente nos dois dispositivos, calcule a diferença absoluta na posição média.
Mostre apenas as linhas em que a diferença é 5.0 ou mais, ordenadas por impressões totais em ordem decrescente.
Para cada linha mostre: consulta, posição no mobile, posição no desktop, lacuna, qual dispositivo é melhor,
impressões no mobile, impressões no desktop.
Termine com duas linhas de resumo:
1. Contagem de consultas em que o mobile é melhor, e contagem em que o desktop é melhor.
2. A única consulta com a maior lacuna, e suas impressões totais.
Não sugira correções. Não escreva recomendações de conteúdo.
Salve a saída como mobile-desktop-gap-YYYY-MM-DD.md na pasta de trabalho.Há três escolhas deliberadas nessa instrução que vale manter se você adaptá-la.
Ela define um piso de impressões, porque uma consulta com quatro impressões no mobile produz uma posição média que não significa nada. Ela proíbe sugestões de correção, porque a decisão depende da classe da consulta e do contexto de negócio, e um agente chutando isso produz bobagem confiante. E ela salva num arquivo com data para você comparar a separação do mês que vem com a deste mês, que é a única forma de ver se uma correção funcionou.
O prompt é neutro em formato quanto ao agente. O Codex executa a mesma instrução pelas convenções de arquivo dele, e a etapa de revisão é idêntica.
Salvaguardas
- Abaixo de cerca de 20 impressões, pare. Médias de posição sobre um punhado de impressões saltam dois dígitos sozinhas. O limite no prompt existe por esse motivo.
- Tablet não é mobile. Nossa linha de tablet tinha 156 impressões e zero cliques. Agrupar tablet dentro de mobile teria piorado os números de mobile por razões que nada têm a ver com busca mobile.
- Este artigo é sobre medição, não sobre elegibilidade. Se o Google consegue ou não ver o seu conteúdo mobile é um problema diferente, com verificações diferentes. Cobrimos o lado da auditoria em Indexação mobile-first em 2026.
- Uma posição melhor pode ser um resultado pior. Nos nossos próprios dados, o mobile ranqueou melhor e clicou pior. Posição e taxa de cliques precisam ser lidas juntas.
- Não persiga toda lacuna. Uma lacuna de 6 posições numa consulta com 30 buscas mensais não é um projeto. Ordene a lista por impressões e deixe a cauda em paz.
- Posições profundas se comportam de forma diferente. Se uma consulta está além da posição 100 nos dois dispositivos, corrija primeiro o problema de profundidade. Medimos até onde os resultados do Google realmente vão no nosso teste de profundidade de verificação de posição.
Visão da Auspia: a divergência entre dispositivos é um problema de medição antes de ser um problema de ranqueamento. A maioria das equipes nunca olhou, porque o relatório padrão esconde a separação. Uma vez que a separação fica visível, a maior parte das lacunas se revela explicável e o punhado interessante vale uma correção.
Perguntas frequentes
O Google ranqueia páginas mobile e desktop separadamente? Na prática, sim. O Google indexa a versão mobile do seu conteúdo, e a página de resultados servida a um celular difere da servida a um notebook. As duas posições vêm dos mesmos sistemas subjacentes, mas não são o mesmo número.
Por que meu rastreador de posições difere do Search Console? Porque medem coisas diferentes. Um rastreador busca uma SERP ao vivo num local e dispositivo. O Search Console faz a média de impressões em todos os dispositivos, países e todo o intervalo de datas. Ambos podem estar certos e discordar.
O que é um rastreador de posições mobile e eu preciso de um? Um rastreador de posições mobile busca a SERP de smartphone para um conjunto de palavras-chave. Vale pagar se você precisa de posições de concorrentes ou de localidades que não consegue ver nos seus próprios dados. Se você só precisa da visibilidade mobile do seu próprio site, o Search Console já a tem, separada por dispositivo, sem custo.
Quantas impressões antes de a posição por dispositivo ser confiável? Cerca de 20 é o piso prático para uma leitura aproximada; a partir de 100 o número para de se mover semana a semana. Abaixo de 20, mantenha a consulta na lista, mas não aja sobre ela.
O Claude Code consegue ler o Search Console diretamente? Sim, pela API do Search Console com uma conta de serviço ou credenciais OAuth. O fluxo de trabalho acima pressupõe que essa conexão exista. Nosso guia do agente de SEO cobre quais tarefas de ranqueamento valem ser entregues a um agente e quais não.
Devo corrigir a página mobile se o mobile ranquear pior? Verifique a SERP primeiro. Se a página de resultados mobile carrega mais vídeo, mais pacotes locais ou uma mistura diferente de tipos de página, a correção é de formato de conteúdo, não de qualidade da página. Se o formato da SERP bater e a página estiver bem, trate como problema de paridade de conteúdo e audite contra as verificações de mobile-first.
Autor: Marcus Ellery, experimentador de crescimento por trás de mais de 150 testes de SEO na Auspia. Escreve sobre dados de referência, testes controlados e a diferença entre uma métrica que se move e uma métrica que significa algo.
