Crawler con rendering JavaScript

SpiderHead può renderizzare le pagine in un browser headless tramite Playwright e conservare l'HTML grezzo e il DOM renderizzato fianco a fianco, così vedi ciò che esiste solo dopo l'esecuzione degli script. Il rendering è opzionale e disattivo per impostazione predefinita.

Cosa fa

Grezzo contro renderizzato

render-check carica una URL due volte: come la manda il server e in un browser dopo l'esecuzione degli script. Confronta title, canonical, link e contenuti che compaiono o scompaiono. In una scansione, imposta rendering.mode su js e SpiderHead renderizza in modo selettivo: per impostazione predefinita esplora qualche URL per pattern di template e renderizza i pattern che differiscono, fino a 30 pagine.

  • Le rotte renderizzate sono registrate come evidenza; scansionarle è un'opzione separata (rendering.rendered_links.crawl)
  • Tempi di laboratorio da una sola esecuzione, non Core Web Vitals sul campo

Solo quando serve

Il browser è un extra opzionale, quindi la scansione base non ne ha bisogno. Installa il gruppo render e un browser, e calcola circa 150 MB per Chromium. Usa render-check prima su una pagina per template, e renderizza un intero sito solo se grezzo e renderizzato differiscono.

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

Tre passaggi, una scansione salvata

  1. Scarica l'HTML grezzo e il DOM renderizzato

    render-check carica la URL due volte: una come la manda il server e una in Chromium tramite Playwright dopo l'esecuzione degli script.

  2. Confronta ciò che appare solo dopo gli script

    Il confronto conta parole e link che esistono solo dopo il rendering e segnala una app shell vuota come un punto di mount #root o #app nudo.

  3. Leggi gli errori di console e i tempi di laboratorio

    Con rendering.artifacts.console_errors attivo (è disattivo per impostazione predefinita), gli errori di script registrati durante il rendering vengono segnalati come JS_CONSOLE_ERRORS. I tempi vengono da un'esecuzione locale e sono dati di laboratorio, non Core Web Vitals sul campo.

Controlli di questa funzionalità

ControlloCosa significaGravitàEvidenza
JS_CONSOLE_ERRORSLa pagina ha registrato errori JavaScript nella console del browser durante il renderingImportantTesto degli errori di console dall'esecuzione renderizzata
ROBOTS_BLOCKS_RESOURCESrobots.txt blocca file .js, .css o _next/static serviti al renderingTipRegola di robots.txt che corrisponde al percorso della risorsa (da robots-check)
AJAX_CRAWLING_SCHEME_URLUna pagina o un link che contiene usa lo schema AJAX deprecato #! o _escaped_fragment_TipLa URL che usa lo schema
Anche nel registro dei controlli
RENDER_RESOURCE_BLOCKEDNOINDEX_ONLY_IN_RAW_HTMLCANONICAL_ONLY_IN_RENDERED_HTMLPAGE_TITLE_ONLY_IN_RENDERED_HTML

Un solo comando

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

Prima installa SpiderHead: guida all'installazione. Ogni comando funziona anche come strumento MCP per agenti AI.

Cosa ti serve

  • Una URL di pagina per render-check
  • L'extra render e un browser Playwright installati
  • Per una scansione renderizzata: una configurazione di scansione con rendering.mode impostato su js

Limiti

  • I tempi vengono da un'esecuzione locale e non sono dati sul campo
  • Il browser si rifiuta di girare come root
  • Le azioni di pagina sono dichiarative (click, scroll, wait, extract); non puoi fornire il tuo JavaScript
  • networkidle può non verificarsi mai su siti con connessioni persistenti

Domande

Serve un browser per ogni scansione?
No. La scansione base funziona senza. Chromium è un extra opzionale per render-check e le scansioni renderizzate: pip install -e ".[render]", poi python -m playwright install chromium (circa 150 MB).
Un controllo di rendering cambia qualcosa sul sito?
No. Carica la URL e le sue risorse come fa un browser e non modifica nulla. Le azioni di pagina come i click girano solo se le configuri in una scansione.
I numeri di velocità sono Core Web Vitals?
No. LCP, CLS e i tempi vengono da un'esecuzione su una macchina. Sono misure di laboratorio, non dati sul campo del Chrome UX Report.
Posso renderizzare come smartphone?
Sì. Aggiungi --viewport mobile per usare l'identità e il viewport dello smartphone integrati. Usa --user-agent per un'identità personalizzata.
E se la pagina non finisce mai di caricarsi?
Usa --wait domcontentloaded. Il predefinito è load. networkidle può non verificarsi mai su siti con connessioni persistenti, quindi evitalo in quei casi.