Rastreador com renderização de JavaScript

O SpiderHead pode renderizar páginas em um navegador headless pelo Playwright e manter o HTML bruto e o DOM renderizado lado a lado, para você ver o que só existe depois que os scripts rodam. A renderização é opcional e vem desativada por padrão.

O que faz

Bruto versus renderizado

O render-check carrega uma URL duas vezes: como o servidor a envia e em um navegador, depois que os scripts rodam. Ele compara tags title, tags canonical, links e conteúdo que aparecem ou desaparecem. Em um rastreamento, defina rendering.mode como js e o SpiderHead renderiza de forma seletiva: por padrão, testa algumas URLs de cada padrão de template e renderiza os padrões que diferem, até 30 páginas.

  • Rotas renderizadas ficam registradas como evidência; rastreá-las exige ativação separada (rendering.rendered_links.crawl)
  • Tempos de laboratório de uma execução, não Core Web Vitals de campo

Só quando você precisa

O navegador é um extra opcional, então o rastreamento básico não precisa dele. Instale o grupo render e um navegador, e conte com cerca de 150 MB para o Chromium. Rode o render-check em uma página de cada template primeiro e renderize o site inteiro só se as páginas bruta e renderizada forem diferentes.

  • pip install -e ".[render]"
  • python -m playwright install chromium

Três passos, um rastreamento salvo

  1. Busque o HTML bruto e o DOM renderizado

    O render-check carrega a URL duas vezes: uma como o servidor a envia e outra no Chromium pelo Playwright, depois que os scripts rodam.

  2. Compare o que aparece só depois dos scripts

    A comparação conta palavras e links que existem apenas após a renderização e sinaliza uma casca de app vazia, como um simples ponto de montagem #root ou #app.

  3. Leia erros de console e tempos de laboratório

    Com rendering.artifacts.console_errors ativado (vem desligado por padrão), os erros de script registrados durante a renderização são reportados como JS_CONSOLE_ERRORS. Os tempos vêm de uma execução local e são dados de laboratório, não Core Web Vitals de campo.

Verificações deste recurso

VerificaçãoO que significaGravidadeEvidência
JS_CONSOLE_ERRORSA página registrou erros de JavaScript no console do navegador durante a renderizaçãoImportantTexto do erro do console na execução renderizada
ROBOTS_BLOCKS_RESOURCESO robots.txt bloqueia arquivos .js, .css ou _next/static necessários para a renderizaçãoTipRegra do robots.txt que corresponde ao caminho do recurso (do robots-check)
AJAX_CRAWLING_SCHEME_URLUma página, ou um link que ela contém, usa o esquema AJAX obsoleto #! ou _escaped_fragment_TipA URL que usa o esquema
Também no registro de verificações
RENDER_RESOURCE_BLOCKEDNOINDEX_ONLY_IN_RAW_HTMLCANONICAL_ONLY_IN_RENDERED_HTMLPAGE_TITLE_ONLY_IN_RENDERED_HTML

Um comando

bash
seohead render-check --url https://example.com/

Instale primeiro: guia de instalação. Todo comando também funciona como ferramenta MCP para agentes de IA.

O que você precisa

  • Uma URL de página para o render-check
  • O extra render e um navegador do Playwright instalado
  • Para um rastreamento com renderização: uma configuração com rendering.mode definido como js

Limites

  • Os tempos vêm de uma única execução local e não são dados de campo
  • O navegador se recusa a rodar como root
  • As ações na página são declarativas (clique, rolagem, espera, extração); não dá para fornecer um JavaScript próprio
  • O networkidle pode nunca acontecer em sites com conexões persistentes

Perguntas

Preciso de um navegador em todo rastreamento?
Não. O rastreamento básico funciona sem ele. O Chromium é um extra opcional para o render-check e para rastreamentos com renderização: pip install -e ".[render]" e depois python -m playwright install chromium (cerca de 150 MB).
A verificação de renderização altera algo no meu site?
Não. Ela carrega a URL e os recursos dela como um navegador faria, e não edita nada. Ações na página, como cliques, rodam só se você as configurar em um rastreamento.
Os números de velocidade são Core Web Vitals?
Não. LCP, CLS e os tempos vêm de uma execução em uma máquina. São medições de laboratório, não dados de campo do Chrome UX Report.
Dá para renderizar como celular?
Dá. Adicione --viewport mobile para usar a identidade de smartphone e o viewport embutidos. Use --user-agent para um user agent personalizado.
E se a página nunca terminar de carregar?
Use --wait domcontentloaded. O padrão é load. O networkidle pode nunca acontecer em sites com conexões persistentes, então evite-o nesses casos.

Teste no seu próprio site