A resposta curta
A indexação mobile-first está concluída. Desde julho de 2024, o Google usa apenas a versão móvel do seu site para indexação e ranqueamento. Se o conteúdo, dados estruturados ou links internos existem no desktop mas não no mobile, o Google não os enxerga. Em 2026, isso tem três novas consequências que a maioria dos proprietários de sites ainda não resolveu: INP substituiu o FID como Core Web Vital, AI Overviews extraem conteúdo renderizado para dispositivos móveis e a Core Update de março de 2026 aumentou o peso de ranqueamento da experiência em páginas móveis.
Abaixo, você encontrará um fluxo de auditoria completo — e uma skill Codex pronta para copiar e colar que executa a maioria das verificações para você.
O que "somente móvel" realmente significa em 2026
O Google começou a migrar sites para a indexação mobile-first em 2018. A transição levou mais de seis anos. Desde julho de 2024, todo site que ainda tinha conteúdo acessível em desktop sem equivalente móvel perdeu esse conteúdo do índice do Google. Não há opção de exclusão e nem fallback apenas para desktop.
Mas a história não terminou aí. Três mudanças em 2025–2026 transformaram o que "mobile-first" exige do seu site:
Mudança 1: INP substituiu o FID — e a maioria dos sites móveis falha nisso
Em março de 2024, o Google substituiu o First Input Delay (FID) pelo Interaction to Next Paint (INP) como Core Web Vital. O INP mede a rapidez com que sua página responde a toques, cliques e pressionamentos de tecla ao longo de toda a sessão na página, não apenas na primeira interação.
O número expressivo: aproximadamente 40% dos sites que passavam no FID não passam no INP. No mobile, apenas cerca de 65% dos sites atingem o limite "bom" de 200 milissegundos ou menos. A Core Update de março de 2026 aumentou ainda mais o peso dos Core Web Vitals no ranqueamento. Sites que falham no INP móvel estão perdendo posições para concorrentes mais rápidos.
Mudança 2: AI Overviews e crawlers de IA leem seu conteúdo móvel
As AI Overviews do Google aparecem em aproximadamente 47% das buscas em meados de 2026. Quando os sistemas de IA do Google geram respostas, eles extraem do mesmo conteúdo indexado para mobile que a busca tradicional usa. Crawlers de IA de terceiros (GPTBot, ClaudeBot, PerplexityBot) também acessam suas páginas renderizadas para dispositivos móveis.
Se sua versão móvel não tem dados estruturados, cabeçalhos claros ou textos essenciais, os sistemas de IA não podem citar você — mesmo que a versão desktop tenha esse conteúdo.
Mudança 3: Lacunas de paridade de conteúdo agora têm impacto mensurável no ranqueamento
Em 2026, sites com conteúdo inconsistente entre mobile e desktop apresentam 31,2% menos exposição em busca orgânica em média, comparados a sites com paridade total de conteúdo. Os elementos mais comumente ausentes no mobile: conteúdo em abas ocultas, links da barra lateral, marcação de dados estruturados, texto alternativo de imagens e links de navegação interna.
Elemento de conteúdo | % de sites sem ele no mobile |
|---|---|
Dados estruturados (JSON-LD) | 23% |
Links internos (menus, breadcrumbs) | 18% |
Texto alternativo de imagens | 27% |
Texto completo em abas/accordions | 15% |
Tags meta robots | 9% |
Como verificar se seu site é aprovado (versão de 2 minutos)
Antes de executar uma auditoria completa, verifique estes três sinais. Cada um leva menos de um minuto e indica se você precisa se aprofundar.
Sinal 1: Status de indexação no Google Search Console
Abra o Google Search Console → clique em Configurações (ícone de engrenagem, canto inferior esquerdo) → procure a seção "Sobre". Se estiver escrito "Googlebot smartphone" em "Rastreador de indexação", seu site está na indexação mobile-first. Isso é verdade para praticamente todos os sites em 2026 — mas verifique mesmo assim.
Verifique também: Ferramenta de inspeção de URL → insira qualquer página importante → expanda "Rastreamento" → confirme "Rastreado como: Googlebot smartphone". Observe a captura de tela que o Google fornece — isso é exatamente o que o Google vê. Se conteúdo essencial estiver ausente dessa captura, ele está ausente do índice.
Sinal 2: PageSpeed Insights com dados reais de dispositivos móveis
Acesse o PageSpeed Insights, insira sua URL e observe a seção "Descubra o que seus usuários reais estão experimentando". Esses são dados de campo do Chrome User Experience Report (CrUX) — os mesmos dados que o Google usa para ranqueamento.
Se o relatório móvel mostrar laranja ou vermelho para INP (Interaction to Next Paint), você tem uma desvantagem ativa de ranqueamento. O limite é abaixo de 200 milissegundos para verde.
Sinal 3: Verificação rápida do viewport móvel no Chrome DevTools
Abra o Chrome DevTools (F12 ou Cmd+Option+I), clique no ícone da barra de dispositivos (Ctrl+Shift+M) e selecione uma predefinição de dispositivo móvel como "Pixel 7". Recarregue a página. Verifique:
- Texto que exige rolagem horizontal
- Botões ou links muito pequenos para tocar (menos de 48×48 pixels CSS)
- Conteúdo oculto atrás de alternadores "leia mais" que não está no código-fonte HTML
- Pop-ups que cobrem a maior parte da tela
Cada um desses é um problema de indexação mobile-first se o conteúdo ou os links por trás deles forem diferentes do que os usuários de desktop veem.
A auditoria mobile-first de 30 minutos (com Codex)
A maneira mais rápida de executar uma auditoria mobile-first completa hoje é dar a um agente de codificação com IA — Claude Code ou Codex — uma tarefa estruturada. O agente lê o código-fonte do seu site, verifica as regras e produz uma lista de correções priorizadas.
Abaixo está um arquivo de skill completo. Copie-o para o seu projeto e peça ao seu agente para executá-lo.
Passo 1: Criar o arquivo de skill
Crie um arquivo em .claude/skills/mobile-first-audit/SKILL.md (para Claude Code) ou .codex/skills/mobile-first-audit/SKILL.md (para Codex):
name: mobile-first-audit
description: Audit a URL or list of URLs for mobile-first indexing readiness. Checks content parity, Core Web Vitals, structured data, mobile UX, and AI crawler access.
# Mobile-First Indexing Audit
Run a structured mobile-first indexing audit on one or more URLs. The agent must report findings, not make edits, unless the user explicitly approves a fix plan.
## Input
The user provides one or more page URLs. If they provide a sitemap URL or a list of more than 5 URLs, sample 5 URLs that represent different page types (homepage, product page, article, category page, landing page).
## Audit Checklist
For each URL, check and report on all eleven items below. Mark each item as `PASS`, `WARN`, or `FAIL`. Include the evidence for every WARN and FAIL.
### 1. Viewport Meta Tag
Check that `<meta name="viewport" content="width=device-width, initial-scale=1">` is present in the HTML `<head>`. If missing or if it sets a fixed width or disables user-scaling without a valid accessibility reason, mark FAIL.
### 2. Content Parity (Text)
Fetch the page with a desktop user-agent and a mobile user-agent (Googlebot Smartphone). Compare the visible text content. If any text block over 50 words exists on desktop but not in the mobile HTML source, mark WARN. If important body text, headings, or product descriptions are missing, mark FAIL.
### 3. Structured Data Parity
Extract all JSON-LD blocks from both desktop and mobile fetches. If any schema type present on desktop is missing from mobile, mark FAIL. If schema content differs between versions, mark WARN.
### 4. Meta Tags Parity
Compare title, meta description, canonical, robots, and hreflang tags between desktop and mobile versions. Any difference is a WARN. A missing canonical or conflicting robots tag is FAIL.
### 5. Internal Links and Navigation
Count the number of internal `<a href>` links in the desktop and mobile HTML. If the mobile version has 20%+ fewer internal links, mark WARN. If breadcrumb links, category navigation, or footer links present on desktop are missing from mobile, mark FAIL.
### 6. Image Alt Text
Count images in the mobile HTML. Report the number and percentage missing alt attributes. If more than 10% of images lack alt text, mark WARN. If hero images or product images lack alt text, mark FAIL.
### 7. Core Web Vitals (Field Data)
Look up the URL's Chrome UX Report (CrUX) field data. If accessible via PageSpeed Insights API or a direct CrUX lookup, report LCP, INP, and CLS for mobile. Mark thresholds: LCP > 2.5s = WARN, > 4.0s = FAIL. INP > 200ms = WARN, > 500ms = FAIL. CLS > 0.1 = WARN, > 0.25 = FAIL.
If CrUX data is unavailable (insufficient traffic), note this and use lab data from Lighthouse as a fallback with the caveat that lab data is not used for ranking.
### 8. Tap Target Sizing
Inspect CSS for buttons, links, and interactive elements. Flag any element whose computed height or width is under 48 CSS pixels. Flag adjacent interactive elements with less than 8px spacing. Mark WARN for 1-3 violations, FAIL for 4+.
### 9. Font Sizing
Check that body text uses a computed font-size of at least 16px. Flag any text below 12px. Mark WARN if body text is 14-15px, FAIL if below 12px.
### 10. Interstitials and Pop-ups
Visually inspect the mobile viewport. If a pop-up, banner, or interstitial covers more than 30% of the initial viewport and is not legally required (cookie consent, age verification), mark WARN. If the pop-up prevents scrolling or reading content, mark FAIL.
### 11. AI Crawler Access
Check robots.txt for rules blocking GPTBot, ClaudeBot, PerplexityBot, Google-Extended, or OAI-SearchBot. If any AI crawler is blocked, note that as a deliberate choice. If AI crawlers are allowed but the page has no structured data, mark WARN (AI systems rely on structured data for citations).
## Output Format
Produce a Markdown report:
```markdown
# Mobile-First Audit Report
**Date:** YYYY-MM-DD
**URLs audited:** N
**Overall score:** X/11 PASS items per URL average
## Summary
| Check | URL 1 | URL 2 | URL 3 | URL 4 | URL 5 |
|-------|-------|-------|-------|-------|-------|
| 1. Viewport | PASS | PASS | ... | ... | ... |
| ... | ... | ... | ... | ... | ... |
## Detailed Findings
### URL 1: [url]
**FAIL items (must fix):**
- [Item name]: [evidence and fix instructions]
**WARN items (should fix):**
- [Item name]: [evidence and fix instructions]
**PASS items:** [list]
### Priority Fix Queue
1. [Highest priority fix] — affects indexing directly
2. [Next fix] — affects ranking
3. ...Rules
- Do not make any changes to the site without explicit user approval of a fix plan.
- If you cannot check an item because the page requires authentication, note it as "NOT CHECKED — authentication required."
- For CrUX data, use the official Chrome UX Report API or PageSpeed Insights API if available. If neither is accessible, use Lighthouse mobile audit as a fallback.
- Never fabricate metrics, scores, or check results. If data is unavailable, say so.
- Do not access or expose API keys, cookies, tokens, or credentials.
### Passo 2: Executar a auditoria
Pergunte ao seu agente: **"Execute a skill de auditoria mobile-first em [sua URL]"** e cole a URL que você deseja verificar. O agente produzirá um relatório com PASS/WARN/FAIL para cada uma das 11 verificações, além de uma fila de correções prioritárias.
Se quiser verificar várias páginas de uma vez, forneça uma lista: **"Execute a auditoria mobile-first nestas 5 URLs: [URL1, URL2, URL3, URL4, URL5]"**.
## Correção nº 1: Paridade de conteúdo — o que verificar primeiro
A paridade de conteúdo é a correção de maior impacto porque determina diretamente o que o Google pode indexar. Veja o que mais costuma falhar e como corrigir cada item.
### Conteúdo oculto em abas e accordions
Muitos sites no mobile colapsam conteúdo extenso em abas, accordions ou alternadores "leia mais". Isso é aceitável **desde que o conteúdo esteja no código-fonte HTML** — o Google não descarta mais conteúdo oculto por razões de UX. Mas se suas abas carregam conteúdo via JavaScript após o toque do usuário, o Googlebot não aciona esse toque. O conteúdo fica invisível.
**Como verificar:** No Chrome DevTools, clique com o botão direito no conteúdo oculto e selecione "Inspecionar". Se o texto aparecer no painel Elements, ele está no DOM e o Google pode vê-lo. Se o painel Elements mostrar um contêiner vazio até você clicar na aba, o conteúdo é carregado dinamicamente e o Google não o encontra.
**Como corrigir:** Renderize o conteúdo oculto no HTML do lado do servidor. Use CSS (`display: none` ou alternadores de visibilidade) para o comportamento de mostrar/ocultar, em vez de injeção de conteúdo via JavaScript.
### Dados estruturados ausentes no mobile
Dados estruturados (JSON-LD) devem estar presentes no HTML móvel. Isso é fácil de passar despercebido se o seu tema mobile ou versão AMP usar um template diferente.
**Como verificar:** Abra a página mobile, visualize o código-fonte (`Cmd+Option+U`) e procure por `application/ld+json`. Depois faça o mesmo no desktop. Os mesmos blocos JSON-LD devem aparecer em ambos.
**Como corrigir:** Garanta que seus dados estruturados sejam renderizados no servidor e incluídos na mesma resposta HTML para mobile e desktop. Se estiver usando um CMS, verifique se o plugin de schema ou o tema não está carregando scripts condicionalmente com base na detecção de dispositivo.
### Links de navegação removidos dos menus móveis
Menus móveis frequentemente simplificam ou removem links que existem na navegação desktop: breadcrumbs, links de categorias, colunas do rodapé, links da barra lateral. O Google usa links internos para entender a estrutura do site e distribuir PageRank. Links ausentes no mobile estão ausentes do grafo do Google.
**Como verificar:** Conte as tags `<a href>` no código-fonte desktop vs. mobile. Um design responsivo deve ter contagens aproximadamente iguais. Se a contagem mobile for 30%+ menor, investigue quais links desapareceram.
**Como corrigir:** Adicione os links de navegação ausentes ao menu móvel, menu hambúrguer ou rodapé. Priorize links para páginas de categorias importantes, artigos-chave e páginas superiores.
## Correção nº 2: INP — a métrica de velocidade móvel que a maioria dos sites ignora
Interaction to Next Paint (INP) mede quanto tempo a página leva para responder visualmente após o usuário tocar, clicar ou pressionar uma tecla. O limite é **200 milissegundos ou menos**.
Diferente do FID, que media apenas o atraso de entrada da primeira interação, o INP mede cada interação e relata a **pior** delas. Isso o torna um teste muito mais rigoroso.
### O que prejudica o INP mobile
As causas mais comuns, em ordem:
1. **JavaScript pesado executando na thread principal.** Bundles grandes, componentes React/Vue não otimizados e scripts de rastreamento bloqueiam o navegador de responder a toques.
2. **Manipuladores de clique que fazem trabalho demais antes de atualizar a interface.** Se um toque dispara uma chamada de API, atualização de estado e mudança no DOM antes de mostrar qualquer feedback visual, o INP sofre.
3. **Tags de terceiros.** Análise, widgets de chat, redes de anúncios e scripts de personalização — especialmente quando várias tags competem pela thread principal.
### Como diagnosticar o INP
1. Abra o [PageSpeed Insights](https://pagespeed.google.com/), insira sua URL e role até "Descubra o que seus usuários reais estão experimentando". O valor de INP em "Mobile" é o que o Google usa.
2. No Chrome DevTools, abra o painel **Performance**, clique em gravar, interaja com a página (toque em botões, abra menus, digite em campos) e depois pare a gravação. Procure por tarefas longas (marcadas em vermelho, 200ms+). Esses são seus problemas de INP.
3. Você também pode perguntar ao seu agente de IA: **"Verifique os Core Web Vitals de [URL] e me diga especificamente o que está prejudicando o INP no mobile. Me dê as 3 principais correções em ordem de prioridade."**
### Como corrigir o INP (ordem de prioridade)
```text
Prioridade 1: Adie ou atrase scripts de terceiros não críticos.
→ Carregue widgets de chat, análises e tags de anúncios depois que a página estiver interativa.
→ Use <script defer> ou carregue-os 3-5 segundos após o carregamento da página.
Prioridade 2: Divida tarefas JavaScript longas.
→ Faça code-splitting por rota. Carregue componentes abaixo da dobra via lazy-loading.
→ Mova computação pesada para requestIdleCallback() ou um Web Worker.
Prioridade 3: Faça os manipuladores de clique atualizarem a interface imediatamente.
→ Mostre um estado de carregamento, spinner ou botão desabilitado nos primeiros 50ms.
→ Execute o trabalho real (chamada de API, atualização de estado) após a resposta visual.Correção nº 3: Preparação para crawlers de IA (a camada de 2026)
A indexação mobile-first agora tem uma camada de IA. Quando as AI Overviews do Google ou sistemas de IA de terceiros respondem a uma pergunta, eles extraem do mesmo conteúdo indexado para mobile. Se suas páginas móveis não têm os sinais que os sistemas de IA procuram, você perde citações.
O que os sistemas de IA precisam das suas páginas móveis
Sinal | Por que importa | Verificação rápida |
|---|---|---|
Dados estruturados (JSON-LD) | Ajuda os sistemas de IA a entender entidades, produtos, artigos, FAQs | Ver código-fonte → buscar |
Hierarquia clara de cabeçalhos | Extratores de IA usam H1-H4 para interpretar a estrutura da página | Examine sua página: cada seção tem um cabeçalho descritivo? |
Blocos de resposta concisos | AI Overviews preferem respostas de 2-4 frases próximas ao topo | Sua página responde à pergunta principal nos primeiros 200 palavras? |
Acesso em robots.txt para crawlers de IA | Se bloqueados, sistemas de IA não podem buscar seu conteúdo | Verifique robots.txt para |
Arquivo llms.txt | Ajuda sistemas de IA a descobrir seu conteúdo-chave com eficiência | Verifique |
Prompt rápido de prontidão para IA para seu agente
"Verifique [URL] quanto à prontidão para busca por IA. Me diga: (1) os dados estruturados JSON-LD estão presentes e são válidos? (2) existe uma resposta clara à pergunta principal da página nos primeiros 200 palavras? (3) os crawlers de IA estão permitidos no robots.txt? (4) o arquivo llms.txt existe na raiz? Me dê um PASS/FAIL para cada um e me diga o que corrigir primeiro."
Prompts completos de auditoria mobile-first para iniciantes
Aqui está um conjunto de prompts que você pode copiar para o Claude Code ou Codex agora mesmo. Cada prompt faz uma tarefa específica — sem necessidade de configuração além de ter o agente aberto e apontado para seu projeto ou uma URL.
Prompt 1: Auditoria mobile de página única
Run a mobile-first indexing audit on [SUA URL AQUI].
Check these 8 things and report PASS or FAIL for each with the evidence:
1. Viewport meta tag is correct
2. All body text visible on desktop is also in the mobile HTML source
3. JSON-LD structured data is the same on desktop and mobile
4. Title tag, meta description, and canonical are identical across desktop and mobile
5. Internal link count is roughly equal (not 20%+ fewer on mobile)
6. Images have alt text
7. Mobile Core Web Vitals (LCP, INP, CLS) from CrUX field data if available
8. AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended) are not blocked in robots.txt
For each FAIL, give me the exact fix in one sentence.Prompt 2: Auditoria em lote por tipos de página
I need to audit mobile-first readiness across different page types on my site. Here are 5 URLs, each representing a different template:
1. [URL DA HOME]
2. [URL DE PÁGINA DE PRODUTO OU SERVIÇO]
3. [URL DE POST DE BLOG OU ARTIGO]
4. [URL DE PÁGINA DE CATEGORIA OU COLEÇÃO]
5. [URL DE PÁGINA SOBRE OU CONTATO]
For each URL, check: viewport meta tag, content parity (text + structured data), meta tags consistency, internal links, image alt coverage, and mobile font/tap-target sizing.
Then produce a single table with all 5 URLs as columns and each check as a row. Color-code PASS green, WARN yellow, FAIL red (use emoji 🟢 🟡 🔴 if colors are not supported). Below the table, list the top 3 fixes across all pages in priority order.Prompt 3: Análise aprofundada de paridade de conteúdo
Fetch [URL] with both a desktop user-agent and the Googlebot Smartphone user-agent (Mozilla/5.0 (Linux; Android 6.0.1; Nexus 5X Build/MMB29P) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/W.X.Y.Z Mobile Safari/537.36 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)).
Compare the two versions and report any differences in:
- Visible text content (highlight blocks missing from mobile)
- Structured data (JSON-LD blocks)
- Meta tags (title, description, canonical, robots, hreflang)
- Internal link count and which sections lost links
- Image alt attributes
Do not make any edits. Just produce a diff report.Prompt 4: Diagnóstico de INP e plano de correção
Analyze [URL] for Interaction to Next Paint (INP) issues on mobile.
1. Check if CrUX field data is available and report the current mobile INP value.
2. If CrUX data is unavailable, run a Lighthouse mobile audit and report the Total Blocking Time (TBT) as a proxy indicator.
3. Identify the top 3 JavaScript tasks blocking the main thread during page load and after user interaction.
4. For each problem, give me: the specific file or script causing it, the impact on INP, and the one-line fix.
Format the output as a table: Problem | Source | Impact | Fix.Prompt 5: Auditoria de crawlers de IA + dados estruturados
Check [URL] for AI search and AI crawler readiness:
1. Crawl robots.txt at the domain root. List all rules that mention these user-agents: GPTBot, ClaudeBot, PerplexityBot, Google-Extended, OAI-SearchBot, Amazonbot, Bytespider. If any are blocked, flag it.
2. Extract all JSON-LD blocks from the page. Validate each against Schema.org types. Report which types are present and whether they are complete (all required properties filled).
3. Check if /llms.txt exists at the domain root. If it does, report its content summary. If it does not, note that as a missing AI discovery asset.
4. Check if the page has a clear, self-contained answer (2-4 sentences) to its main topic within the first 200 words of body text.
5. Score the page on AI readiness: 0-100. Deduct points for: missing structured data (-30), blocked AI crawlers (-20 per crawler), no llms.txt (-15), no clear answer block (-20), headings not descriptive (-15).FAQ
P: Ainda posso usar um site mobile separado (m.exemplo.com)? Tecnicamente sim, mas o Google recomenda design responsivo. URLs móveis separadas adicionam complexidade: você precisa manter conteúdo, tags canônicas e hreflang idênticos em dois conjuntos de URLs. Se algo ficar dessincronizado, o Google indexa a versão que rastreou por último. O design responsivo elimina esse risco completamente.
P: E se meu site for apenas desktop — sem versão móvel? Se o Googlebot Smartphone não puder acessar e renderizar seu conteúdo, esse conteúdo não será indexado. Ponto final. Um site apenas desktop em 2026 é efetivamente invisível para o Google. Se você está nessa situação, migrar para um tema responsivo é sua tarefa de maior prioridade.
P: Preciso me preocupar com tamanhos de tablet? O Googlebot rastreia como smartphone, não como tablet. Concentre-se no viewport de smartphone. Dito isso, usuários de tablet são usuários reais — certifique-se de que seu design responsivo não quebre em larguras intermediárias (768-1024px).
P: Como sei se meu site já passou pela transição mobile-first? Abra o Google Search Console → Configurações → verifique a seção "Sobre" para "Rastreador de indexação: Googlebot smartphone". Se estiver assim, você está na indexação mobile-first. Quase todos os sites já estão nessa situação.
P: O Google ainda rastreia meu site com um user-agent de desktop para alguma coisa? Sim. O Google ocasionalmente rastreia com um user-agent de desktop para verificações específicas (verificação de relacionamento, reprocessamento de alguns dados estruturados). Não se assuste se vir o Googlebot desktop nos seus logs. Essas visitas não significam que seu site está na indexação desktop-first.
P: Corrigir problemas de mobile-first vai melhorar minha visibilidade nas AI Overviews? Correções de indexação mobile-first melhoram a base. Se seu conteúdo móvel, dados estruturados e velocidade da página estiverem todos sólidos, seu conteúdo está elegível para ser citado — mas os sistemas de IA do Google ainda escolhem o que citar com base em relevância, autoridade e qualidade da resposta. Corrigir problemas de mobile-first remove um bloqueador; não garante inclusão nas AI Overviews.
Autor: Julian Mercer, Profissional de Technical SEO com 14 anos de experiência na Auspia. Julian escreve sobre rastreabilidade, renderização, schema, arquitetura de sites e as bases técnicas que tornam o conteúdo detectável por mecanismos de busca e sistemas de IA.
