Il web nel 2026 è ancora pieno di dati preziosi, ma la maggior parte dei team non ha bisogno di “uno scraper” in senso astratto. Ha bisogno di una risposta concreta a una di queste tre domande: quale progetto open source vale ancora la pena adottare, quale stack regge i siti moderni ricchi di JavaScript e se una persona non tecnica dovrebbe saltare del tutto GitHub e usare invece un flusso di lavoro no-code.
Questo aggiornamento segue proprio questo percorso decisionale. Ho ricontrollato le pagine pubbliche dei repository GitHub, il numero di star e l’attività dei feed di commit il 6 agosto 2026, poi ho confrontato i progetti qui sotto in base a complessità di configurazione, supporto JavaScript, segnali di manutenzione, facilità di esportazione e aderenza al tipo di utente.
Risposta rapida
- Scegli Scrapy se vuoi il framework Python più maturo per crawling strutturato su larga scala.
- Scegli Crawlee se il tuo team lavora in JavaScript o TypeScript e vuole un unico stack per scraping HTTP e browser-based.
- Scegli Playwright o Puppeteer se il sito è molto pesante lato JavaScript e la vera esigenza è l’automazione del browser.
- Scegli Maxun se vuoi uno strato no-code open source, visuale e autogestibile invece di scrivere codice da zero.
- Scegli Heritrix, Apache Nutch o Katana solo se il tuo lavoro è davvero specialistico: archiviazione, crawling distribuito o ricognizione di sicurezza.
- Scegli Thunderbit se non vuoi affatto costruire su GitHub e ti servono subito dati in Sheets, Airtable, Notion, CSV o JSON.
Prova uno scraper no-code prima di impegnarti in uno stack di codice
Confronto rapido
Le stelle GitHub e i segnali dell’ultimo commit riportati sotto sono stati verificati sulle pagine pubbliche dei repository e sui feed di commit il 6 agosto 2026.
| Progetto | Linguaggio / Modello | Configurazione | Supporto JS | Caso ideale | Star GitHub | Segnale ultimo commit |
|---|---|---|---|---|---|---|
| Scrapy | Framework Python | Media | Nessun JS nativo | Spider su larga scala, ecommerce, notizie | 63.7k | 6 agosto 2026 |
| Crawlee | Framework Node.js / TypeScript | Media | Sì | Scraping statico + dinamico in un unico stack | 25.2k | 6 agosto 2026 |
| Maxun | Piattaforma no-code open source | Deploy medio, uso semplice | Sì | Business user che vogliono comunque controllo open source | 17.1k | 5 agosto 2026 |
| MechanicalSoup | Libreria Python | Facile | No | Form, sessioni e siti statici semplici | 4.9k | 4 agosto 2026 |
| Node Crawler | Crawler Node.js | Media | No | Crawling statico veloce e aggregazione feed | 6.8k | 18 giugno 2026 |
| Heritrix | Crawler archivistico Java | Avanzata | No | Archiviazione web e acquisizione su scala dominio | 3.3k | 5 agosto 2026 |
| Apache Nutch | Crawler distribuito Java | Avanzata | No | Crawling stile motore di ricerca e big data | 3.3k | 5 agosto 2026 |
| Selenium | Automazione browser multi-linguaggio | Media | Sì | Flussi molto interattivi e fedeltà del browser | 34.3k | 6 agosto 2026 |
| Playwright | Automazione browser multi-linguaggio | Media | Sì | Siti dinamici moderni e scripting robusto | 94.1k | 6 agosto 2026 |
| Puppeteer | Automazione browser Node.js | Media | Sì | Automazione e scraping orientati a Chrome | 95.4k | 6 agosto 2026 |
| Scrapling | Toolkit Python per scraping stealth | Media | Sì | Scraping browser sensibile agli anti-bot | 72.8k | 30 luglio 2026 |
| Katana | Crawler / CLI Go | Media | Headless opzionale | Crawling per sicurezza e scoperta URL | 17.3k | 5 agosto 2026 |
| Colly | Framework Go | Media | No | Scraping statico ad alte prestazioni | 25.4k | 18 giugno 2026 |
| WebMagic | Framework Java | Media | Nessun JS nativo | Pipeline di scraping Java generiche | 11.7k | 20 dicembre 2025 |
| Nokogiri | Parser Ruby | Facile | No | App Ruby e flussi di parsing personalizzati | 6.3k | 3 agosto 2026 |
| Thunderbit | Estensione Chrome no-code con AI | Pronta all’uso | Sì | Team non tecnici che vogliono dati utili in fretta | N/D | Prodotto gestito, aggiornato continuamente |
Prima di scegliere un progetto GitHub, chiediti se vuoi davvero un flusso basato sul codice
Thunderbit non è un progetto GitHub, ed è esattamente per questo che merita di stare in questa guida decisionale. Una grande parte di chi cerca i “migliori progetti GitHub per il web scraping” in realtà non vuole mantenere uno stack di crawler. Vuole ottenere oggi dati strutturati da un sito vivo.
Thunderbit è la via più semplice per passare dalla ricerca sullo scraping basato su codice all’esecuzione pronta per il business:
- Ideale per: prospecting commerciale, monitoraggio ecommerce, raccolta dati immobiliari, ricerche per recruiting e attività operative browser-first.
- Perché si distingue: suggerimento dei campi con AI, arricchimento delle sottopagine, gestione delle pagine dinamiche ed esportazione in Sheets, Airtable, Notion, CSV e JSON senza scrivere logica di scraping.
- Attenzione: se devi costruire una piattaforma di crawling interna di lunga durata con infrastruttura personalizzata, un framework open source ti darà comunque più controllo.
Se vuoi vedere il percorso no-code prima di decidere di vivere dentro GitHub, questa demo attuale di Thunderbit è il controllo della realtà più veloce:
Prova gratis Thunderbit AI Web Scraper
Come ho valutato questi progetti GitHub per lo scraping
Non tutti i progetti GitHub per lo scraping sono confrontabili. Alcuni sono framework completi. Alcuni sono librerie per l’automazione del browser. Alcuni sono parser. Alcuni sono crawler di nicchia costruiti per archivi o team di sicurezza.
Per rendere l’elenco davvero utile, ho dato priorità ai progetti che rispettano ancora quattro filtri pratici:
- Hanno ancora una reale trazione di mercato.
Le star alte da sole non bastano, ma una bassa adozione insieme a una manutenzione ferma di solito è un brutto segnale. - Mostrano ancora movimento del progetto.
Per questo aggiornamento ho ricontrollato l’attività dei feed pubblici di commit il 6 agosto 2026 invece di fidarmi di vecchi numeri da raccolta. - Risolvono un vero lavoro di scraping.
Ho escluso repository interessanti ma troppo di nicchia che non si adattano bene ai flussi di lavoro reali di business o ricerca. - Sono abbastanza diversi da meritare una shortlist.
L’obiettivo non è elencare 50 repository. È aiutarti a decidere tra framework, stack browser, tool open source no-code e crawler specialistici.
Le dimensioni del confronto sono le stesse che di solito determinano successo o fallimento nella pratica:
- Complessità di configurazione: quanto velocemente un nuovo utente arriva a uno scraping funzionante.
- Supporto JavaScript: se il progetto riesce a gestire siti moderni renderizzati lato client.
- Salute del progetto: se il repository sembra ancora vivo abbastanza da meritare fiducia.
- Gestione dei dati: se il progetto produce output strutturato o lascia a te gran parte del lavoro.
- Adattamento al pubblico: se il progetto è davvero pensato per principianti, data engineer, team di sicurezza o operatori non tecnici.
Complessità di configurazione: quanto velocemente puoi iniziare?
Questa classificazione continua a funzionare, ma nel 2026 il modo più utile di leggerla è più semplice:
- Pronto all’uso: Thunderbit per gli utenti business; MechanicalSoup o Nokogiri per script leggeri orientati al codice.
- Media: Scrapy, Crawlee, Maxun, Selenium, Playwright, Puppeteer, Colly, Katana, Scrapling, WebMagic e Node Crawler richiedono un po’ di codice, CLI o lavoro di deploy.
- Avanzata: Heritrix e Apache Nutch hanno senso solo se ti serve davvero crawling archivistico o distribuito basato su Java.
Maxun merita una menzione speciale perché sta a metà strada. La piattaforma in sé va distribuita, ma l’esperienza per l’utente finale è molto più semplice rispetto al lavoro diretto con Scrapy o Playwright.
Supporto ai contenuti dinamici: quali progetti reggono il web moderno?
I siti moderni sono pieni di React, Vue, infinite scroll, chiamate API in background e flussi con login pesante. È qui che si divide il confine tra “ho ottenuto l’HTML” e “ho ottenuto i dati che mi servivano davvero”.
I progetti in questa lista rientrano in tre gruppi:
- Automazione browser completa: Selenium, Playwright e Puppeteer eseguono JavaScript in modo completo e restano le scelte più affidabili per siti ricchi di interazioni.
- Supporto ibrido o wrapper: Crawlee può passare dal crawling HTTP leggero allo scraping con browser. Scrapling aggiunge strumenti orientati allo stealth per target più difficili. Maxun usa un approccio browser-backed dietro un’interfaccia visuale.
- Solo HTML statico per impostazione predefinita: Scrapy, MechanicalSoup, Node Crawler, Colly, WebMagic, Nokogiri, Heritrix e Apache Nutch non risolvono nativamente da soli i problemi di rendering moderno.
Se il tuo dubbio principale è “questo stack gestisce pagine pesanti di JavaScript senza che io debba riscrivere a mano ogni passaggio del browser?”, questo tutorial aggiornato su Playwright è il miglior controllo della realtà a metà articolo:
Salute del progetto: quali repository sembrano ancora affidabili nel 2026?
La versione 2025 di questo articolo si basava sul numero di star e su alcune note di aggiornamento datate. Oggi non basta più. Ho verificato sia gli attuali numeri di star sia i segnali di commit recenti il 6 agosto 2026.
La distinzione sana appare così:
- Chiaramente attivi in questo momento: Scrapy, Crawlee, Maxun, MechanicalSoup, Heritrix, Apache Nutch, Selenium, Playwright, Puppeteer, Scrapling, Katana e Nokogiri hanno tutti pubblicato commit nei due settimane precedenti a questa verifica.
- Vivi ma meno veloci negli aggiornamenti: Colly e Node Crawler hanno entrambi l’ultimo push il 18 giugno 2026. Restano utilizzabili, ma si aggiornano a ondate occasionali invece che con il ritmo settimanale di Playwright o Crawlee.
- Serve più cautela: WebMagic è l’unico vero punto debole in questa lista. L’ultimo segnale di commit pubblico che ho trovato è del 20 dicembre 2025, quindi lo tratterei come stabile più che come progetto in evoluzione attiva.
Questo conta perché lo stile di manutenzione dovrebbe influenzare la tua shortlist:
- Se vuoi un default sicuro per un nuovo progetto ingegneristico, privilegia i repository più visibilmente attivi.
- Se il tool è semplice e il caso d’uso è ristretto, un progetto più lento negli aggiornamenti può andare benissimo.
- Se il progetto è specialistico, giudicalo prima per aderenza al caso d’uso, non per la frequenza delle release.
I 15 migliori progetti GitHub per il web scraping nel 2026
Framework per scraping su larga scala o general purpose
1. Scrapy
Scrapy resta la risposta Python di riferimento quando il lavoro è più grande di un semplice script. Se ti servono spider, pipeline, middleware, throttling, retry ed ecosistema maturo, è ancora la scommessa open source più sicura in questa lista.
- Configurazione: Media
- Ideale per: cataloghi ecommerce, scraping di directory, crawling di news e sistemi di scraping interni di lunga durata
- Supporto JS: Nessun rendering nativo; affianca Playwright o Selenium quando serve
- Perché sceglierlo: architettura matura, documentazione solida e uno dei migliori rapporti tra potenza e community nello scraping open source
- Attenzione: la curva di apprendimento è reale se non hai mai lavorato dentro un framework di crawling
Se vuoi capire se la strada Scrapy fa per te prima di impegnarti, questa guida per principianti è ancora utile:
2. Crawlee
Crawlee è diventato la scelta più interessante in JavaScript o TypeScript quando vuoi un solo progetto capace di coprire sia crawling leggero sia scraping con browser. Il vero vantaggio è la possibilità di passare da flussi HTTP-first a flussi guidati da Playwright o Puppeteer.
- Configurazione: Media
- Ideale per: team JS e TS, target ibridi statici e dinamici, tool interni con forte automazione
- Supporto JS: Sì
- Perché sceglierlo: modello runtime flessibile, aiuti anti-blocco e un’esperienza browser più solida rispetto ai crawler più vecchi
- Attenzione: ha il massimo senso se il tuo team è già a suo agio in Node.js
3. Colly
Colly resta una delle scelte ad alte prestazioni più pulite per i team Go che non hanno bisogno del rendering browser di default. È veloce, elegante e pratico quando il collo di bottiglia è il volume e non la complessità dell’interfaccia.
- Configurazione: Media
- Ideale per: sviluppatori Go che costruiscono crawler statici veloci
- Supporto JS: Nessun rendering nativo
- Perché sceglierlo: concorrenza, rate limiting e API gradevole per lavori ad alto throughput
- Attenzione: non è la scelta giusta quando l’automazione del browser è la vera esigenza
4. WebMagic
WebMagic resta l’equivalente Java per i team che apprezzano il modello Scrapy ma vogliono rimanere nell’ecosistema JVM. Ha ancora senso per gli ambienti Java, anche se l’attenzione generale è inferiore rispetto alle opzioni Python o Node.
- Configurazione: Media
- Ideale per: pipeline di scraping basate su Java
- Supporto JS: Nessun rendering nativo
- Perché sceglierlo: scheduler, pipeline e struttura del framework semplice
- Attenzione: l’ecosistema è più silenzioso rispetto alle opzioni Python e Node più grandi, e l’ultimo segnale di commit pubblico che ho trovato è del 20 dicembre 2025, quindi consideralo stabile più che in evoluzione attiva
5. Nokogiri
Nokogiri non è un framework di crawling. È il parser a cui gli sviluppatori Ruby ricorrono ancora quando vogliono un trattamento pulito di HTML o XML dentro uno script o un flusso applicativo personalizzato.
- Configurazione: Facile
- Ideale per: app Ruby e Rails che hanno bisogno di parsing più che di un framework completo
- Supporto JS: No
- Perché sceglierlo: parsing veloce, stabile e sicuro di default
- Attenzione: devi comunque gestire tu il livello HTTP, sessione o browser
Progetti leggeri, statici e adatti ai principianti
6. Maxun
Maxun è la risposta open source per chi apprezza l’idea del no-code scraping ma vuole comunque self-hosting e controllo in stile GitHub. È molto più accessibile per i non sviluppatori rispetto a un framework puro, ma resta un progetto open source vero e proprio e non un SaaS chiuso.
- Configurazione: Media da distribuire, più semplice per l’utente finale dopo il setup
- Ideale per: team che vogliono una UI visuale con controllo open source
- Supporto JS: Sì
- Perché sceglierlo: estrazione point-and-click, flussi multi-step e accessibilità migliore rispetto allo scrivere codice da zero
- Attenzione: la fase di deploy è comunque più impegnativa di un’estensione browser completamente gestita
7. MechanicalSoup
MechanicalSoup merita ancora spazio perché non ogni scraping richiede un browser headless. Se il problema reale è la gestione delle sessioni, l’invio di form o la navigazione di un flusso statico dietro login, resta piacevolmente compatto e comprensibile.
- Configurazione: Facile
- Ideale per: form semplici, pagine statiche protette da login e script rapidi di automazione Python
- Supporto JS: No
- Perché sceglierlo: bassa frizione, codice leggibile e ingresso graduale per chi usa Python
- Attenzione: su siti molto ricchi di JavaScript smette di essere utile molto in fretta
8. Node Crawler
Node Crawler ha ancora un suo spazio se il target è HTML statico e ti interessano soprattutto concorrenza, code di lavoro e parsing stile Cheerio. Non lo sceglierei per un nuovo progetto browser-heavy, ma può ancora essere una buona soluzione per raccolta di feed e siti statici.
- Configurazione: Media
- Ideale per: crawling statico ad alta velocità e aggregazione
- Supporto JS: No
- Perché sceglierlo: controllo della concorrenza e flusso di parsing familiare, simile a jQuery
- Attenzione: l’ultimo segnale di commit pubblico che ho trovato è del 18 giugno 2026 e gli intervalli tra gli aggiornamenti sono lunghi, quindi non è da cui partirei per un nuovo stack dinamico di lunga durata
Progetti per siti dinamici e automazione browser
9. Selenium
Selenium è più vecchio di Playwright, ma conta ancora quando il comportamento esatto del browser e la fedeltà dell’interazione valgono più dell’eleganza. Resta particolarmente rilevante dove lo scraping si sovrappone a QA, automazione di regressione o siti che richiedono un comportamento browser molto letterale.
- Configurazione: Media
- Ideale per: flussi molto interattivi, automazione legacy del browser e team che già usano Selenium per i test
- Supporto JS: Sì
- Perché sceglierlo: ampia copertura dei browser, ecosistema enorme e maturità consolidata nel tempo
- Attenzione: gli stack di automazione più nuovi spesso risultano più puliti e veloci per lavori di scraping greenfield
10. Playwright
Playwright è la mia raccomandazione moderna di default per i team di sviluppo che hanno bisogno di scraping di pagine dinamiche. La combinazione di supporto multi-browser, comportamento di attesa robusto e API pulite lo rende il progetto di automazione browser più facile da consigliare in generale in questa lista.
- Configurazione: Media
- Ideale per: web app moderne, flussi con login e target ricchi di JavaScript
- Supporto JS: Sì
- Perché sceglierlo: controllo cross-browser, primitive di automazione robuste e manutenzione attiva
- Attenzione: sei comunque tu a gestire selettori, infrastruttura browser, retry e qualità dell’output
11. Puppeteer
Puppeteer resta il classico orientato a Chrome. Se il tuo team lavora già in Node.js e punta soprattutto a flussi compatibili con Chromium, resta una scelta pratica e ben compresa.
- Configurazione: Media
- Ideale per: automazione orientata a Chrome, screenshot, PDF ed estrazione di contenuti dinamici
- Supporto JS: Sì
- Perché sceglierlo: controllo ricco del browser e tantissimi esempi della community
- Attenzione: Playwright è diventato il default più forte se ti serve una copertura browser più ampia o una storia cross-browser più moderna
12. Scrapling
Scrapling è l’ingresso moderno più specializzato in questo gruppo. È pensato per chi sa già che il rendering browser non è l’unico problema. Servono anche stealth, attenzione ai proxy e una postura più forte contro i bot.
- Configurazione: Media
- Ideale per: scraping stealth, target sensibili agli anti-bot e lavoro Python-first su siti dinamici
- Supporto JS: Sì
- Perché sceglierlo: sviluppo attivo e focus più preciso sulle frizioni dello scraping che i framework più semplici ignorano
- Attenzione: è eccessivo per siti statici normali e meno adatto ai principianti rispetto a MechanicalSoup o Scrapy
Crawler specialistici per ricerca, sicurezza e infrastruttura
13. Heritrix
Heritrix non è uno scraper per il confronto di prodotti. È un crawler archivistico costruito per istituzioni che hanno a cuore la conservazione completa dei siti e l’acquisizione conforme agli standard.
- Configurazione: Avanzata
- Ideale per: archivi, biblioteche e workflow di preservazione su larga scala
- Supporto JS: No
- Perché sceglierlo: pedigree Internet Archive e workflow di archiviazione orientati a WARC
- Attenzione: strumento sbagliato per scraping mirato di elenchi o prezzi
14. Apache Nutch
Apache Nutch ha ancora senso per team che ragionano in termini di crawling distribuito, indicizzazione o raccolta dati in stile motore di ricerca, più che di scraping business una tantum.
- Configurazione: Avanzata
- Ideale per: crawling distribuito, dataset di ricerca e raccolta in stile search engine
- Supporto JS: No
- Perché sceglierlo: modello plugin e familiarità enterprise in stile Apache
- Attenzione: decisamente troppo pesante per la maggior parte dei lavori basati su fogli di calcolo o browser
15. Katana
Katana è qui perché il crawling per la sicurezza è un caso d’uso a sé. Se il lavoro è ricognizione, scoperta di endpoint o individuazione rapida della struttura di un target, Katana è molto più adatto di un framework generico per lo scraping.
- Configurazione: Media
- Ideale per: ricognizione di sicurezza, discovery di link e inventario di URL
- Supporto JS: Modalità headless opzionale
- Perché sceglierlo: velocità, concorrenza e modello di crawling orientato alla sicurezza
- Attenzione: non è pensato per essere uno stack rifinito di estrazione dati business
La mia shortlist per tipo di team
- Sviluppatori Python: inizia con Scrapy per i framework, MechanicalSoup per flussi statici più piccoli e Scrapling se stealth o anti-bot fanno già parte del problema.
- Team JavaScript o TypeScript: inizia con Crawlee per un framework, Playwright per l’automazione browser e Puppeteer se i flussi orientati a Chrome sono sufficienti.
- Team Go: Colly per lo scraping, Katana per il crawling di sicurezza focalizzato sulla discovery.
- Team Java: WebMagic per crawling generale, Heritrix per acquisizione archivistica, Apache Nutch per crawling distribuito in stile search.
- Operatori non tecnici: Maxun se vuoi self-hosting open source, oppure Thunderbit se vuoi un flusso no-code gestito che arrivi più velocemente a output utilizzabili.
Da quale progetto dovrebbe partire davvero la maggior parte delle persone?
Ecco la risposta pragmatica:
- Se vuoi costruire e possedere uno scraper, inizia con Scrapy o Crawlee.
- Se devi controllare un browser vero, inizia con Playwright.
- Se ti serve uno strato open source visuale, inizia con Maxun.
- Se hai bisogno di crawling specialistico per archivi o sicurezza, scegli Heritrix, Nutch o Katana solo perché il tuo caso d’uso lo richiede chiaramente.
- Se vuoi saltare il codice e ottenere subito i dati, non costringerti a passare prima da GitHub. Usa Thunderbit.
Considerazione finale
Il miglior progetto GitHub per il web scraping nel 2026 dipende meno dal numero di star e più dal carico che sei disposto a gestire. Scrapy resta il default più sicuro per Python. Crawlee è la migliore scelta moderna per JavaScript. Playwright è il default più forte per l’automazione browser. Maxun è il percorso no-code open source più interessante. Heritrix, Apache Nutch e Katana sono strumenti specialistici eccellenti solo quando il caso d’uso è davvero specialistico.
La cosa importante è non confondere “più potente” con “più adatto”. Se al tuo team servono solo dati puliti in un foglio di calcolo, GitHub potrebbe non essere affatto il punto di partenza giusto.
Salta il peso della manutenzione e inizia a fare scraping più velocemente Get Started Free
