Web scraping che continua a funzionare quando il sito cambia
Estraiamo dati da siti che non ti danno un'API: agende, cataloghi, prezzi, annunci, bollettini. Ogni fonte con la strategia di cui ha bisogno, un test che la chiama davvero ogni pochi giorni e un alert il giorno in cui cambia design, prima che qualcuno si accorga che manca un dato.
Il web scraping è l'estrazione automatizzata di dati pubblicati su siti che non offrono né un'API né un file da scaricare. In Soamee costruiamo scraper su misura in Node.js e TypeScript: per ogni fonte scegliamo tra la sua API interna, il suo feed RSS, l'HTML restituito dal server o un browser headless con Playwright, e facciamo passare tutti i risultati dallo stesso normalizzatore, così arrivano nel tuo database con un formato comune e senza duplicati. Quando un sito blocca le richieste automatiche (403, CAPTCHA, blocchi per IP) integriamo Bright Data: Web Unlocker, Scraping Browser o proxy residenziali. Ogni fonte ha un test contro il sito reale che gira ogni pochi giorni e un alert via email con la diagnosi quando fallisce.
Dall'inventario delle fonti al dato pulito nel tuo database
Uno scraper che funziona oggi si scrive in un pomeriggio. Il lavoro sta nel farlo funzionare ancora tra sei mesi, con trenta fonti che cambiano ognuna al proprio ritmo.
Inventario e fattibilità per fonte
Prima di scrivere codice analizziamo ogni sito: se ha un'API pubblica o interna, se è un WordPress con /wp-json aperto, se carica i dati via XHR, cosa dice il suo robots.txt e se blocca le richieste automatiche. Ne esce una scheda per fonte con strategia, rischi e frequenza.
Una strategia per tipo di fonte
API, RSS, HTML statico o browser headless dietro un'unica interfaccia. Aggiungere una fonte di solito significa scriverne la configurazione (URL, selettori, mappatura dei campi) e il test, senza programmare uno scraper da zero.
Normalizzazione e deduplicazione
Date in spagnolo come «del 10 al 28 de junio», prezzi scritti come testo, HTML incorporato, la stessa categoria con cinque nomi diversi. Tutto passa da un normalizzatore e viene salvato con una chiave univoca per fonte e identificativo esterno, quindi rieseguire aggiorna invece di duplicare.
Siti con protezione anti-bot
Per le fonti che restituiscono 403 o CAPTCHA integriamo Bright Data: Web Unlocker per le richieste HTTP, Scraping Browser per le pagine che richiedono JavaScript e proxy residenziali quando il problema è l'IP. Solo su quelle fonti; le altre escono dirette e non consumano sblocco.
Code, retry e pianificazione
Ogni fonte è un job in una coda BullMQ su Redis, con la sua frequenza, tre retry con attesa esponenziale e un registro per esecuzione: quanti elementi ha trovato, quanti erano nuovi e quanto ci ha messo.
Smoke test e alert
Un test per fonte che chiama il sito reale ogni tre giorni in CI, più test unitari su una copia salvata della risposta. Se un'esecuzione fallisce, arriva un'email con il codice HTTP, un frammento della risposta e cosa controllare per primo.
Quattro strategie, dalla più stabile alla più fragile
Usiamo la prima della lista che la fonte consente. Ogni gradino verso il basso costa velocità e stabilità, quindi scendiamo solo quando la fonte ci obbliga.
| Strategia | Quando la usiamo | Costo | Cosa si rompe |
|---|---|---|---|
| API pubblica o interna | Il sito carica i dati da un JSON: portali open data, WordPress con REST API, plugin per eventi, endpoint visibili nella scheda Network | ~200 ms per richiesta | Cambi di schema, poco frequenti |
| RSS / Atom | La fonte pubblica un feed e bastano titolo, link e riassunto | ~200 ms per feed | La data del feed è quella di pubblicazione, non quella dell'evento né dell'offerta |
| HTML statico | Il contenuto arriva nell'HTML restituito dal server | Una richiesta per elenco, più una per scheda se manca qualche campo | I selettori CSS, a ogni redesign |
| Browser headless | Contenuto renderizzato con JavaScript, scroll infinito, pulsanti «carica altro» o blocco dei client HTTP | 3-5 s per pagina e 100-200 MB di RAM per browser | Tempi di attesa e il binario del browser in ogni ambiente |
Cosa abbiamo in funzione
Numeri di una piattaforma di aggregazione che manteniamo, con fonti pubbliche molto diverse tra loro: portali open data, WordPress, Drupal, siti in React e pagine fatte a mano.
fonti, ognuna con il suo smoke test contro il sito reale
strategie di estrazione dietro un'unica interfaccia
tra un passaggio e l'altro degli smoke test in CI
retry con attesa esponenziale prima di dare un'esecuzione per fallita
Il guasto più frequente è un redesign della fonte. Lo smoke test lo rileva al massimo in tre giorni. Per i siti che bloccano le richieste automatiche lavoriamo con Bright Data.
Integrazione con Bright Data →Dalla lista di URL al primo dato nel tuo database
Prima una fonte per tipo, così i problemi reali emergono subito. Poi il resto, a blocchi.
Scheda per fonte
Analizziamo ogni sito, scegliamo la strategia e annotiamo le stranezze: formati di data, paginazione, blocchi, campi presenti solo nella pagina di dettaglio.
Pilota per strategia
Implementiamo una fonte per tipo con il suo test unitario, il suo smoke test e il suo documento. Lì saltano fuori i problemi che l'inventario non vede.
Resto delle fonti
Con il modello validato, ogni nuova fonte di solito è configurazione più un test. Quelle che richiedono browser o sblocco vanno in un blocco a parte.
Operatività
Pianificazione, alert, report delle esecuzioni e manutenzione quando una fonte cambia. Se preferisci gestirlo con il tuo team, te lo lasciamo documentato fonte per fonte.
Domande frequenti sul web scraping
Il web scraping è legale in Italia e nell'UE? +
Estrarre dati pubblicati senza restrizioni di accesso è una pratica comune, ma ci sono tre limiti che verifichiamo per ogni fonte: i termini d'uso del sito, il diritto sui generis sulle banche dati (non si può estrarre una parte sostanziale di una banca dati altrui per riutilizzarla) e il GDPR quando ci sono dati personali. Non entriamo in aree protette da login senza il permesso del titolare. Se il caso è dubbio, consigliamo una verifica legale prima di iniziare.
Cosa succede quando il sito cambia design? +
Lo smoke test di quella fonte fallisce al passaggio successivo, al massimo dopo tre giorni, e arriva un alert con l'errore. Le fonti via API o RSS non risentono quasi mai dei redesign. Per quelle in HTML o con browser headless di solito basta aggiornare i selettori nella configurazione della fonte, senza deployare codice.
Quando serve Bright Data? +
Quando il sito restituisce 403 a qualsiasi client automatizzato, mostra CAPTCHA o blocca per IP. Lì un browser headless proprio non basta, perché il blocco dipende dall'IP e dall'impronta del browser. Lo attiviamo solo sulle fonti che ne hanno bisogno; le altre continuano a uscire dirette.
Ogni quanto si aggiornano i dati? +
Ogni fonte ha la sua frequenza: ogni ora per prezzi o disponibilità, una volta al giorno per agende o cataloghi che cambiano poco. È anche una questione di cortesia verso il sito di origine: chiedere ogni cinque minuti qualcosa che cambia una volta al giorno genera solo carico.
In che formato ricevo i dati? +
Nel tuo database, di solito PostgreSQL, con uno schema comune a tutte le fonti, oppure tramite un'API REST. Possiamo anche generare esportazioni CSV o JSON periodiche o inviare le modifiche via webhook.
Posso usare i dati per alimentare un modello di IA? +
Sì, ed è uno degli usi più comuni: i dati normalizzati fanno da base per un motore di ricerca semantico, un RAG o un agente. Valgono gli stessi limiti legali di qualsiasi altro uso, e salviamo l'URL e la data di origine di ogni record per poter citare la fonte.
Potrebbe interessarti anche
Mandaci la lista delle fonti
Mandaci gli URL da cui ti servono dati e i campi che ti interessano. Ti restituiamo una scheda per fonte con la strategia, i rischi e la frequenza che consigliamo.
Dicci di quali fonti hai bisognoRaccontaci la tua sfida. Ti proponiamo la soluzione.
Senza impegno. In meno di 24 ore riceverai una proposta con ambito, tempistiche e budget. Nessuna clausola nascosta.