O que um simulador de rastreador Google realmente faz
Um simulador de rastreador envia uma solicitação HTTP para sua URL com uma string user-agent correspondente ao bot que você seleciona, busca a resposta e registra o código de status, cabeçalhos e HTML bruto. Depois carrega a página em um navegador headless—Chrome com JavaScript ativado—aguarda a estabilização do DOM, captura o HTML final renderizado e o compara com o HTML inicial para mostrar o que JavaScript alterou.
Extrai o texto visível—o que um bot vê após remover tags HTML, CSS e scripts—porque esse é o conteúdo que Google indexa. Sinaliza recursos que falharam ao carregar: imagens, fontes, arquivos CSS ou pacotes JavaScript bloqueados por CORS, 404s ou erros de servidor. Verifica tags robots meta, cabeçalhos X-Robots-Tag e tags canônicas que podem impedir a indexação mesmo se a página for carregada com sucesso.
Três categorias de problema aparecem em todos os testes de rastreamento. A primeira é conteúdo ausente do HTML bruto que só aparece após a execução do JavaScript. Se seu título de destaque ou descrição de produto for renderizado no cliente, Googlebot pode não vê-lo durante a busca inicial. A segunda é o tempo limite de renderização. Se o JavaScript levar mais de cinco segundos para terminar, Googlebot pode indexar a página incompleta. A terceira são recursos bloqueados. Se seus arquivos CSS ou JavaScript críticos retornarem 403 ou 404, a página renderiza danificada e Googlebot vê um layout quebrado.
Como usar este simulador de rastreador Google
- Cole a URL da página em Page URL. Use a versão canônica—https, www se aplicável, sem parâmetros UTM a menos que você esteja testando como os parâmetros afetam a renderização.
- Escolha um User-agent no dropdown. Googlebot Desktop é o padrão. Googlebot Mobile simula indexação mobile-first com viewport móvel. Googlebot-Image testa rastreamento específico de imagens. Bingbot testa o rastreador do Bing. GPTBot simula o rastreador de treinamento da OpenAI.
- Clique em Simulate crawler. Você obtém quatro seções: HTML bruto, HTML renderizado, texto visível e um log de recursos mostrando quais arquivos foram carregados ou falharam.
- Compare as abas Raw HTML e Rendered HTML. Se a versão renderizada tem conteúdo ausente do bruto, esse conteúdo é injetado por JavaScript. Se o tempo de renderização exceder cinco segundos, mostramos um aviso.
- Verifique a lista Blocked resources. Qualquer recurso que retornar um status diferente de 200 é sinalizado. Se CSS ou JavaScript crítico for bloqueado, a página provavelmente renderiza danificada para Googlebot.
- Role para Visible text. Isso é o que Google indexa. Se sua palavra-chave alvo aparecer aqui, Google pode classificar a página para ela. Se não aparecer, a palavra-chave é invisível.
Tente simular um aplicativo de página única construído com React ou Vue. O HTML bruto frequentemente contém um <div id="root"></div> vazio e uma tag script. O HTML renderizado mostra a página completa após a execução do JavaScript. Se a renderização levar oito segundos por causa de chamadas de API lentas, avisamos que Googlebot pode expirar e indexar o shell vazio.
Por que HTML bruto versus HTML renderizado importa
O pipeline de indexação do Google tem duas fases. A primeira é a busca inicial, onde Googlebot baixa o HTML bruto. A segunda é a renderização, onde Googlebot executa JavaScript em uma instância Chrome headless e captura o DOM final. A renderização acontece horas ou dias após a busca inicial, e nem toda página é renderizada. Páginas com tempos de carregamento rápidos, links internos fortes e sem erros de JavaScript são priorizadas.
Três consequências práticas.
Conteúdo em HTML bruto indexa mais rápido. Se seu H1, meta description e primeiro parágrafo estão no HTML inicial, Googlebot pode indexá-los imediatamente. Se aparecerem apenas após a execução do JavaScript, a indexação aguarda a fila de renderização. Em um site com 10.000 páginas, esse atraso pode ser dias ou semanas.
Erros de JavaScript bloqueiam a indexação. Se sua página lançar um erro de console durante a renderização, Googlebot pode ver uma página em branco. Nosso simulador executa a página e captura logs de console. Um erro como "Uncaught TypeError: Cannot read property 'map' of undefined" pode impedir que a página inteira seja renderizada.
Orçamento de renderização é finito. Google aloca um orçamento de rastreamento e um orçamento de renderização por site. Se renderizar sua homepage levar 10 segundos, Google pode renderizá-la menos frequentemente que competidores cujas páginas renderizam em dois segundos. Relatamos o tempo de renderização para que você saiba se está acima do orçamento.
Recursos bloqueados e impacto na indexação
Um recurso bloqueado é qualquer arquivo—CSS, JavaScript, imagem, fonte—que a página tentou carregar mas recebeu um código de status 4xx ou 5xx, ou foi bloqueado por robots.txt ou política CORS. Googlebot ignora o arquivo e continua a renderização, mas o arquivo ausente pode quebrar layout ou funcionalidade.
Arquivos CSS críticos controlam layout. Se styles.css for bloqueado por robots.txt, Googlebot renderiza a página sem estilos, significando que conteúdo pode estar oculto por estados CSS padrão—acordeões recolhidos, abas ocultas, modais fora da tela. O conteúdo existe no DOM mas não é visível, então Google pode não indexá-lo.
Arquivos JavaScript críticos controlam interatividade e busca de dados. Se app.js for bloqueado, roteamento do lado do cliente quebra e links dentro do app não funcionam. Se api-client.js for bloqueado, sua página de produto não pode buscar dados de produto, então Googlebot vê um spinner de carregamento em vez de detalhes do produto.
Imagens e fontes são menos críticas. Uma imagem ausente não quebra a indexação, mas pode prejudicar sinais de experiência do usuário se o layout mudar de página ou placeholders aparecerem. Uma fonte ausente volta para fontes do sistema, o que geralmente é bom para indexação.
Nosso simulador lista todos os recursos, sua URL, código de status e tipo. Se um recurso falhou, mostramos o erro. Se foi bloqueado por robots.txt, sinalizamos. Use esta lista para corrigir bloqueios no nível do servidor ou em seu arquivo robots.txt.
Indexação mobile-first e viewport
Em 2026, Google usa indexação mobile-first para todos os sites. Isso significa que Googlebot Mobile é o rastreador primário e a versão móvel de sua página determina classificações mesmo para buscas desktop. Se sua página móvel oculta conteúdo atrás de um toggle "Ler mais" ou remove widgets da barra lateral, Googlebot não vê esse conteúdo e ele não conta para classificações.
Testar com Googlebot Mobile como o user-agent mostra o que o rastreador móvel vê. Renderizamos a página com um viewport de 375px—largura do iPhone SE—para que você veja o layout móvel. Se seu CSS oculta elementos em larguras móveis, eles estão ausentes do HTML renderizado. Se seu JavaScript lazy-loads imagens ou texto conforme o usuário rola, e Googlebot não rola, esse conteúdo é invisível.
Dois fixes são comuns. O primeiro é renderização do lado do servidor ou geração de site estático, onde o conteúdo completo está no HTML bruto independentemente do viewport. O segundo é garantir que CSS móvel não defina display: none em conteúdo importante. Use opacity: 0 ou position: absolute; left: -9999px para acessibilidade, mas até mesmo esses podem prejudicar a indexação se usados em excesso.
Tags robots meta e cabeçalhos X-Robots-Tag
Mesmo que uma página seja carregada com sucesso, uma tag <meta name="robots" content="noindex"> ou um cabeçalho HTTP X-Robots-Tag: noindex diz ao Googlebot para não indexá-la. Nosso simulador verifica ambos e os relata no resumo.
Valores comuns são noindex (não adicione aos resultados de busca), nofollow (não siga links nesta página), noarchive (não cache), nosnippet (não mostre um snippet nos resultados) e none (equivalente a noindex, nofollow). Se seu site de staging acidentalmente entra em produção com tags noindex ainda presentes, você perde todo o tráfego de busca. Verificar antes do lançamento evita isso.
O cabeçalho HTTP tem precedência sobre a tag HTML se ambos estiverem presentes e diferirem. Uma página com <meta name="robots" content="index"> mas X-Robots-Tag: noindex não será indexada. Nosso simulador mostra ambos para que você possa identificar conflitos.
Erros comuns
- Renderizar a página inteira no cliente. Se o HTML bruto está vazio e tudo aparece após JavaScript, a indexação é lenta e frágil. Mova conteúdo crítico para o HTML inicial via renderização do lado do servidor ou pré-renderização.
- Bloquear JavaScript ou CSS em robots.txt. Google precisa desses arquivos para renderizar a página.
Disallow: *.jsouDisallow: *.cssquebra a renderização. Bloqueie apenas se tiver um motivo forte e reverify com o simulador depois. - Ignorar erros de console. Uma única exceção não capturada pode parar a renderização. Verifique o log do console na saída do simulador e corrija erros antes de fazer deploy.
- Testar apenas com um navegador, não com Googlebot. Navegadores são mais tolerantes que Googlebot. Uma página que funciona em Chrome pode falhar em Chrome headless devido a polyfills ausentes ou verificações user-agent. Simule Googlebot para ver a experiência real.
- Assumir que Googlebot rola. Ele não rola. Conteúdo lazy-loaded acionado por eventos de scroll é invisível a menos que você implemente Intersection Observer ou carregue tudo na renderização inicial.
- Não testar após atualizações de framework. Um bump de versão Next.js ou Gatsby pode mudar como a geração estática funciona. Re-verifique a renderização após atualizações para confirmar que o conteúdo ainda está no HTML bruto.
Dicas avançadas
- Teste a mesma URL com Googlebot Desktop e Googlebot Mobile. Se o conteúdo diferir, a indexação mobile-first pode classificar a página diferentemente do que você espera.
- Compare tempos de renderização em páginas. Se sua homepage renderiza em 2 segundos mas páginas de produto levam 8 segundos, identifique a chamada de API lenta ou script pesado e otimize.
- Verifique a seção Visible text para presença de palavra-chave. Se sua palavra-chave alvo está na fonte HTML mas não no texto visível, pode estar oculta por CSS ou JavaScript, significando que não conta para classificações.
- Use o simulador após fazer deploy de uma novo recurso. Um fluxo de checkout, widget de chat ao vivo ou script de analytics pode quebrar a renderização se lançar erros. Capturá-lo post-deploy previne quedas de indexação.
- Se recursos bloqueados forem encontrados, cross-check com o robots.txt checker para confirmar se robots.txt é a causa. Se não, verifique logs de servidor para erros 403 ou CORS.
- Combine esta ferramenta com o website metadata checker para confirmar que title, meta e schema estão presentes no HTML renderizado, não apenas na fonte bruta.
Após simular, se você descobrir que JavaScript é necessário para conteúdo crítico, considere mudar para renderização do lado do servidor ou geração estática. Se recursos bloqueados são o problema, atualize seu robots.txt com o robots.txt file generator. Se você quer ver como todos os fatores de SEO on-page—renderização, metadados, canônicos, links internos—se acumulam, use o SEO checklist para uma auditoria de 20 pontos.