Il 96% delle organizzazioni ha aumentato o mantenuto l’uso dell’open source lo scorso anno, secondo il rapporto 2025 State of Open Source — e il motivo numero uno resta ancora "nessun costo di licenza". Ma c’è un dettaglio che spesso non viene detto quando si prende uno scraper da GitHub: "open source" e "sicuro da usare in un prodotto commerciale" non sono affatto la stessa cosa.
Quest’anno ho passato parecchio tempo a valutare i soliti nomi — Scrapy, Playwright, Puppeteer, e i nuovi crawler AI-native come Crawl4AI e ScrapeGraphAI — e il fattore che conta davvero in una decisione aziendale quasi mai compare nei classici riepiloghi dei "migliori scraper": il tipo di licenza. Molte liste ordinano per stelle GitHub. Io li ordino in base a ciò che succede quando il reparto legale chiede: "Aspetta, questo è AGPL?" Questa lista ordina 12 strumenti prima per categoria adatta al caso d’uso (parser, automazione del browser, scraper AI-native, framework di crawling, estensioni no-code) e solo dopo per licenza, perché è così che avvengono davvero le decisioni.
Perché il tipo di licenza è il primo filtro per qualsiasi Web Scraper open source
"Open source" non significa "libero di farci qualsiasi cosa". La Open Source Definition vieta esplicitamente di discriminare l’uso commerciale — quindi ogni strumento in questa lista consente l’uso business. Ma come puoi usarlo, e quali obblighi scattano quando lo distribuisci, dipende interamente dalla licenza specifica.
Le licenze permissive — MIT, BSD-3-Clause, Apache-2.0 — ti lasciano fare quasi tutto, purché tu mantenga l’avviso di copyright. Apache-2.0 fa un passo in più con una concessione esplicita sui brevetti, ed è la licenza che in genere piace di più agli avvocati. Nessuna di queste tre ti obbliga a pubblicare il tuo codice sorgente.
Le licenze copyleft sono un’altra storia. AGPL-3.0 è quella che mette più spesso in difficoltà le persone, ed è proprio la licenza con cui viene distribuito il core self-hosted di Firecrawl (gli SDK sono MIT, ma il motore di scraping principale è AGPL). In base alla Sezione 13 della AGPL-3.0, se modifichi il programma coperto e permetti agli utenti di interagire con quella versione modificata via rete, devi offrire il relativo codice sorgente. Questo non significa che "tutto il SaaS diventa open source" come a volte si legge nei forum: l’obbligo riguarda nello specifico un programma coperto modificato offerto per interazione remota. Ma è una questione legale reale, e prima di costruire un prodotto closed-source sopra questo tipo di licenza serve un parere professionale, non un thread di Stack Overflow.
Poi c’è la categoria più nebulosa dell’"open-core". Web Scraper, l’estensione Chrome, ha su GitHub un vecchio repository LGPL-3.0 — ma l’ultimo commit di quel codice risale al 2017, e non esiste una mappatura verificata tra quel sorgente datato e l’estensione attualmente nel Chrome Web Store (versione 1.111.13 al momento in cui scrivo). La lettura più onesta: l’estensione locale è gratuita, il livello Cloud con scheduling e rotazione proxy è un prodotto proprietario separato, e chiamare il tutto "open source" tende a nascondere questa distinzione.
Come abbiamo confrontato questi 12 migliori strumenti open source per web scraping
Ho valutato ogni strumento su sette dimensioni: tipo di licenza e attrito sull’uso commerciale, linguaggio/runtime, supporto nativo al rendering JavaScript (rispetto alla necessità di affiancare un plugin), curva di apprendimento, costi nascosti di compute o proxy, segnali di salute della community (issue aperte, frequenza dei rilasci, ultimo commit) e caso d’uso più adatto.
L’elenco è organizzato per categoria — parser statici, framework di automazione del browser, scraper AI-native, framework di crawling, poi l’unica estensione browser no-code — invece che per numero di stelle. È una scelta voluta. Beautiful Soup e Scrapy risolvono problemi completamente diversi anche se sono entrambi molto popolari; metterli sullo stesso piano non aiuta davvero nessuno a scegliere.
| Criterio | Cosa ho verificato |
|---|---|
| Licenza e aderenza al commerciale | Licenza esatta del repository, requisiti di attribuzione, clausole copyleft/rete |
| Runtime e aderenza al team | Python, Node/TypeScript, Java o multi-linguaggio |
| Rendering JS | Supporto nativo del browser, pairing con plugin o assenza totale |
| Ambito del framework | Solo parser, driver browser, pipeline di crawl completa o prodotto gestito |
| Salute della community | Stelle GitHub, data dell’ultima release, issue aperte, ultimo push |
| Costi nascosti | Memoria del browser, bisogno di proxy, dipendenza da API di modelli, carico di manutenzione |
| Miglior utilizzo | Corrispondenza precisa con team/task, supportata da capacità documentate o issue |
Un’unica nota onesta sui numeri di salute della community: Beautiful Soup sviluppa il suo codice canonico su Launchpad, non su GitHub, quindi il conteggio stelle GitHub (223 stelle in una mirror non ufficiale, aggiornata l’ultima volta nel 2022) non è confrontabile con gli altri 10 strumenti. Lo segnalo esplicitamente sotto, invece di fingere che rientri perfettamente nella stessa tabella.
La migliore libreria open source di parsing per siti statici: BeautifulSoup
BeautifulSoup è una libreria Python per navigare e cercare alberi di parsing HTML/XML. Non scarica pagine, non esegue JavaScript e non gestisce code di crawling: prende semplicemente markup che hai già e ti permette di esplorarlo con un’API semplice. È proprio questa la sua forza: lo strumento ideale quando hai già l’HTML e devi solo estrarre i dati.
- Licenza: MIT — permissiva, nessun obbligo oltre a mantenere l’avviso
- Curva di apprendimento: davvero adatta ai principianti; il modello a oggetti è molto tollerante
- Rendering JS: nessuno, nativamente — va affiancata a uno strumento che scarichi prima l’HTML renderizzato
- Limite noto: la documentazione ufficiale ammette che "non sarà mai veloce come i parser sottostanti", e i diversi backend (lxml vs. html5lib vs. html.parser) possono produrre alberi anche molto diversi su HTML malformato
Ideale per: script interni rapidi ed estrazioni una tantum da HTML statico o già scaricato — non per la scala, non per siti molto dinamici.
Il miglior framework open source di automazione browser per test legacy cross-browser: Selenium
Selenium è il nome più storico di questa lista, nato per il browser testing e poi riadattato da metà del mondo dello scraping. La sua caratteristica distintiva non è la velocità, ma la copertura. I binding ufficiali di Selenium 4 coprono Java, Python, C#, Ruby e JavaScript, e controlla Chrome, Edge, Firefox e Safari tramite lo standard W3C WebDriver.
- Licenza: Apache-2.0
- Salute GitHub: 34.366 stelle, 98 issue aperte, 12 release stabili nell’ultimo anno (ultima: 4.47.0)
- Rendering JS: nativo, attraverso il browser reale
- Attrito documentato: la documentazione di Selenium indica la sincronizzazione come "una delle sfide più comuni" — il fatto che il documento sia caricato non garantisce che gli elementi aggiunti via JS siano pronti, e un DOM dinamico può generare
StaleElementReferenceException
Ideale per: team che hanno bisogno di copertura multi-browser o multi-linguaggio, oppure che già usano Selenium per QA e vogliono riutilizzare le stesse competenze per lo scraping.
Il miglior framework open source di automazione browser per siti moderni molto basati su JavaScript: Playwright
Playwright, mantenuto da Microsoft, è la risposta moderna al classico "Selenium è lento e macchinoso". Automatizza nativamente Chromium, Firefox e WebKit, con controlli di actionability che attendono automaticamente che gli elementi siano davvero pronti — visibili, stabili, abilitati — prima di interagirci. Solo questo comportamento elimina una grande quantità del boilerplate manuale di WebDriverWait che gli utenti Selenium scrivono a mano.
Ecco la sfumatura che si perde in quasi ogni discussione "Scrapy vs. Playwright vs. Selenium": Scrapy non esegue JavaScript da solo. Ha bisogno di un plugin separato — scrapy-playwright — da aggiungere per ottenere il rendering del browser. Playwright e Puppeteer fanno rendering in modo nativo perché il rendering è il prodotto.
- Licenza: Apache-2.0
- Salute GitHub: 94.443 stelle, 15 release stabili nell’ultimo anno (ultima: 1.62.1)
- Costo nascosto: solo i binary del browser pesano circa 281 MB per Chromium, 187 MB per Firefox e 180 MB per WebKit — e una breaking change nella 1.38 ha fermato i download automatici dei browser, quindi il pinning delle versioni nell’immagine Docker è fondamentale
Ideale per: team che fanno scraping di SPA React/Vue e vogliono un comportamento affidabile cross-browser senza scrivere a mano tutta la logica di attesa.
Il miglior strumento open source di automazione browser per progetti centrati su Chrome: Puppeteer
Puppeteer, la libreria di automazione di Google, è pensata prima di tutto per Chrome — integrazione profonda con il Chrome DevTools Protocol, generazione integrata di screenshot/PDF e tutto il resto. Vale la pena correggere un’idea ormai superata: l’ultima versione supporta ufficialmente anche Firefox stabile, quindi oggi "solo Chrome" non è più del tutto corretto, anche se Chrome resta il caso d’uso principale.
- Licenza: Apache-2.0
- Salute GitHub: 95.458 stelle, 249 issue aperte — un numero di issue sensibilmente più alto di Playwright, da considerare se valuti la reattività del progetto
- Realtà anti-bot: l’issue #7006 di Puppeteer documenta un normale navigazione bloccata da una challenge Cloudflare — renderizzare una pagina non ti rende invisibile ai sistemi anti-bot, punto e basta
Ideale per: team Node.js standardizzati su Chrome, soprattutto se oltre allo scraping devono generare PDF e screenshot.
Il miglior scraper open source AI-native per pipeline LLM e RAG: Crawl4AI
Crawl4AI usa Playwright sotto il cofano ed è progettato per produrre Markdown pulito per pipeline LLM e RAG invece del classico HTML grezzo. Supporta sia una modalità "clean Markdown" sia una modalità "Fit Markdown" ottimizzata per le finestre di contesto, oltre all’estrazione opzionale via LLM se la vuoi; il filtraggio CSS/XPath e BM25 funziona senza dover toccare alcuna API di modello.
Una precisazione importante: GitHub etichetta il repository come Apache-2.0, ma il file di licenza reale aggiunge un obbligo di attribuzione per usi e distribuzioni pubbliche. Non è la classica Apache-2.0: è Apache-2.0 più una condizione specifica del progetto, quindi il documento da leggere è il file di licenza, non il badge nella sidebar di GitHub.
- Salute GitHub: 77.959 stelle, ultima release v0.9.2 (luglio 2026)
- Requisiti di risorse: la guida al self-hosting consiglia almeno 4 GB di RAM disponibili per il container
- Instabilità documentata: il changelog della v0.9.0 ha registrato breaking change nelle default di autenticazione del server Docker e lo spostamento di moduli — è un target in rapido movimento, quindi blocca le versioni
Ideale per: team Python che alimentano agent LLM o pipeline RAG con dati web freschi e che possono gestire l’infrastruttura browser.
Il miglior scraper open source AI-native per deployment self-hosted (con una clausola di licenza da non ignorare): Firecrawl
Il core self-hosted di Firecrawl è il punto in cui la questione AGPL diventa concreta. È un crawler API-first che restituisce Markdown, HTML, screenshot e dati strutturati — capacità reali, costruite su Fetch e Playwright. Ma la parte più rifinita che molti associano a "Firecrawl" — gestione anti-bot, rotazione proxy, layer stealth Fire-engine — appartiene a Firecrawl Cloud, non al repository self-hosted. La documentazione ufficiale di self-hosting di Firecrawl dichiara chiaramente che Fire-engine e il comportamento anti-bot avanzato non sono inclusi nello stack self-hosted di default, e che screenshot e azioni di pagina lo richiedono.
- Licenza: principalmente AGPL-3.0-or-later per il core, MIT per gli SDK
- Salute GitHub: 166.527 stelle — davvero enorme per questa categoria
- Realtà di setup: self-hosting significa mettere in piedi Redis, RabbitMQ, PostgreSQL e, opzionalmente, FoundationDB — è un’operazione multi-servizio, non un singolo container
Ideale per: strumenti interni o progetti open source che non hanno problemi con l’obbligo AGPL di offrire il sorgente. Prima di costruire un prodotto commerciale closed-source sopra il core self-hosted, è bene farsi approvare il tutto dal legale.
Il miglior scraper open source AI-native per estrazione in linguaggio naturale: ScrapeGraphAI
ScrapeGraphAI ti permette di descrivere in linguaggio naturale ciò che vuoi, invece di scrivere selettori — è una pipeline basata su grafo in cui le chiamate LLM svolgono il lavoro di mappatura dei campi. La libreria con licenza MIT usa la tua infrastruttura: la tua API key LLM (o un modello locale Ollama, se preferisci evitare il costo dei token), la tua istanza Playwright configurata.
Ed è qui il punto da dire apertamente: "open source" non significa "costo operativo zero". Ogni estrazione consuma token sul modello che hai collegato. Inoltre, l’estrazione guidata dal prompt ha una modalità di fallimento che gli strumenti basati su selettori non hanno: una issue aperta segnala che la pipeline completa tutte le fasi con successo ma restituisce campi vuoti/NA per dati che erano chiaramente presenti sulla pagina — un fallimento silenzioso che CSS/XPath deterministici di solito non producono.
- Licenza: MIT
- Salute GitHub: 29.447 stelle, ultima release stabile v2.1.6
Ideale per: attività di estrazione irregolari e occasionali, dove la flessibilità del prompt vale il costo del modello e il lavoro di validazione.
Il miglior scraper open source AI-native per estrazioni leggere e senza modello: AutoScraper
AutoScraper salta del tutto l’LLM. Gli dai un URL e un valore di esempio da estrarre; lui deduce le regole strutturali della pagina e le riusa su pagine simili. Niente API key di un modello, niente consumo di token — solo requests e BeautifulSoup sotto il cofano.
Attenzione all’etichetta "abbandonato" che alcuni thread dei forum gli appiccicano. Non è accurata: ci sono stati commit reali a metà 2025, e l’ultimo push del repository risale a luglio 2026. Però la release che la maggior parte delle persone installerebbe con pip install è ancora la v1.1.14, del 2022. La definizione giusta è "rilasci pacchettizzati lenti", non "progetto morto".
- Licenza: MIT
- Salute GitHub: 7.844 stelle
- Limite netto: nessun rendering JS nativo — chiama
requests.get()e analizza l’HTML che riceve, senza eccezioni
Ideale per: piccoli lavori ripetitivi su pagine statiche strutturalmente stabili, quando accetti di riaddestrare lo strumento ogni tanto dopo un restyling.
Il miglior framework open source di crawling per progetti Python su larga scala: Scrapy
Scrapy è il framework Python di crawling di livello produzione — motore, scheduler, downloader, pipeline degli item, tutto. Se Beautiful Soup è un bisturi, Scrapy è una sala operatoria completa: networking asincrono, controlli di concorrenza per dominio, AutoThrottle ed exporter che scrivono direttamente su CSV, JSON, JSON Lines, XML o storage cloud.
La sfumatura già menzionata prima va ribadita qui, perché è la principale fonte di confusione su Scrapy: Scrapy non ha rendering JavaScript nativo. La documentazione ufficiale consiglia prima di trovare e riprodurre la richiesta dati sottostante — perché di solito è più veloce e più completa rispetto al rendering di un intero browser — e di usare scrapy-playwright solo quando il browser è davvero indispensabile.
- Licenza: BSD-3-Clause
- Salute GitHub: 63.830 stelle, 304 issue aperte, 9 release stabili nell’ultimo anno (ultima: 2.17.0)
- Gap sui rate limit: una richiesta di miglioramento aperta segnala che AutoThrottle si regola sulla latenza, non sulle risposte HTTP 429 — il backoff sensibile alla risposta lo devi ancora costruire tu
Ideale per: crawling su larga scala di siti statici, quando contano più pipeline strutturate e flessibilità di export che il rendering JS.
Il miglior framework open source di crawling per build Node.js in produzione: Crawlee
Crawlee, del team Apify, è l’equivalente Node/TypeScript più vicino a Scrapy — con la differenza che il rendering JavaScript non viene aggiunto dopo: è integrato fin dall’inizio tramite classi crawler basate su Playwright e Puppeteer che si appoggiano a un livello condiviso di coda, storage e rotazione proxy.
- Licenza: Apache-2.0
- Salute GitHub: 25.364 stelle, 8 release stabili nell’ultimo anno (ultima: 3.18.1)
- Dettaglio intelligente: il suo
AutoscaledPoolregola dinamicamente la concorrenza in base al carico reale di CPU, memoria ed event loop — e la documentazione avverte esplicitamente che impostare una concorrenza minima troppo alta può mandare in crash l’intero crawl
Ideale per: team Node.js/TypeScript che vogliono gestione pronta per la produzione e rendering JS senza assemblare da soli pezzi equivalenti a Scrapy.
Il miglior framework open source di crawling per indicizzazione enterprise in Java: Apache Nutch
Apache Nutch è l’eccezione in questa lista — un crawler Java pensato per l’indicizzazione web su larga scala, di solito in alimentazione a Solr, Elasticsearch o OpenSearch. Non è lo strumento che usi per estrarre i prezzi dei prodotti da un sito concorrente; è quello che i team enterprise search usano quando costruiscono il layer di crawl dietro un indice di ricerca.
- Licenza: Apache-2.0
- Salute GitHub: solo 3.276 stelle, ma push recente ad agosto 2026 — il basso numero di stelle riflette una nicchia specialistica, non disinteresse
- Gestione JS: richiede il plugin separato
protocol-selenium; un ticket JIRA documenta un guasto del proxy HTTPS proprio in quel percorso plugin
Ideale per: team che già gestiscono infrastrutture Java/Hadoop e hanno bisogno di indicizzazione web a livello enterprise, non di estrazione dati ad hoc.
Il miglior browser extension no-code open source: Web Scraper
Web Scraper è l’opzione point-and-click — un costruttore di sitemap e alberi di selettori che vive dentro Chrome DevTools. Segue la paginazione, clicca pulsanti, scorre pagine a caricamento infinito ed esporta localmente in CSV/XLSX, tutto senza una riga di codice.
Qui lo split open-core conta più che quasi ovunque in questa lista. L’estrazione locale è davvero gratuita. Ma automazione pianificata, esecuzione cloud, accesso API e gestione proxy stanno dietro Web Scraper Cloud, un prodotto a pagamento separato. E, come già notato, il repository sorgente LGPL-3.0 disponibile pubblicamente non riceve un commit di codice dal 2017 — quindi "open source" descrive la discendenza storica dell’estensione locale, non garantisce cosa stia girando nella build attuale del Chrome Web Store.
Ideale per: persone singole o piccoli team che fanno estrazioni occasionali in locale, senza scrivere codice e senza bisogno di scalabilità.
Parser statici vs. browser headless: scegliere lo strumento giusto per siti molto dinamici
Ecco un dato utile da mettere a terra: il 98,9% dei siti usa JavaScript come linguaggio lato client. Ma questo numero viene citato in modo fuorviante come "il 98,9% dei siti richiede un browser headless per essere estratto" — e non è ciò che dice. Misura la presenza di JavaScript, non se i dati che ti interessano siano nell’HTML iniziale o appaiano solo dopo l’esecuzione degli script.
Questa è la vera discriminante. Dividi i 12 strumenti in due gruppi onesti:
Parser statici — BeautifulSoup, AutoScraper — sono veloci, economici e completamente ciechi a tutto ciò che viene renderizzato lato client. Se i dati che vuoi sono nell’HTML iniziale o in un endpoint JSON richiamabile direttamente, vincono sempre per velocità e semplicità.
Framework con browser headless — Playwright, Puppeteer, Selenium, i crawler browser di Crawlee — eseguono davvero JavaScript, quindi consumano compute reale. I dati dell’HTTP Archive 2024 indicano che il payload JavaScript mediano di una pagina è 558 KB su mobile con 22 richieste JS separate — è questo il carico che un browser headless deve elaborare ad ogni caricamento di pagina, rispetto a un parser statico che prende semplicemente l’HTML grezzo.
E Scrapy resta in una posizione intermedia da ribadire ancora una volta: non è né l’uno né l’altro. È un framework di crawling completo senza rendering nativo, che richiede scrapy-playwright se ti serve il JS.
Il costo nascosto del "gratis": proxy, compute e ore di manutenzione
Un costo di licenza pari a zero è solo una voce dell’equazione, non l’equazione intera. Io suddividerei il costo reale in alcune categorie concrete:
Compute. Eseguire browser headless su larga scala significa pagare i browser-secondi, non solo il tempo macchina. AWS Fargate fattura circa $0,000011244 per vCPU-second e $0,000001235 per GB-second su Linux/x86 — moltiplica questo per il numero di istanze Playwright concorrenti che stai usando, e il conto sale più in fretta di quanto ci si aspetti.
Proxy. Le tariffe pubblicate da Bright Data mostravano proxy residenziali da circa $5/GB e proxy datacenter da $0,9/IP — e in questi modelli il concetto di "bandwidth" include sia il payload delle richieste sia quello delle risposte, non solo ciò che scarichi. È la voce che sorprende i team: evitare rate limit e blocchi non è gratis, è una riga ricorrente del budget infrastrutturale.
Manutenzione. Ogni parser statico e ogni strumento basato su regole strutturali in questa lista è vulnerabile ai redesign dei siti che rompono i selettori. L’esempio nel README di AutoScraper ha persino richiesto un aggiornamento del prezzo dopo che il sito target è cambiato. Questa è la categoria "costo nascosto di compute/proxy" che un’etichetta di licenza a $0 non menziona mai: le ore di ingegneria spese a riparare estrazioni rotte dopo che il team del sito target ha pubblicato un redesign.
Per i team che continuano a sbatterci contro — rottura continua dei selettori, gestione degli account proxy, overhead DevOps che non finisce mai — uno stack open source self-hosted non è automaticamente l’opzione più economica quando si contano le ore degli ingegneri. L’estensione Chrome di Thunderbit propone un approccio diverso per chi non sviluppa: puntala su una pagina autorizzata, clicca One Click Extract e analizza la pagina per capire cosa estrarre — niente selettori, niente script di manutenzione quando il layout cambia. Non sostituisce Scrapy a livello di framework di crawl, ma è un passo sensato per un business user che sta mantenendo a mano un set fragile di regole AutoScraper.
Un framework decisionale: abbinare lo strumento giusto ai vincoli del tuo team
La maggior parte dei confronti si ferma a "il migliore per il caso d’uso X". Quella è una sola variabile. Nella pratica, i team ne gestiscono almeno quattro insieme: necessità di rendering JS × linguaggio del team × formato di output richiesto × vincolo di licenza.
| Situazione del team | Strumento/i più adatti | Perché |
|---|---|---|
| Python, HTML statico, script rapido | BeautifulSoup, AutoScraper | Niente JS, licenza MIT, setup minimo |
| Python, crawl strutturato su larga scala | Scrapy | BSD-3-Clause, pipeline integrate, scrapy-playwright solo se il JS serve davvero |
| Node/TypeScript, crawl in produzione con JS | Crawlee | Apache-2.0, supporto browser nativo integrato nel sistema di code |
| Multi-linguaggio, matrice browser ampia | Selenium | Apache-2.0, copertura più vasta di linguaggi/browser |
| Automazione moderna di SPA, cross-browser | Playwright | Apache-2.0, rendering nativo, auto-wait integrato |
| Automazione specifica per Chrome con screenshot/PDF | Puppeteer | Apache-2.0, integrazione profonda con CDP |
| Pipeline Markdown per LLM/RAG | Crawl4AI | Apache-2.0 + clausola di attribuzione; verifica con il legale se la condizione aggiuntiva è accettabile |
| Estrazione irregolare guidata dal prompt | ScrapeGraphAI | MIT, ma metti in budget il costo dei token LLM |
| Crawler self-hosted compatibile con AGPL | Firecrawl | AGPL-3.0-or-later; serve approvazione legale prima di costruirci sopra un SaaS closed-source |
| Indicizzazione enterprise in Java/Hadoop | Apache Nutch | Apache-2.0, pensato apposta per l’infrastruttura di ricerca |
| No-code, uso occasionale, non sviluppatori | Estensione Web Scraper | Gratis in locale; conviene capire lo split open-core prima di assumere trasparenza totale |
Confronta tutti e 12 gli strumenti open source per web scraping, fianco a fianco
| Strumento | Linguaggio | Licenza | Uso commerciale sicuro? | Rendering JS | Curva di apprendimento | Ideale per |
|---|---|---|---|---|---|---|
| BeautifulSoup | Python | MIT | ✅ Sì | Nessuno (serve pairing) | Bassa | Parsing di HTML statico |
| Selenium | Multi-linguaggio | Apache-2.0 | ✅ Sì | Nativo | Media | Test e scraping multi-browser/multi-linguaggio |
| Playwright | JS/TS/Python/Java/.NET | Apache-2.0 | ✅ Sì | Nativo | Media | Siti moderni molto basati su JS |
| Puppeteer | Node.js/TS | Apache-2.0 | ✅ Sì | Nativo | Media | Automazione focalizzata su Chrome |
| Crawl4AI | Python | Apache-2.0 + clausola di attribuzione | ⚠️ Da rivedere | Nativo (tramite Playwright) | Media | Pipeline Markdown per LLM/RAG |
| Firecrawl (self-hosted) | TypeScript | AGPL-3.0-or-later (core) | ⚠️ Condizionale | Nativo (tramite Playwright) | Alta (multi-servizio) | Crawling AI self-hosted, compatibile con AGPL |
| ScrapeGraphAI | Python | MIT | ✅ Sì | Nativo (tramite Playwright) | Media | Estrazione in linguaggio naturale |
| AutoScraper | Python | MIT | ✅ Sì | Nessuno | Bassa | Task statici leggeri e ripetitivi |
| Scrapy | Python | BSD-3-Clause | ✅ Sì | Serve pairing | Alta | Crawl statici su larga scala |
| Crawlee | Node.js/TS | Apache-2.0 | ✅ Sì | Nativo | Media | Crawler Node.js per produzione |
| Apache Nutch | Java | Apache-2.0 | ✅ Sì | Serve plugin | Alta | Indicizzazione enterprise per search |
| Web Scraper (extension) | N/A (no-code) | Open-core | ⚠️ Dipende dal piano | Nativo (browser live) | Bassa | Uso occasionale per non sviluppatori |
Conclusione: quale Web Scraper open source dovresti usare?
Non esiste un unico strumento "migliore": la risposta giusta dipende dai vincoli di licenza, dal linguaggio del tuo team e dal fatto che i dati target siano in HTML statico o dietro una barriera JavaScript. Scrapy vince per crawl Python su larga scala e statici. Playwright o Crawlee vincono quando il rendering JS è imprescindibile. Crawl4AI è adatto se stai alimentando una pipeline LLM, con la cautela che il file di licenza include una clausola di attribuzione extra che vale la pena leggere rapidamente. Il core self-hosted di Firecrawl è potente, ma apre una conversazione AGPL che il team legale dovrebbe affrontare, non saltare.
E se la manutenzione dei selettori e la gestione dei proxy stanno consumando più ore di ingegneria dello scraping stesso, di solito è il segnale che è ora di guardare a un’alternativa no-code come Thunderbit invece di aggiungere un altro strato allo stack OSS self-hosted.
FAQ sugli strumenti open source per web scraping
È legale usare strumenti open source di web scraping per raccogliere dati aziendali?
In generale, estrarre dati pubblicamente accessibili comporta meno rischio che farlo dietro login o paywall, ma non è automaticamente legale in ogni caso. Controlla sempre i termini di servizio del sito target e il file robots.txt — tenendo presente che robots.txt è un protocollo di richiesta, non un meccanismo di autorizzazione, quindi seguirlo è una buona pratica ma non costituisce di per sé un permesso legale. Anche le leggi sulla privacy dei dati, come il GDPR, si applicano indipendentemente dal fatto che i dati siano visibili pubblicamente. Non è consulenza legale — per tutto ciò che va oltre un uso casuale e a basso volume, consulta un legale.
"Open source" significa che uno strumento è gratuito per uso commerciale?
Sì, nel senso che la Open Source Definition vieta licenze che discriminino l’uso commerciale. Ma "utilizzabile commercialmente" e "senza obblighi" sono due cose diverse — AGPL-3.0 (usata dal core self-hosted di Firecrawl) consente l’uso commerciale ma richiede comunque di offrire il codice corrispondente per le versioni modificate esposte in rete. MIT, BSD e Apache-2.0 non impongono questo vincolo.
Qual è la differenza tra uno scraper open source e uno strumento di scraping no-code?
Gli scraper open source come Scrapy, Playwright o BeautifulSoup richiedono di scrivere codice, gestire l’infrastruttura e occuparti della logica di crawl, dei proxy e degli export. Gli strumenti no-code come l’estensione Chrome Web Scraper o l’estensione browser di Thunderbit gestiscono il rilevamento dei campi e l’estrazione tramite interfaccia visuale o analisi della pagina guidata dall’AI, sacrificando un po’ di flessibilità in cambio di una barriera d’ingresso molto più bassa.
Qual è il miglior scraper open source per chi non sa programmare?
Quasi tutti gli strumenti in questa lista — Scrapy, Playwright, Puppeteer, Crawlee e gli altri — presuppongono la capacità di scrivere codice. Per utenti non tecnici, l’estensione Chrome Web Scraper offre configurazione point-and-click, anche se le funzioni di scheduling e cloud sono a pagamento. Uno strumento no-code agentico come l’estensione browser di Thunderbit è un punto di partenza più pratico se vuoi il rilevamento automatico dei campi senza toccare selettori.
Perché Scrapy ha bisogno di un plugin separato per renderizzare JavaScript?
Scrapy è stato progettato come framework HTTP-first: invia richieste e analizza l’HTML che riceve, senza eseguire script lato client. Questa architettura lo rende veloce e leggero per i crawl di siti statici, ma significa che i contenuti resi via JavaScript non sono presenti nella risposta che Scrapy riceve. scrapy-playwright colma questa distanza instradando richieste specifiche attraverso una vera istanza browser Playwright quando il rendering è inevitabile.
Scopri di più
- 15 migliori progetti GitHub per web scraping nel 2026, più la migliore alternativa no-code
- Crawl4AI usa un browser reale per creare Markdown — e no, non ti sistema i selettori
- Ho testato Playwright e Puppeteer con gli stessi casi di scraping
- I 10 migliori web scraper no-code per soluzioni automatizzate
- Lo scraping web è illegale? Capire le implicazioni legali
